Deployments

Rules

• spec.selector is immutable
• Selector must match template labels (matchLabels)

Architecture

Deployment → ReplicaSet → Pods

• Deployment manages ReplicaSets; template change → new ReplicaSet, gradual migration

Speed

kubectl create deployment d --image=nginx --dry-run=client -o yaml > d.yaml

Create / inspect

kubectl create deployment web-server --image=nginx:1.25.1 --replicas=3
kubectl get deploy,rs,po
kubectl describe deploy web-server
kubectl delete deploy web-server

Rolling updates

kubectl set image deployment app-cache memcached=memcached:1.6.10
kubectl rollout status deployment app-cache
kubectl rollout history deployment app-cache
kubectl rollout history deployment app-cache --revision=2
kubectl annotate deployment app-cache kubernetes.io/change-cause="Image updated to 1.6.10"
kubectl rollout undo deployment app-cache --to-revision=1
kubectl rollout undo deployment app-cache   # previous revision

• Default keeps 10 revisions: spec.revisionHistoryLimit
• rollout undo restores declared state only: not persistent data
• Breaking API + rolling update = two versions live: use Recreate or compatible APIs

Debug broken Deployment

kubectl get po -l app=api-server
kubectl describe po <pod>       # Events: image, probe, mount, scheduling
kubectl logs <pod>
kubectl logs <pod> --previous
kubectl get deploy api-server -o jsonpath='{.spec.template.spec.containers[0].image}'

Fast fixes:

kubectl set image deployment/api-server api-server=nginx:1.25
kubectl set resources deployment api-server \
  --requests=cpu=250m,memory=256Mi \
  --limits=cpu=500m,memory=512Mi
kubectl patch deployment api-server -p '{"spec":{"replicas":3}}'

Scaling

kubectl scale deployment app-cache --replicas=6
kubectl edit deployment app-cache   # change spec.replicas

HPA (autoscaling/v2)

kubectl autoscale deployment app-cache --cpu-percent=80 --min=3 --max=5

• Requires CPU requests on Pod template: else TARGETS shows <unknown>
• Imperative autoscale: CPU only: use YAML for memory
• Metrics server must be installed

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-cache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-cache
  minReplicas: 3
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

minReadySeconds

minReadySeconds: a Pod must remain in a Ready state (readiness probe passing continuously) for this many seconds before the rolling update counts it as available and proceeds to the next Pod.

spec:
  minReadySeconds: 60   # Pod must be Ready for 60s before next Pod is replaced
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 40%
      maxSurge: 10%

• It is about sustained readiness, not just a single probe pass
• Setting this too low risks traffic hitting Pods that aren't fully warmed up

Failures

Exam tips

• ReplicaSet name includes pod-template-hash: don't confuse with app label
• HPA needs requests, not just limits
• kubectl apply preferred for production updates; set image fastest on exam
• minReadySeconds = sustained Ready duration, not a single probe pass
• Don't recreate a broken Deployment unless required; patch/set/edit preserves ownership and rollout history
• Probe fixes often need initialDelaySeconds more than a different image