Perfiles de Fargate para pods sin servidor

AWS Fargate para EKS le permite ejecutar pods de Kubernetes sin aprovisionar ni gestionar nodos EC2. En lugar de pensar en tipos de instancia y grupos de nodos, define un perfil de Fargate que indica a EKS qué pods deben ejecutarse en Fargate según su espacio de nombres y, opcionalmente, selectores de etiquetas. AWS aprovisiona automáticamente la cantidad adecuada de capacidad de cómputo para cada pod y la termina cuando el pod se detiene.

Un perfil de Fargate está asociado a un clúster de EKS y contiene uno o más selectores; cada selector especifica un espacio de nombres y, opcionalmente, pares clave-valor de etiquetas de Kubernetes. Un pod debe coincidir con al menos un selector para programarse en Fargate. El perfil también especifica el rol de ejecución del pod (un rol de IAM) y las subredes privadas que Fargate debe utilizar para lanzar los pods.

El rol de ejecución del pod es un rol de IAM que EKS asume cuando Fargate extrae imágenes de contenedor y envía los registros de los pods a CloudWatch. Debe incluir la política gestionada por AWS AmazonEKSFargatePodExecutionRolePolicy. Sin este rol, los pods programados en Fargate no podrán iniciarse porque Fargate no puede autenticarse en ECR ni escribir en CloudWatch Logs.

Fargate impone importantes restricciones de espacios de nombres. El espacio de nombres kube-system no está disponible para la mayoría de los perfiles de Fargate porque allí se ejecutan pods del sistema, como kube-proxy. CoreDNS es una excepción: AWS proporciona un proceso guiado para aplicar un parche al despliegue de CoreDNS y eliminar la anotación eks.amazonaws.com/compute-type: ec2, de modo que pueda ejecutarse en Fargate. Los pods de los espacios de nombres excluidos permanecerán sin programarse si no hay nodos EC2 disponibles.

Fargate asigna recursos de cómputo según las solicitudes de CPU y memoria definidas en la especificación del pod. Redondea al alza hasta la combinación de vCPU y memoria compatible con Fargate más cercana (por ejemplo, de 0,25 vCPU / 0,5 GB hasta 16 vCPU / 120 GB). Solo se le factura por los recursos asignados por segundo mientras se ejecuta el pod. Establezca siempre solicitudes de recursos precisas: solicitar menos recursos de los necesarios provoca terminaciones por falta de memoria, mientras que solicitar más aumenta el coste.

Fargate elimina la gestión de nodos, pero tiene ciertas limitaciones: no admite daemonsets (ya que no hay nodos persistentes en los que programarlos), no admite contenedores privilegiados y ofrece compatibilidad limitada con determinados tipos de almacenamiento. Los grupos de nodos EC2 admiten GPU, kernels personalizados y cargas de trabajo con estado que utilizan unidades NVMe locales. Un patrón habitual consiste en ejecutar servicios sin estado en Fargate y cargas de trabajo con estado o que usan GPU en grupos de nodos EC2 dedicados dentro del mismo clúster de EKS.

Cada pod de Fargate obtiene su propia interfaz de red elástica (ENI) y una IP privada de la subred especificada en el perfil. Esto significa que puede aplicar un grupo de seguridad único a cada pod mediante la función Security Groups for Pods. Los pods de Fargate admiten todas las reglas estándar de grupos de seguridad de VPC, lo que proporciona un control detallado del tráfico entrante y saliente a nivel de cada pod, una importante ventaja de seguridad frente a los grupos de seguridad compartidos a nivel de nodo.

Los pods de Fargate envían registros a Amazon CloudWatch Logs mediante el enrutador de registros Fluent Bit integrado. Para configurar el registro, cree un ConfigMap llamado aws-logging en el espacio de nombres aws-observability. El rol de ejecución del pod debe tener permiso para crear grupos de registros y escribir eventos de registro. Los registros se organizan en grupos de registros de CloudWatch por clúster y espacio de nombres, lo que facilita la agregación centralizada de registros sin ejecutar un agente de registros independiente.

Fargate admite el Horizontal Pod Autoscaler (HPA) de Kubernetes. Cuando HPA aumenta el número de réplicas, Fargate aprovisiona automáticamente nuevas microVM sin que tenga que ajustar el tamaño de ningún grupo de nodos. Esto proporciona una experiencia de escalado automático realmente sin servidor: HPA controla el número de pods y Fargate gestiona la capacidad de cómputo de forma elástica. Aun así, necesita tener Metrics Server desplegado en el clúster para que HPA pueda leer el uso de CPU y memoria.

Fargate se factura por los vCPU-segundo y GB-segundo consumidos, con un mínimo de 1 minuto por pod. No hay costes a nivel de nodo, cargos por capacidad reservada ni costes de aplicación de parches a la AMI o al sistema operativo. Normalmente, Fargate es más caro por unidad de cómputo que las instancias EC2 bajo demanda dimensionadas correctamente, pero el coste total de propiedad suele ser menor cuando se tiene en cuenta el tiempo de ingeniería ahorrado en la gestión de nodos, la aplicación de parches y las decisiones de escalado.

Limitaciones importantes de Fargate para el examen SAA-C03: no admite DaemonSet (los pods no se pueden colocar en cada nodo porque no hay nodos persistentes), no admite contenedores privilegiados, no admite el modo hostNetwork y el almacenamiento efímero está limitado a 20 GB por pod (ampliable a 200 GB mediante una configuración). No se admite el almacenamiento persistente en bloques con EBS; use EFS para el almacenamiento persistente de archivos compartidos con pods de Fargate.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido lo siguiente: los perfiles de Fargate utilizan selectores de espacios de nombres y etiquetas para programar pods sin servidor, el rol de ejecución del pod concede a Fargate permiso para extraer imágenes y escribir registros, y Fargate no admite DaemonSets ni EBS; use EFS para el almacenamiento persistente. A continuación, exploraremos las redes de EKS con el plugin VPC CNI y AWS Load Balancer Controller.