En la lección anterior cerramos con una promesa: sabes qué hace Kubernetes —mantener de forma continua el estado que le declaras— y ahora toca ver cómo lo hace. Un clúster no es una caja mágica: son seis o siete procesos con responsabilidades muy delimitadas que se comunican siempre a través de un único punto central. Entender esa arquitectura es lo que después te permitirá diagnosticar problemas en lugar de reiniciar cosas al azar: cuando un pod se queda en Pending, cuando un despliegue no avanza o cuando el clúster deja de responder, la causa está casi siempre en una pieza concreta y esta lección te enseña cuál. Terminaremos siguiendo, paso a paso, todo lo que ocurre desde que ejecutas kubectl apply -f api-reservas.yaml hasta que el contenedor de api-reservas está sirviendo peticiones en un nodo.

1. Visión general: plano de control y nodos de trabajo
2. Los componentes del plano de control
3. Los componentes de los nodos de trabajo
4. El bucle de reconciliación: la idea central
5. Recorrido completo de kubectl apply
6. Qué pasa cuando falla cada pieza
7. Alta disponibilidad del plano de control

Un clúster de Kubernetes se divide en dos mitades con papeles muy distintos:

• El plano de control (control plane): es el cerebro. Decide, registra y vigila. No ejecuta las aplicaciones de los usuarios (salvo en clústeres de un solo nodo como minikube).
• Los nodos de trabajo (worker nodes): son los músculos. Ejecutan los contenedores de tus aplicaciones y reportan su estado.

Fíjate en la propiedad más importante del diagrama: todas las flechas pasan por kube-apiserver. Ningún componente habla directamente con otro. El scheduler no llama al kubelet; el kubelet no consulta etcd. Todos leen y escriben en la API, y esa API es la única que toca etcd. Esta topología en estrella es lo que hace el sistema extensible: para añadir una funcionalidad nueva basta con escribir un proceso que observe la API y actúe (eso es un controlador, y es exactamente lo que hacen los operadores del módulo 6).

Es el frontal REST de todo el clúster y el único componente que escribe en etcd. Todo lo que ocurre en Kubernetes es una petición HTTP contra este servidor.

Sus responsabilidades, en el orden en que se aplican a cada petición:

1. Autenticación: ¿quién eres? (certificado de cliente, token, OIDC…).
2. Autorización: ¿puedes hacer esto? Es donde actúa RBAC (módulo 8).
3. Control de admisión: modificar o rechazar el objeto antes de guardarlo (por ejemplo, inyectar valores por defecto, aplicar cuotas o rechazar imágenes no firmadas).
4. Validación del esquema del objeto.
5. Persistencia en etcd.
6. Notificación a todos los componentes suscritos mediante el mecanismo de watch.

Es sin estado y horizontalmente escalable: puedes tener tres réplicas detrás de un balanceador.

Es una base de datos clave-valor distribuida y consistente, basada en el algoritmo de consenso Raft. Guarda absolutamente todo el estado del clúster: objetos, configuración, secretos y estado observado.

Puntos que debes retener:

• Es la única fuente de verdad. Si pierdes etcd sin copia de seguridad, has perdido el clúster (no las aplicaciones ya corriendo, pero sí toda su definición).
• Se despliega en número impar de miembros (3 o 5) para poder formar quórum.
• Es sensible a la latencia de disco: se recomienda SSD dedicado. Es el cuello de botella habitual en clústeres grandes.
• Su copia de seguridad (etcdctl snapshot save) es la copia de seguridad del clúster, y es materia de examen en la CKA (módulo 12).

Su trabajo es una sola cosa, y la hace muy bien: decidir en qué nodo se ejecuta cada pod recién creado. Observa continuamente la API buscando pods sin nodeName asignado y, para cada uno, ejecuta dos fases:

El resultado no es "arrancar el contenedor": es simplemente escribir el campo spec.nodeName del pod en la API. El scheduler nunca contacta con el nodo. Los criterios avanzados (afinidad, taints, tolerations) se estudian en el módulo 6.

Es un único binario que ejecuta decenas de controladores en paralelo, cada uno con su propio bucle de reconciliación. Los más relevantes para el curso:

Cuando en el módulo 2 escribas un Deployment con replicas: 3 y veas aparecer tres pods, quien los ha creado ha sido este proceso.

Aísla todo lo que depende del proveedor de nube, de modo que el núcleo de Kubernetes no tenga código de AWS, Azure o GCP. Se encarga de:

• Nodos: consultar al proveedor si una máquina virtual ha sido eliminada realmente.
• Balanceadores: cuando creas un Service de tipo LoadBalancer, es quien pide el balanceador real a la nube (módulo 4).
• Rutas: configurar el enrutado entre nodos en la red del proveedor.

En minikube o kind no existe, y por eso un Service de tipo LoadBalancer se queda con la IP externa en <pending> salvo que uses minikube tunnel. Es una fuente clásica de confusión que veremos en su momento.

Es el agente que corre en cada nodo y el único que realmente arranca contenedores. Su bucle es:

1. Preguntar a la API qué pods le han sido asignados (spec.nodeName == este nodo).
2. Comparar con lo que hay corriendo en la máquina.
3. Pedir al runtime de contenedores, vía CRI, que arranque o pare lo que haga falta.
4. Montar volúmenes, inyectar ConfigMaps y Secrets, aplicar límites de recursos.
5. Ejecutar las sondas de salud (módulo 7) y reiniciar contenedores fallidos.
6. Reportar continuamente el estado del nodo y de sus pods a la API.

Importante: el kubelet solo obedece a la API, no acepta órdenes de nadie más. Y solo gestiona pods, no contenedores sueltos: si arrancas un contenedor con docker run en un nodo, el kubelet lo ignora.

Implementa el concepto de Service a nivel de red en cada nodo. Observa los Services y sus EndpointSlices y programa reglas de red (iptables o, en clústeres grandes, IPVS) para que el tráfico dirigido a la IP virtual de un servicio se reparta entre los pods sanos.

No es un proxy en el camino de los datos en el modo habitual: escribe reglas del kernel y se aparta. Algunos plugins de red modernos (Cilium en modo eBPF) lo sustituyen por completo. Se estudia en el módulo 4.

El kubelet no sabe crear contenedores: delega en un runtime a través de la CRI (Container Runtime Interface), una API gRPC estándar. Los runtimes habituales:

Debajo del runtime hay otro nivel (runc) que es quien realmente habla con el kernel (namespaces y cgroups). Ese detalle no lo necesitas para operar, pero explica la frase "Kubernetes ya no usa Docker": las imágenes que construyes con Docker siguen funcionando perfectamente porque cumplen el estándar OCI.

Dos interfaces más que conviene nombrar ya:

• CNI (Container Network Interface): el plugin que asigna IPs a los pods y hace que se vean entre nodos. Calico, Cilium, Flannel. Sin CNI instalado, los nodos se quedan en NotReady. Módulo 4.
• CSI (Container Storage Interface): el plugin que aprovisiona discos reales para los volúmenes persistentes. Módulo 5.

Si te quedas con una sola idea de esta lección, que sea esta. Todos los controladores de Kubernetes ejecutan el mismo patrón:

Consecuencias prácticas de este diseño, que explican muchos comportamientos que te encontrarás:

• spec lo escribes tú; status lo escribe el sistema. Nunca edites un status a mano.
• Es nivel, no evento. El controlador no reacciona a "se ha borrado un pod": compara la foto actual con la deseada. Por eso el sistema se recupera aunque se pierda un mensaje o un controlador se reinicie.
• Es idempotente. Aplicar el mismo manifiesto diez veces produce el mismo resultado que aplicarlo una.
• La corrección manual no dura. Si borras un pod gestionado por un ReplicaSet, vuelve en segundos. Para que desaparezca hay que cambiar el estado deseado.
• Los fallos son "eventualmente consistentes". Entre que declaras algo y se cumple pasa un tiempo; por eso los objetos tienen condiciones y eventos, y por eso kubectl get a veces muestra estados intermedios.

Vamos a seguir una petición real de Rutas Norte. Supón este fichero mínimo en el directorio k8s/ del repositorio (los detalles del formato se ven en la lección Objetos, Manifiestos YAML y el Modelo Declarativo):

Y lo aplicas:

Detrás de esa línea de salida han ocurrido doce pasos.

Paso a paso, con detalle:

1. kubectl lee tu kubeconfig para saber a qué clúster hablar, con qué credenciales y en qué namespace.
2. Convierte el YAML a JSON y lo envía como POST (o PATCH si el objeto ya existía) sobre HTTPS al endpoint del recurso.
3. Autenticación. El apiserver valida tu certificado de cliente o token. Si falla: error: You must be logged in to the server (Unauthorized).
4. Autorización. RBAC comprueba si tu usuario puede hacer create pods en el namespace rutas-norte-dev. Si falla: Error from server (Forbidden).
5. Control de admisión. Se ejecutan los admission controllers en dos tandas: primero los mutantes (añaden valores por defecto, la ServiceAccount, límites de un LimitRange…) y después los validantes (ResourceQuota, Pod Security Standards, webhooks propios). Cualquiera puede rechazar la petición.
6. Escritura en etcd. El objeto se guarda. En este momento el pod ya existe como objeto, aunque no haya ningún contenedor en marcha. Su estado es Pending y su spec.nodeName está vacío.
7. etcd confirma la escritura por consenso Raft.
8. El apiserver responde a kubectl con 201 Created. Aquí termina tu comando: kubectl apply no espera a que el contenedor arranque.
9. El scheduler recibe la notificación por su watch sobre pods sin nodo asignado.
10. El scheduler decide. Filtra los nodos sin recursos suficientes o incompatibles, puntúa los restantes, elige nodo-2 y escribe el binding en la API. El pod sigue en Pending, pero ya tiene destino.
11. El kubelet de nodo-2 se entera por su propio watch y toma el control.
12. El kubelet ejecuta: pide al runtime, vía CRI, que descargue registry.rutasnorte.example/api-reservas:2.4.0 (estado ContainerCreating, o ImagePullBackOff si el registro rechaza la descarga), crea el sandbox de red pidiendo una IP al plugin CNI, monta volúmenes y secretos, y arranca el contenedor. Después informa a la API: status.phase = Running.

A partir de ahí, el kubelet vigila el contenedor de forma permanente y el bucle de reconciliación sigue vivo hasta que el objeto se borre.

Esta tabla es oro puro para diagnosticar incidencias, y una pregunta recurrente en entrevistas y certificaciones.

La conclusión operativa es tranquilizadora: el plano de control es el cerebro, no el corazón. Si se cae, el clúster deja de cambiar, pero no deja de servir. Esto es un diseño deliberado y explica por qué una caída del plano de control es grave pero rara vez es una caída del servicio.

Un clúster de prácticas tiene un solo nodo de control. Un clúster de producción, como el que Rutas Norte querrá para su namespace rutas-norte-pro, necesita tolerar la pérdida de una máquina del plano de control.

El esquema estándar:

• 3 nodos de plano de control (número impar, por el quórum de etcd).
• kube-apiserver replicado en los tres, detrás de un balanceador o de un keepalived con IP virtual. Al ser sin estado, escala en activo-activo.
• etcd en 3 miembros. Tolera la pérdida de 1. Con 5 miembros tolera 2. Con 2 miembros no tolera ninguno: nunca uses un número par.
• scheduler y controller-manager en activo-pasivo. Se ejecutan los tres, pero solo uno actúa: eligen líder mediante un objeto Lease en la API. Es imprescindible que solo uno reconcilie, o crearían pods por duplicado.
• etcd apilado o externo: apilado (stacked, etcd en las mismas máquinas de control) es lo habitual y más sencillo; externo aísla el fallo y se usa en clústeres grandes.

Además, en un clúster gestionado (EKS, AKS, GKE, módulo 10-06) el proveedor opera todo esto por ti y ni siquiera ves las máquinas del plano de control: pagas una cuota y solo administras los nodos de trabajo. Para la mayoría de las empresas, incluida Rutas Norte, esa es la opción sensata.

• Creer que el scheduler arranca contenedores. No: solo escribe un nombre de nodo. Quien arranca es el kubelet. Si un pod está en Pending, el problema es del scheduler (no cabe en ningún nodo); si está en ContainerCreating o ImagePullBackOff, el problema es del kubelet o del runtime.
• Pensar que kubectl apply espera a que la aplicación esté lista. Devuelve en cuanto el objeto se guarda en etcd. Para esperar de verdad, se usa kubectl rollout status o kubectl wait.
• Modificar recursos a mano en un nodo. Parar un contenedor con crictl o docker no sirve de nada: el kubelet lo recrea. Siempre se actúa sobre la API.
• Olvidar la copia de seguridad de etcd. Es el único componente cuyo dato es irremplazable. Sin snapshot, un desastre en etcd equivale a reconstruir el clúster desde los manifiestos (razón adicional para tenerlos todos en Git).
• Poner 2 miembros de etcd "para tener redundancia". Empeora la disponibilidad: con 2 miembros el quórum es 2, así que perder uno bloquea el clúster. Siempre impar.
• Consejo de diagnóstico: ante cualquier problema, recorre la cadena en orden — ¿el objeto existe en la API? (kubectl get) → ¿tiene nodo asignado? (kubectl get pod -o wide) → ¿qué dice el kubelet? (kubectl describe pod, sección Events). Ese orden replica exactamente el recorrido de la sección 5.

Para cada síntoma observado en el clúster de Rutas Norte, indica qué componente es el principal sospechoso y por qué:

1. El pod api-reservas lleva 10 minutos en Pending y describe dice 0/3 nodes are available: insufficient memory.
2. kubectl get pods devuelve Unable to connect to the server: dial tcp ... connection refused.
3. Se borra a mano un pod de tienda-web gestionado por un ReplicaSet y no se recrea, pero el resto del clúster responde bien.
4. El pod worker-notificaciones está ContainerCreating desde hace 5 minutos con el evento failed to pull image ... unauthorized.
5. Un nodo aparece como NotReady y a los pocos minutos sus pods aparecen en otros nodos.

Ordena estos ocho pasos, que están desordenados, y señala en cuál de ellos el pod pasa de Pending a ContainerCreating:

• a) El kubelet pide al runtime que cree el contenedor vía CRI.
• b) El apiserver escribe el objeto en etcd.
• c) RBAC comprueba los permisos del usuario.
• d) El scheduler escribe spec.nodeName.
• e) kubectl envía la petición HTTPS.
• f) Se ejecutan los admission controllers.
• g) El apiserver responde 201 Created.
• h) El kubelet recibe el evento del watch.

Rutas Norte quiere un clúster propio para rutas-norte-pro que tolere la caída de una máquina completa del plano de control. Indica: cuántos nodos de control usarías, cuántos miembros de etcd, cómo se accede al apiserver, en qué modo trabajan scheduler y controller-manager, y explica en dos líneas qué pasaría con la tienda web durante los 3 minutos en que el plano de control estuviera completamente caído.

Solución 1

1. kube-scheduler (junto con la capacidad de los nodos). El pod se creó correctamente en la API, pero ningún nodo pasa la fase de filtrado por falta de memoria. La solución es reducir los requests del pod o añadir capacidad.
2. kube-apiserver (o la red hacia él). connection refused significa que kubectl ni siquiera llega a autenticarse: el proceso no está escuchando o el endpoint del kubeconfig es incorrecto.
3. kube-controller-manager. El controlador de ReplicaSet es quien recrea las réplicas; si el resto funciona pero nada se reconcilia, el sospechoso es el controller-manager (o su elección de líder).
4. kubelet y runtime de contenedores, con causa raíz en las credenciales del registro. El pod ya tiene nodo asignado; el fallo es al descargar la imagen (falta el imagePullSecret).
5. kubelet de ese nodo (o la red del nodo). Al dejar de reportar, el controlador de nodos lo marca NotReady y, pasado el periodo de tolerancia, desaloja sus pods para que se recreen en otro sitio. Comportamiento esperado, no un error.

Solución 2

Orden correcto: e → c → f → b → g → d → h → a.

• e) petición HTTPS
• c) autenticación y autorización RBAC
• f) admisión (mutación y validación)
• b) escritura en etcd → el pod existe en Pending
• g) respuesta 201 Created a kubectl
• d) el scheduler asigna nodo → sigue Pending, pero ya con destino
• h) el kubelet recibe el evento
• a) el kubelet crea el contenedor → aquí el pod pasa a ContainerCreating y después a Running

Solución 3

• 3 nodos de plano de control y 3 miembros de etcd (topología apilada): con quórum de 2, se tolera la pérdida de 1 máquina.
• Acceso al apiserver a través de un balanceador o IP virtual (keepalived + HAProxy) que reparta entre las tres réplicas; el kubeconfig apunta a ese punto único, no a una máquina concreta.
• kube-scheduler y kube-controller-manager en activo-pasivo, con elección de líder mediante Lease: los tres procesos corren, pero solo el líder reconcilia, para evitar duplicar acciones.
• Durante 3 minutos sin plano de control, la tienda web sigue funcionando con normalidad: los pods ya están corriendo en los nodos y kube-proxy conserva sus reglas de red. Lo que no ocurre en esos 3 minutos es cambio: no se pueden desplegar versiones, ni escalar, ni recrear pods caídos, ni ejecutar kubectl.

Un clúster de Kubernetes es un conjunto de procesos con responsabilidades muy estrictas que se comunican exclusivamente a través del kube-apiserver, con etcd como única fuente de verdad. El plano de control decide (apiserver, scheduler, controller-manager, cloud-controller-manager) y los nodos ejecutan (kubelet, kube-proxy, runtime vía CRI). El pegamento conceptual es el bucle de reconciliación: comparar el estado deseado que tú declaras con el estado real observado y actuar hasta que coincidan, de forma continua e idempotente. Con ese mapa mental ya puedes razonar sobre incidencias en lugar de adivinar, y sabes por qué la caída del plano de control detiene los cambios pero no el servicio.

Tenemos la arquitectura; nos falta el vocabulario. En las próximas lecciones aparecerán constantemente términos como pod, ReplicaSet, Service, PVC o namespace, y conviene tener un mapa claro de qué es cada cosa y cómo se relacionan entre sí antes de usarlos. Eso es lo que ordena la siguiente lección: Conceptos y Terminología Clave.