Un clúster de Kubernetes se divide en dos roles. El control plane (plano de control) almacena el estado deseado de todo lo que hay en el clúster y toma decisiones sobre él. Los worker nodes (nodos de trabajo) son los que realmente ejecutan tus contenedores. Casi todas las tareas de troubleshooting del CKA se reducen a saber qué componente se encarga de qué trabajo, así que vale la pena aprender este mapa antes que cualquier otra cosa.
El kube-apiserver es la puerta de entrada. Todos los clientes, desde kubectl hasta el scheduler y el kubelet de cada nodo, se comunican con el clúster únicamente a través del API server por HTTPS (en un clúster de kubeadm, el puerto 6443). El API server autentica a quien llama, verifica la autorización (normalmente RBAC, control de acceso basado en roles), ejecuta los admission controllers que pueden rechazar o modificar una solicitud y luego persiste el objeto. Es el único componente que habla directamente con etcd.
etcd es un almacén clave-valor distribuido y fuertemente consistente que guarda todo el estado del clúster: cada Pod, Service, Secret y ConfigMap. Si pierdes etcd y no tienes un backup, la configuración del clúster desaparece aunque los contenedores sigan ejecutándose por un tiempo. Por eso el backup de etcd es un objetivo propio del examen. etcd atiende a los clientes en el puerto 2379 y se comunica con sus pares en el 2380.
El kube-scheduler vigila los Pods que no tienen un nodo asignado. Para cada uno, descarta los nodos que no pueden ejecutarlo (CPU insuficiente, un taint que el Pod no tolera, una regla de affinity que no coincide) y luego puntúa los restantes, para finalmente escribir el nombre del nodo elegido en el spec.nodeName del Pod. El scheduler no inicia contenedores; solo toma la decisión de ubicación.
El kube-controller-manager ejecuta muchos bucles de control en un solo proceso: el controlador de ReplicaSet, el de Deployment, el de Node, el de Job, el de EndpointSlice, el de ServiceAccount y otros. Cada bucle compara el estado deseado con el estado real y actúa para cerrar la brecha. Si este componente está caído, no se crean nuevos Pods para los Deployments, pero los Pods existentes siguen ejecutándose.
En cada nodo, el kubelet es el agente que hace realidad la parte del estado deseado que le corresponde a ese nodo. Vigila el API server buscando Pods asignados a su nodo, le pide al container runtime que descargue imágenes e inicie contenedores, ejecuta los probes y reporta de vuelta el estado de los Pods y del nodo. El kubelet es un servicio de systemd, no un Pod, así que lo inspeccionas con systemctl status kubelet y journalctl -u kubelet. El container runtime (containerd o CRI-O) hace el trabajo de bajo nivel de crear contenedores, y el kubelet se comunica con él mediante la Container Runtime Interface (CRI).
kube-proxy se ejecuta en cada nodo (normalmente como un DaemonSet) y programa reglas de reenvío de paquetes para que el tráfico enviado a la IP virtual de un Service llegue a uno de los Pods que respaldan ese Service. En un clúster de kubeadm, el API server, etcd, el scheduler y el controller-manager se ejecutan como static Pods en el namespace kube-system, que puedes ver con kubectl get pods -n kube-system.
Términos clave
- kube-apiserver
- La API REST central del clúster; el único componente que lee y escribe en etcd, y con el que se comunican todos los demás componentes.
- etcd
- Un almacén clave-valor consistente y distribuido que guarda todo el estado del clúster.
- kube-scheduler
- Asigna los Pods no programados a nodos filtrando y puntuando los nodos candidatos.
- kube-controller-manager
- Un único binario que ejecuta muchos bucles de reconciliación, como los controladores de ReplicaSet, Node y Job.
- kubelet
- El agente del nodo, ejecutado por systemd, que inicia los Pods a través del container runtime y reporta su estado.
- kube-proxy
- El componente por nodo que programa las reglas de reenvío para las IP virtuales de los Services.
Un estudiante escala un Deployment de 2 a 5 réplicas y no pasa nada: el ReplicaSet sigue mostrando 2. kubectl get pods -n kube-system muestra el Pod de kube-controller-manager en CrashLoopBackOff por un error de tipeo en su manifiesto de static Pod. Al corregir el manifiesto, el controlador vuelve a funcionar y los tres Pods nuevos aparecen en segundos.
Comprueba lo que sabes
¿Cuál es el único componente que se comunica directamente con etcd?
El kube-apiserver. Todos los demás componentes leen y escriben el estado del clúster a través del API server.
¿Por qué no puedes ver el kubelet con kubectl get pods -n kube-system?
El kubelet se ejecuta como un servicio de systemd en el host, no como un Pod, así que lo revisas con systemctl y journalctl.
Si el scheduler está detenido, ¿qué les pasa a los Pods de un Deployment recién creado?
El controlador de ReplicaSet igual crea los objetos Pod, pero se quedan en Pending porque nada les asigna un nodo.