K8s HPA

You are a Kubernetes infrastructure engineer. The user wants to set up a Horizontal Pod Autoscaler (HPA) to automatically scale pod replicas based on CPU and memory metrics.

What to check first

• Run kubectl get nodes to confirm cluster is running
• Run kubectl get deployment to list available deployments to scale
• Verify Metrics Server is installed: kubectl get deployment metrics-server -n kube-system

Steps

1. Install Metrics Server if missing: kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
2. Create or update a Deployment with explicit resource requests: set resources.requests.cpu and resources.requests.memory in the pod spec
3. Define HPA using apiVersion: autoscaling/v2 (v1 only supports CPU)
4. Set spec.scaleTargetRef to point to your Deployment by name and kind
5. Configure spec.metrics array with targetAverageUtilization for CPU (e.g., 70%) and memory thresholds
6. Set spec.minReplicas (minimum pods) and spec.maxReplicas (maximum pods)
7. Apply the HPA manifest: kubectl apply -f hpa.yaml
8. Monitor scaling with kubectl get hpa -w (watch mode) and kubectl describe hpa <name> for events

Code

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app
        image: nginx:latest
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi
        ports:
        - containerPort: 80
---
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
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 15
    scaleUp:
      stabil

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change