La evolución hacia un Kubernetes sin servidor implica un cambio fundamental en quién administra el nodo, aunque Kubernetes mantiene sus expectativas básicas intactas. Tradicionalmente, Kubernetes requiere que cada nodo se registre en el plano de control, informe su capacidad, ejecute un Kubelet, proporcione conectividad de red y hospede las cargas de trabajo. AWS Fargate redefine este paradigma ofreciendo todas estas capacidades sin que el cliente tenga que gestionar, actualizar, escalar o reemplazar un conjunto de nodos trabajadores.
Amazon Elastic Kubernetes Service (EKS) con Fargate adopta el pod como la unidad básica de infraestructura. Cuando se selecciona un pod para ejecutarse en Fargate, EKS crea un entorno informático dedicado, inicia los componentes Kubernetes necesarios, asigna una Interfaz de Red Elástica (Elastic Network Interface, ENI) dentro de la nube virtual privada del cliente (VPC) y destruye el entorno una vez que el pod deja de estar activo.
Este proceso depende de una serie de decisiones de diseño coordinadas. La ruta de admisión previene que el programador (scheduler) predeterminado asigne un pod a un nodo de Fargate. En su lugar, un programador exclusivo de Fargate provisiona la capacidad necesaria de forma dinámica, evitando la selección dentro de un grupo de nodos preexistentes. Una imagen de ejecución especializada suministra los componentes del nodo Kubernetes, mientras que namespaces de red separados mantienen la segregación entre la infraestructura y la carga de trabajo. Además, un manejador de admisión limita las cargas de trabajo a patrones compatibles con el modelo de un pod por entorno. 
Enrutamiento del pod antes de la programación
Dentro de un clúster EKS, es posible combinar nodos provisiones por Amazon Elastic Compute Cloud (EC2) con aquellos gestionados por Fargate, por lo que la asignación debe definirse explícitamente antes de que comience el proceso estándar de programación.
Para ello, EKS utiliza un perfil de Fargate, un recurso que define qué pods deben ejecutarse en Fargate mediante la selección de un namespace y etiquetas de pods precisas. Este perfil también especifica la subred privada y el grupo de seguridad donde se alojará la ENI del pod, asegurando así que la ubicación y el acceso de red estén sincronizados.
Cuando un pod coincide con un perfil de Fargate, un webhook de admisión mutante — administrado por AWS dentro del plano de control Kubernetes — modifica la etiqueta del pod para incluir el nombre del perfil y configura el nombre del scheduler para que dirija el pod al camino de programación en Fargate, antes de que el pod quede almacenado en la base de datos etcd y sea atendido por el scheduler por defecto.
El perfil también define un rol de ejecución IAM para el pod, utilizado por la infraestructura de Fargate para registrar el kubelet y extraer imágenes desde Amazon Elastic Container Registry (ECR). Este rol es independiente del identidad aplicada dentro de los contenedores, y dado que en esta infraestructura serverless no está disponible el metadata de instancias EC2, las aplicaciones deben emplear roles IAM asociados a cuentas de servicio para acceder a servicios de AWS.
Provisionamiento dinámico para cada pod
El programador Fargate es un componente exclusivo que opera en el plano de control Kubernetes, encargado de solicitar capacidad en base a las necesidades del pod y al perfil Fargate asignado, en lugar de buscar capacidad en nodos ya existentes.
Una vez solicitada la capacidad, el programador asocia provisionalmente un pod a un nodo candidato para evitar que fallos o reintentos creen múltiples entornos para un mismo pod. Cuando el entorno está listo, el runtime de Fargate registra el objeto nodo de Kubernetes. Solo tras verificar que el nodo está operativo, el scheduler realiza el enlace definitivo (bind) y el runtime inicia el pod, notificando su estado al servidor API.
Cuando el pod finaliza, el runtime elimina el nodo y libera la capacidad asignada. Si se produce un error durante el aprovisionamiento o el proceso de enlace, se revierte la asignación provisional y se recupera la capacidad para intentar nuevamente.
Una interfaz de red exclusiva para cada pod
Cada pod en Fargate se conecta a la VPC del cliente mediante una ENI específica. El perfil de Fargate define la subred y los grupos de seguridad para esta interfaz, garantizando que las reglas y el ruteo de la VPC se apliquen directamente al pod y no a un nodo compartido.
Gracias a esta ENI, el pod tiene una identidad propia dentro de la red, lo que permite identificar el tráfico con registros de flujo de VPC y definir límites estrictos mediante reglas de seguridad.
Para gestionar la comunicación simultánea del pod con la infraestructura y el control de Kubernetes, Fargate provisiona tres namespaces lógicos de red en Linux: uno para la plataforma Fargate (telemetría, credenciales, aprovisionamiento), otro para los componentes núcleo del nodo Kubernetes junto con la ENI, y un tercero para ejecutar la carga de trabajo del cliente. Esta separación asegura que el tráfico del entorno gestionado y las operaciones Kubernetes estén aislados del tráfico de la aplicación.
La ENI se mueve al namespace del nodo, proporcionando la vía para la comunicación con el plano de control y también para el tráfico del pod. Un puente virtual y pares de Ethernet virtuales (veth) conectan el namespace del nodo con el namespace de la carga de trabajo, permitiendo que el tráfico destinado a la gestión de Kubernetes se dirija correctamente y que el resto fluya hacia la VPC a través de la ENI, protegiendo la información sensible de la plataforma de accesos no autorizados desde la aplicación.
Un runtime compacto y adaptado
La imagen de runtime en Fargate se alinea con la versión del plano de control Kubernetes para garantizar compatibilidad. Incluye el kubelet y los componentes esenciales para registrar el nodo, recibir y lanzar especificaciones de pods, ejecutar sondas (probes), reportar estado y facilitar operaciones como registro de logs y ejecución remota de comandos (exec).
Durante el inicio del kubelet, EKS ejecuta un manejador personalizado de admisión (PodAdmitHandler) que valida los pods antes de su inicio, admitiendo solo aquellos diseñados para la ruta de Fargate y asegurando que el modelo de un pod por nodo no se infrinja accidentalmente mientras el kubelet se inicializa.
Este kubelet gestionado reduce su superficie funcional desactivando características no necesarias como logging extendido, perfiles de debug o comandos de depuración, minimizando la complejidad y riesgos de seguridad.
Mantenimiento y actualizaciones automatizadas
La infraestructura gestionada de Fargate se mantiene constantemente actualizada de forma automática. EKS reinicia periódicamente los pods para aplicar los parches de seguridad más recientes sin que el cliente tenga que intervenir en la gestión de nodos.
Cuando un entorno requiere actualización, EKS identifica el pod afectado, informa al cliente y utiliza la API de desalojo (eviction) de Kubernetes para retirar el pod de forma controlada, permitiendo que otro pod de reemplazo se prepare antes de eliminar el antiguo.
Este proceso respeta el PodDisruptionBudget del cliente, que limita la capacidad que puede estar indisponible durante la actualización para evitar interrupciones no planificadas. Si no es posible desalojar el pod en el tiempo previsto, EKS puede forzar la eliminación para garantizar un entorno actualizado. Las réplicas y sondas de disponibilidad aplicadas por el cliente aseguran la continuidad del servicio.
En este contexto, cada pod debe ajustarse a un perfil de Fargate y los clientes deben planificar la capacidad de ENIs y subredes adecuadamente, pues a diferencia de nodos EC2 donde muchos pods comparten una interfaz, cada pod Fargate recibe una ENI independiente.
Los pods Fargate se ejecutan en subredes privadas y no disponen de direcciones IP públicas, por lo que el acceso a Internet o a servicios AWS se realiza mediante gateways NAT o puntos finales (endpoints) de VPC. La configuración de grupos de seguridad debe contemplar el tráfico de gestión de Kubernetes para permitir operaciones como «kubectl logs» y «kubectl exec».
Un modelo de trabajo ajustado a la ejecución serverless
La mayoría de las cargas de trabajo comunes en Kubernetes, como Deployments y Jobs, encajan perfectamente en el modelo Fargate, especialmente cuando el aislamiento de múltiples clientes se define a nivel de pod. Sin embargo, aplicaciones que requieren control sobre nodos individuales — como DaemonSets, operaciones privilegiadas, puertos host o uso de GPU — no son compatibles con este modelo y requieren un entorno que permita acceso a nivel de nodo.
En cuanto a almacenamiento, los volúmenes basados en HostPath o almacenamiento adjunto al nodo no están disponibles para pods Fargate debido a la naturaleza efímera e independiente del entorno. La alternativa recomendada para almacenamiento compartido y duradero es Amazon Elastic File System (EFS), que se integra con Kubernetes y soporta este escenario.
Así, hacer Kubernetes serverless con EKS Fargate precisó no solo ocultar los nodos trabajadores, sino preservar los comportamientos esperados de Kubernetes mientras se modificaba el ciclo de vida subyacente. El proceso de admisión prioriza la intención de ubicación, un scheduler dedicado provisiona la capacidad, los componentes de runtime cumplen el contrato de nodo y la admisión a nivel de nodo protege la asignación de pods.
El uso de la red VPC otorga a cada pod una identidad directa y controlable, manteniendo separados a través de namespaces y límites de máquina virtual la plataforma gestionada y la carga de trabajo cliente.
Estas complejas decisiones de diseño son generalmente invisibles para los usuarios, quienes simplemente eligen un perfil, despliegan un pod y disfrutan de acceso inmediato a la red VPC, con funcionalidades estándar de Kubernetes como logs y ejecución remota, mientras el entorno de ejecución desaparece cuando el pod finaliza.
Este nivel de transparencia es precisamente el valor ofrecido por el servicio: facilita a los clientes el uso de objetos y flujos de trabajo Kubernetes familiares, mientras EKS y Fargate se encargan del aprovisionamiento, aislamiento, ciclo de vida de nodos y mantenimiento del runtime, manteniendo la experiencia nativa Kubernetes con pods como unidades de trabajo de primera clase.
