En AWS conseguimos infraestructura seria con poco esfuerzo operativo: ECS Fargate ejecuta la imagen, RDS guarda los datos, el balanceador reparte y nadie administra un servidor. La lección terminaba con una pregunta abierta: ¿qué pasa cuando la red de Ribalta deja de ser una aplicación y son cinco, con tres equipos desplegando por su cuenta y el ayuntamiento preguntando si esto se puede mover a otro proveedor?

La respuesta de la industria es Kubernetes, el orquestador de contenedores que se ha convertido en el estándar de facto. Esta lección lo aborda con honestidad: primero explica qué problema resuelve y por qué para una sola aplicación como CicloUrbana suele ser complejidad no justificada, y después lo hace bien, con los manifiestos completos y comentados de la red de Ribalta. Aquí es donde encajan por fin dos piezas que llevamos preparando desde el módulo 7: las sondas de salud de 07-01, que Kubernetes consulta de tres formas distintas, y la imagen de 07-04, que es exactamente la unidad que un Deployment despliega.

1. Qué problema resuelve un orquestador, y cuándo compensa
2. Arquitectura y objetos de Kubernetes
3. Entorno de práctica y kubectl
4. Namespace, ConfigMap y Secret
5. El Deployment de CicloUrbana
6. Las tres sondas y los grupos de salud de 07-01
7. Service e Ingress con TLS
8. Migraciones de Flyway: Job o initContainer
9. Despliegue rolling, rollout status y rollout undo
10. HPA y PodDisruptionBudget
11. Empaquetar con Helm
12. PostgreSQL dentro o fuera del clúster
13. Observabilidad y depuración de un pod que no arranca
14. GitOps y Spring Cloud Kubernetes
15. Errores Comunes y Consejos
16. Ejercicios

Un orquestador toma un conjunto de máquinas y las presenta como un único recurso computacional al que se le declara un estado deseado. En lugar de decir «arranca este contenedor en esta máquina», se dice «quiero tres copias de esta imagen, con este límite de memoria, accesibles en este nombre», y el sistema se ocupa de conseguirlo y de mantenerlo pese a las averías.

La advertencia honesta, antes de seguir. Todo lo de esa tabla lo hacía también ECS en 08-03, con una fracción del esfuerzo. Kubernetes trae consigo un vocabulario de decenas de objetos, un plano de control que hay que actualizar, complementos que instalar (controlador de ingress, cert-manager, métricas, agregador de logs), un modelo de red no trivial y una superficie de seguridad amplia. Para una sola aplicación, ECS o un PaaS suelen bastar y suelen ser mejores.

Kubernetes empieza a compensar cuando concurren varias de estas condiciones: hay muchos servicios (más de cinco o seis) que despliegan de forma independiente; hay varios equipos que necesitan autonomía sin pisarse, con Namespace y cuotas; se exige portabilidad entre proveedores o alojamiento propio; hace falta automatización avanzada —canary, GitOps, operadores—; y ya existe una plataforma interna con alguien que la mantiene.

Para CicloUrbana, la respuesta sincera hoy es: no hace falta. La estudiamos porque es el escenario del ayuntamiento a tres años vista, porque es el destino de la imagen que ya sabemos construir, y porque las sondas de 07-01 solo revelan todo su sentido aquí.

El modelo mental es sencillo y conviene fijarlo: se declara el estado deseado en el API Server, que lo guarda en etcd, y los controladores comparan continuamente lo deseado con lo real y actúan para reducir la diferencia. No se dan órdenes: se describe un objetivo.

Para practicar sin coste no hace falta un clúster de pago:

minikube (minikube start --cpus 4 --memory 6144) es la más completa, con addons de ingress y métricas; kind (kind create cluster --name ribalta) es ligera y rapidísima, ideal para la propia CI; y Docker Desktop solo pide marcar la casilla «Enable Kubernetes».

Aviso de coste: un clúster gestionado (EKS, GKE, AKS) cuesta unos 70 $/mes solo por el plano de control, más los nodos. Practica en local; si creas uno gestionado, destrúyelo el mismo día.

Los comandos imprescindibles:

Una regla de trabajo: apply sobre ficheros versionados en Git, nunca kubectl edit ni kubectl run en producción, porque un cambio hecho a mano se pierde en el siguiente apply y nadie sabe que existió.

El primer manifiesto, 00-namespace.yaml, es trivial: un Namespace llamado ciclourbana-prod con las etiquetas proyecto: ciclourbana y entorno: prod. Aísla nombres, permisos y cuotas del entorno de preproducción.

Las claves son nombres de variables de entorno, que Spring Boot traduce a propiedades por relaxed binding (02-05): SPRING_DATASOURCE_URL → spring.datasource.url. Aquí sí podemos mantener el puerto de gestión separado en 8081 de 07-01 —a diferencia de Heroku— porque un pod puede exponer varios puertos, y el Service decide cuáles publica.

Advertencia fundamental: un Secret de Kubernetes solo está codificado en base64, no cifrado. Base64 no es cifrado: kubectl get secret ciclourbana-secretos -o jsonpath='{.data.JWT_SECRETO}' | base64 -d devuelve el valor en claro para cualquiera con permisos de lectura sobre el namespace. Y por defecto se guarda tal cual en etcd.

Nunca se versiona un Secret con valores reales. Se versiona la plantilla con REEMPLAZAR, y el valor real llega por kubectl create secret --from-literal en la creación inicial, o —lo correcto— por External Secrets desde el almacén de 08-03.

Los puntos que importan de verdad:

resources y su relación con MaxRAMPercentage. requests es lo que el planificador reserva para colocar el pod; limits es el techo duro. Superar el límite de memoria no produce una excepción: el kernel mata el proceso (OOMKilled). Con limits.memory: 1Gi y MaxRAMPercentage=75 del ConfigMap, el heap máximo es 768 MB y los 256 MB restantes cubren metaespacio, pilas de hilos, búferes directos y código nativo. Poner el 100 % es la receta garantizada del OOMKilled sin traza. En CPU, limits: 1 significa un núcleo: si se pone un límite bajo, el throttling del kernel alarga el arranque de la JVM y puede hacer fallar el startupProbe — motivo por el que requests.cpu conviene generoso aquí.

securityContext en dos niveles. El del pod fija el usuario sin privilegios (coherente con el usuario no root de la imagen de 07-04); el del contenedor prohíbe escalar privilegios, elimina todas las capacidades del kernel y monta el sistema de ficheros raíz de solo lectura. Esto último rompe la aplicación si algo necesita escribir —Tomcat usa /tmp para subidas y trabajo interno—, y por eso se monta un emptyDir en /tmp: un volumen efímero, propio de cada pod, que desaparece con él. Es el factor 6 de 08-01 impuesto por el sistema.

envFrom con configMapRef y secretRef inyecta de una vez todas las claves de ambos objetos como variables de entorno, así que añadir una propiedad es editar el ConfigMap sin tocar el Deployment. Contrapartida: cambiar un ConfigMap no reinicia los pods, y la nueva configuración no se aplica hasta un kubectl rollout restart deploy/ciclourbana.

preStop y terminationGracePeriodSeconds, casados con el apagado ordenado. La secuencia completa al retirar un pod:

El sleep 10 del preStop no es un truco sucio: es la solución estándar al hecho de que la eliminación del endpoint y el envío del SIGTERM ocurren en paralelo, no en secuencia. Sin ese margen, durante un par de segundos hay tráfico dirigido a un pod que ya está cerrando, y los ciudadanos ven 502. Y la aritmética debe cuadrar: terminationGracePeriodSeconds (60) > preStop (10) + timeout-per-shutdown-phase (40), o Kubernetes matará el proceso a mitad del apagado ordenado.

Este es el apartado donde 07-01 cobra todo su sentido. Kubernetes hace tres preguntas distintas y actúa distinto según la respuesta:

Y la configuración que ya escribimos en 07-01 hace que esos endpoints respondan lo correcto:

Por qué confundirlas provoca reinicios en bucle. Supón que alguien pone la base de datos en el grupo liveness, o que apunta la livenessProbe a /actuator/health completo. RDS tiene un mantenimiento de 40 segundos:

Los tres pods dejan de alcanzar la base de datos y /actuator/health devuelve 503; la livenessProbe falla tres veces seguidas en los tres; Kubernetes mata los tres contenedores a la vez; arrancan de nuevo, la base de datos sigue en mantenimiento y vuelven a morir; y entonces se aplica el retroceso exponencial —CrashLoopBackOff, con esperas de 10, 20, 40 segundos hasta llegar a 5 minutos—. Un incidente de 40 segundos se convierte en uno de veinte, y es el propio orquestador quien lo alarga.

Con la configuración correcta, lo que ocurre es muy distinto: readiness falla, los pods salen del Service, el Ingress devuelve 503 durante los 40 segundos —lo cual es honesto: la aplicación de verdad no puede trabajar— y liveness sigue en verde porque el proceso está perfectamente sano. Cuando la base de datos vuelve, readiness pasa a UP y los pods reciben tráfico otra vez. Sin un solo reinicio.

Y la startupProbe resuelve el conflicto clásico de la JVM. Una aplicación Spring Boot con Hibernate tarda 25-45 segundos en arrancar, y una livenessProbe con failureThreshold: 3 y periodSeconds: 10 la mataría a los 30, antes de que llegara a estar viva. La solución antigua —un initialDelaySeconds grande— retrasa la detección de fallos durante toda la vida del pod; la startupProbe lo separa: da hasta 120 segundos para arrancar (24 × 5 s) y una vez superada cede el control a las otras dos, que ya pueden ser agresivas y detectar un fallo real en 30 segundos.

ClusterIP es deliberado: el Service no publica nada al exterior, solo da un nombre DNS interno estable (ciclourbana.ciclourbana-prod.svc.cluster.local) sobre los pods que estén ready en cada momento; quien expone al exterior es el Ingress. Y fíjate en que el puerto 8081 de gestión no se publica: las sondas lo consultan directamente en el pod, así que Actuator queda inaccesible desde fuera del clúster por construcción — la separación de puertos de 07-01 haciendo su trabajo.

Un Ingress es solo una declaración: hace falta un controlador que la implemente (ingress-nginx, Traefik, o el del proveedor). La anotación cert-manager.io/cluster-issuer hace que cert-manager —un operador que hay que instalar— solicite el certificado a Let's Encrypt, valide el dominio, guarde el certificado en el Secret indicado y lo renueve automáticamente antes de caducar. Es el equivalente de ACM en 08-03.

Como el controlador termina el TLS y habla HTTP con los pods, sigue haciendo falta lo de 08-01, que ya está en el ConfigMap: SERVER_FORWARD_HEADERS_STRATEGY: framework.

El ConfigMap desactivó Flyway. La razón es la misma de 08-01 y 08-03, aquí más aguda: con 3 réplicas, tres pods arrancarían a la vez e intentarían migrar simultáneamente. Flyway lo serializa con un bloqueo en la base de datos, así que no corrompe nada, pero los pods que esperan consumen su ventana de arranque, y si la migración falla los tres entran en CrashLoopBackOff y la aplicación queda caída aunque la versión anterior funcionase.

Un Job ejecuta el pod hasta que termine con éxito. web-application-type=none levanta el contexto sin Tomcat: Flyway migra y el proceso sale. La secuencia del despliegue es entonces:

Si el kubectl wait falla, no se toca el Deployment: la versión anterior sigue sirviendo a Ribalta con total normalidad.

La alternativa del initContainer ejecuta la migración dentro de cada pod antes del contenedor principal. Es más simple de escribir, pero N réplicas ejecutan N migraciones: con el bloqueo de Flyway no se corrompe nada, pero se multiplica el trabajo, se alarga el arranque de todos los pods y se pierde la propiedad más valiosa del Job —que un fallo de migración detenga el despliegue antes de tocar los pods vivos—. Su único caso razonable es un Deployment con una sola réplica.

Y el recordatorio de siempre: durante el rolling update conviven 2.3.0 y 2.4.0 contra el esquema ya migrado, así que cada migración debe ser compatible hacia atrás — expand/contract de 04-08.

Con maxSurge: 1 y maxUnavailable: 0 sobre 3 réplicas, Kubernetes crea un cuarto pod con la versión nueva, espera a que su readinessProbe pase, lo añade al Service y solo entonces retira uno viejo. Y repite. En ningún momento hay menos de 3 pods sanos atendiendo.

Los tres ajustes habituales: maxUnavailable: 0 con maxSurge: 1 garantiza la capacidad a cambio de un despliegue más lento y de necesitar margen en el clúster; maxUnavailable: 1 con maxSurge: 1 es más rápido pero admite un momento con solo 2 pods; y maxSurge: 3 es el más rápido, duplicando el consumo durante la transición.

rollout status es la pieza que la canalización de 08-05 usa como criterio de éxito: devuelve código distinto de cero si la actualización no progresa en el plazo (progressDeadlineSeconds, 600 s por defecto), lo que permite automatizar la reversión.

Y la advertencia de 08-01, que aquí es literal: rollout undo revierte la aplicación, no la base de datos. La migración aplicada sigue aplicada. Si el esquema no es compatible hacia atrás, revertir empeora la situación en lugar de arreglarla.

La relación entre el HPA y resources es la clave y casi nadie la ve a la primera: averageUtilization: 70 no significa el 70 % de un núcleo, sino el 70 % de requests.cpu. Con requests.cpu: 300m, el objetivo es 210 milicores por pod. De ahí dos consecuencias prácticas: si requests está muy bajo, el HPA escala constantemente por nada; si está muy alto, no escala nunca aunque los pods sufran. Sin requests.cpu, el HPA no funciona en absoluto y kubectl describe hpa muestra <unknown> en la columna de métricas.

Y como en 08-03: maxReplicas × maximum-pool-size + margen < max_connections de PostgreSQL. Con 10 réplicas y un pool de 10 son 100 conexiones, más el Job de migración y la administración. Hay que comprobarlo antes de subir maxReplicas, no cuando el pico de tráfico produzca too many clients.

El PodDisruptionBudget protege frente a las interrupciones voluntarias: cuando un administrador vacía un nodo (kubectl drain) o el autoescalador de nodos consolida máquinas, Kubernetes respeta el presupuesto y no retira pods si eso dejaría menos de 2 disponibles. No protege de fallos involuntarios —un nodo que muere se lleva sus pods igualmente— pero elimina la causa más frecuente de caídas evitables en Kubernetes: una actualización del clúster que vacía dos nodos a la vez y se lleva todas las réplicas.

Los ocho manifiestos anteriores describen un entorno. Para pre hacen falta otros ocho casi idénticos, con distinto namespace, réplicas, base de datos y dominio: copiar y pegar es la garantía de que dentro de tres meses pre y prod diverjan sin que nadie sepa en qué. Helm es el gestor de paquetes de Kubernetes: convierte los manifiestos en plantillas y separa los valores por entorno.

Y la plantilla consume esos valores:

--atomic es la opción que más tranquilidad da: si la actualización no termina bien en el plazo, Helm revierte automáticamente al estado anterior. Y --set image.tag=2.4.1 es la línea exacta que ejecutará la canalización de 08-05.

Alternativa: Kustomize, integrado en kubectl (kubectl apply -k), que no usa plantillas sino parches sobre una base común:

Regla práctica: Kustomize si solo cambian unos pocos valores entre pre y prod; Helm si el chart tiene lógica, condicionales o hay que distribuirlo. Para CicloUrbana, Helm compensa por --atomic, rollback y el historial de versiones.

Se puede ejecutar PostgreSQL en Kubernetes con un StatefulSet y un PVC, o con un operador serio como CloudNativePG o Zalando. Pero:

El curso recomienda sin matices la base de datos gestionada. Kubernetes está diseñado para cargas sin estado y desechables —pods que se matan y se recrean sin consecuencias— y una base de datos es exactamente lo contrario. Los operadores modernos son buenos, pero el día que un PVC se corrompe o un fallo de red separa el primario de la réplica, hace falta alguien que sepa de PostgreSQL y de Kubernetes a la vez. Ese perfil es escaso, y el ayuntamiento de Ribalta no lo tiene.

Excepción razonable: PostgreSQL dentro del clúster en dev y en las pruebas, donde perder los datos no cuesta nada.

Los logs de kubectl logs salen del stdout del contenedor y se pierden cuando el pod desaparece: en producción hace falta un agente que los reenvíe a un agregador (Fluent Bit, Vector o el del proveedor), que es el tema de 09-05.

El método de depuración, en este orden exacto:

OOMKilled en una JVM merece explicación aparte, porque despista. No es un OutOfMemoryError de Java: no hay traza, no hay excepción, no hay nada en el log. El proceso simplemente desaparece y kubectl describe pod muestra Last State: Terminated, Reason: OOMKilled, Exit Code: 137, porque la JVM pidió al sistema más memoria de la que el cgroup permite y el kernel la mató. Las causas, por frecuencia: MaxRAMPercentage demasiado alto o ausente (el heap crece hasta el límite y el resto de la memoria de la JVM no cabe); limits.memory insuficiente para lo que la aplicación necesita de verdad; y, en último lugar, una fuga real, que conviene diagnosticar con -XX:+HeapDumpOnOutOfMemoryError y un volumen donde escribir el volcado.

Y la distinción práctica: un OutOfMemoryError de Java sí deja traza en el log y, con ExitOnOutOfMemoryError (07-04), sale con código 1. Un OOMKilled sale con 137 y no deja nada. Si ves 137, es el kernel; si ves 1 con traza, es el heap.

Para depurar un pod con readOnlyRootFilesystem y sin shell existe kubectl debug -it <pod> --image=busybox --target=ciclourbana, que adjunta al pod en ejecución un contenedor efímero con herramientas.

GitOps invierte la dirección del despliegue: en lugar de que la canalización empuje cambios al clúster con kubectl (lo que exige darle credenciales de administrador), un agente dentro del clúster vigila un repositorio Git y aplica lo que encuentra.

El flujo queda: el desarrollador abre un pull request sobre el repositorio de manifiestos, la canalización se limita a actualizar image.tag en ese repositorio, y Argo CD —que vive dentro del clúster— detecta el cambio, lo sincroniza y compara continuamente el estado real con el declarado.

Ventajas concretas: Git es la única fuente de verdad y su historial dice quién desplegó qué y cuándo; la reversión es un git revert; la canalización no necesita credenciales del clúster, lo que reduce mucho la superficie de ataque (08-05); y el agente detecta la deriva, marcando como OutOfSync cualquier cambio hecho a mano. Las herramientas de referencia son Argo CD (interfaz web muy visual) y Flux (más ligero, integrado con Helm).

Spring Cloud Kubernetes, por último, permite a la aplicación leer ConfigMap y Secret como fuentes de propiedades, descubrir servicios por la API de Kubernetes y recargar configuración en caliente. A menudo no hace falta, y es importante saber por qué: montar el ConfigMap como variables (nuestro envFrom) ya resuelve la configuración con cero dependencias; el descubrimiento lo hace el DNS interno, que funciona con cualquier cliente HTTP —el RestClient de 07-06 llama a http://patinetes:8080 sin más—; y la recarga en caliente añade complejidad frente a un kubectl rollout restart, que es explícito, auditable y siempre funciona. Además obligaría a dar a la aplicación permisos RBAC sobre la API, ampliando su superficie de ataque. Vale la pena con decenas de servicios y configuración centralizada; para CicloUrbana, el ConfigMap por envFrom es la respuesta correcta y mantiene el artefacto agnóstico de la plataforma, como pide 08-01.

Poner la base de datos en el grupo liveness. Un mantenimiento de 40 segundos reinicia todos los pods y provoca CrashLoopBackOff durante veinte minutos. Vida = proceso sano; disponibilidad = puede trabajar.

No poner startupProbe. La livenessProbe mata la JVM antes de que termine de arrancar y el pod nunca llega a estar listo. Y MaxRAMPercentage sin margen produce OOMKilled con código 137 y nada en el log: deja el 25 %.

Olvidar requests.cpu. El HPA no puede calcular la utilización, muestra <unknown> y no escala jamás. Y readOnlyRootFilesystem sin montar /tmp hace fallar a Tomcat al escribir su directorio de trabajo, con un error de arranque poco evidente.

Secretos en base64 dados por cifrados. Base64 se deshace con un comando. Usa RBAC estricto, cifrado en reposo y External Secrets o Sealed Secrets.

Cambiar un ConfigMap esperando que se aplique solo. Los pods conservan las variables con las que arrancaron: hace falta kubectl rollout restart. Y migrar desde un initContainer con varias réplicas significa N pods, N migraciones, y un fallo que tumba el despliegue entero en lugar de detenerlo antes.

Consejo: kubectl describe pod antes que cualquier otra cosa. La sección Events del final explica en texto claro el 80 % de los problemas.

Consejo: verifica antes de aplicar. helm template muestra el YAML final resuelto y kubectl apply --dry-run=server -f lo valida contra la API real sin crear nada: los dos pasos de verificación de la canalización.

Consejo: etiqueta todo con app, version y entorno. Los selectores, las consultas de logs y las métricas dependen de ello.

Escribe el Deployment de CicloUrbana para el entorno pre: 1 réplica, requests de 200m/512Mi y limits de 500m/768Mi, imagen 2.5.0-rc1, las tres sondas correctamente configuradas y securityContext endurecido. Calcula qué valor de MaxRAMPercentage corresponde y justifica cada failureThreshold sabiendo que en pre la aplicación tarda unos 50 segundos en arrancar por tener menos CPU.

Se despliega la versión 2.4.0 y kubectl get pods muestra durante diez minutos:

Describe el procedimiento de diagnóstico paso a paso y desarrolla las cinco causas más probables para este síntoma concreto, con la evidencia que confirma cada una y su corrección. Ten en cuenta que la versión 2.3.0 funcionaba correctamente hasta hace diez minutos.

El ayuntamiento quiere desplegar CicloUrbana en pre y prod desde el mismo código, con un solo comando por entorno y sin duplicar manifiestos. Diseña el chart de Helm: qué va en values.yaml, qué en values-pre.yaml y values-prod.yaml, cómo se parametriza el Job de migración para que se ejecute una vez por versión, y cuál es la secuencia completa de comandos que ejecutaría la canalización de 08-05 para desplegar la versión 2.4.1 en producción de forma segura y reversible.

Solución 1

Partiendo del Deployment del apartado 5, cambian el namespace a ciclourbana-pre, replicas: 1, la imagen a 2.5.0-rc1 y estos bloques:

El securityContext endurecido (runAsNonRoot, runAsUser: 10001, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities: drop: ["ALL"]), el emptyDir en /tmp, el preStop y terminationGracePeriodSeconds: 60 se mantienen idénticos: no dependen del entorno.

MaxRAMPercentage. Con limits.memory: 768Mi, el 75 % son 576 MB de heap y quedan 192 MB para lo demás. En una JVM con Hibernate y Spring Security, metaespacio (~90 MB), pilas de hilos (~40 MB) y búferes directos rondan ya los 150-180 MB: es demasiado justo. En contenedores pequeños hay que ser más conservador: MaxRAMPercentage=60 (460 MB de heap, 308 MB de margen). Es un principio general y contraintuitivo: cuanto más pequeño el contenedor, menor debe ser el porcentaje, porque los costes fijos de la JVM no escalan con el tamaño.

Los failureThreshold. El startupProbe es el único que debe acomodar el arranque: 50 s medidos, pero con limits.cpu: 500m —medio núcleo— la JVM sufre throttling y en un día de carga puede tardar el doble, así que 30 intentos × 5 s = 150 s dan un margen de tres veces sin ser absurdo. Una vez superado, liveness con 3 × 10 s detecta un proceso irrecuperable en 30 segundos, y readiness con 3 × 5 s saca el pod de rotación en 15. Con replicas: 1, readiness fallando significa 503 para todo pre, lo cual es correcto y honesto: no hay a quién enviar el tráfico.

Solución 2

Procedimiento. Primero kubectl describe pod ciclourbana-7d4b8c9f5-2xk9p -n ciclourbana-prod y leer la sección Events y el campo Last State (razón y código de salida). Después kubectl logs ciclourbana-7d4b8c9f5-2xk9p --previous, que es la parte que más se olvida: sin --previous se pide el log del contenedor actual, que aún no ha escrito nada. Y en paralelo, kubectl get events --sort-by=.lastTimestamp y kubectl rollout history para ver qué cambió respecto a 2.3.0.

Las cinco causas, con su evidencia:

1. La migración de Flyway falla y ddl-auto: validate rechaza el esquema. Primera sospecha, porque 2.3.0 funcionaba: lo que cambió es la versión y con ella el esquema esperado. Evidencia: en el log previo, FlywayException o Schema-validation: missing column [plazas_totales] in table [estaciones]. Corrección: revisar el Job (kubectl logs job/ciclourbana-migracion-2-4-0); si falló y el Deployment se actualizó igualmente, se ha saltado el kubectl wait — revertir solo si el esquema sigue siendo compatible y arreglar la canalización para que el despliegue dependa del Job.

2. OOMKilled. Evidencia: Last State: Terminated, Reason: OOMKilled, Exit Code: 137, y el log previo no muestra ningún error: la aplicación arrancaba con normalidad y desaparece. Corrección: subir limits.memory o bajar MaxRAMPercentage; si 2.4.0 añadió una caché o una consulta que carga muchos objetos, el límite se ha quedado corto.

3. livenessProbe demasiado agresiva o mal apuntada. Evidencia: en Events, Liveness probe failed: HTTP probe failed with statuscode: 503 seguido de Killing container, y en el log previo la aplicación llega a Started CicloUrbanaApplication y muere poco después. Corrección: verificar que liveness incluye solo livenessState y no db, y que hay startupProbe; si 2.4.0 arranca más lento que 2.3.0, la sonda que antes bastaba ahora no llega.

4. Un Secret o ConfigMap que falta o cambió. Evidencia: el estado sería CreateContainerConfigError si el objeto no existe; si existe con un valor mal, el log previo muestra Could not resolve placeholder 'JWT_SECRETO' o un fallo de autenticación contra PostgreSQL. Corrección: kubectl get secret ciclourbana-secretos -o yaml y comprobar que están todas las claves que 2.4.0 necesita — una propiedad nueva en el código y no añadida al ConfigMap produce exactamente esto.

5. La imagen no es la que se cree. Evidencia: un Image ID que no corresponde, o exec format error en el log previo (imagen arm64 construida en Apple Silicon, 08-03). Corrección: reconstruir con --platform linux/amd64 y usar etiquetas inmutables.

Regla de oro para este escenario: los tres pods fallan igual, así que no es un problema de un nodo ni de infraestructura; es la versión nueva. Y la acción inmediata correcta —antes de investigar— es kubectl rollout undo deploy/ciclourbana, siempre que el esquema siga siendo compatible hacia atrás. Si la causa 1 es la real y la migración fue destructiva, revertir no arregla nada: es el escenario del ejercicio 3 de 08-01.

Solución 3

Reparto de valores. En values.yaml va todo lo común y lo que rara vez cambia: repositorio de la imagen, puertos, las tres sondas con sus umbrales, securityContext, preStop, terminationGracePeriodSeconds, etiquetas y las anotaciones del Ingress. En values-pre.yaml y values-prod.yaml, solo las diferencias: replicaCount, recursos, ingress.host, config.perfil, config.urlBaseDatos, autoescalado y el nombre del Secret. El criterio: si un valor es igual en los dos entornos, no puede estar en los ficheros por entorno, o antes o después divergirán sin motivo.

El Job parametrizado por versión. La clave es que el nombre incluya la etiqueta de la imagen, para que cada despliegue cree un Job distinto (Kubernetes rechazaría recrear uno con el mismo nombre) y quede el rastro de cada migración:

Los hooks de Helm son la pieza elegante: pre-upgrade hace que Helm ejecute el Job y espere a que termine con éxito antes de tocar el Deployment. Si falla, helm upgrade aborta y los pods siguen con la versión anterior — exactamente la propiedad que buscábamos en el apartado 8, ahora sin scripts intermedios.

Secuencia de la canalización para 2.4.1:

Por qué es seguro y reversible. --atomic revierte solo si el despliegue no converge en el plazo; el hook pre-upgrade garantiza que una migración fallida detenga el proceso antes de tocar los pods vivos; helm rollback vuelve a la revisión anterior en un comando; el /actuator/info con build-info de 07-01 confirma qué versión corre de verdad; y la condición de fondo, la de siempre: la reversión solo funciona si la migración de 2.4.1 es compatible hacia atrás (expand/contract, 04-08).

CicloUrbana corre ahora en un orquestador, y lo hace sabiendo por qué y cuándo eso tiene sentido. La lección empezó con una advertencia que conviene no olvidar: para una sola aplicación, ECS o un PaaS suelen bastar y suelen ser mejores, y Kubernetes solo compensa cuando hay muchos servicios, varios equipos autónomos, exigencia de portabilidad o automatización avanzada. Con esa honestidad de partida, has construido la red de Ribalta completa sobre el clúster.

Conoces la arquitectura —plano de control, etcd, planificador, controladores y kubelet— y el modelo mental que la explica: se declara el estado deseado y los controladores reducen la diferencia con la realidad. Manejas los objetos que importan y tienes los manifiestos comentados: un Namespace por entorno, un ConfigMap con la configuración no sensible y un Secret con la advertencia clara de que base64 no es cifrado, junto con las soluciones reales —RBAC estricto, cifrado en reposo, Sealed Secrets y External Secrets Operator, la mejor opción cuando el almacén ya está en AWS (08-03)—.

El Deployment reúne todo lo que el curso venía preparando: la imagen de 07-04, requests y limits casados con MaxRAMPercentage —con el principio de que cuanto más pequeño el contenedor, menor debe ser el porcentaje—, variables desde configMapRef y secretRef, un securityContext con usuario no root, capacidades eliminadas y sistema de ficheros de solo lectura con /tmp en un emptyDir, y el preStop de diez segundos con terminationGracePeriodSeconds holgado que hace encajar el apagado ordenado de 01-05 con la propagación de los endpoints. Y sobre todo, las tres sondas: startupProbe para que la JVM tenga tiempo de arrancar sin que liveness la mate, livenessProbe sobre livenessState para reiniciar solo lo irrecuperable, y readinessProbe sobre el grupo que incluye db para salir de rotación sin morir. Sabes exactamente cómo un mantenimiento de 40 segundos de la base de datos se convierte en veinte minutos de CrashLoopBackOff si se confunden, y por qué la configuración de 07-01 lo evita.

Tienes además el Service ClusterIP que no publica el puerto de gestión, el Ingress con TLS renovado por cert-manager, las migraciones en un Job que detiene el despliegue si falla, el rolling update con maxUnavailable: 0 y su rollout undo con la advertencia sobre la base de datos, el HPA con su relación con requests.cpu que casi nadie ve a la primera, el PodDisruptionBudget, y el chart de Helm con values por entorno, hooks para la migración y --atomic. Sabes cuándo Kustomize es mejor, por qué la base de datos debe seguir siendo gestionada, cómo se depura un pod que no arranca —describe primero, Events al final, logs --previous después— y qué significan CrashLoopBackOff, ImagePullBackOff y un OOMKilled con código 137 que no deja rastro en el log.

Y aquí termina el recorrido por las plataformas. CicloUrbana puede desplegarse en un PaaS, en contenedores gestionados o en un orquestador, y en los tres casos las decisiones de fondo son las de 08-01. Pero en las tres lecciones ha habido un actor implícito que seguía siendo humano: alguien que ejecuta git push heroku main, aws ecs update-service o helm upgrade desde su portátil, con sus credenciales, esperando haber probado antes lo que despliega. La última lección del módulo, Integración y Entrega Continua, elimina a ese actor: una canalización que compila, ejecuta las pruebas del módulo 6 —incluidos los Testcontainers—, analiza la calidad, construye y escanea la imagen, la publica etiquetada con el SHA del commit, despliega en pre, pasa las pruebas de humo y, tras una aprobación explícita, la lleva a producción sin que nadie toque un servidor a mano.