Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Kubernetes autoscaling is a critical skill for 2026-era platform and site reliability engineers. As organizations move toward highly dynamic, cost-optimized cloud environments, the ability to automate resource allocation via the Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) is essential. Interviewers focus on these topics to gauge a candidate's understanding of pod lifecycle management, resource request/limit tuning, and the integration of custom metrics for complex workload scaling. Junior engineers are expected to understand basic HPA triggers based on CPU/Memory, while senior candidates must demonstrate expertise in handling scaling conflicts, implementing custom metrics adapters (e.g., Prometheus Adapter), and managing the interaction between VPA and HPA to prevent resource contention in production clusters.
In 2026, manual scaling is considered an anti-pattern. Efficient autoscaling directly impacts cloud spend and system reliability. For instance, misconfigured HPA settings often lead to 'flapping'—where pods are rapidly created and destroyed—causing excessive latency and potential service outages. A strong candidate understands that autoscaling is not just about adding replicas; it is about the interplay between application performance metrics, node availability, and resource scheduling constraints. Interviewers use this topic to test if a candidate can design systems that handle traffic spikes without human intervention. A weak answer focuses solely on CPU usage, whereas a strong answer discusses the latency of the metrics pipeline, the importance of stabilization windows, and the risks of VPA and HPA competing for the same resource metrics.
The Kubernetes autoscaling architecture relies on a control loop that continuously compares current resource usage against defined targets. The Metrics Server fetches data from Kubelets, which the HPA controller queries to calculate the desired replica count. If the target is exceeded, the HPA updates the Deployment's replica count, triggering the scheduler to place new pods.
[Kubelet] → [Metrics Server]
↓
[Custom Metrics Adapter]
↓
[HPA Controller]
↓
[Deployment Controller]
↓
[Scheduler] → [Node]Use VPA for memory and HPA for CPU, or ensure VPA is in 'Recommendation' mode while HPA handles scaling.
Trade-offs: Prevents resource contention but increases management overhead.
Expose application-level metrics (e.g., queue length) via Prometheus and configure HPA to target those specific metrics.
Trade-offs: Provides precise scaling but requires robust monitoring infrastructure.
Configure the 'behavior' field in HPA to implement a cooldown period for scaling down.
Trade-offs: Increases cost by keeping pods alive longer but prevents service flapping.
| Reliability | Use Pod Disruption Budgets to ensure availability during scaling events. |
| Scalability | Use custom metrics to scale based on actual demand rather than proxy metrics. |
| Performance | Ensure the Metrics Server is highly available and properly resourced. |
| Cost | Use VPA to identify and reduce over-provisioned resource requests. |
| Security | Restrict access to the Metrics API via RBAC. |
| Monitoring | Track 'hpa_controller_loop_duration' and 'hpa_desired_replicas'. |
HPA scales the number of pods (horizontal scaling) based on demand, while VPA adjusts the resource requests and limits of existing pods (vertical scaling). HPA is best for stateless workloads that can be replicated, whereas VPA is useful for right-sizing resource-heavy applications.
Yes, but you must be careful. If both target the same resource (e.g., CPU), they will conflict. The best practice is to use VPA for memory and HPA for CPU, or keep VPA in 'Recommendation' mode to manually apply changes.
A custom metric is any metric not provided by the default Metrics Server (CPU/Memory). Examples include request rate, queue depth, or error rates. These are typically exposed via a Prometheus Adapter to the HPA.
This is called 'flapping'. It usually happens when the stabilization window is too short or the metric being used is highly volatile. Increasing the scale-down stabilization window is the standard fix.
No. The HPA controller requires the Metrics API to function. Without the Metrics Server or a custom metrics provider, the HPA cannot retrieve the data needed to make scaling decisions.
If a pod exceeds its memory limit, it will be OOMKilled by the kernel. If it exceeds its CPU limit, it will be throttled. Autoscalers do not prevent these events; they only adjust the requests/replicas.
HPA scales pods within existing nodes. Cluster Autoscaler scales the number of nodes in the cluster when pods cannot be scheduled due to lack of resources. They work together to manage the entire cluster capacity.
Use load testing tools like 'hey' or 'k6' to simulate traffic spikes. Monitor the HPA status and the HPA controller logs to see how it reacts to the load and whether it hits the target thresholds.
It is a configuration in the HPA 'behavior' field that defines how long the controller should wait before scaling down. It prevents the system from removing pods too quickly in response to transient drops in load.
VPA requires a pod restart to apply new resource requests. This causes downtime for the pod. For stateful or non-redundant services, this can be disruptive, which is why it is often used in 'Recommendation' mode.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.