Simplificación de la administración de computación con AWS Fargate - Amazon EKS
Consideraciones sobre Fargate de AWS

Simplificación de la administración de computación con 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 Kubernetes Pods 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 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 Redirigir 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 del pod con el escalador automático vertical de pods para medir correctamente inicialmente el tamaño de la CPU y la memoria de sus Pods de Fargate y, a continuación, utilizar el Escalado de las implementaciones de pod con 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 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 realizar una codificación rígida de esta información en la especificación del Pod. Esto incluye la región de AWS o la zona de disponibilidad en la que se implementa un Pod.

  • No se pueden implementar Pods de Fargate a AWS Outposts, AWS Wavelength o zonas locales de 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 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 nodo CSI de Amazon EBS DaemonSet 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 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