KCNA — Autoscaling Concepts

3 minute read

Autoscaling in Kubernetes

Autoscaling is a core cloud-native capability. Kubernetes provides multiple scaling mechanisms to handle changing workloads efficiently. The KCNA exam tests your understanding of these approaches.

Types of Autoscaling

Type What It Scales Direction
HPA (Horizontal Pod Autoscaler) Number of pod replicas Adds/removes pods
VPA (Vertical Pod Autoscaler) CPU/memory requests per pod Resizes pods
Cluster Autoscaler Number of worker nodes Adds/removes nodes
KEDA (K8s Event-Driven Autoscaling) Number of pods based on external events Adds/removes pods 
                    Cluster Autoscaler
                    (Adds/removes nodes)
                           │
┌──────────────────────────┼──────────────────────────┐
│                   Kubernetes Cluster                  │
│                                                       │
│   HPA / KEDA                    VPA                   │
│   (Adds/removes pods)          (Resizes pods)         │
│                                                       │
│   ┌───┐ ┌───┐ ┌───┐           ┌───────────┐          │
│   │Pod│ │Pod│ │Pod│    ←→     │  Pod      │          │
│   └───┘ └───┘ └───┘           │ (bigger)  │          │
│   horizontal                   └───────────┘          │
│                                vertical               │
└───────────────────────────────────────────────────────┘

Horizontal Pod Autoscaler (HPA)

HPA automatically adjusts the number of pod replicas based on observed metrics.

How It Works

  1. HPA controller polls metrics every 15 seconds (default)
  2. Compares current metric value to target value
  3. Calculates desired replicas using the formula:
desiredReplicas = ceil(currentReplicas × (currentMetricValue / targetMetricValue))
  1. Scales up or down accordingly

Example

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70    # Scale when CPU > 70%

Key Points

  • Requires metrics-server to be installed in the cluster
  • Supports CPU, memory, and custom metrics
  • Has cooldown periods to prevent rapid scaling oscillation
  • Works with Deployments, ReplicaSets, and StatefulSets

Vertical Pod Autoscaler (VPA)

VPA automatically adjusts CPU and memory requests and limits for pods.

How It Works

  1. VPA monitors actual resource usage over time
  2. Recommends optimal resource requests
  3. Can automatically update pod specs (requires pod restart)

Modes

Mode Description
Off Only provides recommendations — no changes
Initial Sets resources only at pod creation
Auto Automatically updates resources (restarts pods)

Key Points

  • Cannot be used with HPA on the same metric — they would conflict
  • VPA can be used with HPA if they scale on different metrics (e.g., VPA on CPU, HPA on custom metrics)
  • Requires pod restarts to apply changes (in Auto mode)
  • Good for workloads where you don’t know optimal resource requests

Cluster Autoscaler

The Cluster Autoscaler adjusts the number of nodes in the cluster.

Scale Up

When a pod can’t be scheduled because no node has enough resources:

  1. Pod enters Pending state
  2. Cluster Autoscaler detects the pending pod
  3. Adds a new node to the cluster
  4. Pod gets scheduled on the new node

Scale Down

When a node is underutilized:

  1. Cluster Autoscaler identifies underutilized nodes
  2. Checks if all pods can be moved to other nodes
  3. Drains the node (evicts pods)
  4. Removes the node from the cluster

Key Points

  • Works with cloud provider APIs (AWS ASG, GKE node pools, Azure VMSS)
  • Respects Pod Disruption Budgets when scaling down
  • Cannot scale below the minimum node count
  • Common in managed Kubernetes (EKS, GKE, AKS)

KEDA — Kubernetes Event-Driven Autoscaling

KEDA is a CNCF Graduated project that extends HPA with event-driven scaling.

How It Works

External Event Source          KEDA              HPA              Pods
(Kafka, RabbitMQ,        ┌──────────┐      ┌─────────┐     ┌───┐┌───┐
 Azure Queue,            │  Scaler  │─────→│   HPA   │────→│Pod││Pod│
 Prometheus, etc.)       └──────────┘      └─────────┘     └───┘└───┘
                                                            Scale 0→N

Key Features

Feature Description
Scale to Zero Unlike standard HPA, KEDA can scale to zero pods
Scale from Zero Spin up pods when events arrive
50+ Scalers Support for Kafka, RabbitMQ, AWS SQS, Prometheus, Cron, etc.
HPA Extension Works alongside HPA — doesn’t replace it

Example

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0     # Scale to zero!
  maxReplicaCount: 20
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka:9092
      consumerGroup: orders
      topic: incoming-orders
      lagThreshold: "10"  # Scale when lag > 10

Scaling Comparison

Feature HPA VPA Cluster Autoscaler KEDA
Scales Pod count Pod resources Node count Pod count
Direction Horizontal Vertical Horizontal Horizontal
Metric Source CPU/memory/custom CPU/memory Pending pods External events
Scale to Zero No (min=1) No No Yes
Built-in Yes Add-on Cloud provider Add-on (CNCF)

KCNA Exam Tips

  • HPA is the most commonly tested autoscaler — know how it works and what metrics it uses
  • Know that HPA requires metrics-server
  • VPA and HPA should not be used on the same metric — they conflict
  • Cluster Autoscaler responds to pending pods, not metrics directly
  • KEDA is the event-driven option — know it can scale to zero
  • KEDA is a CNCF Graduated project

What’s Next?

Understand the CNCF organization itself — its governance model, project maturity levels, and community structure.

Next: CNCF Governance and Community →

Updated:

You may also enjoy