Simplifiez la gestion des calculs avec AWS Fargate

Chaque pod qui fonctionne sur Fargate possède sa propre limite d'isolation. Ils ne partagent pas le noyau sous-jacent, les ressources du processeur, 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 le trafic d'applications et le trafic HTTP avec des équilibreurs de charge d'application.

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 S'il existe un profil Fargate correspondant, 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 annexe dans vos pods.

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

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

La limite par défaut nofile et nproc souple est de 1024 et la limite stricte est de 65535 pour les Fargate Pods.

GPUs ne 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 (avec accès par passerelle NAT AWS aux services, mais pas de route directe vers une passerelle Internet). Le VPC de votre cluster doit donc disposer de sous-réseaux privés 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 l'outil Adjust pod resources with Vertical Pod Autoscaler pour définir la taille initiale correcte du processeur et de la mémoire de vos Fargate Pods, puis utiliser les déploiements de pods Scale avec Horizontal Pod Autoscaler pour dimensionner ces pods. Si vous souhaitez que le Vertical Pod Autoscaler redéploie automatiquement les pods vers Fargate avec des combinaisons de processeur et de mémoire plus importantes, 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.

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 defense-in-depth complète les 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. Cela est dû au fait que le nombre d'adresses IP disponibles dans un sous-réseau est limité. Par conséquent, le nombre de pods pouvant être créés dans le cluster est également limité. 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 Ajout de blocs IPv4 CIDR à un VPC.

Le service de métadonnées d' EC2 instance Amazon (IMDS) n'est pas disponible pour les pods déployés sur les nœuds Fargate. Si certains de vos pods déployés sur Fargate nécessitent des informations d'identification IAM, attribuez-les à vos pods en utilisant les 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 les spécifications de votre pod. Cela inclut la AWS région ou la zone de disponibilité dans laquelle un pod est déployé.

Vous ne pouvez pas déployer de Fargate Pods dans des AWS Outposts AWS , Wavelength ou des Zones Locales. AWS

Amazon EKS doit appliquer régulièrement des correctifs aux Fargate Pods pour garantir leur sécurité. Nous essayons de procéder aux mises à jour de manière à réduire l'impact, mais il arrive parfois que les 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 pluginAmazon VPC CNI pour Amazon EKS est installé sur des nœuds Fargate. Vous ne pouvez pas utiliser de plug-ins CNI alternatifs pour les clusters Amazon EKS dotés de nœuds Fargate.

Un Pod exécuté sur Fargate monte automatiquement un système de fichiers Amazon EFS, 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 volumes Amazon EBS sur des Fargate Pods.

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

Une fois qu'un Job Kubernetes est Completed marqué Failed ou, les pods créés par le Job 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 pods associés après la fin ou l'échec d'un Job, 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 manifeste 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