Simplifiez la gestion des calculs avec AWS Fargate

Chaque pod fonctionnant sur Fargate a sa propre limite de calcul. Les nœuds ne partagent pas le noyau sous-jacent, les ressources CPU, les ressources mémoire ou l’interface réseau Elastic avec un autre pod.

Les Network Load Balancers et les Application Load Balancers (ALB) peuvent être utilisés avec Fargate avec des cibles IP uniquement. Pour plus d’informations, consultez Créer un équilibreur de charge de réseau et Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer.

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 fonctionnant sur Fargate ne peuvent pas spécifier HostPort ou HostNetwork dans le manifeste du pod.

La limite logicielle par défaut nofile et nproc est de 1 024 et la limite matérielle est de 65 535 pour les pods Fargate.

Les GPU ne sont actuellement pas disponibles sur Fargate.

Les pods qui fonctionnent sur Fargate ne sont pris en charge que sur des sous-réseaux privés (avec un accès aux services AWS par passerelle NAT, mais sans route directe vers une passerelle Internet). Le VPC de votre cluster doit donc disposer de sous-réseaux privés. Pour les clusters sans accès Internet sortant, veuillez consulter Déployer des clusters privés avec un accès Internet limité.

Vous pouvez utiliser la fonctionnalité Ajuster les ressources des pods avec Vertical Pod Autoscaler pour définir la taille initiale correcte du processeur et de la mémoire pour vos pods Fargate, puis utiliser la fonctionnalité Mettre à l’échelle les déploiements de pods avec Horizontal Pod Autoscaler pour mettre à l’échelle ces pods. Si vous souhaitez que le Vertical Pod Autoscaler redéploie automatiquement les pods vers Fargate avec des combinaisons de CPU et de mémoire plus importantes, définissez le mode de Vertical Pod Autoscale sur Auto ou Recreate pour garantir une fonctionnalité correcte. Pour plus d'informations, consultez la documentation Vertical Pod Autoscaler (VPA) sur GitHub.

La résolution DNS et les noms d'hôte DNS doivent être activés pour votre VPC. Pour plus d'informations, consultez Affichage et mise à jour de la prise en charge de DNS pour votre VPC.

Amazon EKS Fargate ajoute une défense approfondie aux applications Kubernetes 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 prennent en charge la spécification de sous-réseaux à partir de blocs CIDR secondaires de VPC. Vous pouvez spécifier un bloc CIDR 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 Ajout de blocs d'adresse CIDR IPv4 à un VPC.

Le service de métadonnées d’instance Amazon EC2 (IMDS) n’est pas disponible pour les pods qui sont déployés sur des nœuds Fargate. Si vous avez des pods déployés sur Fargate qui nécessitent des informations d’identification IAM, attribuez-les à vos pods à l’aide des rôles IAM pour les comptes de service. Si vos pods ont besoin d’accéder à d’autres informations disponibles via IMDS, vous devez coder ces informations en dur dans la spécification de votre pod. Cela inclut la région AWS ou la zone de disponibilité dans laquelle un pod est déployé.

Vous ne pouvez pas déployer de pods Fargate sur AWS Outposts, AWS Wavelength ou AWS Local Zones.

Amazon EKS doit régulièrement appliquer des correctifs aux pods Fargate pour assurer leur sécurité. Les tentatives de mises à jour sont réalisées de manière à réduire les potentielles répercussions ; toutefois, il arrive que des pods doivent être supprimés si leur expulsion a échoué. Certaines actions peuvent être prises pour minimiser les perturbations. Pour de plus amples informations, consultez Définir des actions pour les événements de correction du système d’exploitation AWS Fargate.

Le pluginAmazon VPC CNI pour Amazon EKS est installé sur des nœuds Fargate. Vous ne pouvez pas utiliser les plugins Alternate CNI pour les clusters Amazon EKS avec des nœuds Fargate.

Un Pod fonctionnant sur Fargate monte automatiquement un système de fichiers Amazon EFS, sans nécessiter d’étapes manuelles d’installation de pilotes. Vous ne pouvez pas utiliser l’approvisionnement dynamique des volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser l’approvisionnement statique.

Amazon EKS ne prend pas en charge Fargate Spot.

Vous ne pouvez pas monter des volumes Amazon EBS sur des pods Fargate.

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

Une fois qu’une tâche Kubernetes est marquée Completed ou Failed, les pods créés par la tâche continuent généralement 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 travail après coup.

Pour supprimer automatiquement les pods associés après l’exécution ou l’échec d’une tâche, vous pouvez spécifier une durée à l’aide du contrôleur TTL (time-to-live). L’exemple suivant montre comment spécifier .spec.ttlSecondsAfterFinished dans votre manifeste de tâche.

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