Municipal Kubernetes services on Amazon EKS must add pods when CPU or custom metrics rise. Which scaling approach fits container orchestration performance needs?
Select an answer to reveal the explanation.
Short Explanation
K8s already knows how to grow pods when metrics climb—lean on Horizontal Pod Autoscaler–style scaling for city services on EKS. Nightly SSH, one lonely Docker host, or freezing at one replica throws away orchestrated elasticity.
Full Explanation
Containerized municipal services on Amazon EKS should scale pods when CPU or custom metrics rise using Horizontal Pod Autoscaler–style controls. HPA adjusts Deployment replicas from observed metrics so city services add capacity under load and reduce replicas when demand falls, which is the orchestration-level performance pattern Task 3.2 expects for Kubernetes on AWS. Metric-driven pod scaling keeps EKS workloads responsive without manual host surgery. Manually SSHing to nodes nightly to docker run extra containers fails because it is unscalable, bypasses Kubernetes scheduling and health controls, and cannot respond to daytime metric spikes. Replacing the cluster with a single unmanaged Docker host and no autoscaler fails conceptually by abandoning orchestration, multi-node scheduling, and automated scale. Freezing Deployment replicas at one forever to stabilize latency fails because a single replica cannot absorb load growth and usually worsens latency under concurrency rather than stabilizing it. Exam caveat: HPA scales pods; cluster node capacity may still need Cluster Autoscaler or managed node auto-scaling so pending pods can schedule, and custom metrics require Metrics Server or another metrics pipeline. Operational check: enable HPA on a representative service with CPU or custom metric targets, generate load, confirm replica counts rise and new pods become Ready, and verify node capacity expands if pods would otherwise pend.