Simplifiez la gestion des calculs avec AWS Fargate

Important

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

Cette rubrique décrit l'utilisation d'Amazon EKS pour exécuter Kubernetes Pods sur AWS Fargate. Fargate est une technologie qui fournit une capacité de calcul à la demande et de taille appropriée pour les conteneurs. Avec Fargate, vous n'avez pas à provisionner, configurer ou dimensionner vous-même des groupes de machines virtuelles pour exécuter des conteneurs. Vous n'avez pas non plus besoin de choisir les types de serveurs, de décider quand dimensionner vos groupes de nœuds ou d'optimiser le regroupement de clusters.

Vous pouvez contrôler lequel Pods commencez à utiliser Fargate et à savoir comment ils fonctionnent avec les profils Fargate. Les profils Fargate sont définis dans le cadre de votre cluster Amazon. EKS Amazon EKS intègre Kubernetes avec 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 système EKS géré par Amazon Kubernetes plan de contrôle et sont responsables de la planification native Kubernetes Pods sur Fargate. Les contrôleurs Fargate incluent un nouveau planificateur qui fonctionne parallèlement au planificateur par défaut Kubernetes planificateur en plus de plusieurs contrôleurs d'admission mutants et validants. Lorsque vous lancez un Pod qui répond aux critères d'exécution sur Fargate, les contrôleurs Fargate exécutés dans le cluster reconnaissent, mettent à jour et planifient le Pod sur Fargate.

Cette rubrique décrit les différents composants de Pods qui s'exécutent sur Fargate, et soulève des considérations particulières concernant l'utilisation de Fargate avec Amazon. EKS

AWS Considérations relatives à Fargate

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

Chaque Pod qui s'étend sur Fargate a sa propre limite d'isolation. Ils ne partagent pas le noyau sous-jacent, les CPU ressources, les ressources de mémoire ou l'interface Elastic Network avec un autre Pod.
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 Acheminez les applications et HTTP le trafic avec les équilibreurs de charge des applications.
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ù leur exécution est prévue sur Fargate. Les pods qui ne correspondent pas à un profil Fargate peuvent être bloqués en tant que. Pending Si un profil Fargate correspondant existe, vous pouvez le supprimer en attente Pods que vous avez créé 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 annexe dans votre Pods.
Les conteneurs privilégiés ne sont pas pris en charge sur Fargate.
Les pods exécutés sur Fargate ne peuvent pas HostPort spécifier ou dans HostNetwork Pod manifeste.
La limite par défaut nofile et nproc souple est de 1024 et la limite stricte est de 65535 pour Fargate Pods.
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 les ressources du module Adjust avec Vertical Pod Autoscaler pour définir la taille initiale CPU et la mémoire correctes de votre Fargate. Pods, puis utilisez les déploiements du module Scale avec Horizontal Pod Autoscaler pour les adapter Pods. Si vous souhaitez que le Vertical Pod Autoscaler soit automatiquement redéployé Pods pour Fargate avec des combinaisons CPU plus grandes et de mémoire, réglez le mode du Vertical Pod Autoscaler sur l'un Auto ou Recreate l'autre pour garantir un fonctionnement correct. Pour plus d'informations, consultez la documentation de 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 ajoute pour defense-in-depth Kubernetes 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. Cela est dû au fait que 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 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 qui sont déployés sur les nœuds Fargate. Si vous avez Pods déployés sur Fargate et nécessitant des informations d'identification, IAM attribuez-les à votre Pods utilisation de IAMrôles pour les comptes de service. Si vos recettes Pods avez besoin d'accéder à d'autres informations disponibles viaIMDS, alors vous devez coder ces informations en dur dans votre Pod spécification. Cela inclut la AWS région ou la zone de disponibilité dans laquelle Pod est déployé sur.
Vous ne pouvez pas déployer Fargate Pods vers AWS Outposts, AWS Wavelength ou AWS Local Zones.
Amazon EKS doit appliquer régulièrement des correctifs à Fargate Pods pour les garder en sécurité. Nous essayons les mises à jour de manière à réduire l'impact, mais il arrive parfois que Pods doivent être supprimés s'ils ne sont pas expulsés avec succès. Certaines actions peuvent être prises pour minimiser les perturbations. Pour de plus amples informations, veuillez consulter Définir des actions pour les événements de mise à AWS jour du système d'exploitation Fargate.
Le VPCCNIplugin Amazon pour Amazon EKS est installé sur les nœuds Fargate. Vous ne pouvez pas utiliser de CNIplugins alternatifs pour les EKS clusters Amazon dotés de nœuds Fargate.
A Pod l'exécution sur Fargate permet de monter automatiquement un système de fichiers EFS Amazon, sans nécessiter d'étapes d'installation manuelle du pilote. Vous ne pouvez pas utiliser le provisionnement dynamique de volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser le provisionnement statique.
Amazon EKS ne prend pas en charge Fargate Spot.
Vous ne pouvez pas monter de EBS volumes Amazon sur Fargate Pods.
Vous pouvez exécuter le EBS CSI contrôleur Amazon sur les nœuds Fargate, mais le nœud Amazon EBS CSI DaemonSet ne peut être exécuté que sur EC2 des instances Amazon.
Une fois qu'un Job Kubernetes est Completed marqué Failed ou que Pods que le Job les créations 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 le Job par la suite.

Pour supprimer automatiquement les informations associées Pods après un Job se termine ou échoue, 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 votre Job manifeste.
```
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
```

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

AWS CloudFormation empiler

Mise en route