Kubernetes Pod Autoscaling: HPA, VPA, and KEDA Explained

One of Kubernetes' most powerful features is its ability to automatically scale workloads based on observed metrics. Choosing the right scaling mechanism depends on whether your bottleneck is parallelism (HPA), resource allocation (VPA), or external event queue depth (KEDA).

Horizontal Pod Autoscaler (HPA)

HPA scales the number of pod replicas based on CPU or custom metrics. When CPU utilization exceeds the target, new pods are added; when it drops, pods are removed.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mirahlabs-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mirahlabs-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65

Vertical Pod Autoscaler (VPA)

VPA adjusts the CPU and memory requests of existing pods based on historical usage. Useful for right-sizing pods that were initially over-provisioned. Note: VPA and HPA should not target the same metric simultaneously.

KEDA: Event-Driven Autoscaling

KEDA (Kubernetes Event-Driven Autoscaling) scales deployments based on external event sources: queue depth in SQS/RabbitMQ, Kafka consumer lag, Prometheus metrics, or HTTP request rate. It can scale to zero when idle, making it ideal for batch processing workloads.

triggers:
  - type: rabbitmq
    metadata:
      queueName: image-processing
      queueLength: "20"  # scale up when queue > 20 messages

Production Kubernetes Deployment and HPA Config

Here is an enterprise-grade Kubernetes YAML config defining a deployment spec with security context limits, CPU resources, and a HorizontalPodAutoscaler:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mirahlabs-app
  namespace: production
spec:
  replicas: 3
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
      containers:
      - name: web
        image: mirahlabs/web:latest
        resources:
          limits:
            cpu: "1"
            memory: 1Gi
          requests:
            cpu: 250m
            memory: 256Mi
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mirahlabs-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mirahlabs-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Cloud Infrastructure Performance Profile

Below is a comparative latency and throughput profile of this infrastructure pattern deployed under a simulated load of 10,000 concurrent requests:

US & UK DevOps Governance & Infrastructure Security

Automating infrastructure and deployment workflows must respect regional privacy laws. Under the UK GDPR and US California Consumer Privacy Act (CCPA), system administrators must ensure that data pipelines respect strict boundaries regarding where user telemetry and system logs are stored (data residency). Implementing secure deployment methods (such as the NIST Secure Software Development Framework - SSDF) ensures that pipeline secrets are securely managed in systems like HashiCorp Vault, and that container configurations undergo automated security scanning before being shipped to production environments.