Un clúster de Kubernetes es un conjunto de procesos que cooperan. Saber qué hace cada uno facilita razonar sobre todo lo demás, desde la programación hasta la resolución de problemas. Esta guía nombra los componentes y luego sigue una sola petición hasta un contenedor en ejecución.

Plano de control y nodos worker

El plano de control toma decisiones sobre el clúster. Los nodos worker ejecutan tus cargas de trabajo. En un clúster local como minikube, un solo nodo cumple ambos papeles. Los clústeres de producción suelen tener varios nodos de plano de control para tener disponibilidad: si pierdes el único, ya no puedes cambiar nada en el clúster, aunque las cargas de trabajo que ya están en ejecución normalmente siguen funcionando durante un tiempo. Los nodos del plano de control normalmente llevan un taint para que tus Pods de aplicación no se programen en ellos.

Componentes del plano de control

• kube-apiserver es la puerta de entrada. Todo cliente (kubectl, dashboards, scripts y los demás componentes) habla con él mediante una API HTTP. Autentica y autoriza peticiones, valida objetos y es el único componente que lee y escribe en etcd.
• etcd es un almacén clave-valor consistente que guarda todo el estado del clúster: qué nodos existen, qué Pods deben ejecutarse, su estado actual. Trátalo como la memoria del clúster. Haz copias de seguridad, porque perderlo significa perder el rastro de todo.
• kube-scheduler elige un nodo para cada Pod que aún no tiene uno, según las solicitudes de recursos, las restricciones y la capacidad disponible.
• kube-controller-manager ejecuta los controladores, los bucles de control que comparan el estado deseado con el real y actúan sobre la diferencia. Los controladores de Deployment, ReplicaSet y Node viven aquí.
• cloud-controller-manager (solo en proveedores de nube) se integra con el proveedor para cosas como balanceadores de carga y el ciclo de vida de los nodos.

Componentes de los nodos

• kubelet es el agente de cada nodo. Vigila los Pods asignados a su nodo, se asegura de que sus contenedores estén en ejecución y sanos, e informa del estado de vuelta.
• Container runtime ejecuta realmente los contenedores. Normalmente es containerd o CRI-O, conectado mediante la Container Runtime Interface. Kubernetes ya no habla directamente con el Docker Engine (dockershim se eliminó en la 1.24), pero las imágenes construidas con Docker siguen funcionando, porque las imágenes siguen el estándar abierto OCI.
• kube-proxy mantiene las reglas de red de cada nodo que hacen que las direcciones de los Services lleguen a los Pods correctos.
• Un plugin de red (CNI) da a los Pods sus direcciones IP y conectividad entre nodos.

Sigue una petición desde kubectl apply hasta un contenedor en ejecución

Supón que aplicas un manifiesto de Deployment. Esto es lo que ocurre:

1. kubectl lee tu kubeconfig y envía el manifiesto al API server por HTTPS.
2. El API server te autentica y autoriza, valida el objeto, lo guarda en etcd y responde.
3. El controlador de Deployment detecta el nuevo Deployment y crea un ReplicaSet, y el controlador de ReplicaSet crea los objetos Pod. En este punto los Pods existen pero no están asignados a un nodo.
4. El scheduler detecta los Pods sin nodo, elige uno para cada uno y registra esa decisión mediante el API server.
5. El kubelet del nodo elegido ve un Pod asignado a él y le dice al container runtime que descargue la imagen e inicie los contenedores.
6. El kubelet informa del progreso al API server, que lo guarda en etcd. Eso es lo que lee kubectl get pods.

Fíjate en que los componentes nunca se llaman directamente entre sí. Cada uno vigila el API server en busca de los objetos que le interesan y reacciona. Ese acoplamiento flexible es la razón por la que puedes reiniciar la mayoría de los componentes sin perder nada: el estado que necesitan está en etcd.

Puedes ver la secuencia en los eventos que registra Kubernetes:

kubectl create deployment demo --image=nginx:1.25
kubectl get events --sort-by=.metadata.creationTimestamp

Busca Scheduled, Pulling, Pulled, Created y Started. Son el scheduler y el kubelet haciendo su parte.

Mira los componentes de tu propio clúster

kubectl get nodes -o wide
kubectl get pods -n kube-system

En minikube y en clústeres construidos con kubeadm verás los componentes del plano de control ejecutándose como Pods en el namespace kube-system, junto a kube-proxy y el plugin de red. En servicios administrados (EKS, GKE, AKS) el proveedor ejecuta el plano de control por ti y solo ves tus nodos worker.

Qué significa este diseño en la práctica

• El API server es el cuello de botella. Todo pasa por él, así que asegurarlo y dimensionarlo importa.
• La salud de etcd es la salud del clúster. Haz copias de seguridad y, en producción, ejecútalo de forma redundante.
• Los fallos se esperan. Un nodo muerto, un componente caído o un Pod eliminado es solo una diferencia entre el estado deseado y el real que un controlador acabará corrigiendo.