Day 56: Project: deploy on kind/k3d; rollout strategies
Phase 8 capstone: deploy, break, and watch it heal
Deploy the Phase 5 containerized stack (API, frontend, Postgres, Redis, RabbitMQ) onto a local Kubernetes cluster (kind or k3d), using everything from this phase: Deployments with proper probes and resource requests/limits, a StatefulSet for Postgres, ConfigMaps/Secrets for configuration, and a CronJob for a scheduled task.
Rollout strategies
The default Deployment strategy, RollingUpdate, replaces old Pods with new ones gradually, controlled by maxSurge (how many extra Pods above the desired count are allowed during rollout) and maxUnavailable (how many can be down at once) — balancing rollout speed against availability. Recreate kills all old Pods before creating new ones — simpler, but guarantees a downtime window; only appropriate when your app can't tolerate two versions running simultaneously.
kind create cluster --name devsecops
kubectl apply -f k8s/
kubectl get pods -w
# Now break it on purpose:
kubectl delete pod <api-pod-name>
# watch a replacement appear automatically
kubectl rollout undo deployment/api # practice a rollback tooChaos, on a small scale
Delete a Postgres pod (part of your StatefulSet) and confirm it comes back with the SAME identity and its data intact (the PersistentVolumeClaim followed it). Then deliberately misconfigure a readiness probe and watch the Service correctly stop routing traffic to that Pod without killing it — the exact distinction from Day 54.
Phase 8 complete — you should now be able to
You delete a Pod belonging to a StatefulSet running Postgres. What comes back, and why does this matter?
