¿Cuáles son los componentes principales de la arquitectura de Kubernetes y de qué se encarga cada uno?

Un clúster de Kubernetes consta de un plano de control más un conjunto de máquinas de trabajo, llamadas nodos, que ejecutan aplicaciones en contenedores dentro de Pods. Todo clúster necesita al menos un nodo de trabajo para ejecutar Pods.

Conceptualmente, Kubernetes es declarativo: envías el estado deseado al servidor API (almacenado en etcd), y los controladores ejecutan bucles continuos de reconciliación que observan las diferencias y actúan para llevar el estado real hacia el estado deseado.

Componentes del plano de control

El plano de control toma decisiones globales sobre el clúster (como la programación) y responde a los eventos del clúster. En producción, normalmente se ejecuta en varias máquinas para alta disponibilidad.

• kube-apiserver — el componente central que expone la API HTTP de Kubernetes. Es el frente del plano de control y el único punto de contacto: toda autenticación, autorización, validación de solicitudes y lecturas/escrituras del estado del clúster pasan por él. Escala horizontalmente. En los despliegues normales es el único componente de Kubernetes que lee y escribe directamente el estado del clúster en etcd; todos los demás componentes interactúan con el estado a través del servidor API.
• etcd — un almacén de pares clave-valor consistente y altamente disponible que se usa como almacén de respaldo de Kubernetes para todos los datos del clúster: configuración, estado y metadatos. etcd es obligatorio y es la única fuente de verdad; perderlo significa perder todo el estado del clúster, por lo que debe ejecutarse con quorum (un número impar de miembros) y hacerse copias de seguridad con regularidad.
• kube-scheduler — vigila los Pods que aún no están vinculados a un nodo y asigna cada Pod a un nodo adecuado, teniendo en cuenta recursos, restricciones y políticas.
• kube-controller-manager — ejecuta controladores que implementan el comportamiento de la API de Kubernetes (por ejemplo, Node controller, Job controller, EndpointSlice controller). Cada controlador vigila el estado deseado y reconcilia el estado real hacia él.
• cloud-controller-manager (opcional) — se integra con el proveedor de nube subyacente, aislando la lógica específica de la nube de los componentes centrales de Kubernetes.

Componentes del nodo

Estos se ejecutan en cada nodo, manteniendo los Pods en ejecución y proporcionando el entorno de ejecución.

• kubelet — el agente que garantiza que los Pods estén en ejecución, incluidos sus contenedores. Vigila el servidor API para las asignaciones de Pods, inicia contenedores mediante el runtime, monta volúmenes, ejecuta comprobaciones de liveness/readiness y reporta el estado del nodo.
• kube-proxy — implementa la red de Service programando reglas de iptables o IPVS en los nodos para que el tráfico hacia un Service se reenvíe a las IP correctas de los Pods. Se marca como opcional porque algunos complementos CNI (por ejemplo, Cilium en modo eBPF) asumen su función, pero en un clúster estándar es necesario.
• Runtime de contenedores — el software responsable de ejecutar contenedores (containerd, CRI-O, etc., a través de la interfaz CRI).

Complementos

Los complementos amplían la funcionalidad del clúster: DNS del clúster (CoreDNS por defecto), la interfaz web Dashboard, la monitorización de recursos de contenedores y el registro de eventos a nivel de clúster.

Seguimiento común: toda la comunicación fluye a través del servidor API: el programador, los controladores y los kubelets simplemente lo vigilan y reaccionan, lo que convierte al servidor API en el centro crítico del clúster.