Maintain Workload Uptime
This topic describes how you can maintain workload uptime for Kubernetes clusters deployed with Pivotal Container Service (PKS).
To maintain workload uptime, configure the following settings in your deployment manifest:
- Configure workload replicas to handle traffic during rolling upgrades.
- Define an anti-affinity rule to evenly distribute workloads across the cluster.
To increase uptime, you can also refer to the documentation for the services you run on your clusters and configure your workload based on the best practices recommended by the software vendor.
The PKS tile contains an errand that upgrades all Kubernetes clusters. Upgrades run on a single VM at a time. While one worker VM runs an upgrade, the workload on that VM goes down. The additional worker VMs continue to run replicas of your workload, maintaining the uptime of your workload.
To prevent workload downtime during a cluster upgrade, Pivotal recommends running your workload on at least three worker VMs, using multiple replicas of your workloads spread across those VMs. You must edit your manifest to define the replica set and configure an anti-affinity rule to ensure that the replicas run on separate worker nodes.
Set the number of workload replicas to handle traffic during rolling upgrades. To replicate your workload on additional worker VMs, deploy the workload using a replica set.
spec.replicas value in your deployment manifest:
kind: Deployment metadata: # ... spec: replicas: 3 template: metadata: labels: app: APP-NAME
See the following table for more information about this section of the manifest:
|Set this value to at least 3 to have at least three instances of your workload running at any time.|
|Use this app name when you define the anti-affinity rule later in the spec.|
To distribute your workload across multiple worker VMs, you must use anti-affinity rules. If you do not define an anti-affinity rule, the replicated pods can be assigned to the same worker node. See the Kubernetes documentation for more information about anti-affinity rules.
To define an anti-affinity rule, add the
spec.template.spec.affinity section to your deployment manifest:
kind: Deployment metadata: # ... spec: replicas: 3 template: metadata: labels: app: APP-NAME spec: containers: - name: MY-APP image: MY-IMAGE ports: - containerPort: 12345 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: In values: - APP-NAME topologyKey: "kubernetes.io/hostname"
See the following table for more information:
|This value matches
|This value matches the
Please send any feedback you have to email@example.com.