Creating Scalable Applications with Kubernetes

📘 Chapter 2: Horizontal & Vertical Scaling in Kubernetes

🌐 Introduction

In the age of microservices and cloud-native design, the ability to scale efficiently is fundamental to application success. Kubernetes provides robust, built-in mechanisms to automatically adjust workloads based on demand.

This chapter focuses on two critical methods:

• Horizontal Pod Autoscaling (HPA) – scaling out by adding/removing pods
• Vertical Pod Autoscaling (VPA) – scaling up/down by changing pod resources

We'll walk through when to use each, how to configure them, and common pitfalls with real-world code and examples.

🧱 Section 1: Understanding the Difference

🛠️ Section 2: Horizontal Pod Autoscaling (HPA)

HPA automatically adjusts the number of replicas in a deployment or replicaset based on CPU, memory, or custom metrics.

🔧 Prerequisites

• Kubernetes version ≥1.6
• Metrics Server installed in the cluster
• Pods must define resources.requests.cpu

✅ Step-by-Step HPA Example (CPU-Based)

Step 1: Deploy a Sample Application

bash

kubectl create deployment php-apache --image=k8s.gcr.io/hpa-example

kubectl expose deployment php-apache --port=80 --type=LoadBalancer

Step 2: Apply CPU Resource Requests

bash

kubectl patch deployment php-apache \

  --patch '{"spec": {"template": {"spec": {"containers": [{"name": "php-apache", "resources": {"requests": {"cpu": "200m"}}}]}}}}'

Step 3: Create HPA Resource

bash

kubectl autoscale deployment php-apache \

  --cpu-percent=50 \

  --min=1 \

  --max=10

Step 4: Load Test & Monitor

bash

kubectl run -i --tty load-generator --image=busybox /bin/sh

# Inside busybox:

while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

Use:

bash

kubectl get hpa

kubectl get pods -w

📊 HPA YAML Example

yaml

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: php-apache

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: php-apache

  minReplicas: 2

  maxReplicas: 10

  metrics:

    - type: Resource

      resource:

        name: cpu

        target:

          type: Utilization

          averageUtilization: 50

🧪 Section 3: Custom Metrics for HPA

You can use custom metrics like requests per second, queue length, or business KPIs.

Tools Required:

• Prometheus Adapter
• Custom Metrics API

Example Metric:

yaml

- type: Pods

  pods:

    metric:

      name: queue_messages_ready

    target:

      type: AverageValue

      averageValue: 30

🧠 Section 4: Vertical Pod Autoscaling (VPA)

VPA automatically adjusts the CPU and memory requests of containers based on usage.

🔧 VPA Modes

✅ Installing VPA

On GKE:

bash

kubectl apply -f https://github.com/kubernetes/autoscaler/releases/download/vertical-pod-autoscaler-<version>/vertical-pod-autoscaler.yaml

On other clusters, install using Helm or manifests from the VPA GitHub repo.

🛠️ VPA YAML Example

yaml

apiVersion: autoscaling.k8s.io/v1

kind: VerticalPodAutoscaler

metadata:

  name: my-app-vpa

spec:

  targetRef:

    apiVersion: "apps/v1"

    kind: Deployment

    name: my-app

  updatePolicy:

    updateMode: "Auto"

🔄 Section 5: HPA + VPA Together?

While HPA and VPA can technically co-exist (using memory vs. CPU), they can conflict. Best practices:

• Use HPA for horizontal scaling based on CPU
• Use VPA in recommendation or initial mode for startup sizing
• Avoid both managing the same resource (e.g., CPU)

🧰 Section 6: Cluster Autoscaler

If your workloads can’t schedule due to lack of node resources, Cluster Autoscaler helps by:

• Adding nodes when pending pods can't fit
• Removing underutilized nodes

It works with cloud providers like:

• AWS EKS (with ASG integration)
• GCP GKE
• Azure AKS

🧠 Best Practices Summary

✅ Summary

Scaling in Kubernetes isn’t a one-size-fits-all solution. Horizontal and vertical autoscaling offer powerful tools to respond to changing load and optimize resource usage.

Key takeaways:

• HPA scales pods based on real-time metrics like CPU
• VPA adjusts resource requests and can restart pods
• Both autoscalers can enhance performance if used wisely
• Custom metrics unlock smarter scaling logic
• Cluster autoscaler ensures infrastructure matches workload demand