Describe la arquitectura de Kubernetes: control plane vs worker nodes y sus componentes.

Question

IT Interview Practice · Accepted Answer

Un cluster de Kubernetes tiene dos tipos de máquinas: el **control plane** (el "cerebro" que toma decisiones y almacena el estado) y los **worker nodes** (donde tus Pods realmente se ejecutan). Cada uno tiene un pequeño conjunto de componentes bien definidos.

## La visión general

```text
┌──────────────── CONTROL PLANE (el cerebro) ───────────────┐
│                                                            │
│   kube-apiserver ── la puerta de entrada; TODO pasa por él │
│        │                                                   │
│   etcd ───────── almacén clave-valor: la FUENTE DE VERDAD  │
│                  del cluster (todos los objetos y el estado deseado) │
│   kube-scheduler ── decide EN QUÉ node se ejecuta un Pod nuevo │
│   controller-manager ── ejecuta control loops (reconcilers)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (tus apps)  │ │  └ Pods (tus apps)  │
└─────────────────────┘ └─────────────────────┘
```

## Componentes del control plane

```text
kube-apiserver        El único punto de entrada. Expone la API REST; valida y
                      persiste objetos en etcd. kubectl, controllers y kubelets
                      hablan SOLO con el apiserver.
etcd                  Almacén clave-valor distribuido y consistente. Guarda TODO
                      el estado del cluster (deseado + actual). Perder etcd = perder el cluster.
kube-scheduler        Vigila los Pods sin node asignado y elige el mejor node
                      (según resource requests, affinity, taints, etc.).
kube-controller-      Ejecuta los control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Cada loop lleva lo actual → lo deseado.
cloud-controller-     (En cloud) integra con el proveedor: load balancers, rutas,
manager               ciclo de vida de los nodes.
```

## Componentes del worker node

```text
kubelet          El agente del node. Habla con el apiserver, arranca/detiene contenedores vía
                 el runtime, y reporta el estado de Pods y del node. Hace que la realidad del
                 node coincida con los Pods que se le han asignado.
kube-proxy       Programa la red del node (iptables/IPVS) para que las IPs virtuales de los
                 Services hagan load balancing hacia los endpoints de Pod correctos.
container runtime El software que realmente ejecuta contenedores (containerd, CRI-O).
```

## Cómo fluye un "kubectl apply" por el sistema

```text
1. kubectl → kube-apiserver: "Quiero un Deployment con 3 réplicas"
2. el apiserver valida y escribe el objeto en etcd
3. el controller-manager (controller deployment→replicaset) lo ve, crea 3 objetos Pod
4. el scheduler ve 3 Pods sin asignar, asigna cada uno a un node (lo escribe vía apiserver)
5. el kubelet de cada node ve sus Pods, dice al runtime que baje imágenes y arranque contenedores
6. kube-proxy cablea la red del Service para que el tráfico alcance los Pods nuevos
Todo es un bucle WATCH + RECONCILE mediado por el apiserver.
```

```bash
kubectl get nodes                 # lista nodes (control-plane + workers)
kubectl get pods -n kube-system   # ver los componentes de control-plane / sistema
kubectl get componentstatuses     # salud de las piezas clave del control-plane
```

## Por qué es importante

Entender la separación entre control plane y worker nodes —y el papel de cada componente— es lo que convierte Kubernetes de una caja negra en un sistema sobre el que puedes razonar y operar, así que es conocimiento central para cualquier ingeniero de nivel medio o superior. El **control plane** es el cerebro que toma decisiones: el **kube-apiserver** es la única puerta de entrada por la que se comunican todos los componentes y usuarios; **etcd** es el almacén clave-valor consistente que guarda todo el estado del cluster y es la fuente de verdad (perderlo significa perder el cluster); el **scheduler** decide en qué node aterriza cada Pod nuevo; y el **controller-manager** ejecuta los bucles de reconciliación que llevan continuamente el estado real hacia el deseado. En cada **worker node**, el **kubelet** es el agente que hace que los contenedores del node coincidan con los Pods asignados, **kube-proxy** programa la red que hace que las IPs virtuales de los Services enruten a los Pods correctos, y un **container runtime** (containerd, CRI-O) ejecuta realmente los contenedores. Ver cómo un solo `kubectl apply` fluye por este sistema —del apiserver a etcd, controllers creando objetos, el scheduler colocando Pods, kubelets arrancando contenedores, kube-proxy cableando la red, todo como bucles de watch-and-reconcile— revela el diseño elegante y coherente que hay detrás de la plataforma. Este modelo mental es justo lo que necesitas para depurar por qué un Pod está atascado en Pending (scheduler), por qué el cluster no responde (apiserver/etcd) o por qué un Service no enruta (kube-proxy), lo que lo hace indispensable para operar y solucionar problemas en clusters reales.

La visión general

Componentes del control plane

Componentes del worker node

Cómo fluye un "kubectl apply" por el sistema

Por qué es importante

Preguntas relacionadas