Kubernetes Cluster — componentes y responsabilidades
🧠 CONTROL PLANE (Master)
🌐
API Server
kube-apiserver · única puerta de entrada al cluster
🗄️
Etcd
Base de datos distribuida (KV) · el estado deseado del cluster
📅
Scheduler
kube-scheduler · decide en qué Node vive cada Pod
🔁
Controller Manager
Loops de reconciliación · Deployment, Node, Job controllers
☁️
Cloud Controller Manager
Integración con AWS/GCP/Azure (LBs, discos, IPs)
⚙️ WORKER NODE (×N)
🤖
Kubelet
Agente local · ejecuta Pods · reporta estado al API Server
🔀
Kube-proxy
Reglas iptables/IPVS · implementa los Services en red
🐳
Container Runtime
containerd / CRI-O · ejecuta los contenedores reales
🔑 kubectl habla sólo con el API Server. Nunca con Kubelet directamente. El API Server valida, persiste en Etcd y notifica a los controllers. El Kubelet hace polling al API Server para saber qué Pods debe ejecutar en su Node.
Raft consensus
KV store
Single source of truth
Almacena todo el estado del cluster: Pods, Services, ConfigMaps, Secrets, RBAC. Es el único componente stateful del Control Plane. Usa el algoritmo Raft para consenso distribuido — necesitas quórum (2n+1 nodos) para escrituras.
Pregunta de entrevista: ¿Qué pasa si Etcd cae? El cluster sigue ejecutando los Pods actuales (Kubelet los mantiene vivos) pero no puede aceptar cambios — no hay Deployments, escalados ni rollbacks hasta que Etcd vuelva.
REST API
Admission Controllers
Watch mechanism
Expone la API REST de Kubernetes. Valida (schema) y autentica/autoriza cada request (RBAC). Persiste en Etcd. El mecanismo Watch permite a los controllers recibir notificaciones push en vez de hacer polling.
Admission Controllers: interceptores antes de persistir en Etcd. MutatingAdmissionWebhook puede modificar objetos; ValidatingAdmissionWebhook puede rechazarlos. Aquí vive OPA/Gatekeeper.
Node affinity
Taints/Tolerations
Resource requests
Toma Pods sin Node asignado (Pending) y decide dónde colocarlos. Primero filtra Nodes que no cumplen requisitos (Filtering), luego puntúa los restantes (Scoring) y elige el mejor.
Criterios de decisión: recursos disponibles (CPU/RAM requests), Node Affinity/Anti-Affinity, Taints y Tolerations, Pod Topology Spread, y políticas de prioridad. Si ningún Node pasa el filtro, el Pod queda en Pending.
Control Loop
Desired vs Actual
Self-healing
Agrupa múltiples controllers en un proceso. Cada controller observa el estado actual, lo compara con el deseado, y actúa. El Deployment Controller crea ReplicaSets; el ReplicaSet Controller crea Pods; el Node Controller detecta Nodes caídos.
Ejemplo: borras un Pod manualmente → ReplicaSet controller detecta que actual=2, deseado=3 → crea un nuevo Pod. Este es el self-healing de K8s.
Node agent
CRI interface
Pod lifecycle
Se ejecuta en cada Node (incluido el master en setups single-node). Recibe PodSpecs del API Server y garantiza que los contenedores estén corriendo y sanos. Reporta el estado de vuelta al API Server vía heartbeats.
Responsabilidades: ejecutar contenedores via CRI (containerd), gestionar volúmenes montados, ejecutar Liveness/Readiness probes, y reportar métricas de CPU/RAM del Pod al Metrics Server.
iptables
IPVS
Service VIP
Implementa la abstracción de Service en cada Node. Mantiene reglas iptables (o IPVS) que redirigen tráfico a la IP virtual del Service hacia los Pods reales. Se actualiza cuando los Pods cambian.
Nota moderna: en clusters con CNI plugins avanzados (Cilium con eBPF), kube-proxy puede eliminarse completamente — Cilium gestiona el networking sin iptables, con mejor performance.
El ciclo que hace a K8s self-healing y declarativo
📋
DESIRED STATE
Tú defines en YAML
replicas: 3
image: nginx:1.25
→
👁️
OBSERVE
Controller lee Etcd
Actual: 2 Pods
corriendo
→
⚖️
DIFF
Deseado vs Actual
Faltan 1 Pod
→ actuar
→
⚡
ACT
Controller crea Pod
POST /pods al
API Server
↩
🔑 Imperativo vs Declarativo: con Docker dices "crea este contenedor" (imperativo). Con K8s dices "quiero 3 réplicas de nginx" (declarativo) — K8s se encarga de llegar ahí y mantenerlo, aunque caigan Pods o Nodes.
kubectl get pods -n kube-system
NAME READY STATUS RESTARTS
coredns-xxx-yyy 1/1 Running 0
etcd-minikube 1/1 Running 0
kube-apiserver-minikube 1/1 Running 0
kube-controller-manager-minikube 1/1 Running 0
kube-proxy-xxxxx 1/1 Running 0
kube-scheduler-minikube 1/1 Running 0
kubectl logs -n kube-system kube-apiserver-minikube
kubectl get nodes -o wide
kubectl describe node minikube
kubectl get all -n kube-system
kubectl exec -it -n kube-system etcd-minikube -- etcdctl \
--cacert /var/lib/minikube/certs/etcd/ca.crt \
--cert /var/lib/minikube/certs/etcd/server.crt \
--key /var/lib/minikube/certs/etcd/server.key \
get / --prefix --keys-only | head -20