Docker Compose levanta el sistema de TechCorp en un portátil, pero se queda corto en cuanto hay más de una máquina: si el servidor que ejecuta servicio-pedidos se cae, nadie lo arranca en otro sitio; si el Black Friday exige diez réplicas de servicio-catalogo, alguien tiene que decidir dónde ponerlas; si hay que desplegar la versión 1.0.1 sin cortar el servicio, hay que coordinar a mano el arranque de la nueva y la parada de la vieja. Un orquestador hace todo eso de forma declarativa: le dices qué quieres ("dos réplicas de esta imagen, sanas, accesibles con este nombre") y él se ocupa del cómo, de forma continua. Kubernetes es el orquestador de la lista corta de 04-01. En esta lección entendemos su arquitectura y sus objetos, montamos un clúster local, y escribimos y aplicamos los manifiestos completos de servicio-pedidos con los nombres que 03-05 (Service, /health/*) y 04-03 (servicio-pedidos-config, pedidos-db, pedidos-rabbitmq) dejaron fijados. El pipeline que aplicará estos manifiestos automáticamente (05-03) y las estrategias para cambiar de versión sin cortes (05-04) vienen después.

1. Por qué hace falta un orquestador
2. Arquitectura de Kubernetes: plano de control y nodos
3. Los objetos básicos
4. Entorno local con kind y kubectl imprescindible
5. Namespace, ConfigMap y Secret de servicio-pedidos
6. Un Job para las migraciones
7. El Deployment de servicio-pedidos, línea a línea
8. El Service y el nombre DNS servicio-pedidos:3002
9. Ingress: exponer el gateway en api.techcorp.example
10. Escalado manual y estado del despliegue
11. RabbitMQ y PostgreSQL: dentro del clúster o gestionados
12. Helm y Kustomize para no duplicar YAML entre seis servicios

Lo que un orquestador resuelve, comparado con "contenedores en máquinas":

Todo se declara en YAML y se guarda en git; el clúster reconcilia continuamente el estado real con el deseado. Esa es la idea central: no ejecutas comandos imperativos, describes el resultado.

• API server: recibe todas las peticiones (de kubectl, de los controladores, de los kubelets), las valida y las persiste en etcd, la base de datos clave-valor del clúster.
• Scheduler: observa pods sin nodo asignado y les elige uno según recursos solicitados, afinidades y restricciones.
• Controller manager: ejecuta los bucles de control. El controlador de Deployment crea ReplicaSet; el de ReplicaSet crea o borra pods hasta cuadrar replicas; el de Endpoints mantiene la lista de pods listos de cada Service (el "registro" de 03-05).
• kubelet (en cada nodo): agente que habla con el API server, arranca los contenedores de los pods asignados a su nodo a través del runtime (containerd, la misma tecnología de contenedores de 05-01) y ejecuta las probes.
• kube-proxy: programa las reglas de red para que la ClusterIP de un Service reparta entre sus pods.

Un desarrollador de TechCorp solo habla con el API server (kubectl), y ni siquiera eso en producción: lo hará el pipeline o Argo CD (05-03).

kind (Kubernetes in Docker) crea un clúster completo dentro de contenedores; minikube es la alternativa equivalente. TechCorp usa kind porque es el mismo que corre en CI. El fichero de configuración publica los puertos 80/443 del nodo en el portátil para que el Ingress funcione:

Los comandos de kubectl que se usan cada día (kubectl config set-context --current --namespace=techcorp evita repetir -n techcorp; en lo que sigue lo omitimos):

Los manifiestos viven en techcorp/plataforma/k8s/servicio-pedidos/base/ (apartado 12 explica la estructura). Primero el namespace y la configuración no sensible, que es exactamente la columna "producción" de la tabla de 04-03:

Los secretos no van en YAML dentro del repositorio. Se crean con kubectl (o los inyecta un gestor externo, 07-04):

Ese valor es base64, no cifrado: echo cG9z... | base64 -d devuelve la contraseña. Un Secret solo es "secreto" porque el acceso a él se restringe con permisos (RBAC) y porque etcd puede cifrarse en reposo; ambas cosas son de 07-04. Por eso los secretos no se versionan en texto plano y por eso el .dockerignore de 05-01 excluía .env. Las claves del Secret se llaman como las variables de entorno (PEDIDOS_DB_URL) para poder inyectarlas con envFrom.

scripts/migrar.js (04-04) debe ejecutarse antes de que arranque la nueva versión de Pedidos, una vez, y fallar ruidosamente si no puede. Es un Job:

La alternativa es un init container dentro del pod del servicio; funciona, pero ejecuta las migraciones en cada réplica al arrancar (con dos réplicas, dos veces, y migrar.js tiene que soportar la concurrencia). El Job las ejecuta una vez por versión y se ve en kubectl get jobs. En 05-03 el pipeline lo lanza y espera antes de aplicar el Deployment.

Los puntos que más dudas generan:

• selector y labels: el Deployment (a través de su ReplicaSet) "posee" los pods cuya etiqueta app: servicio-pedidos coincide; el Service del apartado 8 usa el mismo selector. Cambiar selector en un Deployment existente no está permitido: se elige bien desde el principio.
• readinessProbe frente a livenessProbe (03-05): readiness mira dependencias propias (PostgreSQL y RabbitMQ en el /health/ready de 04-04) y su efecto es dejar de recibir tráfico; liveness solo mira que el proceso responde y su efecto es reiniciar. Poner la comprobación de la base de datos en liveness es el error clásico: si PostgreSQL cae, Kubernetes reinicia todos los pods de Pedidos en bucle sin arreglar nada.
• terminationGracePeriodSeconds: 30 cierra el círculo del apagado ordenado: al borrar un pod, Kubernetes lo quita de los Endpoints y envía SIGTERM al PID 1 (el node de 05-01); el servicio pone /health/ready en 503, termina las peticiones en curso y sale en menos de 10 s; si no lo hiciera, a los 30 s llegaría SIGKILL. Con dos réplicas y este contrato, un despliegue no pierde una petición (05-04 lo muestra paso a paso).
• securityContext: runAsNonRoot verifica lo que la imagen ya hace (USER node); readOnlyRootFilesystem obliga a que cualquier escritura vaya a un emptyDir explícito. El resto de endurecimiento (capabilities, seccomp, políticas de admisión) es de 07-04.

Con esto, el PEDIDOS_URL=http://servicio-pedidos:3002 del gateway y el CATALOGO_URL=http://servicio-catalogo:3001 del ConfigMap de Pedidos resuelven exactamente como en Compose (05-01) y como prometía 03-05, sin que ningún servicio sepa cuántas réplicas hay ni en qué nodo están.

Aplicar y comprobar todo lo anterior:

Si un pod se queda en CrashLoopBackOff, kubectl logs --previous enseñará casi siempre el mensaje de config.js (04-03) diciendo qué variable falta: la validación fail-fast está pensada para este momento.

El gateway (03-04) se despliega igual que cualquier servicio (Deployment + Service gateway:8080, con su ConfigMap de URLs). Lo único que sale del clúster es un Ingress que el ingress controller (NGINX en kind y en producción; Traefik sería equivalente con ingressClassName: traefik) convierte en reglas de proxy:

El ingress controller balancea en capa 7 hacia el Service del gateway, y el gateway hacia los servicios internos (03-05). El único punto de entrada sigue siendo el 8080 del gateway; ningún servicio-* tiene Ingress.

kubectl scale es manual: alguien decide el número. El escalado automático por CPU o por métricas (HorizontalPodAutoscaler) es de 06-04, cuando tengamos métricas con las que decidir. Aquí lo importante es que escalar es cambiar un número y que el Service reparte solo entre las réplicas listas.

Decisión de TechCorp: en dev y en el clúster kind de CI, PostgreSQL y RabbitMQ dentro del clúster con Helm (dos comandos, datos desechables); en staging y producción, gestionados, con la URL en los Secret (pedidos-db, pedidos-rabbitmq) y el nombre rabbitmq resuelto por un Service de tipo ExternalName si hace falta mantener RABBITMQ_URL estable. El equipo de Plataforma tiene cuatro personas y su prioridad es el gateway, el clúster y el pipeline, no ser DBA.

Helm instala un chart (paquete de manifiestos parametrizados) que crea el StatefulSet, el Service (rabbitmq, pg-pedidos-postgresql) y los volúmenes; RABBITMQ_URL=amqp://pedidos:dev-rabbit@rabbitmq:5672 funciona en kind sin tocar los manifiestos de los servicios.

Los cuatro ficheros de Pedidos se repetirían casi idénticos para Catálogo, Inventario, Pagos, Notificaciones, Clientes y el gateway, y además por entorno (dev, staging, prod). Dos herramientas evitan copiar y pegar:

TechCorp usa Kustomize para sus servicios y Helm para terceros. Estructura en techcorp/plataforma/k8s/:

La base es una por servicio, y los overlays solo dicen en qué se diferencia cada entorno: réplicas, etiqueta de imagen, dos claves de configuración. Cuando el equipo de Inventario cree su servicio, copiará servicio-pedidos/ y cambiará nombres, puerto (3006) y ConfigMap: es la parte de "plantilla" de la regla de Luis; la parte de "automatizar" es de 05-03.

• Comprobar la base de datos en livenessProbe. PostgreSQL cae 30 s y Kubernetes reinicia todos los pods de Pedidos en bucle. Dependencias en readiness; en liveness, solo el proceso.
• Sin resources. Sin requests el scheduler apila pods en un nodo; sin limits el primero que se dispara en memoria tumba a los demás. Los valores de partida se afinan midiendo (06-04).
• Etiquetas del selector que no coinciden con template.metadata.labels. El apply falla con un mensaje claro; en el Service, en cambio, un selector mal escrito simplemente deja Endpoints vacío y el servicio "no responde". kubectl get endpoints es la primera comprobación.
• Secretos en YAML dentro del repositorio "porque están en base64". No es cifrado. kubectl create secret o herramientas de 07-04 (Sealed Secrets, External Secrets).
• Reaplicar un Job con el mismo nombre y cambios: Kubernetes lo rechaza ("field is immutable"). Nombre con versión o kubectl delete job antes.
• Consejo: kubectl describe pod y su sección Events responden al 90 % de los "no arranca"; kubectl get events --sort-by=.lastTimestamp da la vista del namespace.

Ejercicio 1. Escribe el Deployment y el Service de servicio-catalogo (imagen ghcr.io/techcorp/servicio-catalogo:1.4.2, puerto 3001, ConfigMap servicio-catalogo-config con PUERTO, MONGO_BD, LOG_NIVEL, NODE_ENV; Secret catalogo-mongo con MONGO_URL) indicando solo las líneas que difieren de los de Pedidos. ¿Cuántas réplicas pondrías en el overlay de prod y por qué?

Ejercicio 2. Un pod de servicio-pedidos muestra READY 0/1 durante minutos pero STATUS Running y sin reinicios. kubectl logs enseña "escuchando en 3002" y ninguna traza de error. Enumera, en orden, los tres comandos que ejecutarías para diagnosticarlo y las dos causas más probables.

Ejercicio 3. Marta pregunta por qué el Job de migraciones lleva la versión en el nombre y qué pasa si el pipeline despliega la 1.0.1 sin haber cambiado ninguna migración. Responde y propón cómo evitar que el Job falle en ese caso.

Solución 1. Difieren: metadata.name, labels/selector (app: servicio-catalogo), image: ghcr.io/techcorp/servicio-catalogo:1.4.2, containerPort: 3001, envFrom con configMapRef: servicio-catalogo-config y secretRef: catalogo-mongo, y en el Service port: 3001 (el CATALOGO_URL=http://servicio-catalogo:3001 de todos). Las probes apuntan a los mismos /health/live y /health/ready (contrato de 03-05), terminationGracePeriodSeconds, securityContext y resources pueden ser iguales. No hay Job de migraciones (MongoDB sin esquema; la semilla es solo de dev). Réplicas en prod: más que Pedidos (por ejemplo 4), porque Catálogo recibe los picos ×20 de campañas (01-05) y es de solo lectura, barato de replicar; el número definitivo lo dará el HPA de 06-04.

Solución 2. (1) kubectl describe pod <nombre>: en Events aparecerá "Readiness probe failed: HTTP probe failed with statuscode: 503" (o timeout). (2) kubectl port-forward pod/<nombre> 3002:3002 y curl localhost:3002/health/ready: el cuerpo dice qué dependencia está mal (postgres o rabbitmq). (3) kubectl get secret pedidos-db -o jsonpath='{.data.PEDIDOS_DB_URL}' | base64 -d (y lo mismo para RabbitMQ) para ver a dónde apunta. Causas más probables: la URL del Secret apunta a un host incorrecto o con credenciales malas (el servicio arranca porque config.js solo valida el formato, pero /health/ready no puede hacer SELECT 1), o la dependencia no es alcanzable desde el namespace (RabbitMQ aún no instalado, Service rabbitmq inexistente). Es el comportamiento deseado: no listo, sin tráfico, sin reinicios en bucle.

Solución 3. Un Job es inmutable y su nombre único: si se reaplicara servicio-pedidos-migraciones con otra image, el API server lo rechazaría. Con la versión en el nombre, cada despliegue crea un Job nuevo, queda registro (kubectl get jobs) y ttlSecondsAfterFinished lo limpia. Si la 1.0.1 no trae migraciones nuevas, el Job arranca, migrar.js consulta migraciones_aplicadas, ve que 001-004 ya están y termina con código 0 sin hacer nada: es idempotente por diseño (04-04), así que no falla; simplemente es un Job de dos segundos. La alternativa de omitir el Job cuando "no hay cambios" exige que alguien lo decida, y la regla de Luis prefiere que sea siempre el mismo pipeline.

Kubernetes ejecuta las imágenes de 05-01 de forma declarativa y continua: un plano de control (API server, etcd, scheduler, controller manager) que reconcilia el estado deseado, y nodos con kubelet, kube-proxy y containerd que lo materializan. Para servicio-pedidos hemos escrito y aplicado en el namespace techcorp el ConfigMap servicio-pedidos-config, los Secret pedidos-db y pedidos-rabbitmq creados con kubectl create secret (base64, no cifrado), un Job versionado que ejecuta scripts/migrar.js con la misma imagen, un Deployment de dos réplicas con envFrom, resources, readinessProbe a /health/ready, livenessProbe a /health/live, terminationGracePeriodSeconds: 30 y runAsNonRoot, y el Service que da el nombre http://servicio-pedidos:3002; el gateway sale al exterior por un Ingress NGINX en api.techcorp.example; RabbitMQ y PostgreSQL van con Helm en dev/kind y gestionados en producción; y Kustomize (base + overlays dev/prod, con images: como el punto que cambiará el pipeline) evita duplicar YAML entre los seis servicios. Todo se ha aplicado a mano con kubectl apply, y eso es precisamente lo que la siguiente lección elimina: un pipeline de CI/CD por servicio que prueba, verifica pactos, construye la imagen y actualiza estos manifiestos sin que nadie escriba un comando.