Scaling & Updates

Manual Scaling

Scale deployments with kubectl scale or by editing the replicas field. Horizontal scaling adds more pod replicas behind a service. Vertical scaling adjusts resource requests and limits per pod.

Manual scaling works for predictable traffic patterns. For variable load, use the Horizontal Pod Autoscaler to scale automatically based on metrics.

• Scale down gracefully — pods receive SIGTERM before removal
• PodDisruptionBudgets protect against too many simultaneous evictions
• Cluster Autoscaler adds nodes when pods cannot be scheduled

kubectl scale deployment web-app --replicas=5
kubectl get hpa
kubectl autoscale deployment web-app --min=2 --max=10 --cpu-percent=70

Horizontal Pod Autoscaler

HPA automatically scales replicas based on observed metrics — typically CPU and memory utilization. It requires metrics-server installed in the cluster. Custom metrics (requests per second, queue depth) require Prometheus adapter.

HPA evaluates metrics every 15 seconds by default. It scales up quickly but scales down with a cooldown period to prevent flapping.

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

Rolling Updates

Deployments update pods gradually with a rolling update strategy. maxSurge controls how many extra pods can be created during update. maxUnavailable controls how many pods can be down during update.

Set maxUnavailable: 0 for zero-downtime updates — new pods must be ready before old ones are terminated. Combine with readiness probes for safe rollouts.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0
  minReadySeconds: 10

Rollbacks

Kubernetes keeps rollout history (default 10 revisions). Roll back to a previous version with kubectl rollout undo. View history with kubectl rollout history.

Automate rollback in CI/CD: if health checks fail after deployment, automatically revert to the previous revision. This limits the impact of bad releases.

kubectl rollout history deployment/web-app
kubectl rollout undo deployment/web-app
kubectl rollout undo deployment/web-app --to-revision=3
kubectl rollout status deployment/web-app

Canary and Blue-Green Deployments

Canary deployments route a small percentage of traffic to the new version. Tools like Argo Rollouts and Flagger automate progressive delivery with metric-based promotion or rollback.

Blue-green deploys the new version alongside the old, switches traffic atomically, and keeps the old version ready for instant rollback. Both patterns reduce deployment risk compared to all-at-once updates.

# Argo Rollouts canary example
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100