DEV Community

Deep Fix
Deep Fix

Posted on

Automating Kubernetes Pod Scaling Issues: Best Practices & Scripts for DevOps

#kubernetes #scaling #automation #devops

Introduction

Kubernetes makes horizontal scaling of pods easy, but hidden pitfalls often cause flaky autoscaling, over‑provisioning, or sudden outages. This guide walks you through the most common scaling issues and shows how to automate reliable fixes with native resources and a tiny Bash helper.

Common Scaling Pitfalls

  • Metrics‑Server not installed or mis‑configured – HPA cannot read CPU/memory usage.
  • Hard‑coded replica counts in Deployments that override HPA decisions.
  • Burst traffic causing rapid replica churn that exceeds the default scaling window.
  • Resource requests/limits missing – the scheduler cannot place new pods.

Step‑by‑Step Troubleshooting & Automation

1. Verify the metrics‑server 

kubectl get deployment metrics-server -n kube-system
Enter fullscreen mode Exit fullscreen mode

If the output shows Unavailable, install it:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Enter fullscreen mode Exit fullscreen mode

2. Create a robust HorizontalPodAutoscaler (HPA) 

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
Enter fullscreen mode Exit fullscreen mode

Apply it with kubectl apply -f hpa.yaml.

3. Ensure Deployments don’t lock replicas 

spec:
  replicas: 2   # <-- remove or comment this line when using HPA
Enter fullscreen mode Exit fullscreen mode

Removing the static replicas field lets the HPA control scaling.

4. Automate the sanity check with a Bash helper 

#!/usr/bin/env bash
set -e

# Usage: ./auto‑scale.sh <namespace> <deployment> [target_cpu]
NAMESPACE=${1:-default}
DEPLOYMENT=${2:?Deployment name required}
TARGET_CPU=${3:-70}

# Create HPA if it does not exist
if ! kubectl get hpa -n "$NAMESPACE" "$DEPLOYMENT" > /dev/null 2>&1; then
  echo "Creating HPA for $DEPLOYMENT…"
  kubectl autoscale deployment "$DEPLOYMENT" \
    --cpu-percent=$TARGET_CPU \
    --min=2 --max=10 -n "$NAMESPACE"
else
  echo "HPA already exists for $DEPLOYMENT. Updating target CPU to $TARGET_CPU%…"
  kubectl patch hpa "$DEPLOYMENT" -n "$NAMESPACE" --type='json' -p="[{\"op\":\"replace\",\"path\":\"/spec/metrics/0/resource/target/averageUtilization\",\"value\":$TARGET_CPU}]"
fi

# Quick health check
echo "Current replica count:"
kubectl get hpa "$DEPLOYMENT" -n "$NAMESPACE" -o jsonpath='{.status.currentReplicas}'
Enter fullscreen mode Exit fullscreen mode

Save this as auto-scale.sh, make it executable (chmod +x auto‑scale.sh), and run it whenever you spin up a new service.

Putting It All Together

  1. Deploy metrics-server.
  2. Remove static replicas from your Deployments.
  3. Apply the HPA manifest.
  4. Run the Bash helper to guarantee the HPA exists and matches your target CPU.

Natural Outbound Links

Conclusion

Automating the detection and remediation of Kubernetes pod scaling issues eliminates manual guesswork and keeps your services responsive under load. By combining native HPA definitions with a tiny Bash wrapper, you gain repeatable, version‑controlled scaling that scales with your organization.

Top comments (0)