Swarm te dio un clúster con las ideas justas y una curva de aprendizaje amable. Kubernetes te da el estándar de la industria a cambio de un vocabulario nuevo. La buena noticia es que los conceptos ya los tienes: estado deseado, reconciliación, réplicas, red entre nodos y secretos montados como ficheros. Esta lección pone nombres nuevos a ideas conocidas y añade las que faltan, sin desplegar todavía Aurora Libros entera.

1. Por qué existe Kubernetes y qué añade
2. El modelo declarativo y los controladores
3. Arquitectura del clúster
4. El runtime tras dockershim: CRI y OCI
5. Los objetos fundamentales de un vistazo
6. Pod: la unidad de despliegue
7. ReplicaSet y Deployment
8. Service, sus tipos e Ingress
9. ConfigMap y Secret
10. Namespace
11. PersistentVolume, PersistentVolumeClaim y StorageClass
12. Job, CronJob, StatefulSet y DaemonSet
13. Anatomía de un manifiesto: etiquetas y selectores
14. kubectl esencial, traducido desde Docker
15. Un clúster local para practicar
16. Glosario Docker → Kubernetes

Kubernetes nació en Google a partir de la experiencia de Borg y se donó a la CNCF en 2015. Su objetivo no era mejorar Swarm, sino resolver la orquestación a escala de miles de nodos y de equipos, y por eso su diseño es más ambicioso y también más complejo.

La última fila es la que decide en la mayoría de las organizaciones. La primera es la que más cambia tu forma de pensar, y es la que veremos a fondo.

El corazón conceptual es idéntico al de Swarm: describes el estado deseado y el sistema lo mantiene. La diferencia es que Kubernetes lo generaliza: todo es un objeto en una base de datos (etcd), y por cada tipo de objeto hay un controlador ejecutando el mismo bucle.

Ese patrón se llama reconciliation loop, y explica comportamientos que al principio desconciertan:

• Borras un Pod creado por un Deployment y reaparece: su controlador ve que faltan réplicas.
• Editas un Pod a mano y tu cambio desaparece en el siguiente despliegue: la fuente de verdad es la plantilla del Deployment.
• Aplicas un manifiesto dos veces y no pasa nada: no describes acciones, describes destinos. La operación es idempotente.

Fíjate en la propiedad que hace robusto el diseño: nadie habla con nadie salvo con el kube-apiserver. El scheduler no llama al kubelet; escribe en la API que un Pod va a cierto nodo, y el kubelet de ese nodo, que está observando la API, actúa. Todo pasa por el mismo punto de autenticación y auditoría.

En 2022, Kubernetes 1.24 eliminó dockershim, el adaptador que le permitía usar Docker Engine como runtime. Aquello generó titulares del tipo "Kubernetes elimina Docker" que confundieron a todo el mundo.

Lo que ocurrió en realidad es mucho menos dramático:

• Kubernetes habla con los runtimes por una interfaz llamada CRI (Container Runtime Interface).
• Docker Engine no implementa CRI, así que hacía falta un adaptador (dockershim) mantenido por el propio proyecto.
• Ese adaptador se retiró, y los nodos usan containerd o CRI-O directamente, que sí hablan CRI. Y containerd es, precisamente, el mismo componente que usa Docker Engine por dentro desde 01-03.

Tus imágenes siguen valiendo exactamente igual. Lo que construyes con docker build es una imagen OCI, un formato estándar, no un formato "de Docker". La ghcr.io/auroralibros/aurora-api:2.0.0 que produjo tu pipeline se ejecuta en containerd sin ninguna modificación. Lo único que cambió es qué programa la arranca en el nodo.

Un Pod es un grupo de contenedores que comparten namespace de red (misma IP, se hablan por localhost), namespace IPC y, opcionalmente, volúmenes. Es la unidad que el scheduler coloca y que se escala: en Kubernetes no se replican contenedores, se replican Pods.

Casi nunca se crea un Pod a mano, por una razón contundente: un Pod no se recupera. Si el nodo muere, el Pod muere con él y nadie lo recrea; es el equivalente exacto de un docker run sin --restart. Lo que se crea es un Deployment, que a través de su ReplicaSet garantiza que siempre haya tantos Pods como pediste.

La mayoría de los Pods tienen un solo contenedor. El caso multicontenedor es el patrón sidecar: un contenedor auxiliar que acompaña al principal —un recolector de logs, un proxy de malla de servicios, un sincronizador de ficheros— y se beneficia de compartir red y volúmenes.

La cadena de responsabilidad tiene tres eslabones, y entenderla evita mucha confusión:

El ReplicaSet solo sabe contar: mantiene N Pods que casen con su selector. El Deployment gestiona ReplicaSets: al cambiar la imagen crea uno nuevo, lo va llenando mientras vacía el antiguo, y conserva el viejo con cero réplicas para poder deshacer. Ese ReplicaSet vacío que ves en kubectl get rs no es basura: es tu historial de rollback (06-07).

Un aviso: el selector de un Deployment es inmutable. Si lo cambias, hay que borrar y recrear el objeto. Conviene elegir bien las etiquetas la primera vez.

Los Pods son ganado, no mascotas: nacen y mueren con IPs distintas. Un Service aporta una IP virtual y un nombre DNS estables delante de un conjunto cambiante de Pods, seleccionados —de nuevo— por etiquetas.

Los Pods llegan por DNS con aurora-cache dentro del namespace, o aurora-cache.aurora.svc.cluster.local desde fuera de él: es el equivalente del DNS por nombre de servicio de Compose y Swarm.

Un LoadBalancer por servicio se vuelve caro enseguida: cada uno es un balanceador facturado del proveedor. La solución estándar es un Ingress: un único punto de entrada que enruta por host y por ruta hacia varios Services.

Detalle que causa desconcierto la primera vez: el objeto Ingress no hace nada por sí solo. Es una declaración de intenciones que necesita un ingress controller instalado en el clúster (ingress-nginx, Traefik, HAProxy...) que la lea y configure el proxy real. Sin controlador, el objeto existe, no da error y el tráfico no llega a ninguna parte.

Ambos se consumen igual, y hay dos formas con implicaciones distintas:

Advertencia importante sobre Secret. Un Secret de Kubernetes está en base64, que no es cifrado: cualquiera con permiso de lectura sobre el objeto ve el valor con un base64 -d. Además, etcd no cifra en reposo salvo que se active explícitamente. Para producción hay que activar el cifrado en reposo, restringir el acceso con RBAC y valorar un gestor externo (Vault, Sealed Secrets, el gestor de secretos del proveedor cloud con el driver CSI). Es una decisión que debes acordar con el responsable de seguridad de tu organización, no un ajuste por defecto aceptable.

Y una diferencia práctica frente a Swarm: montado como volumen, un Secret o ConfigMap actualizado se propaga al fichero del Pod sin reiniciarlo (con retardo de hasta un minuto); inyectado como variable de entorno, no se actualiza nunca hasta que el Pod se recrea.

Un Namespace es una partición lógica del clúster. Da tres cosas: nombres que no colisionan (puede haber un aurora-api en aurora y otro en aurora-staging), un ámbito para RBAC y cuotas, y un límite de red si usas NetworkPolicy. No es un límite de seguridad fuerte por sí mismo: no aísla el kernel, solo la API.

Con kubectl config set-context --current --namespace=aurora te evitas escribir -n aurora en cada comando.

Kubernetes separa quién pide almacenamiento de quién lo proporciona, que es justo lo que faltaba en Swarm.

Casi todos los discos de bloque de los proveedores cloud son RWO, y de ahí sale un límite muy real: un PVC de ese tipo no puede montarse a la vez en Pods de nodos distintos. Es la razón técnica por la que aurora-db no se escala replicando Pods, y la trataremos en 06-06.

El DaemonSet es literalmente el mode: global de Swarm. El StatefulSet es lo que Swarm no tenía: cada réplica recibe un nombre estable y su propio volumen, sobrevive al reinicio con la misma identidad y se arranca y se para en orden. Es lo que necesita cualquier cosa con estado, y lo usarás en 06-05.

Todos los objetos comparten cuatro campos de primer nivel:

Y ahora lo más importante de toda la lección. En Kubernetes los objetos no se referencian por nombre, sino por etiquetas. Un Service no dice "manda tráfico a los Pods del Deployment aurora-api"; dice "manda tráfico a todo Pod con la etiqueta app: aurora-api".

Ese acoplamiento débil es potente y frágil a la vez. Potente porque permite cosas como dirigir tráfico a Pods de dos Deployments distintos a la vez, que es la base del blue-green y del canario de 06-07. Frágil porque una errata en una etiqueta no da ningún error: el Service simplemente no encuentra Pods, se queda sin endpoints y el tráfico devuelve 503. Es el fallo silencioso más común, y se diagnostica siempre igual: kubectl get endpoints <servicio>.

Las etiquetas recomendadas por la comunidad, que conviene adoptar desde el principio:

Dos comandos merecen destacarse. kubectl explain es la documentación oficial sin salir del terminal y sirve para cualquier campo de cualquier objeto, incluidos los que instales después. Y kubectl describe termina con una lista de eventos que casi siempre contiene la causa exacta del problema: por qué el scheduler no encuentra nodo, por qué falla la descarga de la imagen o por qué una sonda no pasa.

• Crear Pods sueltos. Nadie los recrea si el nodo cae. Salvo para una prueba de treinta segundos, usa siempre un Deployment.
• Selector y etiquetas que no casan. El error más frecuente y el más silencioso: el Deployment crea Pods que su Service no encuentra. Verifica con kubectl get endpoints.
• Creer que un Secret está cifrado. Es base64. Actívale el cifrado en reposo y protégelo con RBAC.
• Esperar que un Ingress funcione sin controlador. El objeto se crea sin quejarse y no enruta nada.
• Olvidar el namespace. kubectl get pods mira el namespace por defecto y parece que no hay nada. Fija el contexto o usa -n.
• Definir limits sin requests. Kubernetes copia el límite en la petición y reservas mucho más de lo que necesitas.
• Editar Pods con kubectl edit. El cambio dura hasta el siguiente despliegue. Modifica el Deployment.
• Consejo: kubectl describe antes que kubectl logs. Si el Pod no arranca, no hay logs; la causa está en los eventos.
• Consejo: kubectl apply --dry-run=server -f . valida los manifiestos contra la API real sin crear nada. Úsalo en el pipeline.

Ejercicio 1. Monta un clúster kind de tres nodos, despliega aurora-cache con un Deployment y su Service ClusterIP, y comprueba desde otro Pod que el nombre aurora-cache resuelve y responde.

Ejercicio 2. Demuestra el bucle de reconciliación y la diferencia entre Pod suelto y Deployment: crea un Pod a mano y otro gestionado por un Deployment, bórralos y observa qué ocurre con cada uno.

Ejercicio 3. Provoca a propósito el fallo silencioso de las etiquetas: cambia el selector de un Service para que no case con ningún Pod y diagnostícalo sin mirar el manifiesto.

Solución 1.

En una sola salida está la cadena entera de la sección 7: un Deployment que ha creado un ReplicaSet cuyo nombre lleva el sufijo 6b8d4c9f7 —el hash de la plantilla del Pod—, y ese ReplicaSet ha creado un Pod que hereda el hash y añade un sufijo aleatorio. Ese hash es la pieza clave del despliegue progresivo: cambiar la imagen produce otro hash y, por tanto, un ReplicaSet nuevo.

El nombre corto y el completo resuelven a la misma IP, que es la IP virtual del Service, no la del Pod. Esa distinción es la que hace que los Pods puedan morir y renacer con otras direcciones sin que nadie tenga que enterarse: el cliente habla siempre con el Service. Es el mismo servicio que te daba el DNS interno de Compose y Swarm, con una diferencia importante: aquí lo proporciona un objeto explícito que puedes inspeccionar y modificar.

Solución 2.

Borraste dos Pods y solo uno volvió, con nombre distinto y cinco segundos de edad. La columna DUENO explica exactamente por qué: el Pod suelto no tiene ownerReferences, así que al borrarlo nadie echó nada en falta; los otros pertenecen a un ReplicaSet cuyo controlador observa la API, vio que tenía un Pod donde debía haber dos y creó uno nuevo.

Esa es la razón práctica de la regla de la sección 6. Un Pod suelto es equivalente a un docker run sin política de reinicio: sobrevive mientras nada lo moleste, y desaparece con su nodo. El detalle del nombre distinto también importa, porque revela que el Pod no se "reinicia": se crea otro, con otra IP, y por eso ninguna configuración puede depender de la identidad de un Pod concreto. Cuando esa identidad sí hace falta —como en aurora-db— existe el StatefulSet.

Solución 3.

El diagnóstico, sin abrir ningún fichero:

Los ENDPOINTS a <none> son el síntoma decisivo, y la secuencia de tres comandos es la que hay que memorizar: el Service existe, tiene su IP virtual, el DNS resuelve perfectamente... y detrás no hay ningún Pod. Comparando el selector (app=aurora-cach) con las etiquetas reales (app=aurora-cache) aparece la letra que falta.

Lo pedagógico del ejercicio es lo que no ocurrió: ni el kubectl patch ni el kubectl get svc ni el describe del Deployment dieron el más mínimo aviso. Kubernetes no valida que un selector encuentre algo, porque un Service que aún no tiene Pods es una situación legítima —los tendrá cuando se desplieguen—. El precio de ese acoplamiento débil, que en 06-07 te permitirá conmutar tráfico entre dos versiones cambiando una etiqueta, es que una errata se manifiesta como un 503 en producción y no como un error al aplicar el manifiesto.

De ahí la regla de operación: después de cada kubectl apply que toque un Service, comprueba sus endpoints. Es un comando y evita la clase de incidente más frustrante de esta plataforma.

Ya hablas Kubernetes. Sabes que su corazón es el mismo bucle de reconciliación de Swarm, generalizado a todos los objetos de etcd, y que eso explica que un Pod borrado reaparezca y que un apply repetido no haga nada. Conoces la arquitectura —kube-apiserver como única puerta, etcd como estado, el planificador, los controladores, y en cada nodo el kubelet y el kube-proxy— y la propiedad que la hace robusta: nadie habla con nadie salvo con la API. Y tienes zanjado el malentendido de dockershim: Kubernetes ejecuta containerd por CRI, pero tus imágenes valen igual porque son OCI.

Manejas el catálogo de objetos con su YAML mínimo: el Pod como unidad y por qué no se crea a mano, la cadena Deployment → ReplicaSet → Pods donde el ReplicaSet vacío es tu historial de rollback, el Service con sus cinco variantes y el Ingress que no enruta nada sin un controlador instalado, ConfigMap y Secret —con la advertencia de que base64 no es cifrado—, el Namespace, la tríada PVC/PV/StorageClass con los modos de acceso que explicarán en 06-06 por qué una base de datos no se replica sin más, y los cuatro controladores restantes, entre ellos el DaemonSet que es el mode: global de Swarm y el StatefulSet que Swarm no tenía.

Sobre todo, has interiorizado la pieza central: etiquetas y selectores. Todo se conecta por etiquetas, nunca por nombre, y lo has comprobado rompiendo un selector a propósito para ver el fallo más silencioso de la plataforma —un Service perfectamente sano con ENDPOINTS <none>— y diagnosticándolo con tres comandos. Traduces cada operación de Docker a su kubectl equivalente, tienes un clúster kind de tres nodos con aurora-cache corriendo dentro, y un glosario que convierte lo que ya sabías en lo que acabas de aprender.

En la siguiente lección, Desplegando Contenedores Docker en Kubernetes, llega la aplicación entera. Escribirás los manifiestos reales de los cuatro servicios: el StatefulSet de aurora-db con sus volumeClaimTemplates y su Service headless, el Deployment de aurora-api con las tres sondas de 06-01, su securityContext endurecido y su configuración inyectada, el Ingress de aurora-web, y los organizarás con Kustomize en bases y overlays por entorno, con la tabla de estados de un Pod —Pending, ImagePullBackOff, CrashLoopBackOff, OOMKilled— y su comando de diagnóstico para cuando algo no arranque.