AWS Fargate - Amazon EKS
Consideraciones sobre Fargate

AWS Fargate

importante

AWS Fargate con Amazon EKS no está disponible en AWS GovCloud (Este de EE. UU.) y AWS GovCloud (Oeste de EE. UU.).

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 la utilización de 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 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 AWS Fargate

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 Equilibrio de carga de aplicaciones en Amazon EKS.

  • 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 Requisitos del clúster privado.

  • Puede utilizar el Escalador automático vertical de pods para medir correctamente inicialmente el tamaño de la CPU y la memoria de los Pods de Fargate y, a continuación, utilizar el Escalador automático de pods horizontales 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 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 instancia (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 con Roles de IAM para cuentas de servicio. Si los Pods necesitan acceso a otra información disponible a través de IMDS, debe realizar 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 las zonas locales AWS Outposts, AWS Wavelength o AWS.

  • Amazon EKS debe aplicar parches periódicamente de Fargate Pods 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 Parches de SO de Fargate.

  • El complemento CNI de Amazon VPC para Amazon EKS se encuentra instalado en los nodos de Fargate. No puede usar Complementos CNI compatibles alternativos con los nodos de Fargate.

  • Un Pod que se ejecuta en Fargate monta automáticamente un sistema de archivos de Amazon EFS. No se puede utilizar el aprovisionamiento dinámico de volúmenes persistentes con nodos de Fargate, pero se puede utilizar el aprovisionamiento estático.

  • No puede montar volúmenes de Amazon EBS en Fargate Pods.

  • Puede ejecutar el controlador CSI de Amazon EBS en nodos de Fargate, pero el nodo CSI de Amazon EBS DaemonSet solo se puede ejecutar en instancias de Amazon EC2.

  • Después de marcar un JobKubernetes como Completed oFailed, los Pods que Job crea normalmente siguen existiendo. Este comportamiento le permite ver sus registros y resultados, pero con Fargate incurrirá en costos si no limpia después el Job.

    Para eliminar automáticamente los Pods relacionados después de que Job se complete o falle, puede especificar un período de tiempo mediante el controlador de tiempo de vida (TTL). En el siguiente ejemplo, se muestra la especificación .spec.ttlSecondsAfterFinished en el manifiesto de Job.

    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