Autoscaling and Resource Limits

Prerequisites: completion of Deployments, Services, and Ingress.

Version note: verified against kubernetes.io docs, July 2026. autoscaling/v2 is the current stable HPA API version, recommended for all new HPAs; autoscaling/v1 still exists but only supports CPU-based scaling, and its fields are preserved as annotations under the hood. Metrics Server is installed from its latest GitHub release manifest, which always points at the current version — verify with kubectl get deployment metrics-server -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}' after installing.

Without a resources.requests value, the scheduler has no idea how much CPU or memory a Pod actually needs and can pack too many Pods onto one node. Without a resources.limits value, a single runaway container can starve every other Pod on its node. And without both being set sensibly, autoscaling based on "percentage of CPU used" is meaningless, because that percentage is calculated against the request, not against the node's total capacity.

In this project you'll set requests/limits properly, install the Metrics Server (the component that actually measures CPU/memory usage across the cluster), and wire up a HorizontalPodAutoscaler (HPA) that watches that usage and scales your Deployment's replica count automatically.