Vanja Popovic

Kubernetes has powerful autoscaling features that ensure applications and clusters run efficiently while controlling costs. The three main autoscaling components are: Horizontal Pod Autoscaler (HPA): Scales the number of pod replicas up or down based on resource usage. Vertical Pod Autoscaler (VPA): Adjusts the resource requests/limits of containers inside pods. Cluster Autoscaler (CA): Adjusts the number of worker nodes in the cluster depending on overall resource demand. Each of them solves a different problem — but when combined, their interactions can get tricky. This TechBite explores how they complement each other, and where conflicts can appear. Horizontal Pod Autoscaler (HPA) HPA is a form of autoscaling that increases or decreases the number of pods in a replication controller, deployment, replica set, or stateful set based on CPU and/or memory usage—the scaling is horizontal because it affects the number of instances rather than the resources allocated to a single container. HPA can also make scaling decisions based on custom or externally provided metrics and works automatically after initial configuration. All you need to do is define the MIN and MAX number of replicas. Once configured, the Horizontal Pod Autoscaler controller is in charge of checking the metrics and then scaling your replicas up or down accordingly. By default, HPA checks metrics every 15 seconds. Good for stateless workloads (web servers, APIs). Vertical Pod Autoscaler (VPA) Kubernetes Vertical Pod Autoscaler (VPA) is a component you install in your cluster. It increases and decreases container CPU and memory resource configuration to align cluster resource allocation with actual usage. With VPA, there are two different types of resource configurations that we can manage on each container of a pod: Requests Limits Requests define the minimum amount of resources that containers need. For example, an application can use more than 256MB of memory, but Kubernetes will guarantee a minimum of 256MB to the container if its request is 256MB of memory. Limits define the maximum amount of resources that a given container can consume. Your application may require at least 256MB of memory, but it is advisable to limit its memory consumption to 512MB, ensuring it doesn't exceed this limit. Example: Vertical Pod Autoscaler (VPA) for memory-only tuning apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: webapp-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: webapp updatePolicy: updateMode: "Initial" # recommendations applied only on pod start resourcePolicy: containerPolicies: - containerName: "webapp" controlledResources: ["memory"] # let VPA correct memory, not CPU Cluster Autoscaler (CA) The Cluster Autoscaler automatically adds or removes nodes in a cluster based on resource requests from pods. The Cluster Autoscaler doesn’t directly measure CPU and memory usage values to make a scaling decision. Instead, by default, it checks every 10 seconds to detect any pods in a pending state, suggesting that the scheduler could not assign them to a node due to insufficient cluster capacity. In the scaling-up scenario, CA automatically kicks in when the number of pending (unschedulable) pods increases due to resource shortages and works to add additional nodes to the cluster. Additionally, when the cluster’s workload decreases and nodes become underutilized, the Cluster Autoscaler evaluates whether any nodes can be safely removed. It ensures that all pods on a candidate node can be rescheduled elsewhere before scaling the node group down. How They Work Together 1. HPA + CA: HPA creates more pods → cluster may run out of space → CA provisions more nodes. When load drops, HPA removes pods → CA may remove extra nodes. Works well if pod resource requests are correct. 2. VPA + CA: VPA increases pod resource requests → some pods may no longer fit existing nodes → CA provisions bigger/more nodes. Works well for workloads with stable but misconfigured resource requests. 3. HPA + VPA: Both can act on CPU/memory metrics. Conflict: HPA scales out because pods look overloaded, while VPA increases CPU requests, making pods look less loaded, so HPA scales in. This tug-of-war destabilizes scaling. Where They Clash HPA and VPA on the same metric (CPU/Memory): Not recommended. HPA should use CPU or custom app metrics, VPA should focus on memory. VPA eviction conflicts with HPA scaling: Pods may restart just when HPA needs more replicas. Cluster Autoscaler slow response: Pods created by HPA may stay pending while CA scales nodes. Cost inefficiency: Aggressive HPA + VPA can lead to unnecessary scaling and higher bills. Best Practices Use HPA for fast, bursty workloads (CPU or custom metrics like queue length). Use VPA in recommendation-only mode, or let it manage memory only. Use Cluster Autoscaler with multiple node pools for diverse workloads. Monitor pending pods, eviction events, and scaling latency. Document scaling strategies per workload (stateless, stateful, batch jobs). Real-Case Example Imagine a sudden traffic spike: HPA notices higher CPU and scales the deployment from 3 → 12 replicas. If those new pods can’t be scheduled because existing nodes are full, Cluster Autoscaler simulates adding capacity and requests extra nodes — that can take a few minutes.  Meanwhile, VPA analyzes steady memory usage and recommends larger requests. If you allow it to apply changes automatically, pods may be evicted and restarted, which could temporarily reduce capacity while HPA is trying to scale up.  The best outcome is when HPA handles the fast, short bursts, VPA corrects long-term sizing errors or manages memory only, and CA has node pools sized and labeled so the right type of node is added quickly.  If you mix responsibilities, you get restarts, pendings, and cost surprises, but if you separate concerns and tune behavior, you get smooth, resilient autoscaling. Conclusion HPA, VPA, and Cluster Autoscaler are not competing features—they each address a different layer of the Kubernetes scaling challenge. HPA reacts quickly to changes in demand by adjusting replica counts, VPA ensures pods are appropriately sized to use resources efficiently, and Cluster Autoscaler adapts the underlying infrastructure so that workloads have enough capacity to run. When combined, these components can create a highly flexible and resilient system. However, they must be used with care. Overlaps in responsibility, particularly between HPA and VPA on CPU or memory metrics, can lead to instability or unnecessary costs. The best practice is to assign each tool a clear role: HPA for demand-driven scaling, VPA for long-term resource right-sizing (ideally focusing on memory), and CA for expanding or shrinking the cluster as needed. With the right configuration, these tools complement each other to form a self-adjusting Kubernetes cluster that delivers both performance and cost-efficiency. "How HPA, VPA and Cluster Autoscaler Work Together in Kubernetes and Where They Clash" Tech Bite was brought to you by Vanja Popović, DevOps Engineer at Atlantbh. (more…)