Consideraciones sobre Fargate de AWS Tabla de comparación de Fargate

Simplificación de la administración de computación con AWS Fargate

En este tema se explica cómo utilizar Amazon EKS para ejecutar pods de Kubernetes en AWS Fargate. Fargate es una tecnología que proporciona capacidad informática bajo demanda correctamente dimensionada para contenedores. Con Fargate ya no tendrá que aprovisionar, configurar ni escalar grupos de máquinas virtuales por su cuenta para ejecutar los contenedores. Tampoco tendrá que elegir tipos de servidores, decidir cuándo escalar los grupos de nodos u optimizar el empaquetado de clústeres.

Puede controlar qué pods se comienzan en Fargate y cómo se ejecutan con perfiles de Fargate. Los perfiles de Fargate se definen como parte de su clúster de Amazon EKS. Amazon EKS integra Kubernetes con Fargate mediante controladores creados por AWS con el modelo ascendente y extensible proporcionado por Kubernetes. Estos controladores funcionan como parte del plano de control de Kubernetes administrado por Amazon EKS y son responsables de programar los pods de Kubernetes nativos en Fargate. Los controladores de Fargate incluyen un nuevo programador que se ejecuta junto con el programador predeterminado de Kubernetes, además de varios controladores de admisión de mutación y validación. Cuando comienza un pod que cumple los criterios para ejecutarse en Fargate, los controladores de Fargate que se ejecutan en el clúster reconocen, actualizan y programan el pod en Fargate.

En este tema se describen los diferentes componentes de los pods que se ejecutan en Fargate y se ofrecen consideraciones especiales sobre cómo utilizar Fargate con Amazon EKS.

Consideraciones sobre Fargate de AWS

Aquí se incluyen algunos aspectos que debe tener en cuenta sobre la utilización de Fargate en Amazon EKS.

Cada pod que se ejecuta en Fargate tiene su propio límite de aislamiento. No comparten el kernel subyacente, los recursos de CPU, los recursos de memoria o la interfaz de red elástica con otro pod.
Los Network Load Balancers y los Application Load Balancers (ALB) solo se pueden utilizar con Fargate con destinos IP. Para obtener más información, consulte Crear un equilibrador de carga de red y Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones.
Los servicios expuestos de Fargate solo se ejecutan en modo IP de tipo de destino y no en modo IP de nodo. La forma recomendada de verificar la conectividad de un servicio que se ejecuta en un nodo administrado y un servicio que se ejecuta en Fargate es conectarse a través del nombre del servicio.
Los pods deben coincidir con un perfil de Fargate en el momento de su programación para ejecutarse en Fargate. Los pods que no coinciden con un perfil de Fargate podrían quedarse atascados como Pending. Si existe un perfil de Fargate coincidente, puede eliminar los pods pendientes que haya creado para reprogramarlos en Fargate.
No se admiten DaemonSets en Fargate. Si su aplicación requiere un daemon, reconfigure ese daemon para que se ejecute como un contenedor asociado en sus pods.
No se admiten contenedores con privilegios en Fargate.
Los pods que se ejecutan en Fargate no pueden especificar HostPort ni HostNetwork en el manifiesto del pod.
El límite flexible predeterminado de nofile y nproc es 1024 y el límite invariable es 65 535 para los pods de Fargate.
Las GPU no están disponibles actualmente en Fargate.
Los pods que se ejecutan en Fargate solo se admiten en subredes privadas (con acceso de una puerta de enlace NAT a servicios de AWS, pero sin una ruta directa a una puerta de enlace de Internet), por lo que la VPC del clúster debe tener subredes privadas disponibles. Para los clústeres sin acceso a Internet saliente, consulte Implementación de clústeres privados con acceso limitado a Internet.
Puede utilizar el Ajuste de los recursos de pods con el Escalador automático vertical de pods para establecer el tamaño correcto inicial de la CPU y la memoria de sus pods de Fargate y, a continuación, utilizar el Escalado de las implementaciones de pods con el Escalador automático horizontal de pods para ajustar la escala de esos pods. Si desea que el Escalador automático vertical de pods vuelva a implementar automáticamente los pods en Fargate con combinaciones de CPU y memoria más grandes, configure el modo del Escalador automático vertical de pods en Auto o Recreate para garantizar la funcionalidad correcta. Para obtener más información, consulte el documento Escalador automático vertical de pods en GitHub.
La resolución de DNS y los nombres de host DNS deben estar habilitados en la VPC. Para obtener más información, consulte Ver y actualizar el soporte de DNS para su VPC.
Fargate de Amazon EKS agrega defensa en profundidad para las aplicaciones de Kubernetes aislando cada pod dentro de una máquina virtual (VM). Este límite de VM impide el acceso a los recursos basados en host utilizados por otros pods en caso de escape de contenedor, que es un método común para atacar aplicaciones en contenedores y obtener acceso a recursos fuera del contenedor.

El uso de Amazon EKS no modifica sus responsabilidades en virtud del modelo de responsabilidad compartida. Debe evaluar detenidamente la configuración de los controles de seguridad y gobernanza del clúster. La forma más segura de aislar una aplicación es ejecutarla siempre en un clúster independiente.
Los perfiles de Fargate admiten la especificación de subredes de bloques de CIDR secundarios de VPC. Puede que desee especificar un bloque de CIDR secundario. Esto es debido a que hay un número limitado de direcciones IP disponibles en una subred. Como resultado, hay también un número limitado de pods que se pueden crear en el clúster. Si usa subredes diferentes para los pods, puede aumentar el número de direcciones IP disponibles. Para obtener más información, consulte Adición de bloques de CIDR IPv4 a una VPC.
El servicio de metadatos de instancias (IMDS) de Amazon EC2 no está disponible para pods implementados en nodos de Fargate. Si tiene pods implementados en Fargate que necesitan credenciales de IAM, asígnelos a sus pods mediante roles de IAM para cuentas de servicio. Si los pods necesitan acceso a otra información disponible a través de IMDS, debe llevar a cabo una codificación rígida de esta información en la especificación del pod. Esto incluye la región de AWS o zona de disponibilidad en la que se implementa un pod.
No se pueden implementar pods de Fargate en AWS Outposts, AWS Wavelength o Zonas locales de AWS.
Amazon EKS debe aplicar parches periódicamente de pods de Fargate para mantenerlos seguros. Intentamos las actualizaciones de forma que disminuya el impacto, pero hay ocasiones en que los pods deben eliminarse si no se expulsan correctamente. Hay algunas acciones que puede emprender para minimizar las interrupciones. Para obtener más información, consulte Definición de acciones para los eventos de aplicación de revisiones del sistema operativo de AWS Fargate.
El complemento CNI de Amazon VPC para Amazon EKS se encuentra instalado en los nodos de Fargate. No puede utilizar complementos CNI alternativos para clústeres de Amazon EKS con nodos de Fargate.
Un pod que se ejecuta en Fargate monta automáticamente un sistema de archivos de Amazon EFS, sin necesidad de seguir pasos manuales para la instalación de controladores. No se puede utilizar el aprovisionamiento dinámico de volúmenes persistentes con nodos de Fargate, pero se puede utilizar el aprovisionamiento estático.
Amazon EKS no es compatible con Fargate Spot.
No puede montar volúmenes de Amazon EBS en los pods de Fargate.
Puede ejecutar el controlador CSI de Amazon EBS en nodos de Fargate, pero el DaemonSet del nodo CSI de Amazon EBS solo se puede ejecutar en instancias de Amazon EC2.
Después de marcar un trabajo de Kubernetes como Completed o Failed, los pods que el trabajo crea normalmente siguen existiendo. Este comportamiento le permite ver sus registros y resultados, pero se pueden generar costos adicionales con Fargate si después no limpia el trabajo.

Para eliminar automáticamente los pods relacionados después de que se complete o falle un trabajo, puede especificar un periodo de tiempo mediante el controlador de tiempo de vida (TTL). En el siguiente ejemplo, se muestra la especificación .spec.ttlSecondsAfterFinished en el manifiesto del trabajo.
```
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 # <-- TTL controller
```

Tabla de comparación de Fargate

Criterios	AWS Fargate
Se puede implementar en AWS Outposts	No
Se puede implementar en AWS Local Zones.	No
Puede ejecutar contenedores que requieren Windows	No
Puede ejecutar contenedores que requieran Linux.	Sí
Puede ejecutar cargas de trabajo que requieren el chip de inferencias.	No
Puede ejecutar cargas de trabajo que requieren una GPU.	No
Puede ejecutar cargas de trabajo que requieren procesadores Arm.	No
Puede ejecutar AWS Bottlerocket.	No
Los pods comparten un entorno en tiempo de ejecución del kernel con otros pods.	No. Cada pod tiene un kernel dedicado.
Los pods comparten CPU, memoria, almacenamiento y recursos de red con otros pods.	No. Cada pod tiene recursos dedicados y su tamaño se puede adaptar de forma independiente para maximizar la utilización de los recursos.
Los pods pueden utilizar más hardware y memoria que lo que se indica en las especificaciones del pod.	No. El pod se puede volver a implementar mediante una vCPU y una configuración de memoria más grandes.
Debe implementar y administrar instancias de Amazon EC2.	No
Debe proteger, mantener y aplicar parches al sistema operativo de las instancias de Amazon EC2.	No
Puede proporcionar argumentos de arranque en la implementación de un nodo, como argumentos kubelet adicionales.	No
Puede asignar direcciones IP a pods desde un bloque de CIDR diferente de la dirección IP asignada al nodo.	No
Se puede utilizar SSH en el nodo.	No: no hay ningún sistema operativo host de nodos para utilizar SSH.
Puede implementar su propia AMI personalizada en los nodos.	No
Puede implementar su propia CNI personalizada en los nodos.	No
Debe actualizar la AMI de nodos por su cuenta	No
Debe actualizar la versión de Kubernetes de los nodos por su cuenta.	No: no administra nodos.
Puede utilizar el almacenamiento de Amazon EBS con pods.	No
Puede utilizar el almacenamiento de Amazon EFS con pods.	Sí
Puede utilizar el almacenamiento de Amazon FSx para Lustre con pods.	No
Puede utilizar el Network Load Balancer para servicios.	Sí, cuando se utiliza la Creación de un equilibrador de carga de red
Los pods pueden ejecutarse en una subred pública.	No
Puede asignar diferentes grupos de seguridad de VPC a pods individuales.	Sí
Puede ejecutar DaemonSets de Kubernetes.	No
Soporte de `HostPort` y `HostNetwork` en el manifiesto del pod.	No
Disponibilidad regional de AWS	Algunas regiones admitidas por Amazon EKS
Puede ejecutar contenedores en hosts dedicados de Amazon EC2	No
Precios	Costo de una memoria de Fargate individual y configuración de CPU. Cada pod tiene su propio costo. Para obtener más información, consulte AWS Precios de Fargate.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Pila de CloudFormation

Introducción