You are architecting an autoscaling strategy for a latency-critical event processing application deployed on Google Kubernetes Engine (GKE) Standard. The application experiences sudden spikes in message volume from a Google Cloud Pub/Sub subscription and variable memory usage during payload deserialization. You need to scale the container replicas based on queue depth, optimize container resource sizing without metric contention, and ensure the underlying cluster infrastructure dynamically provisions compute capacity when Pods cannot be scheduled. Which autoscaling configuration should you implement?

Define explicit container CPU and memory resource requests, configure the Horizontal Pod Autoscaler (HPA) using an External metric from Pub/Sub, allow Vertical Pod Autoscaler (VPA) to adjust memory resources, and enable GKE Cluster Autoscaler on the node pools.: What Multi-Dimensional Autoscaling Alignment Is Multi-dimensional autoscaling on Google Kubernetes Engine (GKE) combines workload-level horizontal elasticity, workload-level vertical resource right-sizing, and cluster-level compute provisioning into a unified, non-conflicting scaling architecture. How it meets the requirements Workload scaling on queue depth: Configuring the Horizontal Pod Autoscaler (HPA) to consume an External metric (such as Pub/Sub undelivered message count) allows the application to proactively scale replica counts directly in response to incoming traffic demand rather than lagging behind resource saturation. Avoiding HPA and VPA contention: HPA and Vertical Pod Autoscaler (VPA) can safely operate on the same deployment only when they manage different dimensions or metrics. Assigning HPA to an external business metric while allowing VPA to optimize container memory prevents conflicting control loops. Dynamic node provisioning: Cluster Autoscaler (CA) inspects the cluster for Pending (unschedulable) Pods and adds Compute Engine VMs to the node pool when existing nodes lack allocatable capacity. Accurate scheduling decisions: Defining explicit resource requests is mandatory for CA, as it evaluates whether pending Pods will fit onto new node templates based on requested capacity rather than runtime utilization. Key advantages Prevents thrashing: Decoupling horizontal queue-based scaling from vertical memory adjustments eliminates autoscaler race conditions. Guarantees infrastructure expansion: Explicit resource requests ensure Cluster Autoscaler can simulate node placement and provision new VMs. Optimizes cloud spend: Scaling down both Pod replicas and underutilized worker nodes during off-peak periods controls cluster compute costs. Why this is optimal This design establishes a clean separation of concerns: HPA handles concurrency based on external ingress volume, VPA right-sizes container memory footprints, and GKE Cluster Autoscaler ensures underlying compute infrastructure expands dynamically without conflicting with native Compute Engine autoscalers.