An operations engineer manages a production Google Kubernetes Engine (GKE) Standard cluster hosting a web application microservice and a background batch analytics workload. To optimize compute costs, the team provisions a new dedicated node pool configured with Spot VMs for the batch analytics workload. However, during initial testing, several web application pods are scheduled onto the Spot VM nodes and experience unexpected disruptions when nodes are reclaimed. Which configuration should the engineer implement to ensure the web application pods are never scheduled onto the Spot VM node pool?
- Apply a node taint to the Spot VM node pool and add corresponding tolerations only to the batch analytics workload Deployment manifest.Answer
- BConfigure a Horizontal Pod Autoscaler (HPA) for the web application Deployment to dynamically scale up replicas whenever Spot nodes undergo preemption.
- CEnable GKE Cluster Autoscaler on the Spot VM node pool with a minimum node count of zero so non-batch workloads are automatically filtered out.
- DMigrate the cluster to GKE Autopilot mode, which automatically prohibits standard workloads from utilizing Spot VM resources without manifest alterations.
Answer
Apply a node taint to the Spot VM node pool and configure corresponding tolerations specifically within the batch analytics workload manifest.
In Kubernetes and GKE operational management, Taints and Tolerations are used to ensure workloads are not scheduled onto inappropriate nodes. Tainting a Spot VM node pool repels all pods that do not explicitly contain a matching toleration. By defining tolerations only on the fault-tolerant batch workload, the scheduler prevents the web application pods from ever being placed on Spot VM nodes.
Step-by-Step Solution
Key Concept
Workload isolation using GKE Node Taints and Pod Tolerations for Spot VM Node Pools