Policy
Placement Policy in the Controller is where a user indicates "intent" for where/how they wish to operate their applications. Depending on the nature of the application, they may have very different ways of tracking the Service Level Objective (SLO).
--
Drift Policy¶
Cluster or Privileged administrators can inadvertently make changes to workload manifests directly on the cluster (using KubeCTL etc.) and forget to revert this back. This can result in undesirable drift of the "state of the application" compared to "desired state".
Application owners may wish to protect themselves from this eventuality. The Controller provides a number of "drift detection" and "action" related policies for a workload.
Not Set¶
This is the default drift policy. Out of band changes made to application manifests by administrators are not detected or reported.
Detect and Notify¶
For sensitive workloads where governance and compliance may be important. Out of band changes will be detected by the Kubernetes Operator and admins notified via the Audit Logs.
Block and Notify¶
For sensitive workloads where governance and compliance may be important. Out of band changes will be blocked by the Kubernetes Operator and admins notified via the Audit Logs.
Placement Policy¶
The Controller provides several types of placement strategies for workloads.
Specific Clusters Policy¶
This policy is suited for scenarios where the customer only has a few clusters and knows the exact name of the cluster(s) they would like to deploy to.
Specific Locations Policy¶
This policy is well suited for scenarios where the customer's workload needs to deployed to multiple locations and they prefer to "abstract" themselves from the specific clusters which may come and go.
Common use cases are:
Regulatory¶
The application may need to be deployed/operated in a specific country/geography due to regulatory or compliance reasons.
Geo Targeting¶
The application may need to be deployed in specific locations to serve users in the region. The Controller automatically programs DNS to ensure that users are sent to nearest cluster.
For example, users in Australia may be steered to the cluster in Sydney, users in Japan may be steered to the cluster in Tokyo and users in South Korea may be steered to the cluster in Tokyo.
- Within your workload, click on the "placement" tab
- Select "Specific Locations" from the type dropdown
- Select the "locations" where you wish to deploy your workload.
Note
There can be multiple clusters at a given location. New clusters can be added in a given location that are now candidates for workloads at that location.
Custom Labels Policy¶
This policy is suited for scenarios where the customer would like to deploy their workload to clusters that match a specified list of "cluster labels"
