Examkin

Question

Difficulty: HardAuto-scaling and Capacity Planning

An enterprise online gaming company is launching a global game update expected to triple active connection traffic within minutes. The telemetry ingestion pipeline runs on Google Kubernetes Engine (GKE) worker nodes and is primarily I/O-bound as it handles high-volume persistent WebSocket streams and message queues. During load testing, scaling nodes and pods based on CPU utilization failed to react quickly enough to queue backlog spikes, and sudden autoscaling attempts were rejected due to regional limits. Which TWO architectural and operational actions should a Cloud Architect recommend to ensure auto-scaling reliability and guarantee resource availability during peak launch events?

  1. Configure the Kubernetes Horizontal Pod Autoscaler (HPA) using custom Cloud Monitoring metrics based on message queue depth and incoming connection rate instead of CPU utilization.Answer
  2. B
    Configure the Horizontal Pod Autoscaler to target 85% average target CPU utilization across pods to absorb sudden network connection spikes.
  3. Submit regional Compute Engine resource quota increase requests well before launch and purchase Compute Engine capacity reservations for the required machine types.Answer
  4. D
    Rely on Google Cloud default quota auto-expansion mechanisms, which automatically increase regional core limits when cluster node pools trigger scale-up events.
  5. E
    Replace the GKE node pools with Cloud Run service revisions to automatically bypass all project-level regional CPU quotas and custom metric configurations.

Answer

The Cloud Architect should configure the Kubernetes Horizontal Pod Autoscaler using custom Cloud Monitoring metrics (such as queue depth and connection rate) and proactively request regional Compute Engine quota increases along with capacity reservations.
For I/O-bound and queue-based workloads, scaling based on CPU utilization is insufficient because memory, network sockets, or message backlogs saturate before CPU usage spikes. Using custom Cloud Monitoring metrics like queue depth or active connection rate allows the HPA to scale workloads accurately. Additionally, cluster autoscaling requires sufficient underlying Compute Engine quotas and physical compute capacity. Proactively requesting regional quota increases and securing capacity reservations ensures that GKE can successfully provision underlying VM nodes when traffic bursts occur.

Step-by-Step Solution

1
Analyze workload scaling bottlenecks
Identified that the ingestion pipeline is I/O-bound, meaning CPU utilization does not reflect true load backlog.
Scaling on CPU metrics fails for I/O-bound or messaging workloads.
2
Select appropriate autoscaling metrics
Utilize custom Cloud Monitoring metrics (queue depth / incoming connection rate) to drive pod autoscaling.
Allows proactive pod provisioning before processing latency spikes.
3
Evaluate infrastructure capacity constraints
Identify that node autoscaling requires underlying GCP compute quotas and physical instance availability.
Autoscaling attempts will fail if project quotas or zonal compute capacities are exhausted.
4
Implement capacity planning procedures
Request regional quota increases in advance and acquire Compute Engine capacity reservations for the GKE node pools.
Guarantees resource quota approval and physical compute hardware availability during peak demand.

Key Concept

I/O-Bound Custom Metric Autoscaling and Proactive Capacity Planning
Rate this question

Topics

Auto-scaling and Capacity Planning

More questions from this topic