Kubernetes HPA, VPA, and Node Autoscaling: How They Work Together

Kubernetes has several kinds of autoscaling, but they do not all control the same resource. Understanding who controls pod replicas, resource requests, and node capacity is the key to using them together.

1. What is the Horizontal Pod Autoscaler?

The Horizontal Pod Autoscaler (HPA) adjusts the replica count of a workload such as a Deployment. It can respond to CPU or memory metrics, or to custom and external metrics when the necessary metrics APIs are available.

As demand increases, HPA can add replicas. When demand falls, it can reduce them within the configured bounds. Here is the example from the original article:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

This is an HPA definition, not a complete application manifest. The target Deployment must exist, the relevant containers need CPU requests for this utilization-based calculation, and the cluster must provide resource metrics, typically through Metrics Server. The 50% target is relative to requested CPU, not half of a node’s total CPU.

2. Other autoscalers and what they control

• Vertical Pod Autoscaler (VPA): recommends or adjusts container resource requests. Its update mode and resource policy determine how changes are applied and whether limits are adjusted alongside requests.
• Cluster Autoscaler (CA): adjusts node capacity. For example, pods that cannot be scheduled because suitable capacity is unavailable can trigger scale-out when a configured node group can accommodate them.
• EC2 Auto Scaling Group (ASG): manages the number of EC2 instances. An ASG does not, on its own, reason about Kubernetes pod scheduling requirements.

3. Can HPA and VPA run together?

Care is needed when both act on the same CPU or memory resource. A utilization-based HPA compares usage with requests. VPA can change those requests, which changes the denominator HPA uses to make its decisions.

This feedback can lead to unexpected scaling behavior. Avoid having the two controllers independently tune the same resource without a deliberate design. A VPA recommendation-only workflow, or an HPA driven by a separate demand metric, may be easier to reason about.

4. Can HPA and EC2 Auto Scaling run together?

They operate at different layers: HPA changes the number of pods, while the ASG changes the number of instances. Problems can arise if independent policies are not coordinated:

1. Mismatched signals: HPA can request more replicas while an instance-CPU policy sees no need for more nodes. Pods may remain Pending.
2. Overlapping decisions: separate pod and node policies can add more capacity than intended. This is a possibility, not an inevitable result of using both.
3. Uncoordinated scale-in: terminating a node can disrupt running pods if workload draining and disruption constraints are not handled appropriately.

5. A common operating pattern

Let HPA manage replicas and let a Kubernetes-aware node autoscaler manage node capacity. With Cluster Autoscaler on AWS, configured ASGs provide the node groups and their capacity bounds; CA coordinates capacity changes through them. Avoid a competing policy that independently changes the same group’s desired capacity.

This is a common pattern, not a guarantee that every Pending pod will be resolved. Scheduling constraints, node-group limits, quotas, and workload disruption requirements still need attention.

6. Summary

• HPA scales workload replicas.
• VPA manages resource sizing recommendations and, depending on configuration, updates.
• Cluster Autoscaler manages node capacity with awareness of Kubernetes scheduling.
• EC2 Auto Scaling provides instance-group capacity management.

English translation with clarifications about utilization, VPA behavior, and independent scaling policies; the example YAML is preserved. References: Kubernetes HPA documentation and VPA documentation.

Read the Korean original.