Simplifiez la gestion informatique avec AWS Fargate

Important

AWS Fargate with Amazon EKS n'est pas disponible en AWS GovCloud (USA Est) et AWS GovCloud (USA Ouest).

Cette rubrique décrit l'utilisation d'Amazon EKS pour Kubernetes Pods l'exécution AWS Fargate. Fargate est une technologie qui fournit une capacité de calcul à la demande et de taille appropriée pour les conteneurs. Avec Fargate, il n'est pas nécessaire d'allouer, de configurer ou de mettre à l'échelle des groupes de machines virtuelles pour exécuter les conteneurs. Vous n'avez plus à choisir les types de serveurs, à décider quand vos clusters de nœuds doivent être mis à l'échelle, ni à optimiser les packs de clusters.

Vous pouvez contrôler les Pods qui démarrent sur Fargate et la manière dont ils s'exécutent avec des profils Fargate. Les profils Fargate sont définis dans le cadre de votre cluster Amazon. EKS Amazon EKS s'Kubernetesintègre à Fargate en utilisant des contrôleurs conçus à l'aide du modèle extensible en amont fourni AWS par. Kubernetes Ces contrôleurs fonctionnent dans le cadre du plan de Kubernetes contrôle EKS géré par Amazon et sont chargés de la planification native Kubernetes Pods sur Fargate. Les contrôleurs Fargate comprennent un nouveau planificateur qui s'exécute parallèlement au planificateur Kubernetes par défaut, outre plusieurs contrôleurs d'admission mutants et validants. Lorsque vous démarrez un Pod qui répond aux critères d'exécution sur Fargate, les contrôleurs Fargate qui s'exécutent dans le cluster reconnaissent, mettent à jour et programment le Pod sur Fargate.

Cette rubrique décrit les différents composants Pods qui s'exécutent sur Fargate et évoque les points particuliers à prendre en compte lors de l'utilisation de Fargate avec Amazon. EKS

AWS Fargate considérations

Voici quelques points à prendre en compte lors de l'utilisation de Fargate sur Amazon. EKS

• Chaque Pod qui s'exécute sur Fargate a sa propre limite d'isolement. Ils ne partagent pas le noyau sous-jacent, les CPU ressources, les ressources de mémoire ou l'interface Elastic Network avec un autre utilisateurPod.

• Les équilibreurs de charge réseau et les équilibreurs de charge d'application (ALBs) ne peuvent être utilisés avec Fargate qu'avec des cibles IP. Pour plus d’informations, consultez Créer un équilibreur de charge de réseau et Application d'itinéraire et HTTP trafic avec Application Load Balancers.

• Les services exposés de Fargate s'exécutent uniquement en mode IP de type cible, et non en mode IP de nœud. La manière recommandée de vérifier la connectivité entre un service s'exécutant sur un nœud géré et un service s'exécutant sur Fargate est de se connecter via le nom du service.

• Les pods doivent correspondre à un profil Fargate au moment où ils sont programmés pour fonctionner sur Fargate. Les pods qui ne correspondent pas à un profil Fargate peuvent être bloqués comme Pending. Si un profil Fargate correspondant existe, vous pouvez supprimer les Pods en attente que vous avez créés pour les reprogrammer sur Fargate.

• Les DaemonSets ne sont pas pris en charge sur Fargate. Si votre application nécessite un démon, reconfigurez ce démon pour qu'il s'exécute en tant que conteneur secondaire dans vos Pods.

• Les conteneurs privilégiés ne sont pas pris en charge sur Fargate.

• Les pods qui s'exécutent sur Fargate ne peuvent pas spécifier HostPort ou HostNetwork dans le manifeste du Pod.

• La limite flexible nofile et nproc par défaut est de 1 024 et la limite stricte est de 65 535 pour les Pods Fargate.

• GPUsne sont actuellement pas disponibles sur Fargate.

• Les pods qui s'exécutent sur Fargate ne sont pris en charge que sur les sous-réseaux privés (NATavec accès par passerelle AWS aux services, mais pas de route directe vers une passerelle Internet). Les sous-réseaux privés de votre cluster doivent donc être VPC disponibles. Pour les clusters sans accès Internet sortant, veuillez consulter Déployez des clusters privés avec un accès Internet limité.

• Vous pouvez utiliser le Ajustez les ressources du pod avec Vertical Pod Autoscaler pour définir la taille initiale CPU et la mémoire correctes de votre Pods Fargate, puis utiliser le pour Faites évoluer les déploiements de pods avec Horizontal Pod Autoscaler les redimensionner. Pods Si vous souhaitez que le Vertical Pod Autoscaler soit automatiquement redéployé sur Pods Fargate avec des combinaisons plus grandes CPU et de mémoire, réglez le mode du Vertical Pod Autoscaler sur l'un ou l'autre ou pour garantir un fonctionnement correct. Auto Recreate Pour plus d'informations, consultez la documentation Vertical Pod Autoscaler sur GitHub.

• DNSla résolution et les DNS noms d'hôtes doivent être activés pour votreVPC. Pour plus d'informations, consultez la section Affichage et mise à jour du DNS support pour votre VPC.

• Amazon EKS Fargate defense-in-depth ajoute Kubernetes des applications en isolant chaque pod au sein d'une machine virtuelle (VM). Cette frontière VM empêche l'accès aux ressources basées sur l'hôte utilisées par d'autres pods en cas de fuite du conteneur, qui est une méthode courante d'attaque des applications conteneurisées et d'accès aux ressources en dehors du conteneur.

  L'utilisation d'Amazon EKS ne modifie pas vos responsabilités dans le cadre du modèle de responsabilité partagée. Vous devez examiner attentivement la configuration des contrôles de sécurité et de gouvernance du cluster. Le moyen le plus sûr d'isoler une application est toujours de l'exécuter dans un cluster séparé.

• Les profils Fargate permettent de spécifier des VPC sous-réseaux à partir de blocs secondaires. CIDR Vous souhaiterez peut-être spécifier un CIDR bloc secondaire. En effet, le nombre d'adresses IP disponibles dans un sous-réseau est limité. Par conséquent, il existe également un nombre limité de Pods qui peuvent être créés dans le cluster. En utilisant différents sous-réseaux pour les Pods, vous pouvez augmenter le nombre d'adresses IP disponibles. Pour plus d'informations, consultez la section Ajouter IPv4 CIDR des blocs à unVPC.

• Le service de métadonnées d'EC2instance Amazon (IMDS) n'est pas disponible pour Pods les personnes déployées sur les nœuds Fargate. Si vous en avez déployé sur Fargate et Pods que vous IAM avez besoin d'informations d'identification, attribuez-les à votre usage. Pods Rôles IAM pour les comptes de service Si vous Pods avez besoin d'accéder à d'autres informations disponiblesIMDS, vous devez les coder en dur dans vos Pod spécifications. Cela inclut la Région AWS ou la zone de disponibilité dans laquelle a Pod est déployé.

• Vous ne pouvez pas déployer Pods Fargate dans des zones locales ou dans AWS Outposts des AWS Wavelength zones locales AWS .

• Amazon EKS doit régulièrement appliquer des correctifs à Pods Fargate pour garantir leur sécurité. Les tentatives de mise à jour sont réalisées de manière à réduire les répercussions éventuelles, toutefois, il est parfois nécessaire de supprimer des Pods si leur expulsion a échoué. Certaines actions peuvent être prises pour minimiser les perturbations. Pour de plus amples informations, veuillez consulter Définir des actions pour les événements d'application de correctifs au système d' AWS Fargate exploitation.

• Le VPCCNIplugin Amazon pour Amazon EKS est installé sur les nœuds Fargate. Vous ne pouvez pas utiliser Autres plugins CNI compatibles avec des nœuds Fargate.

• Une Pod exécution sur Fargate monte automatiquement un système de fichiers Amazon. EFS Vous ne pouvez pas utiliser l'approvisionnement dynamique des volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser l'approvisionnement statique.

• Vous ne pouvez pas monter de EBS volumes Amazon sur Fargate. Pods

• Vous pouvez exécuter le EBS CSI contrôleur Amazon sur des nœuds Fargate, mais le DaemonSet nœud Amazon ne peut fonctionner que sur des instances EBS CSI Amazon. EC2

• Une fois qu'une Job Kubernetes est marquée Completed ou Failed, les Pods que la Job crée continuent normalement d'exister. Ce comportement vous permet de consulter vos journaux et vos résultats, mais avec Fargate, vous devrez payer des frais si vous ne nettoyez pas la Job par la suite.

  Pour supprimer automatiquement les informations associées Pods après la Job fin ou l'échec d'une opération, vous pouvez spécifier une période à l'aide du contrôleur time-to-live (TTL). L'exemple suivant montre comment spécifier .spec.ttlSecondsAfterFinished dans le manifeste de votre 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