Lección 43 — Kubernetes y servicios gestionados

El despliegue de TicketFlow en K8s (o el argumento de por qué no). Sin solutions.md hasta entregar.

Ejercicio 1 — La decisión documentada

1. Escribe el ADR (48) "Plataforma de despliegue de TicketFlow": PaaS vs K8s vs compose con TU contexto (equipo, producto, presupuesto) — 10 líneas, decisión, razones, trigger de revisión.
2. El trigger de migración: ¿qué evento real (no moda) te haría migrar a K8s? Enumera 3 triggers concretos (¿multi-tenant aislado? ¿servicios > N? ¿requerimiento on-prem?) y marca cuál es el más probable en TU roadmap.
3. El literacy: lista los 6 objetos K8s que TicketFlow necesita (del §2-3) y para cada uno escribe en una línea qué problema resuelve. Sin instalar nada aún: la lectura es la primera habilidad.

Ejercicio 2 — El cluster local

1. Con kind/minikube/k3d: levanta un cluster local y despliega el Deployment+Service del §2 (la imagen del 40 local: kind load docker-image ticketflow:latest). Verifica: kubectl get pods con 3 réplicas Ready y el Service respondiendo (port-forward o NodePort).
2. Las probes en acción: mata el proceso interno del pod (exec + kill) y observa: ¿el liveness lo reinicia? ¿Cuánto tarda el pod en volver a Ready? Documenta el ciclo de resurrección.
3. El readiness vs liveness: congela la BD (el compose del 40 sin PG) y observa el contraste: ¿qué probe marca y qué hace el Service con ese pod? (el pod sale del balanceo SIN reinicio: la diferencia clave del §2).

Ejercicio 3 — El HPA y el CronJob

1. Despliega el HPA del §3 y genera carga con k6 (36): ¿cuántos pods al pico? ¿Cuánto tarda el scale-out (la ventana del HPA es ~15-30 s: el pico de 400 VUs del 36 lo nota)? Documenta el finding.
2. El límite de la aritmética: con el HPA maxReplicas=10 y el pool del 39 (max_size 10): ¿cuántas conexiones pide el cluster al gestionado? ¿Cabe en el max_connections del tier? Ajusta: ¿pool más chico, maxReplicas más bajo, o PgBouncer (42)?
3. El CronJob: despliega expirar-reservas cada minuto y verifica: los pods del CronJob corren y terminan (el log del job), y DOS corridas solapadas no se pisan (el lock de la 31 en acción — corre 2 jobs a mano con kubectl create job --from).

Ejercicio 4 — La BD fuera del cluster

1. El experimento prohibido (en el cluster local, NUNCA en prod): despliega Postgres como Deployment con emptyDir (sin PV): mata el pod y vuelve a levantarlo: ¿dónde están tus datos? Documenta el hallazgo como advertencia.
2. La versión con PV (StatefulSet + PersistentVolume en el cluster local): mata el pod: ¿sobreviven los datos? Aun así, enumera las 3 razones del §4 por las que esto NO va a prod (¿el failover? ¿los backups? ¿el drain del nodo?).
3. La conexión al gestionado: configura el app del cluster (local) para hablar al PG del compose del 40 por IP/servicio externo. La aritmética del 39 con HPA: pega la tabla final de conexiones (pods × pool + worker + beat).

Ejercicio 5 — El despliegue completo

1. El rolling update: cambia la imagen del Deployment a una versión nueva (tag distinto) y observa kubectl rollout status: ¿cuántos pods viejos conviven con los nuevos? ¿El readiness decide el corte? Mide el tiempo total del rollout.
2. El rollout undo: rompe la versión nueva (healthcheck que falla) y haz kubectl rollout undo: ¿cuánto tardó el rollback y cuántas requests 5xx hubo durante el mal rollout? (el readiness de K8s contra el blue-green del 41: ¿quién protege mejor al usuario?).
3. El manifiesto en el repo (44 lo formaliza): crea deploy/k8s/ con los YAML del ejercicio (Deployment, Service, HPA, CronJob, ConfigMap) y el comando de despliegue en el README del directorio. El principio: los YAML se revisan en PR como el código.

Entrega

Pega el ADR de plataforma, la evidencia de las probes (liveness vs readiness), el finding del HPA con la aritmética final, y los YAML del repo. Después: Lección 44 — Infraestructura como código (Terraform).