Lesson 43 — Kubernetes and managed services

TicketFlow's deployment on K8s (or the argument for why not). No solutions.md before submitting.

Exercise 1 — The documented decision

1. Write the ADR (48) "TicketFlow's deployment platform": PaaS vs K8s vs compose with YOUR context (team, product, budget) — 10 lines, decision, reasons, review trigger.
2. The migration trigger: which real event (not fashion) would make you migrate to K8s? List 3 concrete triggers (strict multi-tenant? more than N services? an on-prem requirement?) and mark which is most likely in YOUR roadmap.
3. The literacy: list the 6 K8s objects TicketFlow needs (from §2-3) and for each write in one line which problem it solves. Without installing anything yet: reading is the first skill.

Exercise 2 — The local cluster

1. With kind/minikube/k3d: bring up a local cluster and deploy §2's Deployment+Service (40's image locally: kind load docker-image ticketflow:latest). Verify: kubectl get pods with 3 Ready replicas and the Service answering (port-forward or NodePort).
2. The probes in action: kill the pod's internal process (exec + kill) and watch: does liveness restart it? How long until the pod is Ready again? Document the resurrection cycle.
3. Readiness vs liveness: freeze the DB (40's compose without PG) and watch the contrast: which probe marks it and what does the Service do with that pod? (the pod leaves the load balancing WITHOUT restarting: §2's key difference).

Exercise 3 — The HPA and the CronJob

1. Deploy §3's HPA and generate load with k6 (36): how many pods at the peak? How long does the scale-out take (the HPA's window is ~15-30 s: 36's 400-VU peak notices)? Document the finding.
2. The arithmetic's limit: with HPA maxReplicas=10 and 39's pool (max_size 10): how many connections does the cluster demand from managed? Does it fit the tier's max_connections? Tune: a smaller pool, a lower maxReplicas, or PgBouncer (42)?
3. The CronJob: deploy expirar-reservas every minute and verify: the CronJob's pods run and finish (the job's log), and TWO overlapping runs don't step on each other (31's lock in action — run 2 jobs by hand with kubectl create job --from).

Exercise 4 — The DB outside the cluster

1. The forbidden experiment (on the local cluster, NEVER in prod): deploy Postgres as a Deployment with emptyDir (no PV): kill the pod and bring it back: where is your data? Document the finding as a warning.
2. The PV version (StatefulSet + PersistentVolume on the local cluster): kill the pod: do the data survive? Even so, list §4's 3 reasons this does NOT go to prod (the failover? the backups? the node drain?).
3. Connecting to managed: configure the cluster's app (local) to talk to 40's compose PG via IP/external service. 39's arithmetic with HPA: paste the final connections table (pods × pool + worker + beat).

Exercise 5 — The full deployment

1. The rolling update: change the Deployment's image to a new version (different tag) and watch kubectl rollout status: how many old pods coexist with the new? Does readiness decide the cutover? Time the total rollout.
2. The rollout undo: break the new version (a failing healthcheck) and run kubectl rollout undo: how long did the rollback take and how many 5xx requests happened during the bad rollout? (K8s's readiness vs 41's blue-green: who protects the user better?).
3. The manifest in the repo (44 formalizes it): create deploy/k8s/ with the exercise's YAML (Deployment, Service, HPA, CronJob, ConfigMap) and the deployment command in the directory's README. The principle: the YAMLs get reviewed in PRs like code.

Submit

Paste the platform ADR, the probes' evidence (liveness vs readiness), the HPA finding with the final arithmetic, and the repo's YAMLs. Next: Lesson 44 — Infrastructure as code (Terraform).