Saltar a contenido

Componentes del Control Plane y Worker Nodes

Arquitectura de Kubernetes

flowchart TB
    subgraph "Control Plane (Master)"
        API[kube-apiserver<br/>Puerto: 6443]
        ETCD[etcd<br/>Puerto: 2379-2380]
        SCHED[kube-scheduler<br/>Puerto: 10251]
        CM[kube-controller-manager<br/>Puerto: 10252]
    end

    subgraph "Worker Node"
        KUBELET[kubelet<br/>Puerto: 10250]
        PROXY[kube-proxy]
        CRI[Container Runtime<br/>containerd/CRI-O]
    end

    CLIENT[kubectl] --> API
    API <--> ETCD
    API --> SCHED
    API --> CM
    API --> KUBELET
    KUBELET --> CRI
    KUBELET --> PROXY

Componentes del Control Plane

kube-apiserver

El kube-apiserver es un componente fundamental del Control Plane de Kubernetes. Conocer su funcionamiento a fondo es indispensable.

Actúa como la puerta principal o frontend del sistema. Es el único componente del plano de control expuesto al exterior, permitiendo la comunicación con herramientas como kubectl o sistemas CI/CD, además de interactuar con componentes internos como los Worker Nodes, el kube-scheduler y el kube-controller-manager. Todo el tráfico relacionado con la gestión y configuración se realiza a través de llamadas a su API REST.

Responsabilidades Principales

  • Punto Único de Entrada: Recibe la totalidad de las peticiones del sistema, ya sea para consultar el estado de un nodo, desplegar un Pod o eliminar un Secret.

[!NOTE] Las peticiones que consumen las aplicaciones dentro de los Pods no pasan por el kube-apiserver.

  • Autenticación y Autorización: Funciona como un guardián de seguridad que verifica la identidad del usuario o sistema (Autenticación) y los permisos asignados para ejecutar acciones específicas mediante mecanismos como RBAC (Autorización).

  • Controladores de Admisión: Una vez autorizada una petición, esta atraviesa una serie de filtros y webhooks (Mutating y Validating). En esta fase, la petición puede ser modificada en tiempo real o rechazada si viola alguna política de seguridad del clúster.

  • Comunicación Exclusiva con etcd: Es el único componente autorizado para leer y escribir en etcd, la base de datos clave-valor que almacena todo el estado del clúster. Ningún otro componente interno tiene acceso directo a etcd.

Ciclo de Vida de una Petición

Cuando se envía una instrucción al clúster (por ejemplo, a través de kubectl apply -f mi-app.yaml), el kube-apiserver gestiona el flujo de la siguiente manera:

  1. Recepción: La petición HTTP/REST inicial llega al servidor.

  2. Autenticación: El sistema comprueba las credenciales proporcionadas, tales como certificados TLS o tokens.

  3. Autorización: Se evalúan configuraciones de acceso (como RoleBinding o ClusterRoleBinding) para validar que el origen tiene permisos para crear o modificar el recurso en el namespace especificado.

  4. Admisión: Se aplican las políticas internas del clúster. Como ejemplo, una política podría bloquear un despliegue si la imagen del contenedor utiliza la etiqueta latest.

  5. Persistencia: Si la petición supera todos los controles de seguridad y admisión, el kube-apiserver registra el nuevo estado deseado en la base de datos etcd y devuelve un código de confirmación 200 OK al cliente.

Comprender la función central del kube-apiserver facilita significativamente el diagnóstico de problemas (troubleshooting) y la implementación de medidas de seguridad en cualquier clúster.

# kube-apiserver
# Ver configuración
cat /etc/kubernetes/manifests/kube-apiserver.yaml

# Flags importantes
--advertise-address=<IP>
--anonymous-auth=false
--allow-privileged=true
--authorization-mode=Node,RBAC
--etcd-servers=https://127.0.0.1:2379
--service-cluster-ip-range=10.96.0.0/12
--profiling=false
# End kube-apiserver

etcd

Es un almacén de datos (base de datos) de tipo clave-valor, altamente disponible y distribuido. Funciona como la única fuente de verdad del clúster, donde se guarda todo el estado de Kubernetes, las configuraciones y los metadatos.

Características y Responsabilidades Principales

  • Aislamiento Estricto: El kube-apiserver es el único componente que tiene el privilegio de leer y escribir en etcd. Ningún otro componente interno (ni el scheduler, ni el controller-manager, ni los kubelets) toca etcd directamente.

  • Persistencia del Estado: Cuando envías un manifiesto YAML y este supera las fases de autenticación, autorización y admisión en el API Server, este último escribe el nuevo estado deseado en etcd. Solo en ese momento la orden se considera "registrada".

  • Consenso (Algoritmo Raft): En entornos de producción (Alta Disponibilidad o HA), etcd se despliega en 3, 5 o 7 nodos. Utiliza el algoritmo de consenso Raft para elegir un "Líder" y asegurar que, si un nodo falla, los datos sigan estando consistentes y disponibles en la mayoría de los nodos (quórum).

  • Notificación de Cambios (Watch): Proporciona una función de observación ("watch") que permite al kube-apiserver suscribirse a cambios. Así, cuando algo cambia en etcd, el API Server se entera al instante y notifica a los controladores correspondientes.

[!NOTE] En entornos de Alta Disponibilidad (HA), existen múltiples instancias de kube-apiserver.
Dado que cualquiera de ellas puede registrar un cambio en etcd, la función de watch es vital para notificar al resto de los API Servers y mantener sus cachés locales sincronizadas."

etcd en el Contexto de las Certificaciones

Como administrador de Kubernetes, tu interacción con etcd rara vez será para leer objetos directamente, sino para tareas de mantenimiento crítico y seguridad:

  • Examen CKA (Operaciones Core):

  • Respaldo y Restauración: Saber hacer un backup y un restore de la base de datos etcd es una habilidad fundamental.

  • Herramienta: Utilizarás la utilidad de línea de comandos etcdctl. Tendrás que saber cómo pasarle los certificados correctos (--cacert, --cert, --key) para poder autenticarte contra la base de datos.

  • Examen CKS (Seguridad Avanzada):

  • Encriptación en Reposo: Por defecto, los Secrets se guardan en texto plano (codificados en base64, lo cual no es seguro) dentro de etcd. En el CKS, aprenderás a configurar el EncryptionConfiguration para garantizar la encriptación de secretos en reposo en la base de datos.

# etcd
# Ver miembros del cluster etcd
ETCDCTL_API=3 etcdctl member list \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Verificar salud
ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key
# End etcd

kube-scheduler

Es el componente del Control Plane responsable de decidir en qué nodo (Worker Node) se va a ejecutar un Pod recién creado.

Regla de oro: El scheduler NO ejecuta el Pod. Solo toma la decisión. Una vez que elige el nodo, se lo comunica al kube-apiserver (este proceso se llama Binding), y es el kubelet de ese nodo específico quien realmente arranca los contenedores.

¿Cómo funciona? (El proceso de 2 fases)

El kube-scheduler está constantemente observando (haciendo watch) al API Server buscando Pods que tengan el campo nodeName vacío (es decir, que aún no tienen casa). Cuando encuentra uno, ejecuta un proceso de dos pasos:

1. Filtrado (Filtering / Predicates)

El scheduler evalúa todos los nodos del clúster y descarta aquellos donde el Pod no puede ejecutarse.

  • Ejemplo: Si el Pod pide 4GB de RAM y un nodo solo tiene 2GB libres, ese nodo es descartado. Si el nodo tiene un "Taint" (mancha) y el Pod no tiene la "Toleration" adecuada, también es descartado.

2. Puntuación (Scoring / Priorities)

De los nodos que "sobrevivieron" al filtrado, el scheduler les asigna una puntuación (del 0 al 100) para encontrar el mejor candidato.

  • Ejemplo: Si quedan dos nodos aptos, el scheduler le dará mayor puntuación al nodo que ya tenga descargada la imagen de Docker del Pod (para que inicie más rápido) o al nodo que tenga más recursos libres. El nodo con la puntuación más alta gana.

El kube-scheduler en las Certificaciones

Este componente es la estrella absoluta del examen CKA y tiene gran peso en el CKAD. Debes dominar los mecanismos con los que puedes "influenciar" o forzar las decisiones del scheduler:

  • Mecanismos de Atracción (El Pod elige al Nodo):

  • nodeSelector: La forma más básica. "Quiero ir a un nodo que tenga la etiqueta disk=ssd".

  • nodeAffinity: Una versión avanzada de nodeSelector con reglas como "Prefiero ir a este nodo, pero si no se puede, ponerme en otro" (Soft vs Hard affinity).

  • podAffinity / podAntiAffinity: "Quiero ejecutarme en el mismo nodo donde esté la base de datos" o "No quiero estar en el mismo nodo que otro Pod de mi mismo tipo" (Alta Disponibilidad).

  • Mecanismos de Repulsión (El Nodo rechaza al Pod):

  • Taints y Tolerations: A un nodo se le pone un Taint (ej. gpu=true:NoSchedule). El scheduler no enviará ningún Pod ahí, a menos que el Pod tenga configurada una Toleration explícita para esa "mancha". Es ideal para nodos dedicados.

  • Troubleshooting Crítico:

  • Si el kube-scheduler falla, está apagado, o si no hay ningún nodo que cumpla con los requisitos del Pod (ej. pides más CPU de la que existe), el Pod se quedará atascado eternamente en estado Pending.

  • El comando clave para descubrir por qué el scheduler no asigna tu Pod es: kubectl describe pod <nombre-del-pod>. Al final de la salida, en la sección "Events", el scheduler te dirá exactamente por qué falló el filtrado (ej. 0/3 nodes are available: 1 node(s) had taint, 2 Insufficient cpu).

# kube-scheduler
# Ver configuración
cat /etc/kubernetes/manifests/kube-scheduler.yaml

# Ver logs
kubectl logs -n kube-system kube-scheduler-<node-name>
# End kube-scheduler

kube-controller-manager

Si el kube-apiserver es el recepcionista, etcd la memoria y el kube-scheduler el estratega logístico, el kube-controller-manager es el Supervisor General.

En realidad, no es un solo controlador, sino un único proceso en segundo plano (daemon) que compila y ejecuta decenas de pequeños controladores. Cada uno de estos pequeños controladores tiene un único propósito: vigilar un recurso específico y asegurarse de que se cumpla tu voluntad.

El Bucle de Reconciliación (El concepto más importante)

El principio fundamental bajo el que opera este componente es el Control Loop (Bucle de Control). Constantemente realiza este proceso de tres pasos:

  1. Observar: Lee el Estado Deseado que tú guardaste en etcd (ej. "Quiero 3 réplicas de NGINX").

  2. Comparar: Revisa el Estado Actual del clúster (ej. "Actualmente solo hay 2 réplicas vivas porque un nodo se apagó").

  3. Actuar (Reconciliar): Ejecuta las acciones necesarias para que el Estado Actual sea idéntico al Estado Deseado (ej. Le pide al API Server que cree 1 Pod adicional).

Los Controladores Estrella

Aunque hay muchos, estos son los que impactan directamente tu trabajo diario y tus exámenes:

  • Node Controller (Controlador de Nodos): Vigila la salud de los Worker Nodes. Si un nodo deja de enviar su "latido" (heartbeat), este controlador lo marca como NotReady y, después de un tiempo de gracia (por defecto 5 minutos), decide desalojar (evict) los Pods de ese nodo para reprogramarlos en otro lugar.

  • ReplicaSet Controller: Se asegura de que el número de Pods que pediste en tu Deployment/ReplicaSet coincida exactamente con los que están corriendo. Si borras un Pod manualmente, este controlador es el que reacciona en milisegundos para crear uno nuevo.

  • Endpoints Controller: Une los Services con los Pods. Cuando creas un Service, este controlador busca los Pods que coincidan con los Labels y mantiene actualizada la lista de IPs a las que el Servicio debe enviar tráfico.

  • ServiceAccount & Token Controllers: Crean las cuentas de servicio por defecto y los tokens de acceso a la API para los nuevos Namespaces.

El kube-controller-manager en las Certificaciones

  • Examen CKA (Operaciones y Troubleshooting):

  • Escenario típico de examen: Creas un Deployment pidiendo 5 réplicas, pero solo se crea 1 y el clúster se queda congelado ahí. ¿Por qué? Si el scheduler no es el problema, es altamente probable que el kube-controller-manager esté caído o mal configurado (ej. un error de tipeo en /etc/kubernetes/manifests/kube-controller-manager.yaml).

  • Ajuste de tiempos: Podrían pedirte que reduzcas el tiempo que tarda el clúster en declarar un nodo como "muerto" y desalojar sus Pods. Esto se hace pasando flags específicos como --pod-eviction-timeout al manifiesto del kube-controller-manager.

  • Examen CKS (Seguridad):

  • Al igual que con el API Server, en el examen de seguridad tendrás que auditar su configuración. Deberás asegurarte de que puertos inseguros estén deshabilitados y que la comunicación de este componente con el API Server utilice siempre certificados cifrados.

# kube-controller-manager
# Ver controladores disponibles
kubectl get events -A
# End kube-controller-manager

Componentes del Worker node

Kubelet

Es el agente principal que se ejecuta en cada uno de los nodos del clúster (tanto en los Masters como en los Workers). Su único propósito en la vida es recibir descripciones de Pods (PodSpecs) y asegurarse de que los contenedores descritos en ellos estén ejecutándose y sanos.

Características y Responsabilidades Principales

  • El Gestor de Contenedores (CRI): El kubelet no ejecuta los contenedores por sí mismo. Cuando recibe la orden de crear un Pod, se comunica con el Container Runtime (como containerd o CRI-O) a través de una interfaz llamada CRI (Container Runtime Interface) para que este último descargue la imagen y arranque el contenedor.

  • Registro del Nodo: Cuando un nodo se enciende, el kubelet es el encargado de presentarse ante el kube-apiserver y decirle: "Hola, soy el nodo Worker-1, tengo 16GB de RAM y 4 CPUs, y estoy listo para trabajar".

  • Monitoreo de Salud (Probes): Es el ejecutor material de las pruebas de salud (Liveness, Readiness y Startup Probes). Él es quien hace ping a tu aplicación y, si la Liveness Probe falla, él es quien toma la decisión de reiniciar el contenedor localmente.

  • El Guardián de los "Static Pods": Esta es su característica más especial (y crítica para exámenes). El kubelet puede ejecutar Pods sin necesidad de hablar con el API Server. Si le configuras una ruta en el disco (por defecto /etc/kubernetes/manifests/), el kubelet leerá cualquier YAML que pongas ahí y lo ejecutará automáticamente. ¡Así es como se levantan el API Server, etcd y el Scheduler en el Control Plane!

El kubelet en el Contexto de las Certificaciones

A diferencia de otros componentes que corren como Pods, en un entorno de examen CKA/CKS estándar (basado en kubeadm), el kubelet se ejecuta como un servicio nativo de Linux (systemd). Esto cambia por completo cómo interactúas con él.

  • Examen CKA (Operaciones y Troubleshooting):

  • Diagnóstico de Nodos Caídos: Si un nodo aparece como NotReady, tu primer instinto debe ser entrar por SSH a ese nodo y revisar el estado del servicio: systemctl status kubelet.

  • Lectura de Logs: Como no es un Pod, no puedes usar kubectl logs. Tendrás que usar la herramienta de Linux: journalctl -u kubelet -f.

  • Gestión de Static Pods: Te pedirán crear un Pod Estático en un nodo específico. Tendrás que buscar cuál es la carpeta que está leyendo el kubelet para dejar tu YAML ahí.

  • Examen CKAD (Desarrollo):

  • *Límites de Recursos: Cuando configuras requests y limits (CPU/Memoria) en tu YAML, es el kubelet quien le pasa esas restricciones al kernel de Linux (cgroups) para asegurarse de que tu Pod no consuma más de lo que debe (y lo mata con un OOMKilled si lo hace).

  • Examen CKS (Seguridad):

  • Asegurar el Agente: El kubelet tiene su propia API interna (puertos 10250 y 10255). En el CKS, auditarás el archivo de configuración del kubelet (/var/lib/kubelet/config.yaml) para asegurarte de que la autenticación anónima esté desactivada (authentication.anonymous.enabled: false) y que la autorización esté delegada al API Server (authorization.mode: Webhook).

Kube-proxy

Es un proxy de red que se ejecuta en cada uno de los nodos del clúster (tanto Masters como Workers). Su único propósito es mantener las reglas de red del nodo para permitir la comunicación hacia los Services de Kubernetes, ya sea desde dentro o desde fuera del clúster.

Concepto Clave: Un "Service" en Kubernetes no es un proceso ni un contenedor real; es un concepto abstracto (una IP virtual). El kube-proxy es el componente que hace que esa IP virtual funcione en el mundo real.

Características y Funcionamiento (El "Cómo")

  • Vigilante de la API: Al igual que otros componentes, hace watch sobre el kube-apiserver. Está buscando la creación, actualización o eliminación de objetos de tipo Service y sus Endpoints (las IPs reales de los Pods).

  • Traductor de Reglas: Cuando creas un Servicio, el kube-proxy se entera y baja al sistema operativo del nodo (Linux) para escribir reglas de enrutamiento a bajo nivel.

  • Modos de Operación (Fundamental para el CKA):

  • iptables (El estándar actual): En este modo (el predeterminado), kube-proxy intercepta el tráfico dirigido a la IP del Servicio y lo redirige aleatoriamente (round-robin) a uno de los Pods respaldados. Es rápido, pero en clústeres masivos con miles de servicios puede volverse lento.

  • IPVS (El alto rendimiento): Utiliza un módulo especial del kernel de Linux diseñado específicamente para balanceo de carga. Es mucho más eficiente y escalable que iptables.

El kube-proxy en el Contexto de las Certificaciones

A diferencia del kubelet, que es un servicio nativo de Linux (systemd), el kube-proxy suele desplegarse como un DaemonSet en el clúster. Esto significa que corre como un Pod administrado en el namespace kube-system.

  • Examen CKA (Networking y Troubleshooting):

  • El escenario clásico: Creas un Deployment y un Service. Los Pods están corriendo perfectos, el Service tiene su IP, pero cuando haces curl a la IP del Service, se queda pensando y da Timeout.

  • El diagnóstico: Si los Pods viven, el problema casi siempre está en la capa de red. Debes revisar si los Pods de kube-proxy están corriendo en el namespace kube-system (kubectl get pods -n kube-system | grep kube-proxy) o si el CNI (Calico, Flannel) tiene problemas.

  • Examen CKAD (Desarrollo y Exposición):

  • Debes dominar la diferencia entre cómo el kube-proxy enruta un ClusterIP (tráfico solo interno) versus un NodePort.

  • Cuando creas un NodePort (ej. puerto 32000), es el kube-proxy quien coordina con el sistema operativo para que el nodo empiece a "escuchar" físicamente en ese puerto.

  • Examen CKS (Seguridad Perimetral):

  • Aunque la seguridad de red a nivel de Pod (NetworkPolicies) la maneja el plugin CNI (como Calico o Cilium) y no el kube-proxy, sí debes entender cómo se expone el tráfico al exterior para auditar si se están usando NodePorts innecesarios que expongan la superficie de ataque del nodo.