Examkin

Question

Difficulty: HardManaging Google Kubernetes Engine Resources

An organization runs an enterprise e-commerce application on a Google Kubernetes Engine (GKE) Standard cluster. During sudden promotional events, several newly created pods remain indefinitely in a Pending state because existing nodes lack unallocated CPU capacity, yet the cluster fails to provision additional Compute Engine nodes. Concurrently, non-critical background batch processing workloads are consuming compute capacity on nodes reserved for core stateful API services. Which TWO management actions should a cloud engineer perform to resolve the node scaling failure and isolate the workloads? (Select TWO.)

  1. Define explicit CPU resource requests in the pod specification manifests to allow the GKE Cluster Autoscaler to identify unschedulable pods and trigger node pool expansion.Answer
  2. B
    Deploy a Horizontal Pod Autoscaler (HPA) configured to scale up the underlying Compute Engine node pool when average CPU utilization exceeds 80%.
  3. Apply node taints to a dedicated batch processing node pool and add matching tolerations to the batch workload pod specifications.Answer
  4. D
    Migrate the core stateful API services to a Spot VM node pool with node auto-repair enabled to guarantee continuous low-cost operational availability.

Answer

The cloud engineer must configure explicit CPU resource requests in the pod specifications so the Cluster Autoscaler can evaluate resource deficits, and configure taints on the dedicated batch node pool with matching tolerations on batch workload pods for workload isolation.
Specifying CPU resource requests in pod manifests provides the scheduler and GKE Cluster Autoscaler with the required metrics to detect unschedulable pods and provision new Compute Engine nodes. Applying node taints to a dedicated batch pool combined with matching pod tolerations restricts batch execution strictly to designated nodes, safeguarding stateful API service resources.

Step-by-Step Solution

1
Diagnose why GKE Cluster Autoscaler is failing to scale up node instances for pending pods.
Cluster Autoscaler evaluates pod resource requests against node capacity. Without explicit resource requests in pod specifications, Kubernetes cannot determine required capacity and marks pending pods as non-triggering for autoscaling.
Explicit container CPU requests are mandatory for the scheduler and autoscaler to calculate unallocated capacity and scale node pools automatically.
2
Implement strict workload separation between non-critical batch jobs and core stateful API services.
Tainting the batch node pool repels all pods without matching tolerations, while adding tolerations to batch pods allows them to schedule exclusively on those tainted nodes.
Taints and tolerations enforce node-level execution boundaries, preventing background jobs from competing with primary application workloads.

Key Concept

GKE Cluster Autoscaler Resource Request Requirements and Workload Isolation using Taints and Tolerations
Rate this question

Topics

Managing Google Kubernetes Engine Resources