Deployments manage ReplicaSets and make stateless rollout history explicit. This lab controls surge and unavailable capacity, watches an update, detects a bad image, rolls back, and scales safely.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
kubectl create namespace rollout-lab
kubectl -n rollout-lab create deployment web --image=nginx:1.27-alpine --replicas=3
kubectl -n rollout-lab patch deployment web -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'
kubectl -n rollout-lab rollout status deployment/web
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: web, namespace: rollout-lab}
spec:
minAvailable: 2
selector: {matchLabels: {app: web}}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f pdb.yaml
kubectl -n rollout-lab set image deployment/web nginx=nginx:1.28-alpine
kubectl -n rollout-lab rollout status deployment/web --timeout=3m
kubectl -n rollout-lab rollout history deployment/web
kubectl -n rollout-lab scale deployment/web --replicas=5
kubectl -n rollout-lab get deployment,replicaset,pod
4. Troubleshooting
If rollout status times out, describe the newest ReplicaSet and Pods. A typoed image produces ImagePullBackOff; failed readiness produces unavailable replicas. Do not blindly restart until the event explains the block.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl -n rollout-lab rollout undo deployment/web
kubectl -n rollout-lab rollout status deployment/web
kubectl delete namespace rollout-lab
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
