Deployments and ReplicaSets

The standard for stateless services

A Deployment declares a pod template and a replica count. It creates a ReplicaSet, which keeps exactly that many pods running (replacing any that fail). Changing the template (a new image tag, new environment variables) makes the Deployment create a new ReplicaSet and shift pods to it gradually, keeping old ReplicaSets for rollback (kubectl rollout undo). The selector must match the template's labels; it is how the Deployment knows which pods it owns.

Commands for managing a Deployment

Common day-to-day commands; they need a cluster. Not run here.

kubectl apply -f deployment.yaml
kubectl get deploy,rs,pods -l app=web
kubectl set image deployment/web web=ghcr.io/example/web:1.5.2   # triggers a rollout
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web                                # back to the previous ReplicaSet
kubectl scale deployment/web --replicas=5

Pin image tags

Use explicit versions or digests, never latest; otherwise "what is running" is unknowable and rollbacks are unreliable.

Quick check: What does a Deployment create to manage its pods?

• A StatefulSet
• A ReplicaSet for each version of the pod template
• A new cluster
• A Service automatically