Questions fréquentes (FAQ) HAQM EKS

Le mode automatique HAQM EKS est disponible pour les clusters EKS nouveaux et existants exécutant Kubernetes 1.29+ dans toutes les Régions AWS où EKS est disponible, à l’exception des Régions AWS GovCloud (US) et la Chine. Pour commencer, il vous suffit d’utiliser l’API EKS, la console AWS, eksctl ou votre outil d’infrastructure en tant que code (IaC) préféré pour activer le mode automatique d’EKS dans un cluster nouveau ou existant et de spécifier le rôle IAM que son infrastructure de calcul gérée par AWS doit utiliser. Par défaut, le mode EKS Auto crée des configurations de dimensionnement de calcul générales conformes aux meilleures pratiques dans votre cluster, ce qui vous permet de commencer à exécuter des applications rapidement. Pour une personnalisation plus poussée, vous pouvez choisir de désactiver ces valeurs par défaut et de créer des configurations d’infrastructure et de dimensionnement de calcul supplémentaires à l’aide de l’API Kubernetes dans votre cluster.

Grâce au mode automatique d’HAQM EKS, AWS étend ses responsabilités par rapport à l’infrastructure AWS gérée par le client dans les clusters EKS. Outre l’exploitation du plan de contrôle du cluster Kubernetes avec le mode automatique EKS activé, AWS est également responsable de la sécurisation, de la configuration et de la gestion de l’infrastructure AWS dans les clusters EKS dont vos applications ont besoin pour fonctionner. Pour ce faire, les ressources de l’infrastructure AWS, telles que les instances EC2, des clusters EKS utilisant le mode automatique EKS présentent des limites par rapport à leurs homologues gérés par le client. Par exemple, vous ne pouvez pas vous connecter à distance via SSH ou SSM, modifier le rôle IAM de l’instance, remplacer le volume racine ou attacher des interfaces réseau Elastic supplémentaires aux instances EC2 gérées par le mode automatique d’EKS, car cela limiterait la capacité d’AWS à les sécuriser et à les gérer.

HAQM EKS avec AWS Fargate reste une option pour les clients qui souhaitent exécuter EKS, mais le mode automatique d’HAQM EKS est l’approche recommandée à l’avenir. Le mode automatique d’EKS est entièrement conforme à Kubernetes et prend en charge toutes les primitives Kubernetes en amont et les outils de plateforme tels qu’Istio, que Fargate n’est pas en mesure de prendre en charge. Le mode automatique d’EKS prend également en charge toutes les options d’achat pour l’exécution des instances EC2, y compris les instances Spot et GPU, permettant aux clients de tirer parti des réductions négociées sur EC2 et d’autres mécanismes d’économies. Ces capacités ne sont pas disponibles avec EKS sur Fargate. De plus, le mode automatique d’EKS permet aux clients d’atteindre le même modèle d’isolation que Fargate, en utilisant les capacités standard de planification Kubernetes pour s’assurer que chaque instance EC2 exécute un seul conteneur d’application. En adoptant le mode automatique d’HAQM EKS, les clients peuvent bénéficier de tous les avantages de l’exécution de Kubernetes sur AWS, une plateforme entièrement conforme à Kubernetes qui offre la flexibilité nécessaire pour tirer parti de l’ensemble des options EC2 et d’achat tout en conservant la facilité d’utilisation et l’abstraction de la gestion de l’infrastructure fournie par Fargate.

Le mode automatique d’HAQM EKS améliore la sécurité de vos clusters EKS de trois manières : 1/ L’infrastructure gérée par AWS, créée par le mode automatique d’EKS, est configurée selon les bonnes pratiques de sécurité d’AWS et renforcée selon les critères de niveau 1 du Center for Internet Security (CIS), notamment l’absence d’accès à distance, un système de fichiers racine immuable et des contrôles d’accès obligatoires au niveau du noyau. 2/ Les instances EC2 gérées par AWS dans le mode automatique d’EKS sont automatiquement mises à jour avec les derniers correctifs de sécurité et de bogues dès qu’ils sont disponibles. Dans la mesure du possible, ces correctifs sont appliqués sur place sans perturber les applications en cours d’exécution ni remplacer les instances. 3/ Par défaut, le mode automatique d’EKS fixe une durée de vie maximale de 14 jours pour ses instances EC2 gérées par AWS, ce qui vous aide à respecter les bonnes pratiques de sécurité et de conformité de l’industrie. Si votre cas d’utilisation nécessite des durées de vie d’instance plus ou moins longues, vous pouvez configurer le mode automatique d’EKS avec une durée adaptée à vos besoins, jusqu’à un maximum de 21 jours.

Oui, après la mise à niveau du plan de contrôle EKS vers une nouvelle version de Kubernetes, les nouvelles instances lancées par le mode automatique d’EKS, en raison de la mise à l’échelle des applications, s’exécutent avec le dernier logiciel Kubernetes correspondant à la version du plan de contrôle. Simultanément, les instances existantes sont progressivement mises à jour avec le logiciel Kubernetes pour la nouvelle version de Kubernetes. Combiné à la durée de vie maximale par défaut de 14 jours des instances lancées par le mode automatique d’EKS, cela signifie que, par défaut, votre cluster sera entièrement et automatiquement mis à niveau au plus tard 14 jours après la mise à niveau de la version Kubernetes de votre cluster EKS.

Le mode automatique d’HAQM EKS propose des versions intégrées et gérées des fonctionnalités essentielles de Kubernetes, telles que le calcul, le stockage et la mise en réseau. Cela inclut des versions gérées de : 1/ l’agent du mode automatique EKS qui facilite la sécurité et la gestion des instances ; 2/ l’exécution de conteneurs containerd, un composant fondamental permettant à Kubernetes d’exécuter efficacement des conteneurs ; 3/ le kubelet, qui gère le cycle de vie et l’état des pods Kubernetes sur chaque instance de calcul ; 4/ un proxy réseau qui permet le routage à l’intérieur du cluster ; 5/ un contrôleur Karpenter géré et compatible avec la version en amont ; 6/ le contrôleurs d’interface de stockage de conteneur (CSI) HAQM EBS ; 7/ une version gérée de l’interface réseau conteneur (CNI) AWS VPC pour la gestion des adresses IP, le réseau des pods et les politiques réseau ; 8/ CoreDNS pour la découverte de service au sein du cluster ; 9/ le contrôleur AWS Load Balancer pour orchestrer les équilibreurs de charge externes.

Avec le mode automatique d’HAQM EKS, vous n’avez pas besoin d’installer ou de gérer certains modules complémentaires EKS, tels que le VPC CNI, CoreDNS, kube-proxy et l’agent CloudWatch Observability. Avec le mode automatique d’EKS, votre cluster EKS inclut des versions intégrées des fonctionnalités fournies par ces modules complémentaires. Toutefois, si vos charges de travail n’ont toujours pas été migrées vers le mode automatique d’EKS, vous devez continuer à utiliser ces modules complémentaires EKS pour celles-ci. D’autres modules complémentaires EKS, en dehors de ceux remplacés par les capacités intégrées du mode automatique d’EKS, peuvent être exécutés sur des clusters utilisant le mode automatique d’EKS.

Oui, les instances EC2 gérées lancées par le mode automatique d’EKS peuvent être consultées par défaut en utilisant l’API EC2 DescribeInstances ou la console AWS. Ces instances étant gérées par AWS, les actions que vous pouvez effectuer avec les API EC2 sont limitées à celles qui n’ont aucune incidence sur la capacité d’EKS à assumer ses responsabilités opérationnelles étendues. Par défaut, le mode automatique EKS est fourni avec des configurations de calcul à usage général parfaitement adaptées aux cas d’utilisation courants. Si nécessaire, vous pouvez personnaliser les instances EC2 lancées par le mode automatique d’EKS. Les modifications des paramètres de configuration d’exécution des instances du mode automatique d’EKS peuvent être effectuées à l’aide de l’API Kubernetes Node Class du mode automatique d’EKS.

Oui. Les Compute Savings Plans et les instances réservées sont automatiquement appliqués lorsque des instances EC2 éligibles sont lancées. Consultez la page de tarification pour en savoir plus.

Les fonctionnalités Kubernetes du mode automatique d’HAQM EKS sont fournies par un ensemble de contrôleurs intégrés qui émettent divers événements Kubernetes permettant de comprendre leur comportement.