**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Automatisation de l’infrastructure du cluster avec le mode automatique EKS
**Astuce**
[Inscrivez-vous](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) aux prochains ateliers Amazon EKS Auto Mode.
Le mode automatique d'EKS étend la AWS gestion des clusters Kubernetes au-delà du cluster lui-même, afin de AWS permettre également de configurer et de gérer l'infrastructure qui permet le bon fonctionnement de vos charges de travail. Vous pouvez déléguer les décisions clés en matière d'infrastructure et tirer parti de l'expertise de AWS for day-to-day operations. L'infrastructure de cluster gérée par AWS inclut de nombreuses fonctionnalités Kubernetes en tant que composants principaux, par opposition aux modules complémentaires, tels que le dimensionnement automatique du calcul, la mise en réseau des pods et des services, l'équilibrage de charge des applications, le DNS du cluster, le stockage par blocs et le support du GPU.
Pour commencer, vous pouvez déployer un nouveau cluster du mode automatique EKS ou activer le mode automatique EKS sur un cluster existant. Vous pouvez déployer, mettre à niveau ou modifier vos clusters en mode automatique EKS à l'aide d'eksctl, de la AWS AWS Management Console CLI, d'EKS APIs ou de vos outils préférés infrastructure-as-code.
Avec le mode automatique EKS, vous pouvez continuer d’utiliser vos outils compatibles avec Kubernetes préférés. Le mode automatique d'EKS s'intègre à AWS des services tels qu'Amazon EC2, Amazon EBS et ELB, en tirant parti des ressources AWS cloud conformes aux meilleures pratiques. Ces ressources sont mises à l’échelle automatiquement, optimisées en termes de coûts et mises à jour régulièrement afin de réduire les coûts d’exploitation et les charges opérationnelles.
## Caractéristiques
Le mode automatique EKS offre les fonctionnalités de haut niveau suivantes :
**Simplification de la gestion des clusters Kubernetes** : le mode automatique EKS permet de gérer EKS de manière simplifiée, grâce à des clusters prêts pour la production, avec un minimum de gestion opérationnelle. Avec le mode automatique EKS, vous pouvez exécuter des charges de travail dynamiques et exigeantes en toute confiance, sans avoir besoin d’une expertise EKS approfondie.
**Disponibilité des applications** : le mode automatique EKS ajoute ou supprime dynamiquement des nœuds dans votre cluster en fonction des besoins de vos applications Kubernetes. Cela réduit la planification manuelle de la capacité et contribue à assurer la disponibilité des applications.
**Efficacité** : le mode automatique EKS est conçu pour optimiser les coûts de calcul tout en respectant la flexibilité définie par vos exigences NodePool et celles de votre charge de travail. Il termine les instances inutilisées et consolide les charges de travail sur d’autres nœuds pour améliorer l’efficacité et réduire les coûts.
**Sécurité** : le mode automatique EKS utilise AMIs des éléments considérés comme immuables pour vos nœuds. Ils AMIs renforcent le verrouillage des logiciels, activent les contrôles d'accès SELinux obligatoires et fournissent des systèmes de fichiers racine en lecture seule. De plus, les nœuds lancés par le mode automatique EKS ont une durée de vie maximale de 21 jours (réductible), après laquelle ils sont automatiquement remplacés par de nouveaux nœuds. Cette approche améliore votre niveau de sécurité en renouvelant régulièrement les nœuds, conformément aux bonnes pratiques déjà adoptées par de nombreux clients.
**Mises à niveau automatisées** : le mode automatique d'EKS maintient votre cluster Kubernetes, vos nœuds et les composants associés à jour avec les derniers correctifs, tout en respectant les budgets d'interruption des modules (PDBs) et les budgets d'interruption () que vous NodePool avez configurés. NDBs Jusqu'à la durée de vie maximale de 21 jours, une intervention peut être nécessaire si le blocage PDBs ou d'autres configurations empêchent les mises à jour.
**Composants gérés** : le mode automatique d'EKS inclut Kubernetes et les fonctionnalités AWS cloud en tant que composants de base qui devraient autrement être gérés en tant que modules complémentaires. Cela inclut la prise en charge intégrée des attributions d’adresses IP des pods, des politiques réseau des pods, des services DNS locaux, des plug-ins GPU, des vérificateurs d’état et du stockage EBS CSI.
**Personnalisable NodePools et NodeClasses** : si votre charge de travail nécessite des modifications des configurations de stockage, de calcul ou de mise en réseau, vous pouvez créer des configurations personnalisées NodePools à NodeClasses l'aide du mode automatique EKS. Bien que vous ne deviez pas modifier NodePools les configurations par défaut NodeClasses, vous pouvez ajouter de nouvelles configurations personnalisées NodePools ou en NodeClasses complément des configurations par défaut pour répondre à vos besoins spécifiques.
## Composants automatisés
Le mode automatique EKS simplifie l’exploitation de vos clusters Amazon EKS en automatisant les composants d’infrastructure essentiels. Activer le mode automatique EKS réduit encore davantage les tâches nécessaires à la gestion de vos clusters EKS.
Voici une liste des composants du plan de données automatisés :
+ **Calcul** : pour de nombreuses charges de travail, avec le mode automatique EKS, vous pouvez oublier la plupart des aspects liés au calcul dans vos clusters EKS. Il s’agit des licences suivantes :
+ **Nœuds** : les nœuds du mode automatique EKS sont conçus pour être gérés comme des appareils. Le mode automatique EKS effectue les opérations suivantes :
+ Choisit une AMI appropriée, configurée avec les services nécessaires pour exécuter vos charges de travail sans intervention.
+ Verrouille l'accès aux fichiers de l'AMI à l'aide du mode SELinux coercitif et d'un système de fichiers racine en lecture seule.
+ Empêche l’accès direct aux nœuds en interdisant l’accès SSH ou SSM.
+ Inclut la prise en charge du GPU, avec des pilotes de noyau et des plug-ins distincts pour NVIDIA et Neuron GPUs, permettant des charges de travail de haute performance.
+ Gère automatiquement les [avis d’interruption de l’instance Spot EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) et les événements liés à l’état de l’instance EC2
+ **Autoscaling** : en s’appuyant sur l’autoscaling [Karpenter](https://karpenter.sh/docs/), le mode automatique EKS surveille les pods non planifiés et permet le déploiement automatique de nouveaux nœuds pour les exécuter. Lorsque les charges de travail se terminent, le mode automatique EKS interrompt et termine dynamiquement les nœuds inutilisés afin d’optimiser l’utilisation des ressources.
+ **Mises à niveau** : en prenant le contrôle de gestion des nœuds, le mode automatique EKS facilite l’application des correctifs de sécurité, des mises à niveau du système d’exploitation et des composants associés. Ces mises à niveau sont conçues pour interrompre le moins possible vos charges de travail. Le mode automatique EKS impose une durée de vie maximale des nœuds de 21 jours pour garantir que le up-to-date logiciel et. APIs
+ **Équilibrage de charge** : le mode automatique EKS simplifie l’équilibrage de charge en s’intégrant au service Elastic Load Balancing d’Amazon, ce qui permet d’automatiser le provisionnement et la configuration des équilibreurs de charge pour les ressources Service et Ingress de Kubernetes. Il prend en charge des fonctionnalités avancées pour les équilibreurs de charges Application Load Balancer et les équilibreurs de charge Network Load Balancer, en gère tout le cycle de vie et les met à l’échelle afin de répondre aux besoins du cluster. Cette intégration fournit une solution d'équilibrage de charge prête à être utilisée en production, conforme aux AWS meilleures pratiques, vous permettant de vous concentrer sur les applications plutôt que sur la gestion de l'infrastructure.
+ **Stockage** : le mode automatique EKS configure le stockage éphémère automatiquement, notamment les types de volumes, les tailles et politiques de chiffrement, et les politiques de suppression lors de la terminaison des nœuds.
+ **Mise en réseau** : le mode automatique EKS automatise les tâches réseau essentielles pour la connectivité des pods et des services. Cela inclut le IPv6 support IPv4/et l'utilisation de blocs CIDR secondaires pour étendre les espaces d'adresses IP.
+ **Gestion des identités et des accès** : il n’est pas nécessaire d’installer l’agent d’identité du pod EKS sur les clusters du mode automatique EKS.
Pour plus d'informations sur ces composants, consultez [Découvrez comment fonctionne le mode automatique EKS](auto-reference.md).
## Configuration
Même si le mode automatique EKS gère efficacement la plupart des services du plan de données sans intervention, il peut arriver que vous souhaitiez adapter le comportement de certains services. Vous pouvez modifier la configuration de vos clusters du mode automatique EKS des manières suivantes :
+ **Kubernetes DaemonSets** : plutôt que de modifier les services installés sur vos nœuds, vous pouvez utiliser des daemonsets Kubernetes. Les DaemonSets sont gérés par Kubernetes, mais s’exécutent sur tous les nœuds du cluster. Cela vous permet d’ajouter des services spécialisés pour surveiller ou contrôler l’état de vos nœuds.
+ ** NodePools Personnalisés et NodeClasses** : Par défaut NodePools et NodeClasses configurés par le mode automatique d'EKS, vous ne devez pas les modifier. Pour personnaliser le comportement des nœuds, vous pouvez créer des cas supplémentaires NodePools ou NodeClasses pour des cas d'utilisation tels que :
+ Sélection de types d’instances spécifiques (par exemple, processeurs accélérés ou instances Spot EC2).
+ Isolation des charges de travail à des fins de sécurité ou de suivi des coûts.
+ Configuration des paramètres de stockage éphémères tels que les IOPS, la taille et le débit.
+ **Équilibrage de charge** : certains services, comme l’équilibrage de charge, exécutés en tant qu’objets Kubernetes par le mode automatique EKS, peuvent être configurés directement dans vos clusters du mode automatique EKS.
Pour plus d’informations sur les options de configuration du mode automatique EKS, consultez [Configurer les paramètres du mode automatique EKS](settings-auto.md).
## Modèle de responsabilité partagée
Le modèle de responsabilité AWS partagée définit les responsabilités en matière de sécurité et de conformité entre AWS et les clients. Les images et le texte ci-dessous comparent et contrastent les différences entre le client et les AWS responsabilités entre le mode automatique d'EKS et le mode standard d'EKS.
![\[Modèle de responsabilité partagée avec le mode automatique EKS et le mode standard\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/eksautosrm.png)
Le mode automatique EKS transfère une grande partie des responsabilités partagées liées à l’infrastructure Kubernetes du client vers AWS. Avec le mode automatique d'EKS, AWS vous assumez davantage la responsabilité de la sécurité du cloud, qui relevait autrefois de la responsabilité du client et qui est désormais partagée. Les clients peuvent désormais se concentrer davantage sur leurs applications tout en AWS gérant l'infrastructure sous-jacente.
**Responsabilité du client**
Avec le mode automatique EKS, les clients demeurent responsables des conteneurs des applications, y compris la disponibilité, la sécurité et la surveillance. Ils gardent également le contrôle de l’infrastructure VPC et de la configuration du cluster EKS. Ce modèle permet aux clients de se concentrer sur les préoccupations spécifiques aux applications tout en déléguant la gestion de l'infrastructure du cluster à. AWS Des fonctionnalités optionnelles par nœud peuvent être incluses dans les clusters par le biais de AWS modules complémentaires.
**Responsabilité d’ AWS **
Avec le mode automatique d'EKS, ses responsabilités AWS s'étendent pour inclure la gestion de plusieurs composants critiques supplémentaires par rapport à ceux déjà gérés dans les clusters EKS n'utilisant pas le mode automatique. Plus précisément, le mode automatique EKS prend en charge la configuration, la gestion, la sécurité et la mise à l’échelle des instances EC2 lancées pour le cluster ainsi que des capacités du cluster liées à l’équilibrage de charge, à la gestion des adresses IP, aux politiques réseau et au stockage par blocs. Les composants suivants sont gérés par AWS le mode automatique EKS :
+ Instances **EC2 lancées en mode automatique : AWS gère le cycle de vie complet des nœuds en tirant parti des instances** gérées par Amazon EC2. Les instances gérées EC2 sont responsables de la configuration du système d’exploitation, de l’application des correctifs, de la surveillance et de la maintenance du système d’exploitation. Dans ce modèle, l’instance elle-même et le système d’exploitation invité qui y est exécuté relèvent de la responsabilité de AWS. Les nœuds utilisent des variantes de [Bottlerocket](https://aws.amazon.com/bottlerocket) AMIs optimisées pour exécuter des conteneurs. Les Bottlerocket AMIs disposent d'un logiciel verrouillé, de systèmes de fichiers racines immuables et d'un accès réseau sécurisé (pour empêcher les communications directes via SSH ou SSM).
+ **Capacités du cluster** : AWS gère le dimensionnement automatique du calcul, la mise en réseau des pods avec l'application des politiques réseau, l'intégration d'Elastic Load Balancing et la configuration des pilotes de stockage.
+ **Plan de contrôle du cluster** : AWS continue de gérer le serveur d'API Kubernetes, les comptes multiples et la base de données etcd ENIs, comme avec le système EKS standard.
+ **Services de base et infrastructure globale** : assume AWS la responsabilité des services sous-jacents de calcul, de stockage, de mise en réseau et de surveillance, ainsi que de l'infrastructure globale des régions, des zones locales et des emplacements périphériques.
# Création d’un cluster avec le mode automatique Amazon EKS
Ce chapitre explique comment créer un cluster Amazon EKS avec le mode automatique activé, en utilisant différents outils et interfaces. Le mode automatique EKS simplifie la création de cluster en configurant et en gérant automatiquement l’infrastructure de cluster computing, de mise en réseau et de stockage du cluster. Vous apprendrez à créer un cluster du mode automatique à l’aide de la CLI AWS, de la AWS Management Console ou de l’outil de ligne de commande eksctl.
**Note**
Le mode automatique EKS nécessite la version 1.29 ou une version ultérieure de Kubernetes.
Choisissez votre outil préféré en fonction de vos besoins : la AWS Management Console fournit une interface visuelle idéale pour découvrir les fonctionnalités du mode automatique EKS et créer des clusters individuels. La CLI AWS convient parfaitement aux tâches de script et d’automatisation, en particulier lorsqu’il s’agit d’intégrer la création de clusters dans des flux de travail existants ou des pipelines CI/CD. La CLI offre une expérience native Kubernetes et est recommandée pour les utilisateurs familiers des outils Kubernetes, souhaitant effectuer des opérations simplifiées en ligne de commande avec des paramètres par défaut pertinents.
Avant de commencer, assurez-vous d’avoir installé et configuré les prérequis nécessaires, notamment les autorisations IAM appropriées pour créer des clusters EKS. Pour savoir comment installer des outils CLI tels que `kubectl`, `aws` et `eksctl`, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
Vous pouvez utiliser la CLI AWS, la AWS Management Console, ou la CLI eksctl pour créer un cluster avec le mode automatique Amazon EKS.
**Topics**
+ [Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl](automode-get-started-eksctl.md)
+ [Création d'un cluster en mode automatique EKS à l'aide de la AWS CLI](automode-get-started-cli.md)
+ [Création d’un cluster du mode automatique EKS à l’aide de la AWS Management Console](automode-get-started-console.md)
# Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl
Cette rubrique vous explique comment créer un cluster du mode automatique Amazon EKS à l’aide de l’interface de ligne de commande (CLI) eksctl. Vous pouvez créer un cluster du mode automatique en exécutant une seule commande CLI ou en appliquant un fichier de configuration YAML. Les deux méthodes fournissent les mêmes fonctionnalités, l’approche YAML offrant un contrôle plus précis des paramètres du cluster.
La CLI eksctl simplifie le processus de création et de gestion des clusters du mode automatique EKS en gérant la création et la configuration des ressources AWS sous-jacentes. Avant de continuer, assurez-vous que les informations d’identification AWS et les autorisations nécessaires sont configurées sur votre ordinateur local. Ce guide suppose que vous connaissez les concepts de base d’Amazon EKS et que vous avez déjà installé les outils CLI requis.
**Note**
Vous devez installer la version `0.195.0` ou ultérieure d’eksctl. Pour plus d’informations, consultez [versions eksctl](https://github.com/eksctl-io/eksctl/releases) sur GitHub.
## Création d’un cluster du mode automatique EKS à l’aide de la commande CLI
Vous devez avoir installé les outils `aws` et `eksctl`. Vous devez être connecté à la CLI AWS avec des autorisations suffisantes pour gérer les ressources AWS, y compris : instances EC2, réseau EC2, clusters EKS et rôles IAM. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
Exécutez la commande suivante pour créer un nouveau cluster du mode automatique EKS avec
```
eksctl create cluster --name= --enable-auto-mode
```
## Création d’un cluster du mode automatique Amazon EKS à l’aide d’un fichier YAML
Vous devez avoir installé les outils `aws` et `eksctl`. Vous devez être connecté à la CLI AWS avec des autorisations suffisantes pour gérer les ressources AWS, y compris : instances EC2, réseau EC2, clusters EKS et rôles IAM. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
Passez en revue les options de configuration du mode automatique EKS dans l’exemple de ressource ClusterConfig ci-dessous. [Pour la spécification complète de ClusterConfig, consultez la documentation eksctl](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS recommande d’activer le mode automatique EKS. Si c’est la première fois que vous créez un cluster du mode automatique EKS, laissez la valeur `nodeRoleARN` non spécifiée pour que le système crée un rôle IAM de nœud pour le mode automatique EKS. Si vous disposez déjà d’un rôle IAM de nœud dans votre compte AWS, AWS recommande de le réutiliser.
AWS recommande de ne pas spécifier de valeur pour `nodePools`. Le mode automatique EKS créera des groupes de nœuds par défaut. Vous pouvez utiliser l’API Kubernetes pour créer des groupes de nœuds supplémentaires.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Enregistrez le fichier `ClusterConfig` sous `cluster.yaml`, puis utilisez la commande suivante pour créer le cluster :
```
eksctl create cluster -f cluster.yaml
```
# Création d'un cluster en mode automatique EKS à l'aide de la AWS CLI
Les clusters du mode automatique EKS automatisent les tâches courantes de gestion du cluster pour le calcul, le stockage et la mise en réseau. Par exemple, les clusters du mode automatique EKS détectent automatiquement lorsque des nœuds supplémentaires sont nécessaires et provisionnent de nouvelles instances EC2 pour répondre aux besoins des charges de travail.
Cette rubrique explique comment créer un nouveau cluster en mode automatique EKS à l'aide de la AWS CLI et éventuellement déployer un exemple de charge de travail.
## Conditions préalables
+ La dernière version de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [configuration rapide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande.
+ Connectez-vous à la CLI avec des autorisations IAM suffisantes pour créer des AWS ressources, notamment des politiques IAM, des rôles IAM et des clusters EKS.
+ L'outil de ligne de commande kubectl installé sur votre appareil. AWS suggère que vous utilisiez la même version de kubectl que la version Kubernetes de votre cluster EKS. Pour installer ou mettre à niveau kubectl, consultez [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
## Spécification des sous-réseaux VPC
Le mode automatique Amazon EKS déploie des nœuds sur des sous-réseaux VPC. Lorsque vous créez un cluster EKS, vous devez spécifier les sous-réseaux VPC dans lesquels les nœuds seront déployés. Vous pouvez utiliser les sous-réseaux VPC par défaut de votre AWS compte ou créer un VPC dédié aux charges de travail critiques.
+ AWS suggère de créer un VPC dédié pour votre cluster. Découvrez comment [Création d’un VPC Amazon pour votre cluster Amazon EKS](creating-a-vpc.md).
+ La console EKS aide à créer un nouveau VPC. Découvrez comment [Création d’un cluster du mode automatique EKS à l’aide de la AWS Management Console](automode-get-started-console.md).
+ Vous pouvez également utiliser le VPC par défaut de votre AWS compte. Suivez les instructions ci-dessous pour trouver le sous-réseau IDs.
### Pour trouver le sous-réseau IDs de votre VPC par défaut
**À l'aide de la AWS CLI :**
1. Exécutez la commande suivante pour répertorier le VPC par défaut et ses sous-réseaux :
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Enregistrez la sortie et notez le **sous-réseau IDs**.
Exemple de sortie :
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## Rôles IAM des clusters du mode automatique EKS
### Rôle IAM du cluster
Le mode automatique d'EKS nécessite un rôle IAM de cluster pour effectuer des actions sur votre AWS compte, telles que le provisionnement de nouvelles instances EC2. Vous devez créer ce rôle pour accorder à EKS les autorisations nécessaires. AWS recommande d'associer les politiques AWS gérées suivantes au rôle IAM du cluster :
+ [EKSComputePolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Rôle IAM de nœud
Lorsque vous créez un cluster du mode automatique EKS, vous spécifiez un rôle IAM de nœud. Lorsque le mode automatique EKS crée des nœuds pour traiter les charges de travail en attente, chaque nouvelle instance EC2 est associée au rôle IAM de nœud. Ce rôle permet au nœud de communiquer avec EKS, mais il n’est généralement pas utilisé par les charges de travail qui s’exécutent sur ce nœud.
Si vous souhaitez accorder des autorisations à des charges de travail exécutées sur un nœud, utilisez l’identité du pod EKS. Pour de plus amples informations, veuillez consulter [Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md).
Vous devez créer ce rôle et y associer la politique AWS gérée suivante :
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
Le mode automatique EKS nécessite également un rôle lié au service, qui est automatiquement créé et configuré par AWS. Pour plus d'informations, consultez [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## Création d’un rôle IAM de cluster du mode automatique Amazon EKS
### Étape 1 : créer la politique d’approbation
Créez une politique d’approbation qui permet au service Amazon EKS d’assumer le rôle. Enregistrez la politique sous `trust-policy.json` :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Étape 2 : créer le rôle IAM
Utilisez la politique d’approbation pour créer le rôle IAM du cluster :
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### Étape 3 : noter l’ARN du rôle
Extrayez et enregistrez l’ARN du nouveau rôle pour les étapes ultérieures :
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### Étape 4 : attacher les politiques requises
Associez les politiques AWS gérées suivantes au rôle IAM du cluster pour accorder les autorisations nécessaires :
**EKSClusterPolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputePolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingPolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
## Création d’un rôle IAM de nœud du mode automatique EKS
### Étape 1 : créer la politique d’approbation
Créez une politique d’approbation qui permet au service Amazon EKS d’assumer le rôle. Enregistrez la politique sous `node-trust-policy.json` :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Étape 2 : créer le rôle IAM du nœud
Utilisez le fichier **node-trust-policy.json** de l'étape précédente pour définir les entités qui peuvent assumer le rôle. Exécutez la commande suivante pour créer le rôle IAM du nœud :
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Étape 3 : noter l’ARN du rôle
Après la création du rôle, extrayez et enregistrez l’ARN du rôle IAM du nœud. Cet ARN sera nécessaire dans les étapes suivantes. Utilisez la commande suivante pour extraire l’ARN :
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Étape 4 : attacher les politiques requises
Associez les politiques AWS gérées suivantes au rôle Node IAM pour fournir les autorisations nécessaires :
**Amazon EKSWorker NodeMinimalPolicy** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## Création d’un cluster du mode automatique EKS
### Présentation de
Pour créer un cluster en mode automatique EKS à l'aide de la AWS CLI, vous aurez besoin des paramètres suivants :
+ `cluster-name` : nom du cluster.
+ `k8s-version` : version Kubernetes (p. ex. : 1.31).
+ `subnet-ids`: sous-réseau IDs identifié lors des étapes précédentes.
+ `cluster-role-arn` : ARN du rôle IAM du cluster.
+ `node-role-arn` : ARN du rôle IAM de nœud.
#### Configurations de clusters par défaut
Vérifiez ces valeurs et fonctionnalités par défaut avant de créer le cluster :
+ `nodePools` : le mode automatique EKS inclut des groupes de nœuds généraux et des groupes de nœuds système par défaut. Pour en savoir plus, consultez [Groupes de nœuds](create-node-pool.md).
**Remarque :** les groupes de nœuds du mode automatique EKS sont différents des groupes de nœuds gérés par Amazon EKS, mais ils peuvent coexister dans le même cluster.
+ `computeConfig.enabled` : automatise les tâches de calcul de routine, telles que la création et la suppression d’instances EC2.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled` : automatise les tâches d’équilibrage de charge, notamment la création et la suppression d’équilibreur de charges Elastic Load Balancer.
+ `storageConfig.blockStorage.enabled` : automatise les tâches de stockage, telles que la création et la suppression de volumes Amazon EBS.
+ `accessConfig.authenticationMode` : nécessite des entrées d’accès EKS. Pour en savoir plus, consultez [Modes d’authentification EKS](grant-k8s-access.md).
#### Exécution de la commande
Utilisez la commande suivante pour créer le cluster :
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Vérification de l’état du cluster
#### Étape 1 : vérifier la création de cluster
Exécutez la commande suivante pour vérifier l’état de votre cluster. La création d’un cluster prend généralement environ 15 minutes :
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Étape 2 : mettre à jour kubeconfig
Une fois le cluster prêt, mettez à jour votre fichier kubeconfig local pour permettre à `kubectl` de communiquer avec le cluster. Cette configuration utilise la AWS CLI pour l'authentification.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Étape 3 : vérifier les groupes de nœuds
Répertoriez les groupes de nœuds présents dans votre cluster à l’aide de la commande suivante :
```
kubectl get nodepools
```
## Étapes suivantes
+ Découvrez comment [déployer un exemple de charge de travail](automode-workload.md) sur votre nouveau cluster du mode automatique EKS.
# Création d’un cluster du mode automatique EKS à l’aide de la AWS Management Console
La création d’un cluster du mode automatique EKS dans la AWS Management Console nécessite moins de configuration que les autres options. EKS s’intègre aux réseaux AWS IAM et VPC pour vous aider à créer les ressources associées à un cluster EKS.
Vous disposez de deux options pour créer un cluster dans la console :
+ Configuration rapide (avec le mode automatique EKS)
+ Configuration personnalisée
Dans cette rubrique, vous apprendrez à créer un cluster du mode automatique EKS en utilisant l’option Configuration rapide.
## Création d’un cluster du mode automatique EKS avec l’option de configuration rapide
Vous devez être connecté à la AWS Management Console avec des autorisations suffisantes pour gérer les ressources AWS, y compris :instances EC2, le réseau EC2, les clusters EKS et les rôles IAM.
1. Navigation vers la console EKS
1. Cliquez sur **Créer un cluster**
1. Vérifiez que l’option **Configuration rapide** est sélectionnée
1. Déterminez les valeurs suivantes, ou utilisez les valeurs par défaut pour un cluster de test.
+ **Nom** du cluster
+ Version de Kubernetes
1. Sélectionnez le rôle IAM du cluster. Si c’est la première fois que vous créez un cluster du mode automatique EKS, utilisez l’option **Créer un rôle recommandé**.
+ Vous pouvez, si vous le souhaitez, réutiliser un seul rôle IAM de cluster dans votre compte AWS pour tous les clusters du mode automatique EKS.
+ Le rôle IAM du cluster inclut les autorisations requises pour le mode automatique EKS afin de gérer les ressources, notamment les instances EC2, les volumes EBS et les équilibreurs de charge EC2.
+ L’option **Créer un rôle recommandé** préremplit tous les champs avec les valeurs recommandées. Sélectionnez **Suivant**, puis **Créer**. Le rôle utilisera le nom `AmazonEKSAutoClusterRole` suggéré.
+ Si vous avez récemment créé un nouveau rôle, utilisez l’icône **Actualiser** pour recharger le menu déroulant de sélection des rôles.
1. Sélectionnez le rôle IAM de nœud. Si c’est la première fois que vous créez un cluster du mode automatique EKS, utilisez l’option **Créer un rôle recommandé**.
+ Vous pouvez éventuellement réutiliser un rôle IAM de nœud unique dans votre AWS compte pour tous les clusters du mode automatique EKS.
+ Le rôle IAM de nœud inclut les autorisations nécessaires pour permettre aux nœuds du mode automatique de se connecter au cluster. Le rôle IAM de nœud doit également inclure les autorisations permettant d’extraire les images ECR nécessaires à vos conteneurs.
+ L’option **Créer un rôle recommandé** préremplit tous les champs avec les valeurs recommandées. Sélectionnez **Suivant**, puis **Créer**. Le rôle utilisera le nom `AmazonEKSAutoNodeRole` suggéré.
+ Si vous avez récemment créé un nouveau rôle, utilisez l’icône **Actualiser** pour recharger le menu déroulant de sélection des rôles.
1. Sélectionnez le VPC pour votre cluster du mode automatique EKS. Sélectionnez **Créer un VPC** pour créer un nouveau VPC pour EKS, ou choisissez un VPC que vous avez déjà créé pour EKS.
+ Si vous utilisez la console VPC pour créer un nouveau VPC, AWS vous recommande de créer au moins une passerelle NAT par zone de disponibilité. Sinon, vous pouvez utiliser toutes les autres valeurs par défaut.
+ Pour plus d’informations et de détails sur les exigences du cluster IPv6, consultez [Création d’un VPC Amazon pour votre cluster Amazon EKS](creating-a-vpc.md).
1. (facultatif) Le mode automatique EKS remplit automatiquement les sous-réseaux privés du VPC sélectionné. Vous pouvez supprimer les sous-réseaux indésirables.
+ EKS sélectionne automatiquement les sous-réseaux privés à partir du VPC conformément aux meilleures pratiques. Vous pouvez éventuellement sélectionner des sous-réseaux supplémentaires dans le VPC, tels que des sous-réseaux publics.
1. (facultatif) Sélectionnez **Afficher les valeurs par défaut de la configuration rapide** pour passer en revue toutes les valeurs de configuration du nouveau cluster. Le tableau indique que certaines valeurs ne sont plus modifiables une fois le cluster créé.
1. Sélectionnez **Créer un cluster**. Notez que la création du cluster peut prendre quinze minutes.
## Étapes suivantes
+ Découvrez comment [Déployer un exemple de charge de travail sur votre cluster du mode automatique EKS](sample-storage-workload.md)
# Activer le mode automatique EKS sur les clusters EKS existants
Vous pouvez activer le mode automatique EKS sur les clusters EKS existants.
**AWS prend en charge les migrations suivantes :**
+ Migration de Karpenter vers les nœuds du mode automatique EKS. Pour de plus amples informations, consultez [Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl](auto-migrate-karpenter.md).
+ Migration des groupes de nœuds gérés par EKS vers des nœuds du mode automatique EKS. Pour de plus amples informations, consultez [Migration des groupes de nœuds gérés EKS vers le mode automatique EKS](auto-migrate-mng.md).
+ Migration d’EKS Fargate vers le mode automatique EKS. Pour de plus amples informations, consultez [Migration d’EKS Fargate vers le mode automatique EKS](auto-migrate-fargate.md).
**AWS ne prend pas en charge les migrations suivantes :**
+ Migration des volumes du contrôleur CSI EBS (à l’aide du module complémentaire Amazon EKS) vers le contrôleur CSI EBS en mode automatique EKS (géré par le mode automatique EKS). Les PVC créés avec l’un ne peuvent pas être montés par l’autre, car ils utilisent deux provisionneurs de volume Kubernetes différents.
+ Le [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)(projet AWS Labs) permet la migration entre la norme EBS CSI StorageClass (`ebs.csi.aws.com`) et EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`). Notez que la migration nécessite la suppression et la recréation des ressources PersistentVolumeClaim/PersistentVolume existantes. Il est donc essentiel de procéder à une validation dans un environnement hors production avant la mise en œuvre.
+ Migration des équilibreurs de charge de l’AWS Load Balancer Controller vers le mode automatique EKS
Vous pouvez installer l’AWS Load Balancer Controller sur un cluster du mode automatique Amazon EKS. Utilisez les options `IngressClass` ou `loadBalancerClass` pour associer les ressources de service et d’entrée au Load Balancer Controller ou au mode automatique EKS.
+ Migration de clusters EKS avec des CNI alternatifs ou d’autres configurations réseau non prises en charge
## Référence de migration
Utilisez la référence de migration suivante pour configurer les ressources Kubernetes afin qu’elles appartiennent soit à des contrôleurs autogérés, soit au mode automatique EKS.
| Capacité | Ressource | Champ | Autogéré | Mode automatique EKS |
| --- | --- | --- | --- | --- |
| Stockage en mode bloc | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Équilibrage de charge | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Équilibrage de charge | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Équilibrage de charge | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Équilibrage de charge | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Calcul | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migration de volumes EBS
Lors de la migration des charges de travail vers le mode automatique EKS, vous devez gérer la migration des volumes EBS en raison des différents provisionneurs de pilotes CSI :
+ Provisionneur du mode automatique EKS : `ebs.csi.eks.amazonaws.com`
+ Provisionneur CSI EBS open source : `ebs.csi.aws.com`
Pour migrer vos volumes persistants, procédez comme suit :
1. **Modifier la politique de conservation des volumes** : modifier la version `persistentVolumeReclaimPolicy` existante de la plate-forme (PV) vers `Retain` afin de garantir que le volume EBS sous-jacent ne soit pas supprimé.
1. **Supprimer le PV de Kubernetes** : supprimez l’ancienne ressource PV tout en préservant le volume EBS réel.
1. **Créez un nouveau PV avec provisionnement statique** : créez un nouveau PV qui fait référence au même volume EBS mais fonctionne avec le pilote CSI cible.
1. **Liaison à un nouveau PVC** : créez un nouveau PVC qui fait spécifiquement référence à votre PV en utilisant le champ `volumeName`.
### Considérations
+ Assurez-vous que vos applications sont arrêtées avant de commencer cette migration.
+ Sauvegardez vos données avant de commencer le processus de migration.
+ Ce processus doit être effectué pour chaque volume persistant.
+ La charge de travail doit être mise à jour pour utiliser le nouveau PVC.
## Migration des équilibreurs de charge
Vous ne pouvez pas transférer directement les équilibreurs de charge existants de l’AWS Load Balancer Controller autogéré vers le mode automatique EKS. Vous devez plutôt mettre en œuvre une stratégie de déploiement bleu/vert. Cela implique de conserver votre configuration d’équilibreur de charge existante tout en créant de nouveaux répartiteurs de charge sous le contrôleur géré.
Afin de minimiser les perturbations du service, nous recommandons une approche de transfert du trafic basée sur le DNS. Commencez par créer de nouveaux équilibreurs de charge à l’aide du mode automatique EKS tout en conservant votre configuration existante opérationnelle. Ensuite, utilisez le routage DNS (tel que Route 53) pour transférer progressivement le trafic des anciens équilibreurs de charge vers les nouveaux. Une fois le trafic migré avec succès et la nouvelle configuration vérifiée, vous pouvez mettre hors service les anciens équilibreurs de charge et le contrôleur autogéré.
# Activation du mode automatique EKS sur un cluster existant
Cette rubrique explique comment activer le mode automatique EKS sur des clusters Amazon EKS déjà existants. L’activation du mode automatique sur un cluster existant nécessite la mise à jour des autorisations IAM et la configuration des paramètres essentiels du mode automatique EKS. Une fois activé, vous pouvez commencer à migrer vos charges de calcul existantes afin de profiter des opérations simplifiées et de la gestion automatisée de l’infrastructure offertes par le mode automatique.
**Important**
Avant d’activer le mode automatique EKS, vérifiez que vous disposez de la version minimale requise de certains modules complémentaires Amazon EKS. Pour de plus amples informations, veuillez consulter [Versions requises des modules complémentaires](#auto-addons-required).
Avant de commencer, assurez-vous également de disposer d’un accès administrateur à votre cluster Amazon EKS et des autorisations nécessaires pour modifier les rôles IAM. Les étapes décrites dans cette rubrique vous expliquent comment activer le mode automatique à l'aide de la AWS CLI AWS Management Console ou de la CLI.
## AWS Management Console
Vous devez être connecté à la AWS console avec l'autorisation de gérer IAM, EKS et les EC2 ressources.
**Note**
Le rôle IAM d’un cluster EKS ne peut pas être modifié après la création du cluster. Le mode automatique EKS nécessite des autorisations supplémentaires pour ce rôle. Vous devez donc attacher des politiques supplémentaires au rôle actuel.
### Mise à jour du rôle IAM du cluster
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **ARN du rôle IAM du cluster**, sélectionnez **Afficher dans IAM**.
1. Dans la liste déroulante **Ajouter des autorisations**, sélectionnez **Attacher des politiques**.
1. Dans la boîte **Recherche**, trouvez et sélectionnez les politiques suivantes :
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Sélectionnez **Ajouter des autorisations**
1. Dans l’onglet **Relations d’approbation**, sélectionnez **Modifier la politique d’approbation**
1. Insérez la politique d’approbation du rôle IAM du cluster suivante, puis sélectionnez **Mettre à jour la politique**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Activation du mode automatique EKS
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **Mode automatique EKS**, sélectionnez **Gérer**
1. Activez l’option **Mode automatique EKS**.
1. Dans le menu déroulant **Groupe de nœuds EKS**, sélectionnez les groupes de nœuds par défaut que vous souhaitez créer.
+ Pour plus d’informations, consultez la section sur les groupes de nœuds en mode automatique EKS. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
1. Si vous avez déjà créé un rôle IAM de nœud en mode automatique EKS sur ce AWS compte, sélectionnez-le dans le menu déroulant **Rôle de nœud IAM**. Si vous n’avez pas encore créé ce rôle, sélectionnez **Créer le rôle recommandé** et suivez les étapes indiquées.
## AWS CLI
### Conditions préalables
+ Le rôle IAM du cluster EKS existant doit inclure les autorisations suffisantes pour le mode automatique EKS, notamment les politiques suivantes :
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ Le rôle IAM du cluster doit également comporter une politique d’approbation mise à jour incluant l’action `sts:TagSession`. Pour plus d’informations sur la création d’un rôle IAM de cluster, consultez [Création d'un cluster en mode automatique EKS à l'aide de la AWS CLI](automode-get-started-cli.md).
+ Assurez-vous que la CLI `aws` est installée, connectée et à jour. Vous devez être autorisé à gérer IAM, EKS et les EC2 ressources. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
### Procédure
Utilisez les commandes suivantes pour activer le mode automatique EKS sur un cluster existant.
**Note**
Les capacités de calcul, de stockage bloc et d’équilibrage de charge doivent toutes être activées ou désactivées dans la même requête.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versions requises des modules complémentaires
Si vous prévoyez d’activer le mode automatique EKS sur un cluster existant, il peut être nécessaire de mettre à jour certains modules complémentaires. Remarques :
+ Cela s’applique uniquement aux clusters existants en cours de transition vers le mode automatique EKS.
+ Les nouveaux clusters créés avec le mode automatique EKS déjà activé n’ont pas besoin de ces mises à jour.
Si l’un des modules complémentaires suivants est installé, assurez-vous qu’il possède au moins la version minimale spécifiée :
| Nom du module complémentaire | Version minimale requise |
| --- | --- |
| Plug-in CNI Amazon VPC pour Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/auto-enable-existing.html) |
| Pilote CSI Amazon EBS | v1.37.0-eksbuild.1 |
| Contrôleur d'instantané CSI | v8.1.0-eksbuild.2 |
| Agent d'identité du pod EKS | v1.3.4-eksbuild.1 |
Pour de plus amples informations, veuillez consulter [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md).
## Étapes suivantes
+ Pour migrer les charges de travail de gestion des groupes de nœuds, consultez [Migration des groupes de nœuds gérés EKS vers le mode automatique EKS](auto-migrate-mng.md).
+ Pour migrer depuis Karpenter autogéré, consultez [Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl](auto-migrate-karpenter.md).
# Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl
Cette rubrique décrit en détail le processus de migration des charges de travail de Karpenter vers le mode automatique Amazon EKS à l’aide de kubectl. La migration peut être effectuée progressivement, vous permettant de transférer les charges de travail à votre propre rythme, tout en préservant la stabilité du cluster et la disponibilité des applications pendant toute la transition.
L' step-by-stepapproche décrite ci-dessous vous permet d'exécuter Karpenter et le mode automatique d'EKS côte à côte pendant la période de migration. Cette stratégie de double exploitation garantit une transition fluide, car elle vous permet de valider le comportement des charges de travail en mode automatique EKS avant de désactiver complètement Karpenter. Vous pouvez migrer les applications individuellement ou par groupes, ce qui offre une flexibilité accrue pour répondre à vos exigences opérationnelles spécifiques et à votre tolérance au risque.
## Conditions préalables
Avant de commencer la migration, assurez-vous d’avoir :
+ Karpenter v1.1 ou une version ultérieure installée sur votre cluster. Pour plus d’informations, consultez [Mise à niveau vers la version 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) dans la documentation Karpenter.
+ `kubectl` installé et connecté à votre cluster. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
Cette rubrique suppose que vous connaissez Karpenter et NodePools. Pour plus d’informations, consultez la [Documentation Karpenter](https://karpenter.sh/).
## Étape 1 : activer le mode automatique EKS sur le cluster
Activez le mode automatique EKS sur votre cluster existant à l'aide de la AWS CLI ou de la console de gestion. Pour de plus amples informations, veuillez consulter [Activation du mode automatique EKS sur un cluster existant](auto-enable-existing.md).
**Note**
Lors de l’activation du mode automatique EKS, n’activez pas le groupe de nœuds `general purpose` à ce stade de la transition. Ce groupe de nœuds n’est pas sélectif.
Pour de plus amples informations, veuillez consulter [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
## Étape 2 : Création d'un mode automatique EKS altéré NodePool
Créez un nouveau mode automatique NodePool pour EKS avec une teinte. Cela garantit que les pods existants ne seront pas automatiquement planifiés sur les nouveaux nœuds du mode automatique EKS. Ce groupe de nœuds utilise la `NodeClass` `default` intégrée au mode automatique EKS. Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
Exemple de groupe de nœuds avec balise de rejet :
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Mettez à jour les exigences du groupe de nœuds afin qu’elles correspondent à la configuration Karpenter d’origine à partir de laquelle vous effectuez la migration. Vous devez définir au moins une exigence.
## Étape 3 : mettre à jour les charges de travail pour la migration
Identifiez et mettez à jour les charges de travail que vous souhaitez migrer vers le mode automatique EKS. Ajoutez des tolérances et des sélecteurs de nœuds à ces charges de travail :
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Cette modification permet de planifier la charge de travail sur les nouveaux nœuds du mode automatique EKS.
Le mode automatique EKS utilise des étiquettes différentes de celles de Karpenter. Les étiquettes associées aux instances EC2 gérées commencent par`eks.amazonaws.com`. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Étape 4 : migrer progressivement les charges de travail
Répétez l’étape 3 pour chaque charge de travail que vous souhaitez migrer. Cette méthode vous permet de déplacer les charges de travail individuellement ou par groupes, selon vos besoins et votre tolérance au risque.
## Étape 5 : Retirez le Karpenter d'origine NodePool
Une fois que toutes les charges de travail ont été migrées, vous pouvez supprimer le Karpenter d'origine : NodePool
```
kubectl delete nodepool
```
## Étape 6 : Supprimer les taches du mode automatique EKS NodePool (facultatif)
Si vous souhaitez que le mode automatique EKS devienne le mode par défaut pour les nouvelles charges de travail, vous pouvez supprimer les traces du mode automatique EKS : NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Étape 7 : supprimer les sélecteurs de nœuds des charges de travail (facultatif)
Si vous avez supprimé l'altération du mode automatique EKS NodePool, vous pouvez éventuellement supprimer les sélecteurs de nœuds de vos charges de travail, le mode automatique EKS étant désormais le mode par défaut :
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Étape 8 : désinstaller Karpenter de votre cluster
Les étapes de suppression de Karpenter dépendent de la méthode d’installation que vous avez utilisée. Pour plus d’informations, consultez les [Instructions d’installation de Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migration des groupes de nœuds gérés EKS vers le mode automatique EKS
Lors de la transition de votre cluster Amazon EKS vers le mode automatique EKS, vous pouvez migrer en douceur vos charges de travail existantes à partir des groupes de nœuds gérés (Managed Node Groups, MNG) à l’aide de l’outil CLI eksctl. Ce processus garantit la disponibilité continue des applications, tout en permettant au mode automatique EKS d’optimiser vos ressources de calcul. La migration peut être effectuée avec un minimum d’interruptions pour vos applications en cours d’exécution.
Cette rubrique présente les étapes à suivre pour évacuer en toute sécurité les pods de vos groupes de nœuds gérés existants et permettre au mode automatique EKS de les replanifier automatiquement sur de nouvelles instances provisionnées. En suivant cette procédure, vous pourrez tirer parti de la consolidation intelligente des charges de travail en mode automatique EKS, tout en préservant la disponibilité de vos applications pendant toute la durée de la migration.
## Prérequis
+ Cluster avec le mode automatique EKS activé
+ CLI `eksctl` installée et connectée à votre cluster. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
+ Karpenter non installé sur le cluster.
## Procédure
Utilisez la commande CLI `eksctl` suivante pour commencer à évacuer les pods des instances de groupes de nœuds gérés existants. Le mode automatique EKS créera automatiquement de nouveaux nœuds pour héberger les pods déplacés.
```
eksctl delete nodegroup --cluster= --name=
```
Vous devrez exécuter cette commande pour chaque groupe de nœuds géré de votre cluster.
Pour plus d’informations sur cette commande, consultez [Suppression et évacuation des groupes de nœuds](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) dans la documentation eksctl.
# Migration d’EKS Fargate vers le mode automatique EKS
Cette rubrique décrit en détail le processus de migration des charges de travail d’EKS Fargate vers le mode automatique Amazon EKS à l’aide de `kubectl`. La migration peut être effectuée progressivement, vous permettant de transférer les charges de travail à votre propre rythme, tout en préservant la stabilité du cluster et la disponibilité des applications pendant toute la transition.
L' step-by-stepapproche décrite ci-dessous vous permet d'exécuter EKS Fargate et EKS Auto Mode côte à côte pendant la période de migration. Cette stratégie de double exploitation garantit une transition fluide, car elle vous permet de valider le comportement des charges de travail sous le mode automatique EKS avant de désactiver complètement EKS Fargate. Vous pouvez migrer les applications individuellement ou par groupes, ce qui offre une flexibilité accrue pour répondre à vos exigences opérationnelles spécifiques et à votre tolérance au risque.
## Comparaison entre le mode automatique d'Amazon EKS et EKS avec AWS Fargate
Amazon EKS with AWS Fargate reste une option pour les clients qui souhaitent exécuter EKS, mais le mode automatique Amazon EKS est l'approche recommandée pour l'avenir. Le mode automatique EKS est entièrement conforme à Kubernetes, et prend en charge tous les éléments natifs de Kubernetes ainsi que les outils de plateforme tels qu’Istio, que Fargate ne prend pas en charge. Le mode automatique EKS prend également en charge toutes les options d’exécution EC2, y compris les instances GPU et Spot, permettant ainsi aux clients de bénéficier des remises EC2 négociées et d’autres mécanismes d’optimisation des coûts. Ces fonctionnalités ne sont pas disponibles avec EKS associé à Fargate.
De plus, le mode automatique EKS permet d’obtenir le même modèle d’isolation que Fargate, en utilisant les capacités natives de planification de Kubernetes pour garantir que chaque instance EC2 exécute un seul conteneur d’application. En adoptant le mode automatique d'Amazon EKS, les clients peuvent profiter de tous les avantages liés à 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 d'achat et d'EC2 tout en conservant la facilité d'utilisation et l'abstraction de la gestion de l'infrastructure proposées par Fargate.
### Obtenir une isolation semblable à celle de Fargate en mode automatique EKS
Pour répliquer le modèle d'isolation des pods de Fargate dans lequel chaque pod s'exécute sur sa propre instance dédiée, vous pouvez utiliser les contraintes de propagation de la topologie Kubernetes. Voici l'approche recommandée pour contrôler la distribution des pods entre les nœuds :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
Dans cette configuration :
+ `maxSkew: 1`garantit que la différence de nombre de pods entre deux nœuds est d'au plus 1, en répartissant efficacement un pod par nœud
+ `topologyKey: kubernetes.io/hostname`définit le nœud en tant que domaine topologique
+ `whenUnsatisfiable: DoNotSchedule`empêche la planification si la contrainte ne peut pas être respectée
+ `minDomains: 1`s'assure qu'au moins un domaine (nœud) existe avant la planification
Le mode automatique d'EKS provisionne automatiquement les nouvelles instances EC2 selon les besoins pour satisfaire cette contrainte, en fournissant le même modèle d'isolation que Fargate tout en vous donnant accès à la gamme complète des types d'instances EC2 et des options d'achat.
Vous pouvez également utiliser les règles d'anti-affinité des pods pour une isolation plus stricte :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
La `podAntiAffinity` règle `requiredDuringSchedulingIgnoredDuringExecution` garantit qu'aucun module portant l'étiquette ne `app: isolated-app` peut être planifié sur le même nœud. Cette approche fournit des garanties d'isolation strictes similaires à celles de Fargate.
## Conditions préalables
Avant de commencer la migration, assurez-vous d’avoir
+ Mis en place un cluster avec Fargate. Pour de plus amples informations, veuillez consulter [Commencez à utiliser AWS Fargate pour votre cluster](fargate-getting-started.md).
+ Installé et connecté `kubectl` à votre cluster. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
## Étape 1 : vérifier le cluster Fargate
1. Vérifiez si le cluster EKS avec Fargate est en cours d’exécution :
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Vérifiez les pods en cours d’exécution :
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Créez un déploiement dans un fichier appelé `deployment_fargate.yaml` :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Appliquez le déploiement :
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Vérifiez les pods et les déploiements :
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Vérifiez le nœud :
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Étape 2 : activer le mode automatique EKS sur le cluster
1. Activez le mode automatique EKS sur votre cluster existant à l'aide de la AWS CLI ou de la console de gestion. Pour de plus amples informations, veuillez consulter [Activation du mode automatique EKS sur un cluster existant](auto-enable-existing.md).
1. Vérifiez le groupe de nœuds :
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Étape 3 : mettre à jour les charges de travail pour la migration
Identifiez et mettez à jour les charges de travail que vous souhaitez migrer vers le mode automatique EKS.
Pour migrer une charge de travail de Fargate vers le mode automatique EKS, appliquez l’annotation `eks.amazonaws.com/compute-type: ec2`. Cela garantit que la charge de travail ne sera pas planifiée par Fargate, malgré le profil Fargate, et qu'elle sera absorbée par le mode automatique EKS. NodePool Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
1. Modifiez vos déploiements (par exemple le fichier `deployment_fargate.yaml`) afin de changer le type de calcul en `ec2` :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Appliquez le déploiement. Cette modification permet de planifier la charge de travail sur les nouveaux nœuds du mode automatique EKS :
```
kubectl apply -f deployment_fargate.yaml
```
1. Vérifiez que le déploiement est en cours d’exécution dans le cluster du mode automatique EKS :
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Vérifiez qu’aucun nœud Fargate n’est en cours d’exécution et que le déploiement s’exécute sur les nœuds gérés en mode automatique EKS :
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Étape 4 : migrer progressivement les charges de travail
Répétez l’étape 3 pour chaque charge de travail que vous souhaitez migrer. Cette méthode vous permet de déplacer les charges de travail individuellement ou par groupes, selon vos besoins et votre tolérance au risque.
## Étape 5 : supprimer le profil Fargate d’origine
Une fois que toutes les charges de travail ont été migrées, vous pouvez supprimer le profil `fargate` d’origine. Remplacez ** par le nom de votre profil Fargate :
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Étape 6 : réduire verticalement CoreDNS
Comme le mode automatique EKS prend en charge CoreDNS, vous devez réduire le déploiement `coredns` à 0 :
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Exécution d’exemples de charges de travail dans des clusters du mode automatique EKS
Ce chapitre fournit des exemples de déploiement de différents types de charges de travail sur des clusters Amazon EKS exécutés en mode automatique. Les exemples illustrent des modèles de charges de travail clés, notamment des exemples d’applications, des applications web avec équilibrage de charge, des charges de travail avec état utilisant du stockage persistant, et des charges de travail nécessitant un placement spécifique des nœuds. Chaque exemple inclut des manifestes complets et des instructions de step-by-step déploiement que vous pouvez utiliser comme modèles pour vos propres applications.
Avant de passer aux exemples, assurez-vous qu'un cluster EKS fonctionne en mode automatique et que vous avez installé la AWS CLI et kubectl. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md). Les exemples présupposent une connaissance de base des concepts Kubernetes et des commandes kubectl.
Vous pouvez utiliser ces exemples basés sur des cas d’utilisation pour exécuter des charges de travail dans des clusters du mode automatique EKS.
[Déploiement d’une charge de travail de gonflement dans un cluster du mode automatique Amazon EKS](automode-workload.md)
Montre comment déployer un exemple de charge de travail sur un cluster du mode automatique EKS à l’aide de commandes `kubectl`.
[Déploiement d’une charge de travail de l’équilibreur de charge en mode automatique EKS](auto-elb-example.md)
Montre comment déployer une version conteneurisée du jeu 2048 sur Amazon EKS.
[Déployer un exemple de charge de travail avec état dans le mode automatique EKS](sample-storage-workload.md)
Montre comment déployer un exemple d’application dynamique sur un cluster du mode automatique EKS.
[Déploiement d’une charge de travail accélérée](auto-accelerated.md)
Montre comment déployer des charges de travail accélérées par le matériel sur des nœuds gérés par le mode automatique EKS.
[Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md)
Montre comment utiliser une annotation pour contrôler si une charge de travail est déployée sur des nœuds gérés par le mode automatique EKS.
# Déploiement d’une charge de travail de gonflement dans un cluster du mode automatique Amazon EKS
Ce tutoriel montre comment déployer une charge de travail d’exemple dans un cluster du mode automatique EKS et observer le provisionnement automatique des ressources de calcul nécessaires. Vous utiliserez des `kubectl` commandes pour observer le comportement du cluster et voir par vous-même comment le mode automatique simplifie les opérations de Kubernetes sur. AWSÀ la fin de ce tutoriel, vous comprendrez comment le mode automatique EKS réagit aux déploiements de charges de travail en gérant automatiquement les ressources de calcul sous-jacentes, sans configuration manuelle de groupes de nœuds.
## Conditions préalables
+ Un cluster du mode automatique Amazon EKS. Notez le nom et AWS la région du cluster.
+ Un principal IAM, tel qu’un utilisateur ou un rôle, disposant d’autorisations suffisantes pour gérer le réseau, le calcul et les ressources EKS.
+ Pour plus d’informations, consultez la section [Création de rôles et attribution de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) dans le Guide de l’utilisateur IAM.
+ CLI `aws` installée et configurée avec une identité IAM.
+ CLI `kubectl` installée et connectée au cluster.
+ Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
## Étape 1 : consulter les ressources de calcul existantes (facultatif)
Tout d’abord, utilisez `kubectl` pour répertorier les groupes de nœuds de votre cluster.
```
kubectl get nodepools
```
Exemple de résultat :
```
general-purpose
```
Dans ce tutoriel, nous allons déployer une charge de travail configurée pour utiliser le groupe de nœuds `general-purpose`. Ce groupe de nœuds est intégré au mode automatique EKS et propose des valeurs par défaut raisonnables pour des charges générales, comme des microservices et des applications web. Vous pouvez créer votre propre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
Ensuite, utilisez `kubectl` pour répertorier les nœuds connectés à votre cluster.
```
kubectl get nodes
```
Si vous venez de créer un cluster du mode automatique EKS, vous n’aurez aucun nœud.
Dans ce tutoriel, vous allez déployer un exemple de charge de travail. Si vous n’avez aucun nœud ou si la charge de travail ne peut pas être adaptée aux nœuds existants, le mode automatique EKS provisionnera un nouveau nœud.
## Étape 2 : déployer un exemple d’application sur votre cluster
Consultez le déploiement Kubernetes suivant et enregistrez-le sous `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Notez que le sélecteur `eks.amazonaws.com/compute-type: auto` nécessite que la charge de travail soit déployée sur un nœud du mode automatique Amazon EKS.
Appliquez le déploiement à votre cluster.
```
kubectl apply -f inflate.yaml
```
## Étape 3 : surveiller les événements Kubernetes
Utilisez la commande suivante pour surveiller les événements Kubernetes, notamment la création d’un nouveau nœud. Utilisez `ctrl+c` pour arrêter la surveillance des événements.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilisez `kubectl` pour répertorier à nouveau les nœuds connectés à votre cluster. Notez le nœud nouvellement créé.
```
kubectl get nodes
```
## Étape 4 : Afficher les nœuds et les instances dans la AWS console
Vous pouvez afficher les nœuds du mode automatique EKS dans la console EKS et les EC2 instances associées dans la EC2 console.
EC2 Les instances déployées par le mode automatique d'EKS sont soumises à des restrictions. Vous ne pouvez pas exécuter de commandes arbitraires sur les nœuds du mode automatique EKS.
## Étape 5 : supprimer le déploiement
Utilisez `kubectl` pour supprimer l’exemple de déploiement
```
kubectl delete -f inflate.yaml
```
Si aucune autre charge de travail n’est déployée sur votre cluster, le nœud créé par le mode automatique EKS sera vide.
Dans la configuration par défaut, le mode automatique EKS détecte les nœuds vides depuis trente secondes et les arrête.
Utilisez `kubectl` la EC2 console pour confirmer que l'instance associée a été supprimée.
# Déploiement d’une charge de travail de l’équilibreur de charge en mode automatique EKS
Ce guide explique comment déployer une version conteneurisée du jeu 2048 sur Amazon EKS, avec équilibreur de charge et accès Internet.
## Prérequis
+ Un cluster du mode automatique EKS
+ `kubectl` configuré pour interagir avec votre cluster
+ Autorisations IAM nécessaires pour créer des ressources ALB
## Étape 1 : créer l’espace de noms
Créez d’abord un espace de noms dédié pour l’application de jeu 2048.
Créez un fichier nommé `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Appliquez la configuration de l’espace de noms :
```
kubectl apply -f 01-namespace.yaml
```
## Étape 2 : déployer l’application
L’application exécute plusieurs réplicas du conteneur du jeu 2048.
Créez un fichier nommé `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**Note**
Si vous recevez une erreur lors du chargement de l’image `public.ecr.aws/l6m2t8p7/docker-2048:latest`, vérifiez que votre rôle IAM de nœud possède les autorisations nécessaires pour extraire les images depuis ECR. Pour de plus amples informations, consultez [Rôle IAM de nœud](auto-learn-iam.md#auto-learn-node-iam-role). De plus, l’image `docker-2048` utilisée dans l’exemple est une image `x86_64` et ne fonctionnera pas sur d’autres architectures.
**Composants clés :**
+ Déploiement de 5 réplicas de l’application
+ Utilisation d’une image ECR publique
+ Demande de 0,5 cœur de processeur par pod
+ Exposition du port 80 pour le trafic HTTP
Appliquez le déploiement :
```
kubectl apply -f 02-deployment.yaml
```
## Étape 3 : créer le service
Le service expose le déploiement au réseau du cluster.
Créez un fichier nommé `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Composants clés :**
+ Création d’un service NodePort
+ Mappage du port 80 vers le port 80 du conteneur
+ Utilisation d’un sélecteur d’étiquettes pour cibler les pods
Appliquez le service :
```
kubectl apply -f 03-service.yaml
```
## Étape 4 : configurer l’équilibrage de charge
Vous allez configurer un objet Ingress pour exposer l’application sur Internet.
Commencez par créer la `IngressClass`. Créez un fichier nommé `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
Créez ensuite la ressource Ingress. Créez un fichier nommé `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Composants clés :**
+ Création d’un ALB orienté Internet
+ Utilisation du type de cible IP pour un routage direct vers les pods
+ Routage de tout le trafic (/) vers le service du jeu
Appliquez les configurations Ingress :
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Étape 5 : vérifier le déploiement
1. Vérifiez que tous les pods sont en cours d’exécution :
```
kubectl get pods -n game-2048
```
1. Vérifiez que le service a été créé :
```
kubectl get svc -n game-2048
```
1. Obtenez le point de terminaison de l’ALB :
```
kubectl get ingress -n game-2048
```
Le champ ADDRESS dans le résultat Ingress affiche le point de terminaison de votre ALB. Attendez 2 à 3 minutes pour que l’ALB soit entièrement provisionné et enregistre toutes les cibles.
## Étape 6 : accéder au jeu
Ouvrez votre navigateur web et accédez à l’URL du point de terminaison de l’ALB obtenue à l’étape précédente. L’interface du jeu 2048 devrait s’afficher.
## Étape 7 : nettoyage
Pour supprimer toutes les ressources créées dans ce tutoriel :
```
kubectl delete namespace game-2048
```
Cela supprimera toutes les ressources de l’espace de noms, y compris les ressources Déploiement, Service et Ingress.
## Ce qui se passe dans les coulisses
1. Le déploiement crée 5 pods exécutant le jeu 2048
1. Le service fournit un accès réseau stable à ces pods
1. Mode automatique EKS :
+ Crée un équilibreur de charge Application Load Balancer dans AWS
+ Configure les groupes cibles pour les pods
+ Définit les règles de routage pour transmettre le trafic au service
## Résolution des problèmes
Si le jeu ne se charge pas :
+ Assurez-vous que tous les pods sont en cours d’exécution : `kubectl get pods -n game-2048`
+ Vérifiez l’état de la ressource Ingress : `kubectl describe ingress -n game-2048`
+ Vérifiez la surveillance de l’état de l’ALB : consultez l’état du groupe cible dans la console AWS
# Déployer un exemple de charge de travail avec état dans le mode automatique EKS
Ce tutoriel vous guidera dans le déploiement d’un exemple d’application avec état dans votre cluster du mode automatique EKS. L’application écrit des horodatages dans un volume persistant, démontrant ainsi les capacités de provisionnement et de persistance automatiques des volumes EBS du mode automatique EKS.
## Prérequis
+ Un cluster du mode automatique EKS
+ L’interface AWS CLI configurée avec les autorisations appropriées
+ `kubectl` installé et configuré
+ Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
## Étape 1 : configurer votre environnement
1. Définissez vos variables d’environnement :
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Mettez à jour votre kubeconfig :
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Étape 2 : créer la classe de stockage
La `StorageClass` définit la manière dont le mode automatique EKS provisionnera les volumes EBS.
Le mode automatique EKS ne crée pas de `StorageClass` pour vous. Vous devez créer une `StorageClass` faisant référence à `ebs.csi.eks.amazonaws.com` pour utiliser les fonctionnalités de stockage du mode automatique EKS.
1. Créez un fichier nommé `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Appliquez le `StorageClass` :
```
kubectl apply -f storage-class.yaml
```
**Composants clés :**
+ `provisioner: ebs.csi.eks.amazonaws.com` : utilise le mode automatique EKS
+ `volumeBindingMode: WaitForFirstConsumer` : retarde la création du volume jusqu’à ce qu’un pod en ait besoin
+ `type: gp3` : spécifie le type de volume EBS
+ `encrypted: "true"` : EBS utilisera la clé `aws/ebs` par défaut pour activer le chiffrement sur les volumes créés avec cette classe. Cette action est facultative, mais recommandée.
+ `storageclass.kubernetes.io/is-default-class: "true"` : Kubernetes utilisera cette classe de stockage par défaut, à moins que vous ne spécifiiez une autre classe de volume dans une demande de volume persistant. Soyez prudent lorsque vous définissez cette valeur si vous migrez depuis un autre contrôleur de stockage. (facultatif)
## Étape 3 : créer la revendication de volume persistant
La PVC demande du stockage à la `StorageClass`.
1. Créez un fichier nommé `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Appliquez le PVC :
```
kubectl apply -f pvc.yaml
```
**Composants clés :**
+ `accessModes: ReadWriteOnce` : le volume peut être monté par un nœud à la fois
+ `storage: 8Gi` : demande un volume de 8 Gio
+ `storageClassName: auto-ebs-sc` : fait référence à la `StorageClass` que nous avons créée
## Étape 4 : déployer l’application
Le déploiement exécute un conteneur qui écrit des horodatages sur le volume persistant.
1. Créez un fichier nommé `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Appliquez le déploiement :
```
kubectl apply -f deployment.yaml
```
**Composants clés :**
+ Conteneur bash simple qui écrit des horodatages dans un fichier
+ Monte le PVC à `/data`
+ Demande 1 cœur de processeur
+ Utilise le sélecteur de nœuds pour les nœuds gérés par EKS
## Étape 5 : vérifier la configuration
1. Vérifiez que le pod est en cours d’exécution :
```
kubectl get pods -l app=inflate-stateful
```
1. Vérifiez que le PVC est lié :
```
kubectl get pvc auto-ebs-claim
```
1. Vérifiez le volume EBS :
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Vérifiez que les données sont écrites :
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Étape 6 : nettoyage
Exécutez la commande suivante pour supprimer toutes les ressources créées dans ce tutoriel :
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Ce qui se passe dans les coulisses
1. Le PVC demande du stockage à la `StorageClass`
1. Lorsque le pod est planifié :
1. Le mode automatique EKS provisionne un volume EBS
1. Crée un PersistentVolume
1. Attache le volume au nœud
1. Le pod monte le volume et commence à écrire les horodatages
## Contrôleur d’instantané
Le mode automatique EKS est compatible avec le Kubernetes CSI Snapshotter, également appelé contrôleur d’instantané. Cependant, le mode automatique EKS n’inclut pas le contrôleur d’instantané. Vous êtes responsable de l’installation et de la configuration du contrôleur d’instantané. Pour de plus amples informations, consultez [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md).
Veuillez consulter la classe `VolumeSnapshotClass` suivante qui fait référence à la capacité de stockage du mode automatique EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[En savoir plus sur le contrôleur de snapshots CSI Kubernetes.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Déploiement d’une charge de travail accélérée
Ce didacticiel montre comment le mode automatique d'Amazon EKS simplifie le lancement de charges de travail accélérées par le matériel. Le mode automatique Amazon EKS simplifie les opérations au-delà du cluster lui-même en automatisant les composants clés de l’infrastructure qui fournissent des capacités de calcul, de mise en réseau, d’équilibrage de charge, de stockage et de gestion des identités et des accès dès leur installation.
Le mode automatique Amazon EKS inclut les pilotes et les plug-ins de périphérique requis pour certains types d'instances, tels que les pilotes NVIDIA et AWS Neuron. Vous n’avez pas à installer ni à mettre à jour ces composants.
Le mode automatique EKS gère automatiquement les pilotes pour les accélérateurs suivants :
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inférentie](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Instances EC2 accélérées NVIDIA GPUs sur Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**Note**
Le mode automatique EKS inclut le plug-in de périphérique NVIDIA pour Kubernetes. Ce plug-in s’exécute automatiquement et n’est pas visible comme un ensemble de démons dans votre cluster.
Prise en charge du réseautage supplémentaire :
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Le mode automatique Amazon EKS élimine les tâches fastidieuses liées à la gestion des pilotes d’accélérateurs et des plug-ins de périphériques.
Vous pouvez également bénéficier d’économies, car le cluster peut être mis à l’échelle jusqu’à zéro. Il est possible de configurer le mode automatique EKS pour arrêter les instances lorsqu’aucune charge de travail n’est en cours d’exécution. Cela est utile pour les charges de travail d’inférence basées sur des lots.
La section suivante présente un exemple de lancement de charges de travail accélérées avec le mode automatique Amazon EKS.
## Conditions préalables
+ Un cluster Kubernetes avec le mode automatique Amazon EKS configuré.
+ Une classe de nœuds `default` EKS est créée lorsque les groupes de nœuds gérés `general-purpose` ou `system` sont activés.
## Étape 1 : déployer une charge de travail GPU
Dans cet exemple, vous allez créer un NodePool pour les charges de travail basées sur NVIDIA qui nécessitent 45 Go de mémoire GPU. Avec le mode automatique EKS, vous utilisez les contraintes de planification Kubernetes pour définir vos exigences d’instance.
Pour déployer le mode automatique Amazon EKS `NodePool` et l'exemple`workload`, consultez les informations suivantes NodePool et la définition du pod, puis enregistrez-les sous `nodepool-gpu.yaml` et `pod.yaml` :
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Notez que le sélecteur `eks.amazonaws.com/compute-type: auto` nécessite que la charge de travail soit déployée sur un nœud du mode automatique Amazon EKS. Cela crée NodePool également une odeur qui permet uniquement de planifier des pods avec des tolérances GPUs pour Nvidia.
Appliquez la charge de travail NodePool et à votre cluster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Vous devriez voir la sortie suivante :
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Attendez quelques secondes, puis vérifiez les nœuds de votre cluster. Vous devriez voir un nouveau nœud provisionné dans votre cluster du mode automatique Amazon EKS :
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Étape 2 : valider
Vous pouvez constater que le mode automatique Amazon EKS a lancé un `g6e.2xlarge` plutôt qu’un `g6.2xlarge` autonome, car la charge de travail nécessitait une instance avec un `GPU` L40S, conformément aux contraintes de planification Kubernetes suivantes :
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Maintenant, consultez les journaux des conteneurs en exécutant la commande suivante :
```
kubectl logs nvidia-smi
```
Exemple de sortie :
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Vous pouvez constater que le conteneur a détecté qu’il s’exécute sur une instance dotée d’un GPU `NVIDIA` et que vous n’avez pas eu à installer de pilote de périphérique, car cela est géré par le mode automatique Amazon EKS.
## Étape 3 : nettoyer
Pour supprimer tous les objets créés, utilisez `kubectl` pour supprimer l'exemple de déploiement NodePool afin de mettre fin au nœud :
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Exemple de NodePools référence
### Créez un NVIDIA NodePool
Les définitions suivantes sont NodePool les suivantes :
+ Lancement uniquement d’instances des familles `g6e` et `g6`
+ Consolidation des nœuds lorsqu’ils restent vides pendant 1 heure
+ La valeur de 1 heure pour `consolodateAfter` prend en charge des charges de travail irrégulières et réduit le roulement des nœuds. Vous pouvez ajuster `consolidateAfter` selon les exigences de votre charge de travail.
**Exemple NodePool de famille d'instances GPU et de consolidation**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Au lieu de définir directement le paramètre `eks.amazonaws.com/instance-gpu-name`, vous pouvez utiliser `eks.amazonaws.com/instance-family` pour spécifier la famille d’instances. Pour consulter d’autres étiquettes courantes influençant la planification, consultez [Étiquettes prises en charge par le mode automatique EKS](create-node-pool.md#auto-supported-labels).
Si vous avez des besoins de stockage spécifiques, vous pouvez ajuster le stockage `iops` éphémère des nœuds `size` et `throughput` en créant le vôtre [NodeClass](create-node-class.md)à référencer dans le. NodePool En savoir plus sur les [ NodeClass options configurables](create-node-class.md).
**Exemple de configuration de stockage pour NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Définition d'un AWS trainium et AWS d'une inférence NodePool
Ce qui suit NodePool contient un `eks.amazonaws.com/instance-category` ensemble qui indique de ne lancer que les instances de la famille Inferentia et Trainium :
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# Configurer les paramètres du mode automatique EKS
Ce chapitre décrit comment configurer certains aspects spécifiques de vos clusters du mode automatique Amazon Elastic Kubernetes Service (EKS). Bien que le mode automatique EKS gère automatiquement la plupart des composants de l’infrastructure, vous pouvez personnaliser certaines fonctionnalités pour répondre aux exigences de votre charge de travail.
À l’aide des options de configuration décrites dans cette rubrique, vous pouvez modifier les paramètres réseau, les ressources de calcul et les comportements d’équilibrage de charge tout en conservant les avantages de la gestion automatisée de l’infrastructure. Avant d’apporter des modifications à la configuration, examinez les options disponibles dans les sections suivantes afin de déterminer l’approche la mieux adaptée à vos besoins.
| Quelles fonctionnalités voulez-vous configurer ? | Option de configuration |
| --- | --- |
| **Réseau et stockage des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md) |
| **Ressources de calcul des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Create a Node Pool for EKS Auto Mode](create-node-pool.md) |
| **Pools de nœuds à capacité statique** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Pools de nœuds à capacité statique en mode automatique EKS](auto-static-capacity.md) |
| **Paramètres de l’Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Créez un IngressClass pour configurer un Application Load Balancer](auto-configure-alb.md) |
| **Paramètres du Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer](auto-configure-nlb.md) |
| **Paramètres de la classe de stockage** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Création d’une classe de stockage](create-storage-class.md) |
| **Contrôle de l’utilisation de l’ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md) |
| **Sécurité avancée des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Configuration des paramètres de sécurité avancés pour les nœuds](auto-advanced-security.md) |
# Création d’une classe de nœuds pour Amazon EKS
Les classes de nœuds Amazon EKS sont des modèles qui offrent un contrôle précis de la configuration de vos nœuds gérés par le mode automatique EKS. Une classe de nœuds définit les paramètres d’infrastructure appliqués à des groupes de nœuds de votre cluster EKS, notamment la configuration réseau, les paramètres de stockage et le balisage des ressources. Cette rubrique explique comment créer et configurer une classe de nœuds pour répondre à vos exigences opérationnelles spécifiques.
Lorsque vous devez personnaliser la façon dont le mode automatique EKS provisionne et configure les instances EC2 au-delà des paramètres par défaut, la création d’une classe de nœuds vous permet de contrôler précisément des paramètres d’infrastructure essentiels. Par exemple, vous pouvez spécifier le placement dans des sous-réseaux privés pour renforcer la sécurité, configurer un stockage éphémère des instances pour les charges de travail sensibles aux performances ou appliquer des étiquettes personnalisées pour l’allocation des coûts.
## Création d’une classe de nœuds
Pour créer une `NodeClass`, procédez comme suit :
1. Créez un fichier YAML (par exemple `nodeclass.yaml`) contenant la configuration de votre classe de nœuds
1. Appliquez la configuration à votre cluster à l’aide de `kubectl`
1. Référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
Vous devez avoir installé et configuré `kubectl`. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
### Exemple de classe de nœuds simple
Voici un exemple de classe de nœuds :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Cela NodeClass augmente la quantité de stockage éphémère sur le nœud.
Appliquez cette configuration en utilisant :
```
kubectl apply -f nodeclass.yaml
```
Ensuite, référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Création d’une entrée d’accès pour la classe de nœuds
Si vous créez une classe de nœuds personnalisée, vous devez créer une entrée d’accès EKS pour permettre aux nœuds de rejoindre le cluster. EKS crée automatiquement les entrées d’accès lorsque vous utilisez la classe de nœuds intégrée et les groupes de nœuds intégrés.
Pour plus d’informations sur le fonctionnement des entrées d’accès, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
Lorsque vous créez des entrées d’accès pour les classes de nœuds du mode automatique EKS, vous devez utiliser le type d’entrée d’accès `EC2`.
### Création d’une entrée d’accès à l’aide de la CLI
**Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :**
Mettez à jour les commandes CLI suivantes avec le nom de votre cluster et l’ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Créez une entrée d'accès avec CloudFormation
**Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :**
Mettez à jour ce qui suit CloudFormation avec le nom de votre cluster et l'ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Pour plus d'informations sur le déploiement CloudFormation de stacks, voir [Getting started with CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Spécification de la classe de nœuds
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Considérations
+ Si vous souhaitez vérifier le volume de stockage local d’une instance, vous pouvez décrire le nœud pour voir la ressource de stockage éphémère.
+ **Chiffrement du volume** : EKS utilise la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance et le read/write volume de données.
+ **Remplacement du rôle IAM du nœud** : si vous modifiez le rôle IAM du nœud associé à une `NodeClass`, vous devrez créer une nouvelle entrée d’accès. EKS crée automatiquement une entrée d’accès pour le rôle IAM du nœud lors de la création du cluster. Le rôle IAM du nœud nécessite la stratégie d’accès `AmazonEKSAutoNodePolicy` EKS. Pour de plus amples informations, veuillez consulter [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
+ **Densité maximale de pods** : EKS limite le nombre maximal de pods sur un nœud à 110. Cette limite s’applique après le calcul existant du nombre maximal de pods. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md).
+ **Balises** : si vous souhaitez propager des balises de Kubernetes vers EC2, vous devez configurer des autorisations IAM supplémentaires. Pour de plus amples informations, veuillez consulter [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md).
+ **Classe de nœuds par défaut** : ne nommez pas votre classe de nœuds personnalisée `default`. En effet, le mode automatique EKS inclut une `NodeClass` appelée `default`, provisionnée automatiquement lorsque vous activez au moins un `NodePool` intégré. Pour plus d’informations sur l’activation des `NodePools` intégrés, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ **Comportement des `subnetSelectorTerms` avec plusieurs sous-réseaux** : si plusieurs sous-réseaux correspondent aux conditions `subnetSelectorTerms` ou sont fournis par ID, le mode automatique EKS crée des nœuds répartis sur l’ensemble des sous-réseaux.
+ Si les sous-réseaux se trouvent dans des zones de disponibilité différentes (AZs), vous pouvez utiliser les fonctionnalités de Kubernetes telles que les [contraintes de propagation de la topologie des pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) et le [routage adapté à la topologie pour répartir les](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) pods et le trafic entre les zones, respectivement.
+ S’il existe plusieurs sous-réseaux *dans la même zone de disponibilité* qui correspondent aux `subnetSelectorTerms`, le mode automatique EKS crée des pods sur chaque nœud répartis dans ces sous-réseaux de cette même zone de disponibilité. Le mode automatique EKS crée également des interfaces réseau secondaires sur chaque nœud dans les autres sous-réseaux de la même zone de disponibilité. Il choisit en fonction du nombre d’adresses IP disponibles dans chaque sous-réseau, afin d’utiliser les sous-réseaux plus efficacement. Cependant, vous ne pouvez pas spécifier quel sous-réseau le mode automatique EKS utilise pour chaque pod ; si vous avez besoin que des pods s’exécutent dans des sous-réseaux spécifiques, utilisez [Sous-réseaux et groupes de sécurité distincts pour les pods](#pod-subnet-selector).
## Sous-réseaux et groupes de sécurité distincts pour les pods
Les `podSecurityGroupSelectorTerms` champs `podSubnetSelectorTerms` et permettent des configurations réseau avancées en permettant aux pods d'utiliser des sous-réseaux et des groupes de sécurité différents de ceux de leurs nœuds. Les deux champs doivent être spécifiés ensemble. Cette séparation offre un meilleur contrôle du routage du trafic réseau et des politiques de sécurité.
**Note**
Cette fonctionnalité est différente de la fonctionnalité [Security Groups for Pods](security-groups-for-pods.md) (SGPP) utilisée avec le CNI VPC d'AWS pour le calcul en mode automatique hors EKS. Le SGPP n'est pas pris en charge en mode automatique EKS. Utilisez plutôt `podSecurityGroupSelectorTerms` in `NodeClass` pour appliquer des groupes de sécurité distincts au trafic du pod. Les groupes de sécurité s'appliquent au `NodeClass` niveau, ce qui signifie que tous les pods situés sur les nœuds utilisateurs `NodeClass` partagent les mêmes groupes de sécurité de pods.
### Comment ça marche
Lorsque vous configurez `podSubnetSelectorTerms` et `podSecurityGroupSelectorTerms` :
1. L'ENI principal du nœud utilise les sous-réseaux et les groupes de sécurité provenant de `subnetSelectorTerms` et`securityGroupSelectorTerms`. Seule l'adresse IP du nœud est attribuée à cette interface.
1. Le mode automatique EKS crée un ENIs élément secondaire dans les sous-réseaux correspondants`podSubnetSelectorTerms`, les groupes de sécurité étant `podSecurityGroupSelectorTerms` rattachés. Les adresses IP des pods sont allouées à partir de ces préfixes secondaires à ENIs l'aide des préfixes /28 par défaut, avec un retour automatique au secondaire IPs (/32) lorsqu'aucun bloc de préfixe contigu n'est disponible. Si `ipv4PrefixSize` ce paramètre est défini sur `"32"` in`advancedNetworking`, seuls IPs les éléments secondaires sont utilisés.
1. Les groupes de sécurité spécifiés dans `podSecurityGroupSelectorTerms` s'appliquent au trafic des pods au sein du VPC. Pour le trafic destiné à l'extérieur du VPC, les pods utilisent l'ENI principal du nœud (et ses groupes de sécurité) car la traduction d'adresses réseau source (SNAT) traduit l'adresse IP du pod en adresse IP du nœud. Vous pouvez modifier ce comportement à l'aide du `snatPolicy` champ situé dans le`NodeClass`.
### Cas d’utilisation
À utiliser `podSubnetSelectorTerms` et `podSecurityGroupSelectorTerms` quand vous devez :
+ Appliquez différents groupes de sécurité pour contrôler le trafic des nœuds et des pods séparément.
+ Séparez le trafic d'infrastructure (node-to-node communication) du trafic d'applications (Pod-to-Pod communication).
+ Appliquer des configurations réseau différentes aux sous-réseaux des nœuds et aux sous-réseaux des pods.
+ Configurer des serveurs proxy inverses ou des filtres réseau spécifiquement pour le trafic des nœuds sans affecter le trafic des pods. Utiliser `advancedNetworking` et `certificateBundles` pour définir votre serveur proxy inverse ainsi que tout certificat autosigné ou privé pour ce serveur.
### Exemple de configuration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Considérations relatives aux sous-réseaux Pod et aux groupes de sécurité distincts
+ **Étendue du groupe** de sécurité : les groupes de sécurité provenant de `podSecurityGroupSelectorTerms` sont attachés au groupe secondaire ENIs et s'appliquent au trafic des pods au sein du VPC. Lorsque le SNAT est activé (valeur par défaut`snatPolicy: Random`), le trafic quittant le VPC est traduit vers l'adresse IP ENI principale du nœud, de sorte que les groupes de sécurité du nœud s'appliquent `securityGroupSelectorTerms` plutôt à ce trafic. Si vous le configurez`snatPolicy: Disabled`, les pods utilisent leurs propres adresses IP pour l'ensemble du trafic, et vous devez vous assurer que les groupes de routage et de sécurité sont configurés en conséquence.
+ **NodeClass-niveau de granularité** : les groupes de sécurité Pod s'appliquent à tous les Pods planifiés sur les nœuds utilisant le. `NodeClass` Pour appliquer différents groupes de sécurité à différentes charges de travail, créez des `NodePool` ressources `NodeClass` et utilisez des restrictions, des tolérances ou des sélecteurs de nœuds pour planifier les charges de travail sur les nœuds appropriés.
+ **Densité de pods réduite** : moins de pods peuvent être exécutés sur chaque nœud car l'interface réseau principale du nœud est réservée à l'adresse IP du nœud et ne peut pas être utilisée pour les pods.
+ **Limites du sélecteur de sous-réseau** : la norme `subnetSelectorTerms` et les `securityGroupSelectorTerms` configurations ne s'appliquent pas à la sélection du sous-réseau ou du groupe de sécurité du Pod.
+ **Planification du réseau** : assurez-vous de disposer d’un espace d’adresses IP suffisant dans les sous-réseaux des nœuds et des pods pour répondre aux besoins de vos charges de travail.
+ **Configuration du routage** : vérifiez que la table de routage et les listes de contrôle d’accès (ACL) réseau des sous-réseaux destinés aux pods sont correctement configurées pour permettre la communication entre les sous-réseaux des nœuds et ceux des pods.
+ **Zones de disponibilité** : vérifiez que vous avez créé des sous-réseaux Pod sur plusieurs AZs. Si vous utilisez un sous-réseau Pod spécifique, il doit se trouver dans le même AZ que le sous-réseau de nœuds AZ.
## Mode IP secondaire pour les pods
Le `ipv4PrefixSize` champ permet des configurations réseau avancées en n'allouant que des adresses IP secondaires aux nœuds. Cette fonctionnalité n'alloue pas de préfixes (/28) aux nœuds et ne conserve qu'une seule adresse IP secondaire comme minimale. IPTarget
### Cas d’utilisation
Utilisez `ipv4PrefixSize` lorsque vous devez :
+ **Utilisation IP réduite** : une seule adresse IP sera réchauffée dans chaque nœud.
+ **Réduction du taux de rotation des capsules** : la vitesse de création des capsules n'est pas une préoccupation majeure.
+ **Aucune fragmentation des préfixes : la fragmentation** causée par les préfixes est une préoccupation majeure ou un obstacle à l'utilisation du mode automatique.
### Exemple de configuration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Considérations relatives au mode IP secondaire
+ **Vitesse de création de pods réduite** : étant donné qu'une seule adresse IP secondaire est réchauffée, le service IPAM a besoin de plus de temps pour le provisionner IPs lorsque d'autres pods sont créés.
## Désactivez la IPv4 sortie des IPv6 pods en IPv6 clusters.
Le `enableV4Egress` champ est défini `true` par défaut. Pour les IPv6 clusters en mode automatique, la fonctionnalité peut être désactivée afin que le mode automatique ne crée pas d' IPv4 interface de sortie uniquement pour les pods. IPv6 Ceci est important car l'interface de IPv4 sortie n'est pas soumise à l'application de la politique réseau. Les politiques réseau ne sont appliquées que sur l'interface principale du Pod (eth0).
### Cas d’utilisation
Utilisez `enableV4Egress` lorsque vous devez :
+ **Utiliser le IPv6 cluster** : le trafic de IPv4 sortie est autorisé par défaut.
+ **Utiliser la politique réseau** : actuellement, EKS Network Policy ne prend pas en charge le double stack. La désactivation `enableV4Egress` peut empêcher le trafic du pod de sortir de façon inattendue. IPv4
### Exemple de configuration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Considérations relatives à la désactivation d'EnableV4egress
+ **Politique réseau dans le IPv6 cluster** : les IPv6 clusters autorisent IPv4 le trafic par défaut. Le réglage `enableV4Egress: false` bloque le IPv4 trafic sortant, offrant ainsi une sécurité renforcée, en particulier lorsqu'il est utilisé avec des politiques réseau.
# Create a Node Pool for EKS Auto Mode
Les groupes de nœuds Amazon EKS offrent une méthode flexible pour gérer les ressources de calcul dans votre cluster Kubernetes. Cette rubrique explique comment créer et configurer des groupes de nœuds à l’aide de Karpenter, un outil de provisionnement de nœuds qui permet d’optimiser l’étendue du cluster et l’utilisation des ressources. Grâce à la ressource NodePool de Karpenter, vous pouvez définir des exigences précises pour vos ressources de calcul, notamment les types d’instances, les zones de disponibilité, les architectures et les types de capacité.
Les groupes de nœuds intégrés `system` et `general-purpose` ne peuvent pas être modifiés. Vous pouvez uniquement les activer ou les désactiver. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
La spécification NodePool permet un contrôle précis des ressources de cluster computing EKS à l’aide de diverses étiquettes et exigences prises en charge. Ces options incluent la définition des catégories d’instances EC2, la configuration du processeur, la sélection des zones de disponibilité, le choix de l’architecture (ARM64 ou AMD64) et le type de capacité (Spot ou à la demande). Vous pouvez également définir des limites de ressources pour l’utilisation du processeur et de la mémoire, afin que votre cluster respecte les contraintes opérationnelles requises.
Le mode automatique EKS utilise des étiquettes Kubernetes reconnues afin de proposer des méthodes uniformes et standardisées d’identification des caractéristiques des nœuds. Ces étiquettes, par exemple `topology.kubernetes.io/zone` pour les zones de disponibilité et `kubernetes.io/arch` pour l’architecture du processeur, respectent les conventions établies de Kubernetes. De plus, des étiquettes spécifiques à EKS (préfixées par `eks.amazonaws.com/`) étendent cette fonctionnalité en ajoutant des attributs spécifiques à AWS, tels que les types d’instance, les fabricants de processeurs, les capacités GPU et les spécifications réseau. Ce système d’étiquetage standardisé assure une intégration fluide avec les outils Kubernetes existants, tout en offrant une intégration approfondie à l’infrastructure AWS.
## Création d’un NodePool
Pour créer un NodePool pour votre cluster Amazon EKS, procédez comme suit :
1. Créez un fichier YAML nommé `nodepool.yaml` contenant la configuration requise de votre NodePool. Vous pouvez utiliser l’exemple de configuration ci-dessous.
1. Appliquez le NodePool à votre cluster :
```
kubectl apply -f nodepool.yaml
```
1. Vérifiez que le NodePool a été créé avec succès :
```
kubectl get nodepools
```
1. (Facultatif) Surveillez l’état du NodePool :
```
kubectl describe nodepool default
```
Assurez-vous que votre NodePool fait référence à un NodeClass valide existant dans votre cluster. La NodeClass définit les configurations spécifiques à AWS pour vos ressources de calcul. Pour de plus amples informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Exemple de NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Étiquettes prises en charge par le mode automatique EKS
Le mode automatique EKS prend en charge les étiquettes bien connues suivantes.
**Note**
Le mode automatique EKS utilise des étiquettes différentes de celles de Karpenter. Les étiquettes associées aux instances gérées EC2 commencent par `eks.amazonaws.com`.
| Étiquette | exemple | Description |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS région |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Type d'instance AWS |
| kubernetes.io/arch | amd64 | Architectures définies par les [valeurs GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) sur l’instance |
| karpenter.sh/capacity-type | spot | Les types de capacité comprennent `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Types d’instance utilisant un hyperviseur spécifique |
| eks.amazonaws.com/compute-type | auto | Identifie les nœuds gérés par le mode automatique EKS |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Types d’instance prenant en charge (ou non) le chiffrement en transit |
| eks.amazonaws.com/instance-category | g | Types d’instance de la même catégorie, généralement la chaîne précédant le numéro de génération |
| eks.amazonaws.com/instance-generation | 4 | Numéro de génération du type d’instance au sein d’une même catégorie d’instances |
| eks.amazonaws.com/instance-family | g4dn | Types d’instance présentant des propriétés similaires, mais des quantités de ressources différentes |
| eks.amazonaws.com/instance-size | 8xlarge | Types d’instance présentant des quantités de ressources similaires, mais des propriétés différentes |
| eks.amazonaws.com/instance-cpu | 32 | Nombre de processeurs sur l’instance |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nom du fabricant du processeur |
| eks.amazonaws.com/instance-memory | 131072 | Nombre de mébioctets de mémoire sur l’instance |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Nombre [maximal de mégabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) d’EBS disponibles sur l’instance |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Nombre de [mégabits de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibles sur l’instance |
| eks.amazonaws.com/instance-gpu-name | t4 | Nom du GPU présent sur l’instance, le cas échéant |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nom du fabricant du GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Nombre de GPU présents sur l’instance |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Quantité de mémoire GPU en mébioctets sur l’instance |
| eks.amazonaws.com/instance-local-nvme | 900 | Quantité de stockage local NVMe en gibioctets sur l’instance |
**Note**
Le mode automatique EKS ne prend en charge que certains types d’instances et impose des exigences de taille minimale. Pour de plus amples informations, consultez [Référence des instances prises en charge par le mode automatique EKS](automode-learn-instances.md#auto-supported-instances).
## Étiquettes non prises en charge par le mode automatique EKS
Le mode automatique EKS ne prend pas en charge les étiquettes suivantes.
+ Le mode automatique EKS ne prend en charge que Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Désactivation des groupes de nœuds intégrés
Si vous créez des groupes de nœuds personnalisés, vous pouvez désactiver les groupes de nœuds intégrés. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
## Cluster sans groupes de nœuds intégrés
Vous pouvez créer un cluster sans groupes de nœuds intégrés. Cela est utile si votre organisation a mis en place des groupes de nœuds personnalisés.
**Note**
Lorsque vous créez un cluster sans groupes de nœuds intégrés, la NodeClass `default` n’est pas provisionnée automatiquement. Vous devrez créer une NodeClass personnalisée. Pour de plus amples informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
**Présentation :**
1. Créez un cluster EKS avec les valeurs `nodePools` et `nodeRoleArn` laissées vides.
+ Exemple eksctl `autoModeConfig` :
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Pour plus d’informations, consultez [Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl](automode-get-started-eksctl.md).
1. Créez une NodeClass personnalisée avec un ARN de rôle de nœud
+ Pour plus d’informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
1. Créez une entrée d’accès pour la classe de nœuds personnalisée
+ Pour plus d’informations, consultez [Création d’une entrée d’accès pour la classe de nœuds](create-node-class.md#auto-node-access-entry).
1. Créez un groupe de nœuds personnalisé, comme décrit ci-dessus.
## Interruption
Vous pouvez configurer le mode automatique EKS afin de gérer l’interruption des nœuds à partir de votre NodePool de plusieurs façons. Vous pouvez utiliser `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` ou `spec.template.spec.expireAfter`. Vous pouvez également limiter le taux d’interruption du mode automatique EKS à l’aide du paramètre `spec.disruption.budgets` du NodePool. Vous pouvez également contrôler les fenêtres temporelles et le nombre de nœuds interrompus simultanément. Pour obtenir des instructions sur la configuration de ce comportement, consultez la section [Interruption](https://karpenter.sh/docs/concepts/disruption/) dans la documentation de Karpenter.
Vous pouvez configurer l’interruption pour les groupes de nœuds afin de :
+ Identifier les instances sous-utilisées et consolider les charges de travail.
+ Créer un budget d’interruption pour limiter la fréquence des arrêts de nœuds liés à la dérive, au vidage ou à la consolidation.
Par défaut, le mode automatique EKS :
+ Consolide les instances sous-utilisées.
+ Met fin aux instances au bout de 336 heures.
+ Définit un budget d’interruption unique correspondant à 10 % des nœuds.
+ Permet le remplacement des nœuds en cas de dérive lors de la publication d’une nouvelle AMI du mode automatique (environ une fois par semaine).
## Délai de grâce avant terminaison
Lorsque le `terminationGracePeriod` n’est pas explicitement définie dans une NodePool EKS Auto, le système applique automatiquement un délai de grâce de 24 heures à la NodeClaim associée. Même si les utilisateurs d’EKS Auto ne verront pas un `terminationGracePeriod` défini par défaut dans leurs configurations personnalisées de NodePool, ils pourront l’observer dans la NodeClaim. La fonctionnalité demeure identique, qu’elle soit définie explicitement dans la NodePool ou appliquée par défaut dans la NodeClaim, ce qui garantit un comportement prévisible lors de la terminaison des nœuds dans le cluster.
# Pools de nœuds à capacité statique en mode automatique EKS
Le mode automatique Amazon EKS prend en charge les pools de nœuds à capacité statique qui maintiennent un nombre fixe de nœuds, quelle que soit la demande de pods. Les pools de nœuds à capacité statique sont utiles pour les charges de travail qui nécessitent une capacité prévisible, des instances réservées ou des exigences de conformité spécifiques pour lesquelles vous devez maintenir une empreinte d'infrastructure cohérente.
Contrairement aux pools de nœuds dynamiques qui évoluent en fonction des demandes de planification des pods, les pools de nœuds à capacité statique maintiennent le nombre de nœuds que vous avez configurés.
## Configuration d'un pool de nœuds à capacité statique
Pour créer un pool de nœuds à capacité statique, définissez le `replicas` champ dans votre NodePool spécification. Le `replicas` champ définit le nombre exact de nœuds que le pool de nœuds conservera. Consultez [Exemples](#static-capacity-examples) la section pour savoir comment configurer`replicas`.
## Considérations relatives au pool de nœuds à capacité statique
Les pools de nœuds à capacité statique présentent plusieurs contraintes et comportements importants :
**Contraintes de configuration :**
+ **Impossible de changer de mode** : une fois que vous avez configuré `replicas` un pool de nœuds, vous ne pouvez pas le supprimer. Le pool de nœuds ne peut pas passer du mode statique au mode dynamique.
+ **Limites de ressources limitées** : seul le `limits.nodes` champ est pris en charge dans la section des limites. Les limites de processeur et de mémoire ne sont pas applicables.
+ **Aucun champ de pondération** : le `weight` champ ne peut pas être défini sur les pools de nœuds à capacité statique car la sélection des nœuds n'est pas basée sur la priorité.
**Comportement opérationnel :**
+ **Aucune consolidation** : les nœuds des pools de capacité statiques ne sont pas pris en compte pour la consolidation.
+ Opérations de **dimensionnement : les opérations** de dimensionnement évitent les budgets liés aux interruptions de service des nœuds, tout en les respectant PodDisruptionBudgets.
+ **Remplacement** des nœuds : les nœuds sont toujours remplacés pour cause de dérive (comme les mises à jour d'AMI) et d'expiration en fonction de votre configuration.
## Bonnes pratiques
**Planification des capacités :**
+ Définissez `limits.nodes` une valeur supérieure `replicas` à pour permettre une mise à l'échelle temporaire lors des opérations de remplacement de nœuds.
+ Tenez compte de la capacité maximale requise lors de la dérive des nœuds ou des mises à jour de l'AMI lors de la définition des limites.
**Sélection de l'instance :**
+ Utilisez des types d'instances spécifiques lorsque vous avez des instances réservées ou des exigences matérielles spécifiques.
+ Évitez les exigences trop restrictives susceptibles de limiter la disponibilité des instances lors du dimensionnement.
**Gestion des perturbations :**
+ Configurez les budgets d'interruption appropriés pour équilibrer la disponibilité avec les opérations de maintenance.
+ Tenez compte de la tolérance de votre application en matière de remplacement de nœuds lors de la définition des pourcentages de budget.
**Surveillance :**
+ Surveillez régulièrement le `status.nodes` terrain pour vous assurer que la capacité souhaitée est maintenue.
+ Configurez des alertes lorsque le nombre réel de nœuds s'écarte des répliques souhaitées.
**Répartition des zones :**
+ Pour une haute disponibilité, répartissez la capacité statique sur plusieurs zones de disponibilité.
+ Lorsque vous créez un pool de nœuds à capacité statique qui couvre plusieurs zones de disponibilité, le mode automatique EKS distribue les nœuds dans les zones spécifiées, mais il n'est pas garanti que la distribution soit uniforme.
+ Pour une distribution prévisible et uniforme entre les zones de disponibilité, créez des pools de nœuds à capacité statique distincts, chacun étant épinglé à une zone de disponibilité spécifique conformément aux `topology.kubernetes.io/zone` exigences.
+ Si vous avez besoin de 12 nœuds répartis uniformément sur trois zones, créez trois pools de nœuds avec 4 répliques chacun, plutôt qu'un pool de nœuds avec 12 répliques sur trois zones.
## Dimensionner un pool de nœuds à capacité statique
Vous pouvez modifier le nombre de répliques dans un pool de nœuds à capacité statique à l'aide de la `kubectl scale` commande suivante :
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Lors de la réduction de la taille, le mode automatique d'EKS met fin aux nœuds de manière harmonieuse, en respectant PodDisruptionBudgets et en autorisant la replanification des pods en cours d'exécution vers les nœuds restants.
## Surveillez les pools de nœuds à capacité statique
Utilisez les commandes suivantes pour surveiller vos pools de nœuds à capacité statique :
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Le `status.nodes` champ indique le nombre actuel de nœuds gérés par le pool de nœuds, qui devrait correspondre au `replicas` nombre souhaité dans des conditions normales.
## Résolution des problèmes
**Les nœuds n'atteignent pas les répliques souhaitées :**
+ Vérifiez si la `limits.nodes` valeur est suffisante
+ Vérifiez que vos exigences ne limitent pas trop la sélection d'instances
+ Vérifiez les quotas de AWS service pour les types d'instances et les régions que vous utilisez
**Le remplacement du nœud prend trop de temps :**
+ Ajustez les budgets d'interruption pour permettre un plus grand nombre de remplacements simultanés
+ Vérifiez si PodDisruptionBudgets vous empêchez la terminaison du nœud
**Arrêt inattendu du nœud :**
+ Vérifiez les `terminationGracePeriod` paramètres `expireAfter` et
+ Vérifiez la présence de terminaisons manuelles de nœuds ou AWS d'événements de maintenance
## Exemples
### Pool de nœuds à capacité statique de base
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacité statique avec des types d'instances spécifiques
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Pool de nœuds à capacité statique multizone
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacité statique avec réservation de capacité
L'exemple suivant montre comment utiliser un pool de nœuds à capacité statique avec une réservation de capacité EC2. Pour plus d'informations sur l'utilisation des réservations de capacité EC2 avec le mode automatique EKS, consultez[Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md).
`NodeClass`définissant le `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`en faisant référence à ce qui précède `NodeClass` et en utilisant`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Créez un IngressClass pour configurer un Application Load Balancer
Le mode automatique EKS automatise les tâches courantes liées à l’équilibrage de charge, y compris l’exposition des applications du cluster à Internet.
AWS suggère d'utiliser des équilibreurs de charge d'application (ALB) pour gérer le trafic HTTP et HTTPS. Les équilibreurs de charge Application Load Balancer peuvent acheminer les requêtes en fonction de leur contenu. Pour plus d’informations sur les équilibreurs de charge Application Load Balancer, consultez [Qu’est-ce qu’un Application Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
Le mode automatique EKS crée et configure les équilibreurs de charge d'application ()ALBs. Par exemple, le mode automatique EKS crée un équilibreur de charge lorsque vous créez un objet Kubernetes `Ingress` et le configure pour acheminer le trafic vers votre charge de travail dans le cluster.
**Présentation**
1. Créez une charge de travail que vous souhaitez exposer à Internet.
1. Créez une `IngressClassParams` ressource en spécifiant AWS des valeurs de configuration spécifiques telles que le certificat à utiliser SSL/TLS et les sous-réseaux VPC.
1. Créez une ressource `IngressClass` en spécifiant que le mode automatique EKS sera le contrôleur utilisé pour cette ressource.
1. Créez une ressource `Ingress` qui associe un chemin et un port HTTP à une charge de travail du cluster.
Le mode automatique EKS créera un équilibreur de charge Application Load Balancer pointant vers la charge de travail définie dans la ressource `Ingress`, en utilisant la configuration définie dans la ressource `IngressClassParams`.
## Conditions préalables
+ Le mode automatique EKS activé sur un cluster Amazon EKS
+ Kubectl configuré pour se connecter à votre cluster
+ Vous pouvez utiliser `kubectl apply -f ` pour appliquer les exemples de fichiers YAML de configuration ci-dessous à votre cluster.
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
## Étape 1 : créer une charge de travail
Tout d’abord, créez une charge de travail que vous souhaitez exposer à Internet. Il peut s’agir de n’importe quelle ressource Kubernetes qui gère le trafic HTTP, telle qu’un déploiement ou un service.
Cet exemple utilise un service HTTP simple appelé `service-2048`, qui écoute sur le port `80`. Créez ce service et son déploiement en appliquant le manifeste `2048-deployment-service.yaml` suivant :
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f 2048-deployment-service.yaml
```
Les ressources répertoriées ci-dessus seront créées dans l’espace de noms par défaut. Vous pouvez le vérifier en exécutant la commande suivante :
```
kubectl get all -n default
```
## Étape 2 : créer IngressClassParams
Créez un `IngressClassParams` objet pour spécifier AWS des options de configuration spécifiques pour l'Application Load Balancer. Dans cet exemple, nous créons une ressource `IngressClassParams` nommée `alb` (qui sera utilisée à l’étape suivante), afin de définir le mode de fonctionnement de l’équilibreur de charge comme `internet-facing`, dans un fichier appelé `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Étape 3 : créer IngressClass
Créez un `IngressClass` qui fait référence aux valeurs de configuration AWS spécifiques définies dans la `IngressClassParams` ressource dans un fichier nommé`alb-ingressclass.yaml`. Notez le nom de la ressource `IngressClass`. Dans cet exemple, la ressource `IngressClass` et la ressource `IngressClassParams` portent toutes deux le nom `alb`.
Utilisez l’annotation `is-default-class` pour indiquer si les ressources `Ingress` doivent utiliser cette classe par défaut.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Pour plus d’informations sur les options de configuration, consultez [IngressClassParams Référence](#ingress-reference).
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingressclass.yaml
```
## Étape 4 : créer une ressource Ingress
Créez une ressource `Ingress` dans un fichier nommé `alb-ingress.yaml`. Le but de cette ressource est d’associer les chemins et les ports de l’équilibreur de charge Application Load Balancer aux charges de travail de votre cluster. Dans cet exemple, nous créons une ressource `Ingress` nommée `2048-ingress` qui achemine le trafic vers un service nommé `service-2048` sur le port 80.
Pour plus d’informations sur la configuration de cette ressource, consultez [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) dans la documentation Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingress.yaml
```
## Étape 5 : vérifier l’état
Utilisez `kubectl` pour afficher l’état de la ressource `Ingress`. Il peut falloir quelques minutes pour que l’équilibreur de charge soit disponible.
Utilisez le nom de la ressource `Ingress` définie à l’étape précédente. Par exemple :
```
kubectl get ingress 2048-ingress
```
Une fois la ressource prête, extrayez le nom de domaine de l’équilibreur de charge.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Pour afficher le service dans un navigateur web, vérifiez le port et le chemin indiqués dans la résolution `Ingress`.
## Étape 6 : nettoyage
Pour nettoyer l’équilibreur de charge, utilisez la commande suivante :
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Le mode automatique EKS supprimera automatiquement l'équilibreur de charge associé dans votre AWS compte.
## IngressClassParams Référence
Le tableau ci-dessous constitue une référence rapide des options de configuration les plus courantes.
| Champ | Description | Exemple de valeur |
| --- | --- | --- |
| `scheme` | Définit si l’ALB est interne ou orienté Internet | `internet-facing` |
| `namespaceSelector` | Limite les espaces de noms qui peuvent l'utiliser IngressClass | `environment: prod` |
| `group.name` | Regroupe plusieurs ressources Ingress pour partager un même ALB | `retail-apps` |
| `ipAddressType` | Définit le type d’adresse IP de l’ALB | `dualstack` |
| `subnets.ids` | Liste des sous-réseaux pour le déploiement IDs d'ALB | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Filtres de balises pour sélectionner les sous-réseaux destinés à l’ALB | `Environment: prod` |
| `certificateARNs` | ARNs de certificats SSL à utiliser | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tags personnalisés pour les AWS ressources | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Attributs spécifiques à l’équilibreur de charge | `idle_timeout.timeout_seconds: 60` |
## Considérations
+ Vous ne pouvez pas utiliser les annotations sur et IngressClass pour configurer les équilibreurs de charge avec le mode automatique EKS. IngressClass la configuration doit être effectuée via IngressClassParams. Cependant, vous pouvez utiliser des annotations sur des ressources d'entrée individuelles pour configurer le comportement de l'équilibreur de charge (tel que `alb.ingress.kubernetes.io/security-group-prefix-lists` ou). `alb.ingress.kubernetes.io/conditions.*`
+ Vous ne pouvez pas effectuer de réglage [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)avec le mode automatique EKS.
+ Vous devez mettre à jour le rôle IAM du cluster pour permettre la propagation des balises depuis Kubernetes vers les ressources Load AWS Balancer. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Pour plus d'informations sur l'association de ressources au mode automatique EKS ou au AWS Load Balancer Controller autogéré, consultez. [Référence de migration](migrate-auto.md#migration-reference)
+ Pour plus d’informations sur la résolution des problèmes liés aux équilibreurs de charge, consultez [Résolution des problèmes avec le mode automatique EKS](auto-troubleshoot.md).
+ Pour des considérations supplémentaires concernant l’utilisation de la fonctionnalité d’équilibrage de charge du mode automatique EKS, consultez [Équilibrage de charge](auto-networking.md#auto-lb-consider).
Les tableaux suivants fournissent une comparaison détaillée des modifications IngressClassParams, des annotations d'entrée et des TargetGroupBinding configurations pour le mode automatique EKS. Ces tableaux mettent en évidence les principales différences entre la fonctionnalité d’équilibrage de charge du mode automatique EKS et le contrôleur d’équilibreur de charge open source, notamment l’évolution des versions d’API, les fonctionnalités obsolètes et les nouveaux noms de paramètres.
### IngressClassParams
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.certificateArn` | `spec.certificateARNs` | Support pour plusieurs certificats ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Modification du schéma de correspondance des sous-réseaux |
| `spec.listeners.listenerAttributes` | Non pris en charge | Pas encore pris en charge par le mode automatique EKS |
### Annotations Ingress
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Non pris en charge | Utilisation de `spec.ingressClassName` sur les objets Ingress |
| `alb.ingress.kubernetes.io/group.name` | Non pris en charge | Spécifier les groupes dans IngressClass uniquement |
| `alb.ingress.kubernetes.io/waf-acl-id` | Non pris en charge | Utilisation de WAF v2 à la place |
| `alb.ingress.kubernetes.io/web-acl-id` | Non pris en charge | Utilisation de WAF v2 à la place |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Non pris en charge | Intégration Shield désactivée |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Non pris en charge | Type d’authentification OIDC non pris en charge actuellement |
### TargetGroupBinding
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.targetType` facultatif | `spec.targetType` obligatoire | Spécifications explicite du type de cible |
| `spec.networking.ingress.from` | Non pris en charge | Ne prend plus en charge NLB sans groupes de sécurité |
Pour utiliser la TargetGroupBinding fonctionnalité personnalisée, vous devez étiqueter le groupe cible avec la eks-cluster-name balise eks : avec le nom du cluster afin d'accorder au contrôleur les autorisations IAM nécessaires. Sachez que le contrôleur supprimera le groupe cible lorsque la TargetGroupBinding ressource ou le cluster sera supprimé.
# Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer
Découvrez comment configurer les équilibreurs de charge Network Load Balancer (NLB) dans Amazon EKS à l’aide des annotations du service Kubernetes. Cette rubrique décrit les annotations prises en charge par le mode automatique d'EKS pour personnaliser le comportement du NLB, notamment l'accessibilité à Internet, les bilans de santé, la SSL/TLS résiliation et les modes de ciblage IP.
Lorsque vous créez un service Kubernetes de type `LoadBalancer` EKS Auto Mode, EKS approvisionne et configure automatiquement un AWS Network Load Balancer en fonction des annotations que vous spécifiez. Cette approche déclarative vous permet de gérer les configurations des équilibreurs de charge directement via vos manifestes Kubernetes, conformément aux pratiques d’infrastructure en tant que code.
Le mode automatique EKS gère le provisionnement du Network Load Balancer par défaut pour tous les types LoadBalancer de services. Aucune installation ou configuration de contrôleur supplémentaire n'est requise. La spécification `loadBalancerClass: eks.amazonaws.com/nlb` est automatiquement définie comme valeur par défaut du cluster, simplifiant ainsi le déploiement et assurant la compatibilité avec les charges de travail Kubernetes existantes.
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
## Exemple de service
Pour plus d’informations sur la ressource Kubernetes `Service`, consultez la [documentation Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
Consultez l’exemple de ressource `Service` ci-dessous :
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Annotations couramment utilisées
Le tableau ci-dessous présente les annotations couramment utilisées et prises en charge par le mode automatique EKS. Notez que le mode automatique EKS ne prend pas en charge toutes les annotations existantes.
**Astuce**
Toutes les annotations suivantes doivent être préfixées par `service.beta.kubernetes.io/`
| Champ | Description | Exemple |
| --- | --- | --- |
| `aws-load-balancer-type` | Spécifie le type d’équilibreur de charge. Utilisez `external` pour les nouveaux déploiements. | `external` |
| `aws-load-balancer-nlb-target-type` | Spécifie s'il faut acheminer le trafic vers les instances de nœuds ou directement vers le pod IPs. Utilisez `instance` pour les déploiements standards ou `ip` pour un routage direct vers les pods. | `instance` |
| `aws-load-balancer-scheme` | Contrôle si l’équilibreur de charge est interne ou accessible depuis Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocole de surveillance de l’état pour le groupe cible. Les options courantes sont `TCP` (par défaut) ou `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Le chemin HTTP pour les contrôles de santé lors de l'utilisation HTTP/HTTPS du protocole. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Port utilisé pour la surveillance de l’état. Il peut s’agir d’un numéro de port spécifique ou du `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Spécifie les sous-réseaux dans lesquels créer l’équilibreur de charge. Peut utiliser un sous-réseau IDs ou des noms. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN du certificat SSL fourni par Certificate Manager for HTTPS/TLS. AWS | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Spécifie les ports devant utiliser SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Plages CIDR autorisées à accéder à l’équilibreur de charge. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Balises supplémentaires à appliquer à l'équilibreur de charge et aux ressources associées. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Spécifie si l'équilibreur de charge utilise IPv4 ou double pile (IPv4 \$1 IPv6). | `ipv4` ou `dualstack` |
## Considérations
+ Vous devez mettre à jour le rôle IAM du cluster pour permettre la propagation des balises depuis Kubernetes vers les ressources Load AWS Balancer. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Pour plus d'informations sur l'association de ressources au mode automatique EKS ou au AWS Load Balancer Controller autogéré, consultez. [Référence de migration](migrate-auto.md#migration-reference)
+ Pour plus d’informations sur la résolution des problèmes liés aux équilibreurs de charge, consultez [Résolution des problèmes avec le mode automatique EKS](auto-troubleshoot.md).
+ Pour des considérations supplémentaires concernant l’utilisation de la fonctionnalité d’équilibrage de charge du mode automatique EKS, consultez [Équilibrage de charge](auto-networking.md#auto-lb-consider).
Lors de la migration vers le mode automatique EKS pour l’équilibrage de charge, plusieurs modifications concernant les annotations de service et la configuration des ressources sont nécessaires. Les tableaux suivants présentent les principales différences entre l’ancienne et la nouvelle mise en œuvre, incluant les options non prises en charge et les alternatives recommandées.
### Annotations de service
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Non pris en charge | Utiliser `spec.loadBalancerSourceRanges` sur le service |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Non pris en charge | Utiliser `spec.loadBalancerClass` sur le service |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Non pris en charge | Utilisation des `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` à la place |
| Divers attributs de l’équilibreur de charge | Non pris en charge | Utilisation des `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
Pour migrer à partir des annotations d’attributs d’équilibreur de charge désormais obsolètes, regroupez ces paramètres dans l’annotation `service.beta.kubernetes.io/aws-load-balancer-attributes`. Cette annotation accepte une liste de paires clé-valeur séparées par des virgules afin de définir plusieurs attributs de l’équilibreur de charge. Par exemple, pour spécifier la journalisation des accès et l'équilibrage de charge entre zones, utilisez le format suivant :
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Ce format consolidé offre une méthode plus cohérente et flexible pour configurer les attributs de l’équilibreur de charge, tout en réduisant le nombre d’annotations nécessaires. Passez en revue vos configurations de service existantes et mettez-les à jour pour utiliser ce format consolidé.
### TargetGroupBinding
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.targetType` facultatif | `spec.targetType` obligatoire | Spécifications explicite du type de cible |
| `spec.networking.ingress.from` | Non pris en charge | Ne prend plus en charge NLB sans groupes de sécurité |
Remarque : Pour utiliser la TargetGroupBinding fonctionnalité personnalisée, vous devez étiqueter le groupe cible avec le `eks:eks-cluster-name` tag portant le nom du cluster afin d'accorder au contrôleur les autorisations IAM nécessaires. Sachez que le contrôleur supprimera le groupe cible lorsque la TargetGroupBinding ressource ou le cluster sera supprimé.
# Création d’une classe de stockage
Une `StorageClass` dans le mode automatique Amazon EKS définit la façon dont les volumes Amazon EBS sont automatiquement provisionnés lorsque les applications demandent du stockage persistant. Cette page explique comment créer et configurer une `StorageClass` compatible avec le mode automatique Amazon EKS pour le provisionnement de volumes EBS.
En configurant une `StorageClass`, vous pouvez définir les paramètres par défaut de vos volumes EBS, notamment le type de volume, le chiffrement, le nombre d’IOPS et d’autres paramètres liés au stockage. Vous pouvez également configurer le `StorageClass` pour utiliser les clés AWS KMS pour la gestion du chiffrement.
Le mode automatique EKS ne crée pas de `StorageClass` pour vous. Vous devez créer une `StorageClass` faisant référence à `ebs.csi.eks.amazonaws.com` pour utiliser les fonctionnalités de stockage du mode automatique EKS.
Tout d’abord, créez un fichier nommé `storage-class.yaml` :
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Ensuite, appliquez la classe de stockage à votre cluster.
```
kubectl apply -f storage-class.yaml
```
**Composants clés :**
+ `provisioner: ebs.csi.eks.amazonaws.com` : utilise le mode automatique EKS
+ `allowedTopologies` : en spécifiant `matchLabelExpressions` pour filtrer selon `eks.amazonaws.com/compute-type:auto`, vous vous assurez que si vos pods ont besoin qu’un volume soit automatiquement provisionné via le mode automatique, ceux-ci ne seront pas programmés sur des nœuds qui ne sont pas gérés par le mode automatique.
+ `volumeBindingMode: WaitForFirstConsumer` : retarde la création du volume jusqu’à ce qu’un pod en ait besoin
+ `type: gp3` : spécifie le type de volume EBS
+ `encrypted: "true"` : EBS chiffre tous les volumes créés avec la `StorageClass`. EBS utilisera l’alias de clé `aws/ebs` par défaut. Pour plus d’informations, consultez [Fonctionnement du chiffrement Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) dans le Guide de l’utilisateur Amazon EBS. Cette valeur est facultative, mais recommandée.
+ `storageclass.kubernetes.io/is-default-class: "true"` : Kubernetes utilisera cette classe de stockage par défaut, à moins que vous ne spécifiiez une autre classe de volume dans une demande de volume persistant. Cette valeur est facultative. Faites preuve de prudence lorsque vous définissez cette valeur si vous effectuez une migration depuis un autre contrôleur de stockage.
## Utilisation d’une clé KMS autogérée pour chiffrer les volumes EBS
Pour utiliser une clé KMS autogérée afin de chiffrer des volumes EBS automatisés par le mode automatique EKS, vous devez :
1. Créer une clé KMS autogérée.
+ Pour plus d’informations, consultez [Création d’une clé KMS de chiffrement symétrique](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) ou [Utilisation de KMS par Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html).
1. Créez une nouvelle politique permettant l’accès à la clé KMS.
+ Utilisez l’exemple de politique IAM ci-dessous comme modèle pour créer la politique. Insérez l’ARN de votre nouvelle clé KMS autogérée. Pour plus d'informations, consultez la section [Création de rôles et attachement de politiques (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) dans le guide de l'utilisateur AWS IAM.
1. Attachez la politique au rôle du cluster EKS.
+ Utilisez la AWS console pour trouver l'ARN du rôle de cluster EKS. Les informations relatives au rôle sont visibles dans la section **Présentation**. Pour de plus amples informations, veuillez consulter [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md).
1. Mettez à jour la `StorageClass` pour faire référence à l’ID de la clé KMS dans le champ `parameters.kmsKeyId`.
### Exemple de politique IAM KMS autogérée
Mettez à jour les valeurs suivantes dans la politique ci-dessous :
+ ``— Votre identifiant de AWS compte, tel que `111122223333`
+ ``— La AWS région de votre cluster, telle que `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Exemple de `StorageClass` KMS autogérée
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Référence des paramètres `StorageClass`
Pour des informations générales sur les ressources `StorageClass` de Kubernetes, consultez [Classes de stockage](https://kubernetes.io/docs/concepts/storage/storage-classes/) dans la documentation Kubernetes.
THe `parameters`section de la `StorageClass` ressource est spécifique à AWS. Utilisez le tableau ci-dessous pour consulter les options disponibles.
| Parameters | Valeurs | Par défaut | Description |
| --- | --- | --- | --- |
| « csi.storage.k8s.io/fstype » | xfs, ext2, ext3, ext4 | ext4 | Type de système de fichiers qui sera formaté lors de la création du volume. Ce paramètre n’est pas sensible à la casse \$1 |
| « type » | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Type de volume EBS. |
| « iopsPerGB » | | | Nombre d’opérations d’E/S par seconde par Gio. Peut être spécifié pour IO1 IO2, et les GP3 volumes. |
| « Autoriser Auto IOPSPer GBIncrease » | true, false | false | Lorsque `"true"` le pilote CSI augmente le nombre d'IOPS pour un volume trop faible pour correspondre à la plage d'IOPS prise en charge par. `iopsPerGB * ` AWS Cela permet au provisionnement dynamique de réussir en tout temps, même si l’utilisateur spécifie une capacité PVC trop faible ou une valeur `iopsPerGB` insuffisante. Cependant, cette fonctionnalité peut entraîner des coûts plus élevés, car ces volumes obtiennent un niveau d’IOPS supérieur à celui demandé dans `iopsPerGB`. |
| « iops » | | | Nombre d’opérations d’E/S par seconde. Peut être spécifié pour IO1 IO2, et les GP3 volumes. |
| « throughput » | | 125 | Le débit est exprimé en Mio/s. Efficace uniquement lorsque le type de volume gp3 est spécifié. |
| « encrypted » | true, false | false | Indique si le volume doit être chiffré ou non. Les valeurs valides sont « true » ou « false ». |
| « blockExpress » | true, false | false | Permet la création de volumes io2 Block Express. |
| "kmsKeyId" | | | ARN complet de la clé à utiliser pour chiffrer le volume. Si elle n'est pas spécifiée, AWS utilisera la clé KMS par défaut pour la région dans laquelle se trouve le volume. Si elle n’a pas été modifiée, cette clé autogénérée s’appelera `/aws/ebs`. |
| « blockSize » | | | Taille des blocs utilisée lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3`, `ext4` ou `xfs`. |
| « inodeSize » | | | Taille des inodes utilisée lors du formatage du système de fichiers. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3`, `ext4` ou `xfs`. |
| "bytesPerInode" | | | Nombre de `bytes-per-inode` utilisé lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3` et `ext4`. |
| "numberOfInodes" | | | Nombre de `number-of-inodes` utilisé lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3` et `ext4`. |
| « poste 4 BigAlloc » | true, false | false | Modifie le système de fichiers `ext4` pour activer l’allocation de blocs en clusters en utilisant l’option de formatage `bigalloc`. Avertissement : `bigalloc` peut ne pas être entièrement pris en charge par le noyau Linux de vos nœuds. |
| « poste 4 ClusterSize » | | | Taille des clusters utilisée lors du formatage d’un système de fichiers `ext4` lorsque la fonctionnalité `bigalloc` est activée. Remarque : le paramètre `ext4BigAlloc` doit être défini sur true. |
Pour plus d'informations, voir le [pilote AWS EBS CSI activé](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md). GitHub
## Considérations
**Note**
Vous pouvez uniquement déployer des charges de travail en fonction du mode automatique EKS StorageClasses sur les nœuds du mode automatique EKS. Si votre cluster comporte différents types de nœuds, vous devez configurer vos charges de travail afin qu’elles s’exécutent uniquement sur les nœuds du mode automatique EKS. Pour de plus amples informations, veuillez consulter [Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md).
La capacité de stockage par blocs du mode automatique EKS est différente de celle du pilote CSI EBS.
+ Provisionnement statique
+ Si vous souhaitez utiliser des volumes EBS créés en externe avec le mode automatique EKS, vous devez ajouter manuellement une AWS balise avec la clé `eks:eks-cluster-name` et la valeur du nom du cluster.
+ Rejet de démarrage des nœuds
+ Vous ne pouvez pas utiliser la fonctionnalité de rejet de démarrage des nœuds pour empêcher la planification des pods avant que la capacité de stockage ne soit prête
+ Balises personnalisées sur les volumes provisionnés dynamiquement
+ Vous ne pouvez pas utiliser le paramètre CLI extra-tag pour configurer des balises personnalisées sur les volumes EBS provisionnés dynamiquement
+ Vous pouvez utiliser le balisage `StorageClass` pour ajouter des balises personnalisées. Le mode automatique EKS ajoutera des balises aux AWS ressources associées. Vous devrez mettre à jour le rôle IAM du cluster afin d’utiliser des balises personnalisées. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Métriques de performances détaillées d’EBS
+ Vous ne pouvez pas accéder aux métriques Prometheus pour les performances détaillées d’EBS
## Installation du module complémentaire CSI Snapshot Controller
Le mode automatique EKS est compatible avec le module complémentaire Amazon EKS CSI Snapshot Controller.
AWS vous suggère de configurer ce module complémentaire pour qu'il s'exécute sur le pool de `system` nœuds intégré.
Pour en savoir plus, consultez :
+ [Exécutez les modules complémentaires critiques sur des instances dédiées.](critical-workload.md)
+ [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md)
+ [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md)
### Pour installer le contrôleur d’instantané dans le groupe de nœuds système
1. Ouvrez votre cluster EKS dans la AWS console
1. Dans l’onglet **Modules complémentaires**, sélectionnez **Obtenir plus de modules complémentaires**
1. Sélectionnez le module **CSI Snapshot Controller**, puis **Suivant**
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, sélectionnez **Paramètres de configuration facultatifs** pour afficher le **schéma de configuration des modules complémentaires**
1. Insérez le fichier YAML suivant pour associer le contrôleur d’instantané au groupe de nœuds `system`. Le contrôleur d’instantané inclut une tolérance pour le rejet `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Sélectionnez **Suivant**
1. Vérifier la configuration du module complémentaire, puis sélectionnez **Créer**
# Désactivation du mode automatique EKS
Vous pouvez désactiver le mode automatique EKS sur un cluster EKS existant. Cette opération est destructrice.
+ EKS mettra fin à toutes les EC2 instances gérées par le mode automatique EKS.
+ EKS supprime tous les équilibreurs de charge gérés par le mode automatique EKS.
+ EKS **ne** supprime pas les volumes EBS provisionnés par le mode automatique EKS.
Le mode automatique EKS est conçu pour gérer entièrement les ressources qu’il crée. Toute intervention manuelle peut empêcher le mode automatique EKS de nettoyer correctement ces ressources lors de sa désactivation. Par exemple, si vous faites référence à un groupe de sécurité géré depuis des règles d’un groupe de sécurité externe et que vous oubliez de supprimer cette référence avant de désactiver le mode automatique EKS pour un cluster, le groupe de sécurité géré peut ne pas être supprimé (fuite de ressource). Les étapes ci-dessous expliquent comment supprimer un groupe de sécurité ayant fui.
## Désactiver le mode automatique EKS (AWS console)
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **Mode automatique EKS**, sélectionnez **Gérer**
1. Basculez **Mode automatique EKS** sur `off`.
Si un groupe de sécurité géré n’est pas supprimé à la fin du processus, vous pouvez le supprimer manuellement en suivant les instructions de la section [Suppression d’un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Désactiver le mode automatique EKS (AWS CLI)
Utilisez la commande suivante pour désactiver le mode automatique EKS sur un cluster existant.
La CLI `aws` doit être installée et vous devez être connecté avec des autorisations suffisantes pour gérer les clusters EKS. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
**Note**
Les capacités de calcul, de stockage bloc et d’équilibrage de charge doivent toutes être activées ou désactivées dans la même requête.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Vous pouvez vérifier si un groupe de sécurité géré par le mode automatique EKS n’a pas été supprimé après la désactivation en procédant comme suit :
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Pour supprimer ensuite le groupe de sécurité :
```
aws ec2 delete-security-group --group-name=
```
# Mise à jour de la version Kubernetes d’un cluster du mode automatique Amazon EKS
Cette rubrique explique comment mettre à jour la version Kubernetes de votre cluster du mode automatique. Le mode automatique EKS simplifie le processus de mise à jour en gérant la coordination entre la mise à jour du plan de contrôle et le remplacement des nœuds, tout en préservant la disponibilité des charges de travail grâce aux budgets d’interruption des pods.
Lors de la mise à niveau d’un cluster du mode automatique EKS, de nombreux composants traditionnellement mis à jour manuellement sont désormais gérés automatiquement par le service. La compréhension des aspects automatisés du processus de mise à jour et de vos responsabilités permet d’assurer une transition fluide entre les versions de votre cluster.
## Informations sur les mises à jour avec le mode automatique EKS
Une fois la mise à niveau du plan de contrôle lancée, le mode automatique EKS procède à la mise à jour des nœuds de votre cluster. Au fur et à mesure que les anciens nœuds arrivent à expiration, le mode automatique EKS les remplace par de nouveaux nœuds. Les nouveaux nœuds exécutent la nouvelle version Kubernetes correspondante. Le mode automatique EKS respecte les budgets d’interruption des pods pendant le processus de mise à jour des nœuds.
De plus, il n’est plus nécessaire de mettre à jour manuellement certains composants tels que :
+ CNI Amazon VPC
+ Contrôleur de l'équilibreur de charge AWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ Pilote AWS EBS CSI
Le mode automatique EKS remplace ces composants par des fonctionnalités de service intégrées.
Vous restez toutefois responsable de la mise à jour des éléments suivants :
+ Applications et charges de travail déployées sur votre cluster
+ Modules complémentaires et contrôleurs autogérés
+ Modules complémentaires Amazon EKS
+ Découvrez comment… [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md)
Découvrez les [bonnes pratiques pour les mises à niveau des clusters](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Démarrage de la mise à jour du cluster
Pour démarrer la mise à jour d’un cluster, consultez [Mettre à jour un cluster existant vers une nouvelle version de Kubernetes](update-cluster.md).
# Activer ou désactiver la fonction intégrée NodePools
Le mode automatique EKS en possède deux intégrés NodePools. Vous pouvez les activer ou les désactiver à NodePools l'aide de la AWS console, de la CLI ou de l'API.
## NodePool Référence intégrée
+ `system`
+ Cela NodePool a une `CriticalAddonsOnly` odeur. De nombreux modules complémentaires EKS, tels que CoreDNS, tolèrent ce rejet. Utilisez ce groupe de nœuds système pour séparer les applications critiques du cluster.
+ Prend en charge les architectures `amd64` et `arm64`.
+ `general-purpose`
+ Cela NodePool permet de lancer des nœuds pour des charges de travail générales dans votre cluster.
+ Utilise uniquement l’architecture `amd64`.
Les deux sont intégrés NodePools :
+ Utiliser l'EKS par défaut NodeClass
+ Utiliser uniquement la EC2 capacité à la demande
+ Utiliser les familles d' EC2 instances C, M et R
+ Exiger des EC2 instances de génération 5 ou plus récentes
**Note**
L'activation d'au moins une fonction intégrée NodePool est requise pour qu'EKS puisse configurer la « valeur par défaut » NodeClass. Si vous désactivez toutes les NodePools fonctionnalités intégrées, vous devrez créer une personnalisation NodeClass et en configurer une NodePool pour l'utiliser. Pour plus d'informations sur NodeClasses, voir[Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Procédure
### Conditions préalables
+ La dernière version de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [configuration rapide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande.
+ Connectez-vous à la CLI avec des autorisations IAM suffisantes pour créer des AWS ressources, notamment des politiques IAM, des rôles IAM et des clusters EKS.
### Activer avec la AWS CLI
Utilisez la commande suivante pour activer les deux fonctions intégrées NodePools :
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Vous pouvez modifier la commande pour activer de manière sélective le NodePools.
### Désactiver avec la AWS CLI
Utilisez la commande suivante pour désactiver les deux fonctions intégrées NodePools :
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS
Lors de l’exécution de charges de travail dans un cluster EKS utilisant le mode automatique EKS, il peut être nécessaire de contrôler si certaines charges de travail doivent s’exécuter sur des nœuds du mode automatique EKS ou sur d’autres types de calcul. Cette section explique comment utiliser des sélecteurs de nœuds et des règles d’affinité pour garantir que vos charges de travail soient planifiées sur l’infrastructure de calcul souhaitée.
Les exemples de cette rubrique montrent comment utiliser l’étiquette `eks.amazonaws.com/compute-type` pour imposer ou empêcher le déploiement d’une charge de travail sur les nœuds du mode automatique EKS. Cette approche est particulièrement utile dans les clusters en mode mixte, où vous utilisez à la fois le mode automatique EKS et d’autres types de calcul, tels que les fournisseurs Karpenter autogérés ou les groupes de nœuds gérés par EKS.
Les nœuds du mode automatique EKS définissent l’étiquette `eks.amazonaws.com/compute-type` sur `auto`. Vous pouvez utiliser cette étiquette pour contrôler si une charge de travail est déployée sur des nœuds gérés par le mode automatique EKS.
## Exigence de déploiement d’une charge de travail sur les nœuds du mode automatique EKS
**Note**
Cette valeur `nodeSelector` n’est pas obligatoire pour le mode automatique EKS. Cette valeur `nodeSelector` n’est pertinente que si vous exécutez un cluster en mode mixte, avec des types de nœuds non gérés par le mode automatique EKS. Par exemple, un cluster peut combiner une capacité de calcul statique fournie par les groupes de nœuds gérés par EKS et une capacité dynamique fournie par le mode automatique EKS.
Vous pouvez ajouter ce `nodeSelector` aux déploiements ou à d’autres charges de travail afin d’indiquer à Kubernetes à les planifier exclusivement sur des nœuds du mode automatique EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Exigence de non-déploiement d’une charge de travail sur les nœuds du mode automatique EKS
Vous pouvez ajouter ce `nodeAffinity` aux déploiements ou à d’autres charges de travail afin d’indiquer à Kubernetes de **ne pas** les planifier sur des nœuds du mode automatique EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Exécutez les modules complémentaires critiques sur des instances dédiées.
Dans cette rubrique, vous apprendrez comment déployer une charge de travail avec une tolérance `CriticalAddonsOnly` afin que le mode automatique EKS la planifie sur le pool de nœuds `system`.
Le pool de nœuds `system` intégré au mode automatique EKS est conçu pour exécuter des modules complémentaires essentiels sur des instances dédiées. Cette séparation garantit que les composants essentiels disposent de ressources dédiées et sont isolés des charges de travail générales, ce qui améliore la stabilité et les performances globales du cluster.
Ce guide explique comment déployer des modules complémentaires dans le pool de nœuds `system` en utilisant la tolérance `CriticalAddonsOnly` et les sélecteurs de nœuds appropriés. En suivant ces étapes, vous pouvez vous assurer que vos applications critiques sont planifiées sur les nœuds `system` dédiés, en tirant parti des avantages en termes d’isolation et d’allocation des ressources offerts par la structure de pool de nœuds spécialisée du mode automatique EKS.
Le mode automatique EKS dispose de deux pools de nœuds intégrés : `general-purpose` et `system`. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
Le but du pool de nœuds `system` est de séparer les modules complémentaires critiques sur différents nœuds. Les nœuds provisionnés par le pool de nœuds `system` ont un rejet Kubernetes `CriticalAddonsOnly`. Kubernetes ne planifiera les pods sur ces nœuds que s’ils ont une tolérance correspondante. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.
## Prérequis
+ Le cluster du mode automatique EKS avec le groupe de nœuds `system` intégré activé. Pour plus d’informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ `kubectl` installé et configuré. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
## Procédure
Consultez l’exemple YAML ci-dessous. Notez les configurations suivantes :
+ `nodeSelector`— Cela associe la charge de travail au pool de nœuds `system` intégré. Ce pool de nœuds doit être activé avec l’API AWS. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ `tolerations` : cette tolérance permet de surmonter le rejet `CriticalAddonsOnly` des nœuds dans le groupe de nœuds `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Pour mettre à jour une charge de travail afin qu’elle s’exécute sur le pool de nœuds `system`, vous devez :
1. Mettez à jour la charge de travail existante pour ajouter les configurations suivantes décrites ci-dessus :
+ `nodeSelector`
+ `tolerations`
1. Déployez la charge de travail mise à jour sur votre cluster avec `kubectl apply`
Une fois la charge de travail mise à jour, elle s’exécutera sur des nœuds dédiés.
# Utilisation des politiques réseau avec le mode automatique EKS
## Présentation de
À mesure que les clients adaptent leurs environnements applicatifs à l'aide d'EKS, l'isolation du trafic réseau devient de plus en plus fondamentale pour empêcher tout accès non autorisé aux ressources à l'intérieur et à l'extérieur du cluster. Cela est particulièrement important dans un environnement mutualisé dans lequel plusieurs charges de travail indépendantes s'exécutent côte à côte dans le cluster. Les politiques réseau Kubernetes vous permettent d'améliorer le niveau de sécurité du réseau pour vos charges de travail Kubernetes, ainsi que leur intégration avec les points de terminaison externes au cluster. Le mode automatique EKS prend en charge différents types de politiques réseau.
### Isolation des couches 3 et 4
Les politiques réseau standard de Kubernetes s'appliquent aux couches 3 et 4 du modèle de réseau OSI et vous permettent de contrôler le flux de trafic au niveau de l'adresse IP ou du port au sein de votre cluster Amazon EKS.
#### Cas d’utilisation
+ Segmentez le trafic réseau entre les charges de travail afin de garantir que seules les applications associées puissent communiquer entre elles.
+ Isolez les locataires au niveau de l'espace de noms à l'aide de politiques visant à appliquer la séparation des réseaux.
### Application basée sur le DNS
Les clients déploient généralement des charges de travail dans EKS qui font partie d'un environnement distribué plus large, dont certaines doivent communiquer avec des systèmes et des services extérieurs au cluster (trafic en direction du nord). Ces systèmes et services peuvent être hébergés dans le AWS cloud ou AWS totalement externes. Les politiques basées sur le système de noms de domaine (DNS) vous permettent de renforcer votre posture de sécurité en adoptant une approche plus stable et prévisible pour empêcher tout accès non autorisé des pods aux ressources ou points de terminaison externes au cluster. Ce mécanisme élimine le besoin de suivre manuellement et d'autoriser la création de listes d'adresses IP spécifiques. En sécurisant les ressources grâce à une approche basée sur le DNS, vous bénéficiez également d'une plus grande flexibilité pour mettre à jour l'infrastructure externe sans avoir à assouplir votre posture de sécurité ou à modifier les politiques réseau en cas de modifications apportées aux serveurs et hôtes en amont. Vous pouvez filtrer le trafic sortant vers des points de terminaison externes à l'aide d'un nom de domaine complet (FQDN) ou d'un modèle de correspondance pour un nom de domaine DNS. Cela vous donne la flexibilité supplémentaire d'étendre l'accès à plusieurs sous-domaines associés à un point de terminaison externe au cluster particulier.
#### Cas d’utilisation
+ Utilisez une approche basée sur le DNS pour filtrer l'accès depuis un environnement Kubernetes vers des points de terminaison externes au cluster.
+ Accès sécurisé aux AWS services dans un environnement mutualisé.
+ Gérez l'accès au réseau, des modules aux charges de travail sur site dans vos environnements de cloud hybride.
### Règles relatives à l'administration (ou à l'échelle du cluster)
Dans certains cas, tels que les scénarios multi-locataires, les clients peuvent avoir besoin d'appliquer une norme de sécurité réseau qui s'applique à l'ensemble du cluster. Au lieu de définir et de gérer de manière répétitive une politique distincte pour chaque espace de noms, vous pouvez utiliser une seule stratégie pour gérer de manière centralisée les contrôles d'accès au réseau pour les différentes charges de travail du cluster, quel que soit leur espace de noms. Ces types de politiques vous permettent d'étendre le champ d'application des règles de filtrage de votre réseau appliquées aux couches 3, 4 et lors de l'utilisation des règles DNS.
#### Cas d’utilisation
+ Gérez de manière centralisée les contrôles d'accès au réseau pour toutes les charges de travail (ou un sous-ensemble de celles-ci) de votre cluster EKS.
+ Définissez une posture de sécurité réseau par défaut sur l'ensemble du cluster.
+ Étendez les normes de sécurité organisationnelles à l'étendue du cluster de manière plus efficace sur le plan opérationnel.
## Prise en main
### Conditions préalables
+ Cluster Amazon EKS avec le mode automatique EKS activé
+ kubectl configuré pour se connecter à votre cluster
### Étape 1 : activer le contrôleur de politiques réseau
Pour utiliser les politiques réseau avec le mode automatique EKS, vous devez d'abord activer le Network Policy Controller en appliquant un ConfigMap à votre cluster.
1. Créez un fichier nommé `enable-network-policy.yaml` avec le contenu suivant:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Appliquez le ConfigMap à votre cluster :
```
kubectl apply -f enable-network-policy.yaml
```
### Étape 2 : créer et tester des politiques réseau
Votre cluster du mode automatique EKS est maintenant configuré pour prendre en charge les politiques réseau Kubernetes. Vous pouvez tester cette configuration à l’aide de [Démonstration des politiques réseau pour Amazon EKS](network-policy-stars-demo.md).
### Étape 3 : ajuster la configuration de l'agent de politique réseau dans la classe de nœuds (facultatif)
Vous pouvez éventuellement créer une nouvelle classe de nœuds pour modifier le comportement par défaut de l'agent de stratégie réseau sur les nœuds ou activer la journalisation des événements de politique réseau. Pour cela, procédez comme suit :
1. Créez ou modifiez un fichier YAML de classe de nœud (par exemple, `nodeclass-network-policy.yaml`) avec le contenu suivant :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Appliquez la configuration de la classe de nœuds à votre cluster :
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Vérifiez que la classe de nœuds a été créée :
```
kubectl get nodeclass network-policy-config
```
1. Mettez à jour votre groupe de nœuds pour utiliser cette classe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Fonctionnement
### Politique réseau basée sur le DNS
![\[Illustration du flux de travail lorsqu'une politique basée sur le DNS est appliquée dans EKS Auto\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Illustration du flux de travail lorsqu'une politique basée sur le DNS est appliquée dans EKS Auto\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/apply-dns-policy-2.png)
1. L'équipe de la plateforme applique une politique basée sur le DNS au cluster EKS.
1. Le Network Policy Controller est chargé de surveiller la création de politiques au sein du cluster, puis de réconcilier les points de terminaison des politiques. Dans ce cas d'utilisation, le contrôleur de stratégie réseau demande à l'agent du nœud de filtrer les demandes DNS en fonction des domaines autorisés dans la politique créée. Les noms de domaine sont autorisés à l'aide du nom de domaine complet ou d'un nom de domaine correspondant à un modèle défini dans la configuration des ressources Kubernetes.
1. La charge de travail A tente de résoudre l'adresse IP d'un point de terminaison externe au cluster. La demande DNS passe d'abord par un proxy qui filtre ces demandes en fonction de la liste d'autorisation appliquée par le biais de la politique réseau.
1. Une fois que la demande DNS passe par la liste d'autorisation du filtre DNS, elle est transmise par proxy à CoreDNS,
1. CoreDNS envoie à son tour la demande au résolveur DNS externe (Amazon Route 53 Resolver) pour obtenir la liste des adresses IP sous-jacentes au nom de domaine.
1. Les données résolues IPs avec TTL sont renvoyées dans la réponse à la demande DNS. Ils IPs sont ensuite écrits dans une carte eBPF qui est utilisée à l'étape suivante pour l'application de la couche IP.
1. Les sondes eBPF connectées à l'interface Pod veth filtreront ensuite le trafic sortant de la charge de travail A vers le point de terminaison externe au cluster en fonction des règles en place. Cela garantit que les pods ne peuvent envoyer du trafic externe au cluster que vers les domaines autorisés IPs répertoriés. Leur validité IPs est basée sur le TTL extrait du résolveur DNS externe (Amazon Route 53 Resolver).
#### Utilisation de la politique du réseau d'applications
Il `ApplicationNetworkPolicy` combine les fonctionnalités des politiques réseau standard de Kubernetes avec le filtrage basé sur le DNS au niveau de l'espace de noms en utilisant une seule définition de ressource personnalisée (CRD). Par conséquent, `ApplicationNetworkPolicy` ils peuvent être utilisés pour :
1. Définition des restrictions au niveau des couches 3 et 4 de la pile réseau à l'aide de blocs IP et de numéros de port.
1. Définir des règles qui s'appliquent à la couche 7 de la pile réseau et vous permettre de filtrer le trafic en fonction de FQDNs.
**Important**
Les règles basées sur le DNS définies à l'aide du `ApplicationNetworkPolicy` ne s'appliquent qu'aux charges de travail exécutées dans des instances EC2 lancées en mode EKS Auto. `ApplicationNetworkPolicy`prend en charge tous les champs du Kubernetes standard`NetworkPolicy`, avec un filtre FQDN supplémentaire pour les règles de sortie.
**Avertissement**
N'utilisez pas le même nom pour un `ApplicationNetworkPolicy` et un `NetworkPolicy` dans le même espace de noms. Si les noms entrent en collision, les `PolicyEndpoints` objets obtenus risquent de ne pas refléter correctement l'une ou l'autre des politiques. Les deux ressources sont acceptées sans erreur, ce qui rend ce problème difficile à diagnostiquer.
Pour résoudre un conflit de dénomination, renommez les objets `ApplicationNetworkPolicy` ou renommez-les de `NetworkPolicy` manière à ce qu'ils soient uniques dans l'espace de noms, puis vérifiez que les `PolicyEndpoints` objets correspondants sont correctement mis à jour.
#### Exemple
Dans votre cluster EKS Auto Mode, vous avez une charge de travail qui doit communiquer avec une application sur site située derrière un équilibreur de charge portant un nom DNS. Vous pouvez y parvenir en appliquant la politique réseau suivante :
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Au niveau du réseau Kubernetes, cela permettrait de sortir de tous les pods de l'espace de noms « galaxy » étiqueté avec `role: backend` pour se connecter au nom de domaine **myapp.mydomain.com** sur le port TCP 8080. En outre, vous devez configurer la connectivité réseau pour le trafic sortant de votre VPC vers le centre de données de votre entreprise.
![\[Illustration de la charge de travail dans EKS Auto communiquant avec les applications sur site\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Politique réseau de l'administrateur (ou du cluster)
![\[illustration de l'ordre d'évaluation des politiques réseau dans EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/evaluation-order.png)
#### Utilisation de la politique réseau du cluster
Lorsque vous utilisez un`ClusterNetworkPolicy`, les politiques du niveau administrateur sont évaluées en premier et ne peuvent pas être remplacées. Lorsque les politiques de niveau administrateur ont été évaluées, les politiques délimitées par espace de noms standard sont utilisées pour exécuter les règles de segmentation du réseau appliquées. Cela peut être accompli en utilisant l'un `ApplicationNetworkPolicy` ou l'autre`NetworkPolicy`. Enfin, les règles du niveau de référence qui définissent les restrictions réseau par défaut pour les charges de travail des clusters seront appliquées. Ces règles du niveau de base **peuvent** être remplacées par les politiques délimitées de l'espace de noms si nécessaire.
#### Exemple
Votre cluster contient une application que vous souhaitez isoler des charges de travail des autres locataires. Vous pouvez bloquer explicitement le trafic du cluster en provenance d'autres espaces de noms pour empêcher l'accès réseau à l'espace de noms de charge de travail sensible.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Considérations
### Comprendre l'ordre d'évaluation des politiques
Les fonctionnalités de politique réseau prises en charge dans EKS sont évaluées dans un ordre spécifique afin de garantir une gestion du trafic prévisible et sécurisée. Il est donc important de comprendre le flux d'évaluation afin de concevoir une posture de sécurité réseau efficace pour votre environnement.
1. **Politiques du niveau administrateur (évaluées en premier)** : toutes les politiques du niveau administrateur ClusterNetworkPolicies sont évaluées avant les autres politiques. Au niveau administrateur, les politiques sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Le type d'action détermine ce qui se passe ensuite.
+ **Refuser l'action (priorité la plus élevée)** : lorsqu'une politique d'administration associée à une action de refus correspond au trafic, ce trafic est immédiatement bloqué, quelles que soient les autres politiques. Aucune autre ClusterNetworkPolicy NetworkPolicy règle n'est traitée. Cela garantit que les contrôles de sécurité à l'échelle de l'organisation ne peuvent pas être remplacés par des politiques au niveau de l'espace de noms.
+ **Autoriser l'action** : une fois les règles de refus évaluées, les politiques d'administration comportant des actions d'autorisation sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Lorsqu'une action Autoriser correspond, le trafic est accepté et aucune autre évaluation de politique n'est effectuée. Ces politiques peuvent accorder l'accès à plusieurs espaces de noms en fonction de sélecteurs d'étiquettes, offrant ainsi un contrôle centralisé des charges de travail pouvant accéder à des ressources spécifiques.
+ **Action de transfert** : les actions de transfert prévues dans les politiques du niveau administrateur délèguent la prise de décision aux niveaux inférieurs. Lorsque le trafic correspond à une règle Pass, l'évaluation ignore toutes les règles de niveau administrateur restantes pour ce trafic et passe directement au NetworkPolicy niveau. Cela permet aux administrateurs de déléguer explicitement le contrôle de certains modèles de trafic aux équipes d'application. Par exemple, vous pouvez utiliser les règles Pass pour déléguer la gestion du trafic intra-espace à des administrateurs d'espaces de noms tout en maintenant des contrôles stricts sur l'accès externe.
1. **Niveau de politique réseau** : si aucune politique de niveau administrateur ne correspond à Deny ou Allow, ou si une action Pass correspond, les NetworkPolicy ressources traditionnelles ApplicationNetworkPolicy et limitées à l'espace de noms sont ensuite évaluées. Ces politiques fournissent un contrôle précis au sein des espaces de noms individuels et sont gérées par les équipes d'application. Les politiques étendues à l'espace de noms ne peuvent être que plus restrictives que les politiques d'administration. Ils ne peuvent pas annuler la décision de refus d'une politique d'administration, mais ils peuvent restreindre davantage le trafic autorisé ou approuvé par les politiques d'administration.
1. **Politiques d'administration du niveau de référence** : si aucune politique d'administration ou limitée à un espace de noms ne correspond au trafic, le niveau de référence est évalué. ClusterNetworkPolicies Ils fournissent des postures de sécurité par défaut qui peuvent être remplacées par des politiques délimitées par des espaces de noms, permettant aux administrateurs de définir des valeurs par défaut à l'échelle de l'organisation tout en donnant aux équipes la flexibilité de les personnaliser selon les besoins. Les politiques de base sont évaluées par ordre de priorité (le numéro de priorité le plus bas en premier).
1. **Refus par défaut (si aucune politique ne correspond)** : ce deny-by-default comportement garantit que seules les connexions explicitement autorisées sont autorisées, garantissant ainsi un niveau de sécurité élevé.
### Appliquer le principe du moindre privilège
+ **Commencez par des politiques restrictives et ajoutez progressivement des autorisations selon les besoins** : commencez par mettre en œuvre des deny-by-default politiques au niveau du cluster, puis ajoutez progressivement des règles d'autorisation au fur et à mesure que vous validez les exigences de connectivité légitimes. Cette approche oblige les équipes à justifier explicitement chaque connexion externe, créant ainsi un environnement plus sécurisé et plus contrôlable.
+ **Auditez régulièrement et supprimez les règles de politique non utilisées** : les politiques réseau peuvent s'accumuler au fil du temps à mesure que les applications évoluent, laissant derrière elles des règles obsolètes qui étendent inutilement votre surface d'attaque. Mettez en œuvre un processus de révision régulier pour identifier et supprimer les règles de politique qui ne sont plus nécessaires, afin de garantir que votre posture de sécurité reste stricte et maintenable.
+ **Utilisez des noms de domaine spécifiques plutôt que des modèles généraux lorsque cela est possible**. Si les modèles génériques sont pratiques, ils `*.amazonaws.com` permettent également d'accéder à un large éventail de services. Dans la mesure du possible, spécifiez des noms de domaine exacts, par exemple `s3.us-west-2.amazonaws.com` pour limiter l'accès aux seuls services spécifiques dont vos applications ont besoin, réduisant ainsi le risque de déplacement latéral si une charge de travail est compromise.
### Utilisation de politiques basées sur le DNS dans EKS
+ Les règles basées sur le DNS définies à l'aide du `ApplicationNetworkPolicy` ne s'appliquent qu'aux charges de travail exécutées dans des instances EC2 lancées en mode EKS Auto. Si vous utilisez un cluster en mode mixte (composé à la fois de nœuds de travail EKS Auto et de nœuds de travail non EKS Auto), vos règles basées sur le DNS ne sont efficaces que dans les nœuds de travail en mode automatique d'EKS (instances gérées EC2).
### Validation de vos politiques DNS
+ **Utilisez des clusters intermédiaires qui reflètent la topologie du réseau de production pour les tests** - Votre environnement intermédiaire doit reproduire l'architecture réseau, les dépendances externes et les modèles de connectivité de production afin de garantir des tests de politiques précis. Cela inclut les configurations VPC correspondantes, le comportement de résolution DNS et l'accès aux mêmes services externes dont vos charges de travail de production ont besoin.
+ **Mettez en œuvre des tests automatisés pour les chemins réseau critiques** - Créez des tests automatisés qui valident la connectivité aux services externes essentiels dans le cadre de votre CI/CD pipeline. Ces tests doivent vérifier que les flux de trafic légitimes sont autorisés tandis que les connexions non autorisées sont bloquées, afin de valider en permanence que vos politiques réseau maintiennent le bon niveau de sécurité au fur et à mesure de l'évolution de votre infrastructure.
+ **Surveillez le comportement des applications après les modifications des politiques** : après avoir déployé des politiques réseau nouvelles ou modifiées en production, surveillez de près les journaux des applications, les taux d'erreur et les indicateurs de performance pour identifier rapidement les problèmes de connectivité. Établissez des procédures d'annulation claires afin de pouvoir annuler rapidement les modifications de politique si elles entraînent un comportement inattendu des applications ou des interruptions de service.
### Interaction avec le pare-feu DNS Amazon Route 53
Les politiques d'administration et de réseau d'EKS sont d'abord évaluées au niveau du module lorsque le trafic est initié. Si une politique réseau EKS autorise la sortie vers un domaine spécifique, le pod exécute alors une requête DNS qui atteint le résolveur Route 53. À ce stade, les règles du pare-feu DNS Route 53 sont évaluées. Si le pare-feu DNS bloque la requête de domaine, la résolution DNS échoue et la connexion ne peut pas être établie, même si la politique réseau EKS l'autorise. Cela crée des couches de sécurité complémentaires : les politiques réseau basées sur le DNS d'EKS fournissent un contrôle des sorties au niveau du pod pour répondre aux exigences d'accès spécifiques aux applications et aux limites de sécurité mutualisées, tandis que le pare-feu DNS fournit une protection à l'échelle du VPC contre les domaines malveillants connus et applique des listes de blocage à l'échelle de l'organisation.
# Baliser les sous-réseaux pour le mode automatique EKS
Si vous utilisez la fonctionnalité d'équilibrage de charge du mode automatique d'EKS, vous devez ajouter des AWS balises à vos sous-réseaux VPC.
## Contexte
Ces balises identifient les sous-réseaux comme étant associés au cluster et, plus important encore, indiquent si le sous-réseau est public ou privé.
Les sous-réseaux publics ont un accès direct à Internet via une passerelle Internet. Ils sont utilisés pour les ressources qui doivent être accessibles au public, telles que les équilibreurs de charge.
Les sous-réseaux privés n’ont pas d’accès direct à Internet et utilisent des passerelles NAT pour le trafic sortant. Ils sont utilisés pour les ressources internes telles que les nœuds EKS qui n'ont pas besoin d'être publics IPs.
Pour en savoir plus sur les passerelles NAT et les passerelles Internet, consultez [Connecter votre VPC à d’autres réseaux](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) dans le Guide de l’utilisateur Amazon Virtual Private Cloud (VPC).
## Exigence
À l’heure actuelle, les sous-réseaux utilisés pour l’équilibrage de charge par le mode automatique EKS doivent être balisés avec l’une des balises suivantes.
### Sous-réseaux publics
Les sous-réseaux publics sont utilisés pour les équilibreurs de charge connectés à Internet. Ces sous-réseaux doivent comporter les balises suivantes :
| Clé | Valeur |
| --- | --- |
| `kubernetes.io/role/elb` | `1` ou `` |
### Sous-réseaux privés
Les sous-réseaux privés sont utilisés pour les équilibreurs de charge internes. Ces sous-réseaux doivent comporter les balises suivantes :
| Clé | Valeur |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` ou `` |
## Procédure
Avant de commencer, identifiez les sous-réseaux publics (avec accès à une passerelle Internet) et les sous-réseaux privés (utilisant une passerelle NAT). Vous aurez besoin d’autorisations pour modifier les ressources VPC.
### AWS Management Console
1. **Ouvrez la console Amazon VPC et accédez à Subnets.**
1. Sélectionnez le sous-réseau à étiqueter.
1. Choisissez l'onglet **Tags**, puis sélectionnez **Ajouter un tag**.
1. Ajoutez la balise appropriée :
+ Pour les sous-réseaux publics : Key=`kubernetes.io/role/elb`
+ Pour les sous-réseaux privés : Key=`kubernetes.io/role/internal-elb`
1. Définissez **la valeur** sur `1` ou laissez le champ vide.
1. Enregistrez et répétez l'opération pour les sous-réseaux restants.
### AWS CLI
Pour les sous-réseaux publics :
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Pour les sous-réseaux privés :
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Remplacez `subnet-ID` par votre ID de sous-réseau réel.
# Génération de rapports de conformité CIS à partir des nœuds Kubernetes à l’aide de kubectl debug
Cette rubrique explique comment générer des rapports de conformité CIS (Center for Internet Security) pour les nœuds Amazon EKS à l’aide de la commande `kubectl debug`. Cette commande permet de créer temporairement un conteneur de débogage sur un nœud Kubernetes et d’exécuter les vérifications CIS à l’aide de l’outil `apiclient`. L’outil `apiclient` fait partie de l’OS Bottlerocket, utilisé par les nœuds du mode automatique EKS.
## Conditions préalables
Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Accès à un cluster Amazon EKS avec la commande `kubectl` configurér (la version installée doit être au minimum v1.32.0 ; tapez `kubectl version` pour vérifier).
+ Autorisations IAM appropriées pour déboguer les nœuds.
+ Profil valide autorisant les opérations de débogage (par exemple, `sysadmin`).
Pour plus d’informations sur l’utilisation de profils de débogage avec `kubectl`, consultez la section [Débogage d’un pod ou d’un nœud lors de l’application d’un profil](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) dans la documentation de Kubernetes.
## Procédure
1. Déterminez l'ID d' AWS instance du nœud sur lequel vous souhaitez exécuter le rapport. Utilisez la commande suivante pour afficher la liste des nœuds du cluster. L’ID d’instance se trouve dans la colonne du nom et commence par `i-` :
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Exécutez la commande ci-dessous en remplaçant `` par l’ID d’instance du nœud ciblé :
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Les composants de cette commande sont les suivants :
+ `kubectl debug node/` : crée une session de débogage sur l’ID d’instance EC2 spécifié.
+ `-it` : alloue un TTY (shell de ligne de commande) et maintient stdin ouvert pour une utilisation interactive.
+ `--profile=sysadmin` : utilise le profil `kubectl` spécifié avec les autorisations appropriées.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` : utilise `amazonlinux:2023` comme image de conteneur pour le débogage.
+ `bash -c "…"` : exécute les commandes suivantes dans un shell bash :
+ `yum install -q -y util-linux-core` : installe discrètement le package d’utilitaires requis.
+ `nsenter -t 1 -m` : exécute `nsenter` pour accéder à l’espace de noms du processus hôte (PID 1).
+ `apiclient report cis --level 1 --format text` : exécute le rapport de conformité CIS au niveau 1, avec un résultat au format texte.
1. Passez en revue le résultat au format texte du rapport.
## Interprétation du résultat
La commande génère un rapport au format texte indiquant l’état de conformité des différents contrôles CIS. Le résultat comprend :
+ Contrôle CIS individuel IDs
+ Description de chaque contrôle
+ État Réussite, Échec ou Ignoré pour chaque vérification
+ Détails expliquant les éventuels problèmes de conformité
Voici un exemple de résultat du rapport exécuté sur une instance de Bottlerocket :
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Pour plus d’informations sur le référentiel, consultez [Référentiel Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dans la documentation du Center for Internet Security (CIS).
## Ressources connexes
+ [Référence CIS Bottlerocket](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) dans la documentation du système d’exploitation Bottlerocket.
+ [Débogage des pods en cours d’exécution](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) dans la documentation de Kubernetes.
+ [Référentiel Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dans la documentation du Center for Internet Security (CIS)
# Activation du chiffrement des volumes EBS avec des clés KMS gérées par le client pour le mode automatique EKS
Vous pouvez chiffrer le volume racine éphémère des instances gérées par le mode automatique EKS à l’aide d’une clé KMS gérée par le client.
Le mode automatique Amazon EKS utilise des rôles liés à des services pour déléguer des autorisations à d'autres AWS services lors de la gestion de volumes EBS chiffrés pour vos clusters Kubernetes. Cette rubrique explique comment configurer la stratégie de clé requise lorsque vous spécifiez une clé gérée par le client pour le chiffrement Amazon EBS avec le mode automatique EKS.
Considérations :
+ Le mode automatique EKS n'a pas besoin d'autorisation supplémentaire pour utiliser la clé AWS gérée par défaut afin de protéger les volumes chiffrés de votre compte.
+ Cette rubrique traite du chiffrement des volumes éphémères, les volumes racines pour les instances. EC2 Pour plus d’informations sur le chiffrement des volumes de données utilisés pour les charges de travail, consultez [Création d’une classe de stockage](create-storage-class.md).
## Présentation de
Les clés AWS KMS suivantes peuvent être utilisées pour le chiffrement du volume racine Amazon EBS lorsque le mode automatique EKS lance des instances :
+ **Clé gérée par AWS ** : clé de chiffrement créée, détenue et gérée par Amazon EBS dans votre compte. Il s'agit de la clé de chiffrement par défaut d'un nouveau compte.
+ **Clé gérée par le client** : clé de chiffrement personnalisée que vous créez, détenez et gérez vous-même.
**Note**
La clé doit être symétrique. Amazon EBS ne prend pas en charge les clés asymétriques gérées par le client.
## Étape 1 : configurer la stratégie de clé
Vos clés KMS doivent inclure une stratégie de clé permettant au mode automatique EKS de lancer des instances avec des volumes Amazon EBS chiffrés à l’aide d’une clé gérée par le client.
Configurez votre stratégie de clé selon la structure suivante :
**Note**
Cette stratégie inclut uniquement les autorisations nécessaires au mode automatique EKS. La stratégie de clé peut nécessiter des autorisations supplémentaires si d’autres identités ont besoin d’utiliser la clé ou de gérer des autorisations.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Assurez-vous de le remplacer `` par votre numéro de AWS compte actuel.
Lors de la configuration de la stratégie de clé :
+ Le `ClusterServiceRole` doit disposer des autorisations IAM nécessaires pour utiliser la clé KMS lors des opérations de chiffrement
+ Cette `kms:GrantIsForAWSResource` condition garantit que les subventions ne peuvent être créées que pour AWS des services
## Étape 2 : Configuration à l' NodeClass aide de votre clé gérée par le client
Après avoir configuré la politique des clés, référencez la clé KMS dans votre NodeClass configuration du mode automatique EKS :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Remplacez les valeurs d’exemple par vos valeurs réelles :
+ ``avec votre AWS région
+ ``avec votre identifiant AWS de compte
+ `` par l’ID de votre clé KMS
Vous pouvez spécifier la clé KMS selon l’un des formats suivants :
+ ID de clé KMS : `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN de clé KMS : ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nom d’alias de clé : `alias/eks-auto-mode-key`
+ ARN d’alias de clé : ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Appliquez la NodeClass configuration à l'aide de kubectl :
```
kubectl apply -f nodeclass.yaml
```
## Ressources connexes
+ [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md)
+ Pour plus d'informations, consultez le guide du développeur du service de gestion des AWS clés
+ [Autorisations pour les AWS services dans les politiques clés](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Modification d’une stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Subventions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Mise à jour des contrôles d’organisation pour le mode automatique EKS
Certains contrôles organisationnels peuvent empêcher le mode automatique EKS de fonctionner correctement. Dans ce cas, vous devez mettre à jour ces contrôles afin de permettre au mode automatique EKS de disposer des autorisations nécessaires pour gérer les instances EC2 en votre nom.
Le mode automatique EKS utilise un rôle de service pour lancer les instances EC2 qui constituent les nœuds du mode automatique EKS. Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) créé dans votre compte, qu’un service peut assumer afin d’effectuer des actions en votre nom. Les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) s'appliquent toujours aux actions effectuées avec des rôles de service. Ainsi, une SCP peut bloquer certaines opérations du mode automatique EKS. L'occurrence la plus courante se produit lorsqu'un SCP est utilisé pour restreindre les Amazon Machine Images (AMIs) qui peuvent être lancées. Pour permettre au mode automatique EKS de fonctionner, modifiez le SCP afin de permettre le lancement à AMIs partir des comptes du mode automatique EKS.
Vous pouvez également utiliser la AMIs fonctionnalité [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) pour limiter la visibilité sur AMIs d'autres comptes. Si vous utilisez cette fonctionnalité, vous devez élargir les critères d’images afin d’inclure également les comptes d’AMI en mode automatique EKS dans les régions concernées.
## Exemple de SCP pour tout bloquer AMIs sauf le mode automatique EKS AMIs
L’exemple ci-dessous empêche l’appel de `ec2:RunInstances` sauf si l’AMI appartient au compte d’AMI en mode automatique EKS pour us-west-2 ou us-east-1.
**Note**
Il est important de **ne pas** utiliser la clé de contexte `ec2:Owner`. Amazon est propriétaire des comptes AMI en mode automatique EKS et la valeur de cette clé sera toujours `amazon`. La construction d'un SCP qui permet le `ec2:Owner` lancement AMIs s'il permet de lancer n'importe quelle AMI appartenant à Amazon, et pas seulement celles destinées au mode automatique d'EKS. `amazon` \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Comptes AMI en mode automatique EKS
AWS les comptes qui varient selon les régions hébergent le mode automatique EKS public AMIs.
| | |
| --- |--- |
| AWS Région | Compte |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Association d’une adresse IP publique
Lorsque l’appel `ec2:RunInstances` est effectué, la valeur du champ `AssociatePublicIpAddress` lors du lancement d’une instance est déterminée automatiquement en fonction du type de sous-réseau dans lequel l’instance est lancée. Une SCP peut être utilisée pour imposer que cette valeur soit explicitement définie sur « false », quel que soit le sous-réseau utilisé pour le lancement. Dans ce cas, le NodeClass champ `spec.advancedNetworking.associatePublicIPAddress` peut également être défini sur false pour satisfaire aux exigences du SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS
Vous pouvez contrôler le déploiement des charges de travail dans des [réserves de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). Le mode automatique EKS prend en charge les réserves de capacité à la demande (On-Demand Capacity Reservation, ODCR) EC2 ainsi que les blocs de capacité EC2 pour le ML.
**Astuce**
Par défaut, le mode automatique d'EKS peut être lancé en mode ouvert ODCRs par le biais d'une correspondance ouverte, mais il ne les priorise pas. Les instances lancées par le biais d'une correspondance ouverte sont étiquetées`karpenter.sh/capacity-type: on-demand`, non`reserved`. Pour hiérarchiser l'utilisation de l'ODCR et étiqueter les instances`karpenter.sh/capacity-type: reserved`, configurez `capacityReservationSelectorTerms` dans la NodeClass définition. Les blocs de capacité pour le ML nécessitent toujours `capacityReservationSelectorTerms` et ne sont pas utilisés automatiquement.
## Réservations de capacité à la demande EC2 () ODCRs
Les réserves de capacité à la demande (ODCR) EC2 permettent de réserver de la capacité de calcul pour vos instances Amazon EC2 dans une zone de disponibilité spécifique, pour toute durée souhaitée. Lorsque vous utilisez le mode automatique EKS, vous pouvez vouloir contrôler le déploiement de vos charges de travail Kubernetes sur ces instances réservées afin de maximiser l’utilisation de la capacité préachetée ou garantir l’accès des charges de travail critiques à des ressources dédiées.
Par défaut, le mode automatique EKS démarre automatiquement en mode ouvert ODCRs. Cependant, en configurant `capacityReservationSelectorTerms` sur un NodeClass, vous pouvez contrôler explicitement les charges de travail utilisées par ODCRs vos charges de travail. Les nœuds approvisionnés à l'aide de la configuration ODCRs auront `karpenter.sh/capacity-type: reserved` et seront priorisés par rapport à la demande et au spot. Une fois cette fonctionnalité activée, le mode automatique d'EKS n'utilisera plus automatiquement les options ouvertes. ODCRs Elles doivent être explicitement sélectionnées par un NodeClass, ce qui vous permet de contrôler précisément l'utilisation des réservations de capacité au sein de votre cluster.
**Avertissement**
Si vous effectuez une configuration `capacityReservationSelectorTerms` NodeClass dans un cluster, le mode automatique d'EKS n'utilisera plus automatiquement l'option open ODCRs pour *aucun* NodeClass élément du cluster.
### Exemple NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Cet exemple NodeClass illustre deux approches de sélection ODCRs. La première méthode fait référence directement à une ODCR spécifique à l’aide de son ID (`cr-56fac701cc1951b03`). La seconde méthode utilise la sélection basée sur les balises, le ciblage à l' ODCRs aide de la balise`Name: "targeted-odcr"`. Vous pouvez également éventuellement filtrer en fonction du AWS compte propriétaire de la réservation, ce qui est particulièrement utile dans les scénarios entre comptes ou lorsque vous travaillez avec des réservations à capacité partagée.
## Blocs de capacité EC2 pour ML
Les blocs de capacité pour ML vous permettent de réserver à l’avance des instances de calcul accéléré basées sur GPU pour exécuter des charges de travail de machine learning (ML) de courte durée. Les instances qui s'exécutent au sein d'un bloc de capacité sont automatiquement placées à proximité les unes des autres dans Amazon EC2 UltraClusters, pour une mise en réseau non bloquante à faible latence, à l'échelle du pétabit.
Pour plus d’informations sur les plateformes et les types d’instances pris en charge, consultez [Blocs de capacité ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur EC2.
Vous pouvez créer un mode automatique EKS NodeClass qui utilise un bloc de capacité pour le ML, similaire à un ODCR (décrit précédemment).
Les exemples de définitions suivants créent trois ressources :
1. A NodeClass qui fait référence à votre réservation Capacity Block
1. Un NodePool qui utilise le NodeClass et applique une teinte
1. Une spécification de pod tolérant cette balise de rejet et demandant des ressources GPU
### Exemple NodeClass
Cela NodeClass fait référence à un bloc de capacité spécifique pour ML par son ID de réservation. Vous pouvez obtenir cet ID dans la console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
### Exemple NodePool
Cela NodePool fait référence à la configuration importante `gpu` NodeClass et précise :
+ Il utilise **uniquement** la capacité réservée en définissant `karpenter.sh/capacity-type: reserved`
+ Il demande des familles d’instances GPU spécifiques adaptées aux charges de travail ML
+ Il applique une balise de rejet `nvidia.com/gpu` pour s’assurer que seules les charges de travail GPU sont planifiées sur ces nœuds
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
### Exemple de pod
Cet exemple de pod montre comment configurer une charge de travail afin qu’elle s’exécute sur vos nœuds de bloc de capacité :
+ Il utilise un **NodeSelector** pour cibler des types de GPU spécifiques (dans ce cas, le H200) GPUs
+ Il inclut une **tolérance à l'égard de** la `nvidia.com/gpu` souillure appliquée par le NodePool
+ Il **demande explicitement des ressources GPU** en utilisant le type de ressource `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Pour plus d'informations, consultez [pods](https://kubernetes.io/docs/concepts/workloads/pods/) dans la documentation Kubernetes.
### Ressources connexes
+ [Blocs de capacité pour ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur Amazon EC2
+ [Trouver et acheter des blocs de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) dans le Guide de l’utilisateur Amazon EC2
+ [Gérez les ressources informatiques pour les AI/ML charges de travail sur Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimisation et gestion des coûts des ressources GPU](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dans le Guide des bonnes pratiques EKS
# Déployer des nœuds EKS Auto Mode sur des Zones Locales
Le mode automatique EKS simplifie la gestion des clusters grâce au provisionnement automatique des nœuds. AWS Les zones locales étendent AWS l'infrastructure à des emplacements géographiques plus proches de vos utilisateurs finaux, réduisant ainsi le temps de latence pour les applications sensibles à la latence. Ce guide explique le processus de déploiement des nœuds EKS Auto Mode sur les Zones AWS Locales, ce qui vous permet d'exécuter des applications conteneurisées avec une latence plus faible pour les utilisateurs de zones géographiques spécifiques.
Ce guide explique également comment utiliser les contraintes et les tolérances de Kubernetes pour garantir que seules des charges de travail spécifiques s'exécutent sur les nœuds de votre zone locale, ce qui vous aide à contrôler les coûts et à optimiser l'utilisation des ressources.
## Conditions préalables
Avant de commencer à déployer des nœuds EKS Auto Mode sur des Zones Locales, assurez-vous que les conditions préalables suivantes sont réunies :
+ [Un cluster de mode automatique EKS existant](create-auto.md)
+ [Vous avez activé la zone locale dans votre compte AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Étape 1 : créer un sous-réseau de zone locale
La première étape du déploiement des nœuds du mode automatique EKS dans une zone locale consiste à créer un sous-réseau dans cette zone locale. Ce sous-réseau fournit l'infrastructure réseau pour vos nœuds et leur permet de communiquer avec le reste de votre VPC. Suivez les instructions de [création d'un sous-réseau de zone locale](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (dans le guide de l'utilisateur des zones AWS locales) pour créer un sous-réseau dans la zone locale de votre choix.
**Astuce**
Notez le nom du sous-réseau de votre zone locale.
## Étape 2 : Création NodeClass pour le sous-réseau de zone locale
Après avoir créé votre sous-réseau de zone locale, vous devez définir un NodeClass qui fait référence à ce sous-réseau. NodeClass Il s'agit d'une ressource personnalisée Kubernetes qui spécifie les attributs d'infrastructure de vos nœuds, notamment les sous-réseaux, les groupes de sécurité et les configurations de stockage à utiliser. Dans l'exemple ci-dessous, nous créons une « zone locale » qui cible un sous-réseau de zone locale en fonction de son NodeClass nom. Vous pouvez également utiliser l'ID de sous-réseau. Vous devrez adapter cette configuration pour cibler votre sous-réseau de zone locale.
Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Étape 3 : créer NodePool avec NodeClass et teindre
Une fois que vous êtes NodeClass configuré, vous devez maintenant créer un NodePool qui l'utilise NodeClass. A NodePool définit les caractéristiques de calcul de vos nœuds, y compris les types d'instances. Il NodePool utilise le NodeClass comme référence pour déterminer où lancer les instances.
Dans l'exemple ci-dessous, nous créons un NodePool qui fait référence à notre « zone locale ». NodeClass Nous ajoutons également une touche aux nœuds afin de garantir que seuls les pods présentant une tolérance correspondante puissent être planifiés sur ces nœuds de zone locale. Cela est particulièrement important pour les nœuds de zone locale, qui ont généralement des coûts plus élevés et ne doivent être utilisés que par des charges de travail bénéficiant spécifiquement de la réduction de la latence.
Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
L'odeur associée à la touche `aws.amazon.com/local-zone` et à l'effet `NoSchedule` garantit que les pods sans tolérance correspondante ne seront pas planifiés sur ces nœuds. Cela permet d'éviter que des charges de travail régulières ne s'exécutent accidentellement dans la zone locale, ce qui pourrait entraîner des coûts imprévus.
## Étape 4 : Déployer les charges de travail avec tolérance et affinité des nœuds
Pour un contrôle optimal du placement de la charge de travail sur les nœuds de zone locale, utilisez à la fois l'affinité taints/tolerations des nœuds et l'affinité des nœuds. Cette approche combinée offre les avantages suivants :
1. **Contrôle des coûts** : Cette altération garantit que seuls les pods soumis à des tolérances explicites peuvent utiliser des ressources de zone locale potentiellement coûteuses.
1. **Placement garanti** : l'affinité des nœuds garantit que vos applications sensibles à la latence s'exécutent exclusivement dans la zone locale, et non sur des nœuds de cluster ordinaires.
Voici un exemple de déploiement configuré pour s'exécuter spécifiquement sur les nœuds de zone locale :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Ce déploiement comporte deux configurations de planification clés :
1. La **tolérance** permet de planifier les capsules sur les nœuds présentant cette odeur`aws.amazon.com/local-zone`.
1. L'exigence d'**affinité des nœuds** garantit que ces pods ne s'exécuteront que sur les nœuds portant le label`node-type: local-zone`.
Ensemble, ils garantissent que votre application sensible à la latence ne s'exécute que sur les nœuds de zone locale, et que les applications ordinaires ne consomment pas les ressources de la zone locale, sauf si elles sont explicitement configurées pour le faire.
## Étape 5 : vérification à l'aide de AWS la console
Après avoir configuré vos déploiements NodeClass NodePool, et,,,,,,,,,,, vous devez vérifier que les nœuds sont approvisionnés dans votre zone locale comme prévu et que vos charges de travail s'exécutent sur eux. Vous pouvez utiliser la console AWS de gestion pour vérifier que les EC2 instances sont lancées dans le sous-réseau de zone locale approprié.
En outre, vous pouvez consulter la liste des nœuds Kubernetes en utilisant `kubectl get nodes -o wide` pour vérifier que les nœuds rejoignent votre cluster avec les étiquettes et les caractéristiques appropriées :
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Vous pouvez également vérifier que vos pods de charge de travail sont planifiés sur les nœuds de la zone locale :
```
kubectl get pods -o wide
```
Cette approche garantit que seules les charges de travail qui tolèrent spécifiquement l'empreinte de zone locale seront planifiées sur ces nœuds, ce qui vous permet de contrôler les coûts et d'utiliser au mieux les ressources de votre zone locale.
# Configuration des paramètres de sécurité avancés pour les nœuds
Cette rubrique explique comment configurer les paramètres de sécurité avancés pour les nœuds Amazon EKS Auto Mode à l'aide des `advancedSecurity` spécifications de votre classe de nœuds.
## Conditions préalables
Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Un cluster du mode automatique Amazon EKS. Pour de plus amples informations, veuillez consulter [Création d’un cluster avec le mode automatique Amazon EKS](create-auto.md).
+ `kubectl` installé et configuré. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
+ Compréhension de la configuration des classes de nœuds. Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Configuration des paramètres de sécurité avancés
Pour configurer les paramètres de sécurité avancés pour vos nœuds, définissez les `advancedSecurity` champs dans la spécification de votre classe de nœud :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Appliquez cette configuration :
```
kubectl apply -f nodeclass.yaml
```
Référencez cette classe de nœuds dans la configuration de votre pool de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Descriptions des champs
+ `fips`(booléen, facultatif) : lorsqu'il est défini sur`true`, approvisionne les nœuds à l'aide de modules cryptographiques validés AMIs par la norme FIPS 140-2. Ce paramètre sélectionne la conformité à la norme FIPS AMIs ; les clients sont responsables de la gestion de leurs exigences de conformité. Pour plus d'informations, consultez la section [Conformité à la AWS norme FIPS](https://aws.amazon.com/compliance/fips/). Valeur par défaut : `false`.
+ `kernelLockdown`(chaîne, facultatif) : contrôle le mode du module de sécurité du verrouillage du noyau. Valeurs acceptées :
+ `integrity`: bloque les méthodes permettant de remplacer la mémoire du noyau ou de modifier le code du noyau. Empêche le chargement de modules de noyau non signés.
+ `none`: désactive la protection contre le verrouillage du noyau.
Pour plus d'informations, consultez la [documentation sur le verrouillage du noyau Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Considérations
+ Les produits conformes à la norme FIPS AMIs sont disponibles dans les AWS régions de l'Est/Ouest des États-Unis et du AWS Canada AWS GovCloud (Centre-Ouest). Pour plus d'informations, consultez la section [Conformité à la AWS norme FIPS](https://aws.amazon.com/compliance/fips/).
+ Lors de l'utilisation`kernelLockdown: "integrity"`, assurez-vous que vos charges de travail ne nécessitent pas le chargement de modules de noyau non signés ou la modification de la mémoire du noyau.
## Ressources connexes
+ [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md)- Guide complet de configuration des classes de nœuds
+ [Create a Node Pool for EKS Auto Mode](create-node-pool.md)- Configuration du pool de nœuds
# Découvrez comment fonctionne le mode automatique EKS
Ce chapitre explique le fonctionnement des composants des clusters du mode automatique Amazon EKS.
**Topics**
+ [Informations sur les instances gérées par le mode automatique Amazon EKS](automode-learn-instances.md)
+ [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md)
+ [Informations sur le réseau VPC et l’équilibrage de charge dans le mode automatique EKS](auto-networking.md)
# Informations sur les instances gérées par le mode automatique Amazon EKS
Cette rubrique explique comment le mode automatique Amazon EKS gère les EC2 instances Amazon dans votre cluster EKS. Lorsque vous activez le mode automatique EKS, les ressources de calcul de votre cluster sont automatiquement provisionnées et gérées par EKS, ce qui modifie la façon dont vous interagissez avec les EC2 instances qui servent de nœuds dans votre cluster.
Il est essentiel de comprendre comment le mode automatique Amazon EKS gère les instances afin de bien planifier votre stratégie de déploiement des charges de travail et vos procédures opérationnelles. Contrairement aux EC2 instances traditionnelles ou aux groupes de nœuds gérés, ces instances suivent un modèle de cycle de vie différent dans lequel EKS assume la responsabilité de nombreux aspects opérationnels, tout en limitant certains types d'accès et de personnalisation.
Le mode automatique Amazon EKS automatise les tâches de routine pour créer de nouvelles EC2 instances et les attache en tant que nœuds à votre cluster EKS. Le mode automatique EKS détecte lorsqu'une charge de travail ne peut pas s'adapter aux nœuds existants et crée une nouvelle EC2 instance.
Le mode automatique Amazon EKS est chargé de créer, de supprimer et d'appliquer des correctifs aux EC2 instances. Vous restez responsable des conteneurs et des pods déployés sur ces instances.
EC2 Les instances créées par le mode automatique d'EKS sont différentes des autres EC2 instances, ce sont des instances gérées. Ces instances gérées sont détenues par EKS et présentent des restrictions supplémentaires. Vous ne pouvez ni accéder directement aux instances gérées par le mode automatique EKS, ni y installer de logiciels.
AWS suggère d'exécuter le mode automatique EKS ou Karpenter autogéré. Vous pouvez installer les deux durant une phase de migration ou dans une configuration avancée. Si vous avez installé les deux, configurez vos pools de nœuds afin que les charges de travail soient associées soit à Karpenter, soit au mode automatique EKS.
Pour plus d'informations, consultez les [instances EC2 gérées par Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) dans le guide de EC2 l'utilisateur Amazon.
## Tableau comparatif
| EC2 Instance standard | Instance gérée par le mode automatique EKS |
| --- | --- |
| Vous êtes responsable de l’application des correctifs et de la mise à jour de l’instance. | AWS corrige et met à jour automatiquement l'instance. |
| EKS n’est pas responsable des logiciels installés sur l’instance. | EKS est responsable de certains logiciels sur l’instance, tels que `kubelet`, le moteur d’exécution des conteneurs et le système d’exploitation. |
| Vous pouvez supprimer l' EC2 instance à l'aide de l' EC2 API. | EKS détermine le nombre d’instances déployées dans votre compte. Si vous supprimez une charge de travail, EKS réduira le nombre d’instances dans votre compte. |
| Vous pouvez utiliser SSH pour accéder à l' EC2 instance. | Vous pouvez déployer des pods et des conteneurs sur l’instance gérée. |
| Vous déterminez le système d’exploitation et l’image (AMI). | AWS détermine le système d'exploitation et l'image. |
| Vous pouvez déployer des charges de travail reposant sur les fonctionnalités de Windows ou d’Ubuntu. | Vous pouvez également déployer des conteneurs basés sur Linux, sans dépendances particulières au système d’exploitation. |
| Vous déterminez le type et la famille d’instance à lancer. | AWS détermine le type et la famille d'instances à lancer. Vous pouvez utiliser un groupe de nœuds pour limiter les types d’instances parmi lesquels le mode automatique EKS peut sélectionner. |
Les fonctionnalités suivantes fonctionnent à la fois pour les instances gérées et les EC2 instances standard :
+ Vous pouvez afficher l'instance dans la AWS console.
+ Vous pouvez utiliser le stockage d’instance comme stockage éphémère pour les charges de travail.
### Support AMI
Avec le mode automatique EKS, AWS détermine l'image (AMI) utilisée pour vos nœuds de calcul. AWS surveille le déploiement des nouvelles versions de l'AMI en mode automatique d'EKS. Si vous rencontrez des problèmes de charge de travail liés à une version d’AMI, créez un cas de support. Pour plus d'informations, consultez les sections [Création de dossiers de support et gestion de dossiers](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) dans le Guide de l'utilisateur du AWS support.
En général, EKS publie chaque semaine une nouvelle AMI contenant des correctifs CVE et de sécurité.
## Référence des instances prises en charge par le mode automatique EKS
Le mode automatique EKS crée uniquement des instances de types pris en charge et répondant à une taille minimale requise.
Le mode automatique EKS prend en charge les types d’instances suivants :
| Family | Types d’instances |
| --- | --- |
| Optimisées pour le calcul (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c5ad, c5n, 4 |
| Usage général (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m5, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Optimisées pour la mémoire (R) | r8i, r8i-flex, r8gn, r8gb, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5dn, r5b, r5b, 5ad, 5d, r4 |
| Capacité extensible (T) | t4g, t3, t3a, t2 |
| Mémoire élevée (Z/X) | z1d, x8g, x2gd |
| Optimisées pour le stockage (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| Informatique accélérée (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| Calcul haute performance (X2) | x2iezn, x2iedn, x2idn |
En outre, le mode automatique d'EKS ne créera que EC2 des instances répondant aux exigences suivantes :
+ Plus d’un processeur
+ Taille d’instance différente de nano, micro ou petite
Pour plus d'informations, consultez les [conventions de dénomination des types d' EC2 instances Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Service des métadonnées d’instance
+ Le mode automatique EKS est IMDSv2 appliqué avec une limite de saut de 1 par défaut, conformément aux meilleures pratiques AWS de sécurité.
+ Cette configuration par défaut ne peut pas être modifiée en mode automatique.
+ Pour les modules complémentaires qui nécessitent généralement un accès IMDS, fournissez des paramètres (tels que AWS la région) lors de l'installation afin d'éviter les recherches IMDS. Pour de plus amples informations, veuillez consulter [Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS](kubernetes-field-management.md).
+ Si un pod doit absolument accéder à IMDS lorsqu’il s’exécute en mode automatique, il doit être configuré pour s’exécuter avec `hostNetwork: true`. Cela permet au pod d’accéder directement au service de métadonnées de l’instance.
+ Évaluez toujours les implications de sécurité avant d’autoriser un pod à accéder aux métadonnées de l’instance.
Pour plus d'informations sur le service de métadonnées d' EC2 instance Amazon (IMDS), consultez [Configurer les options du service de métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) dans le *guide de l' EC2 utilisateur Amazon*.
## Considérations
+ Si le stockage éphémère configuré dans le NodeClass est plus petit que le stockage NVMe local de l'instance, le mode automatique d'EKS élimine le besoin de configuration manuelle en effectuant automatiquement les actions suivantes :
+ Utilise un volume de données Amazon EBS plus petit (20 Gio) afin de réduire les coûts.
+ Formate et configure le stockage NVMe local pour une utilisation éphémère des données. Cela inclut la configuration d'une matrice RAID 0 s'il existe plusieurs NVMe disques.
+ Lorsque la NVMe capacité locale `ephemeralStorage.size` est égale ou supérieure, les actions suivantes se produisent :
+ Le mode automatique ignore le petit volume EBS.
+ Le NVMe ou les disques sont exposés directement à votre charge de travail.
+ Le mode automatique d'Amazon EKS ne prend pas en charge les actions suivantes du service d'injection de AWS défauts :
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Le mode automatique d'Amazon EKS prend en charge les actions du Pod EKS du service d'injection de AWS défauts. Pour plus d'informations, consultez les sections [Gestion des expériences du service d'injection de défauts](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) et [Utilisation des actions AWS FIS aws:eks:pod](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) dans le guide de l' AWS utilisateur de Resilience Hub.
+ Vous n’avez pas besoin d’installer le `Neuron Device Plugin` sur les nœuds du mode automatique EKS.
Cependant, si votre cluster contient d’autres types de nœuds, vous devez configurer le plug-in Neuron Device pour qu’il ne s’exécute pas sur les nœuds du mode automatique. Pour de plus amples informations, veuillez consulter [Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md).
# Informations sur les identités et l’accès dans le mode automatique EKS
Cette rubrique décrit les rôles et autorisations de gestion des identités et des accès (IAM) requis pour utiliser le mode automatique EKS. Le mode automatique EKS utilise deux rôles IAM principaux : un rôle IAM de cluster et un rôle IAM de nœud. Ces rôles fonctionnent conjointement avec l’identité du pod EKS et les entrées d’accès EKS pour assurer une gestion complète des accès aux clusters EKS.
Lorsque vous configurez le mode automatique d'EKS, vous devez configurer ces rôles IAM avec des autorisations spécifiques qui permettent aux AWS services d'interagir avec les ressources de votre cluster. Ces autorisations couvrent la gestion des ressources de calcul, des volumes de stockage, des équilibreurs de charge et des composants réseau. La compréhension de la configuration de ces rôles est essentielle pour garantir le bon fonctionnement et la sécurité du cluster.
En mode automatique d'EKS, les rôles AWS IAM sont automatiquement mappés aux autorisations Kubernetes via les entrées d'accès EKS, ce qui élimine le besoin de configuration manuelle ou de liaisons personnalisées. `aws-auth` ConfigMaps Lorsque vous créez un nouveau cluster en mode automatique, EKS crée automatiquement les autorisations Kubernetes correspondantes à l'aide des entrées Access, garantissant ainsi que les AWS services et les composants du cluster disposent des niveaux d'accès appropriés au sein du système d'autorisation AWS et du système d'autorisation Kubernetes. Cette intégration automatisée réduit la complexité de la configuration et aide à prévenir les problèmes d’autorisations fréquemment rencontrés lors de la gestion des clusters EKS.
## Rôle IAM du cluster
Le rôle Cluster IAM est un rôle AWS Identity and Access Management (IAM) utilisé par Amazon EKS pour gérer les autorisations pour les clusters Kubernetes. Ce rôle accorde à Amazon EKS les autorisations nécessaires pour interagir avec d'autres AWS services au nom de votre cluster et est automatiquement configuré avec des autorisations Kubernetes à l'aide des entrées d'accès EKS.
+ Vous devez associer des politiques AWS IAM à ce rôle.
+ Le mode automatique EKS attache automatiquement les autorisations Kubernetes à ce rôle via les entrées d’accès EKS.
+ Avec le mode automatique d'EKS, AWS suggère de créer un seul rôle IAM de cluster par AWS compte.
+ AWS suggère de nommer ce rôle`AmazonEKSAutoClusterRole`.
+ Ce rôle nécessite des autorisations pour plusieurs AWS services afin de gérer les ressources, notamment les volumes EBS, les Elastic Load Balancers et EC2 les instances.
+ La configuration suggérée pour ce rôle inclut plusieurs politiques IAM AWS gérées, liées aux différentes fonctionnalités du mode automatique d'EKS.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
Pour plus d'informations sur le rôle IAM du cluster et les politiques IAM AWS gérées, voir :
+ [AWS politiques gérées pour Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md)
Pour plus d’informations sur les autorisations d’accès Kubernetes, consultez :
+ [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md)
## Rôle IAM de nœud
Le rôle Node IAM est un rôle AWS Identity and Access Management (IAM) utilisé par Amazon EKS pour gérer les autorisations des nœuds de travail dans les clusters Kubernetes. Ce rôle accorde aux EC2 instances exécutées en tant que nœuds Kubernetes les autorisations nécessaires pour interagir avec les AWS services et les ressources, et est automatiquement configuré avec les autorisations RBAC Kubernetes à l'aide des entrées d'accès EKS.
+ Vous devez associer des politiques AWS IAM à ce rôle.
+ Le mode automatique EKS attache automatiquement ces autorisations Kubernetes RBAC à ce rôle via les entrées d’accès EKS.
+ AWS suggère de nommer ce rôle`AmazonEKSAutoNodeRole`.
+ Avec le mode automatique d'EKS, AWS suggère de créer un rôle IAM de nœud unique par AWS compte.
+ Ce rôle dispose d’autorisations limitées. Les principales autorisations incluent la possibilité d’assumer un rôle d’identité du pod et l’autorisation d’extraire des images depuis ECR.
+ AWS suggère les politiques IAM AWS gérées suivantes :
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
Pour plus d'informations sur le rôle IAM du cluster et les politiques IAM AWS gérées, voir :
+ [AWS politiques gérées pour Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Rôle IAM de nœud Amazon EKS](create-node-role.md)
Pour plus d’informations sur les autorisations d’accès Kubernetes, consultez :
+ [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md)
## Rôle lié à un service
Amazon EKS utilise un rôle lié à un service (Service-Linked Role, SLR) pour certaines opérations. Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom.
AWS crée et configure automatiquement le reflex. Vous ne pouvez supprimer un SLR qu’après avoir supprimé les ressources associées. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
La politique SLR accorde à Amazon EKS l'autorisation d'observer et de supprimer les principaux composants de l'infrastructure : EC2 ressources (instances, interfaces réseau, groupes de sécurité), ressources ELB (équilibreurs de charge, groupes cibles), CloudWatch fonctionnalités (journalisation et métriques) et rôles IAM avec le préfixe « eks ». Il permet également la mise en réseau de terminaux privés via l'association de VPC/hosted zones et inclut des autorisations pour la EventBridge surveillance et le nettoyage des ressources étiquetées EKS.
Pour en savoir plus, consultez :
+ [AWS politique gérée : Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## AWS Balises personnalisées pour les ressources EKS Auto
Par défaut, les politiques gérées liées au mode automatique d'EKS n'autorisent pas l'application de balises définies par l'utilisateur aux AWS ressources provisionnées en mode automatique. Si vous souhaitez appliquer des balises définies par l'utilisateur aux AWS ressources, vous devez attribuer des autorisations supplémentaires au rôle IAM du cluster avec des autorisations suffisantes pour créer et modifier des balises sur les AWS ressources. Voici un exemple de politique qui autorisera un accès illimité au balisage :
### Voir un exemple de stratégie de balisage personnalisée
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Référence de stratégie d’accès
Pour plus d’informations sur les autorisations Kubernetes utilisées par le mode automatique EKS, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md).
# Informations sur le réseau VPC et l’équilibrage de charge dans le mode automatique EKS
Cette rubrique explique comment configurer les fonctionnalités de réseau du cloud privé virtuel (VPC) et d’équilibrage de charge dans le mode automatique EKS. Même si le mode automatique EKS gère automatiquement la plupart des composants réseau, vous pouvez tout de même personnaliser certains aspects de la configuration réseau de votre cluster à l’aide de ressources `NodeClass` et d’annotations d’équilibreur de charge.
Lorsque vous utilisez le mode automatique EKS, il AWS gère la configuration de l'interface réseau de conteneurs VPC (CNI) et le provisionnement de l'équilibreur de charge pour votre cluster. Vous pouvez influencer le comportement du réseau en définissant des objets `NodeClass` et en appliquant des annotations spécifiques à vos ressources Service et Ingress, tout en conservant le modèle opérationnel automatisé fourni par le mode automatique EKS.
## Fonctionnalité de réseau
Le mode automatique EKS introduit une nouvelle fonctionnalité de réseau qui gère le réseau des nœuds et des pods. Vous pouvez la configurer en créant un objet Kubernetes `NodeClass`.
Les options de configuration du AWS VPC CNI précédent ne s'appliqueront pas au mode automatique EKS.
### Configuration du réseau avec une `NodeClass`
La ressource `NodeClass` dans le mode automatique EKS permet de personnaliser certains aspects de la fonctionnalité de réseau. Grâce à `NodeClass`, vous pouvez définir la sélection des groupes de sécurité, contrôler le placement des nœuds dans les sous-réseaux du VPC ,définir des politiques SNAT, configurer des politiques réseau et activer la journalisation des événements réseau. Cette approche maintient le modèle opérationnel automatisé du mode automatique EKS, tout en offrant une flexibilité de personnalisation du réseau.
Vous pouvez utiliser une `NodeClass` pour :
+ Sélectionner un groupe de sécurité pour les nœuds
+ Contrôler la manière dont les nœuds sont placés sur les sous-réseaux VPC
+ Définisser la politique SNAT du nœud sur `random` ou `disabled`
+ Activer les politiques *réseau* Kubernetes, notamment :
+ Définir la politique réseau sur Refuser ou Autoriser par défaut
+ Activer la journalisation des événements réseau dans un fichier.
+ Isoler le trafic des pods du trafic des nœuds en attachant des pods à différents sous-réseaux.
Découvrez comment [créer un Amazon EKS NodeClass](create-node-class.md).
### Considérations
Le mode automatique EKS prend en charge :
+ Politiques réseau EKS.
+ Les options `HostPort` et `HostNetwork` pour les pods Kubernetes.
+ Nœuds et pods dans des sous-réseaux publics ou privés.
+ Mise en cache des requêtes DNS sur le nœud.
Le mode automatique EKS ne prend **pas** en charge :
+ Groupes de sécurité par pod (SGPP). Pour appliquer des groupes de sécurité distincts au trafic du pod en mode automatique, utilisez `podSecurityGroupSelectorTerms` `NodeClass` plutôt le. Pour de plus amples informations, veuillez consulter [Sous-réseaux et groupes de sécurité distincts pour les pods](create-node-class.md#pod-subnet-selector).
+ Réseau personnalisé dans la `ENIConfig`. Possibilité de placer des pods dans plusieurs sous-réseaux ou de les isoler complètement du trafic des nœuds via [Sous-réseaux et groupes de sécurité distincts pour les pods](create-node-class.md#pod-subnet-selector).
+ Configurations Warm IP, Warm Prefix et Warm ENI.
+ Configuration minimale des cibles IP.
+ Autres configurations prises en charge par le AWS VPC CNI open source.
+ Configurations de politique réseau telles que la personnalisation du temporisateur Conntrack (la valeur par défaut est 300 s).
+ Exportation des journaux d'événements réseau vers CloudWatch.
### Gestion des ressources réseau
Le mode automatique EKS gère les préfixes, l'adressage IP et la gestion de l'interface réseau en surveillant les NodeClass ressources pour les configurations réseau. Le service exécute automatiquement plusieurs opérations essentielles :
**Délégation de préfixes**
Le mode automatique d'EKS utilise par défaut la délégation de préfixes (préfixes /28) pour la mise en réseau des pods et gère un pool prédéfini de ressources IP qui évolue en fonction du nombre de pods planifiés. Lorsque la fragmentation du sous-réseau du pod est détectée, le mode automatique provisionne les adresses IP secondaires (/32). Grâce à cet algorithme de mise en réseau de pods par défaut, le mode automatique calcule le nombre maximum de pods par nœud en fonction du nombre de ENIs pods IPs pris en charge par type d'instance (en supposant le pire des cas de fragmentation). Pour plus d'informations sur Max ENIs et IPs par type d'instance, consultez la section [Nombre maximal d'adresses IP par interface réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) dans le guide de l'utilisateur EC2. Les familles d'instances de nouvelle génération (Nitro v6 et versions ultérieures) ont généralement augmenté ENIs et IPs par type d'instance, et le mode automatique ajuste le calcul du nombre maximum de pods en conséquence.
Pour les IPv6 clusters, seule la délégation de préfixes est utilisée, et le mode automatique utilise toujours une limite maximale de 110 pods par nœud.
**Gestion de la stabilisation**
Le service implémente un pool de recharge pour les préfixes ou IPv4 les adresses secondaires qui ne sont plus utilisés. Une fois le temps de stabilisation expiré, ces ressources sont renvoyées au VPC. Cependant, si des pods réutilisent ces ressources pendant le temps de stabilisation, elles sont restaurées à partir du groupe de stabilisation.
**IPv6 Support**
Pour les IPv6 clusters, le mode automatique EKS fournit un `/80` IPv6 préfixe par nœud sur l'interface réseau principale. Lors de l'utilisation`podSubnetSelectorTerms`, le préfixe est plutôt alloué sur une interface réseau secondaire dans le sous-réseau du pod.
Le service assure également une gestion et une récupération de mémoire appropriées de toutes les interfaces réseau.
## Équilibrage de charge
Vous configurez les équilibreurs de charge AWS élastiques fournis par EKS Auto Mode à l'aide d'annotations sur les ressources de service et d'entrée.
Pour plus d’informations, consultez [Créez un IngressClass pour configurer un Application Load Balancer](auto-configure-alb.md) ou [Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer](auto-configure-nlb.md).
### Considérations relatives à l’équilibrage de charge avec le mode automatique EKS
+ Le mode de ciblage par défaut est le mode IP, et non le mode instance.
+ Le mode automatique EKS prend uniquement en charge le mode groupe de sécurité pour les équilibreurs de charge réseau Network Load Balancer.
+ AWS ne prend pas en charge la migration des équilibreurs de charge depuis le contrôleur d'équilibrage de AWS charge autogéré vers le mode automatique EKS.
+ Le champ `networking.ingress.ipBlock` dans la spécification `TargetGroupBinding` n’est pas pris en charge.
+ Si vos composants master utilisent des groupes de sécurité personnalisés (et non ceux suivant le modèle de nommage `eks-cluster-sg- `), le rôle de votre cluster doit disposer d’autorisations IAM supplémentaires. La politique gérée par EKS par défaut permet uniquement à EKS de modifier les groupes de sécurité nommés `eks-cluster-sg-`. Sans l'autorisation de modifier vos groupes de sécurité personnalisés, EKS ne peut pas ajouter les règles d'entrée requises permettant au ALB/NLB trafic d'atteindre vos modules.
#### Considérations relatives au CoreDNS
Le mode automatique EKS n'utilise pas le déploiement CoreDNS traditionnel pour fournir une résolution DNS au sein du cluster. Au lieu de cela, les nœuds en mode automatique utilisent CoreDNS s'exécutant en tant que service système directement sur chaque nœud. Si vous passez d'un cluster traditionnel en mode automatique, vous pouvez supprimer le déploiement CoreDNS de votre cluster une fois que vos charges de travail ont été déplacées vers les nœuds du mode automatique.
**Important**
Si vous prévoyez de gérer un cluster avec des nœuds en mode automatique et en mode non automatique, vous devez conserver le déploiement CoreDNS. Les nœuds non en mode automatique s'appuient sur les modules CoreDNS traditionnels pour la résolution DNS, car ils ne peuvent pas accéder au service DNS au niveau des nœuds fourni par le mode automatique.
# Observabilité pour le mode automatique EKS
Consultez ce chapitre pour en savoir plus sur les options d'observabilité pour les clusters en mode automatique Amazon EKS.
**Topics**
+ [Journaux AWS de composants gérés par accès pour EKS Auto](auto-managed-component-logs.md)
# Journaux AWS de composants gérés par accès pour EKS Auto
Vous pouvez accéder aux journaux des composants AWS gérés depuis le mode automatique d'EKS pour améliorer l'observabilité des opérations de votre cluster. Le mode automatique EKS prend en charge les journaux pour les sources suivantes :
+ Mise à l'échelle automatique des ordinateurs - Karpenter
+ Stockage par blocs - EBS CSI
+ Équilibrage de AWS charge - Load Balancer Controller
+ Mise en réseau des pods - Gestion des adresses IP VPC CNI
Les journaux peuvent être livrés à la [destination de livraison](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) de votre choix.
Lorsque vous créez un cluster EKS Auto, vous avez la possibilité d'activer la journalisation du plan de contrôle (serveur API, audit, authentificateur, gestionnaire de contrôleurs, planificateur). Les journaux des composants gérés par EKS Auto (tels que le calcul, le stockage par blocs, l'équilibrage de charge et l'IPAM) nécessitent une configuration séparée via la livraison des journaux.
## Configuration de la diffusion des journaux
Pour configurer la livraison des journaux des composants AWS gérés pour votre cluster EKS Auto Mode, utilisez l'API Amazon CloudWatch Logs. Pour obtenir des instructions de configuration détaillées, consultez la section [Activation de la journalisation à partir AWS des services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) dans le guide de l'utilisateur Amazon CloudWatch Logs. Chaque fonctionnalité du mode automatique peut être configurée en tant que source de diffusion individuelle de CloudWatch Vended Logs, ce qui vous permet de sélectionner les journaux auxquels vous souhaitez avoir accès.
Le mode automatique EKS prend en charge les types de journaux suivants :
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **MODE AUTOMATIQUE BLOQUE LES JOURNAUX DE STOCKAGE**
+ **LOAD\$1BALANCING\$1LOAD\$1LOGS EN MODE AUTOMATIQUE**
+ **MODE AUTOMATIQUE IPAM LOGS**
### Utilisation d'Amazon CloudWatch APIs
La configuration de la journalisation nécessite trois étapes :
1. Créez une source de diffusion pour la fonctionnalité à l'aide de l' CloudWatch PutDeliverySource API
1. Créez une destination de livraison à l'aide de PutDeliveryDestination
1. Créez une livraison pour connecter la source et la destination à l'aide de CreateDelivery
Vous pouvez configurer les détails de la destination des journaux du mode automatique à l'aide de l' deliveryDestinationConfiguration objet de l' CloudWatch PutDeliveryDestination API. Il utilise l'ARN d'un groupe de CloudWatch logs, d'un bucket S3 ou d'un flux de diffusion Kinesis Data Firehose.
Vous pouvez configurer une seule fonctionnalité du mode automatique (source de livraison) pour envoyer des journaux vers plusieurs destinations en créant plusieurs livraisons. Vous pouvez également créer plusieurs livraisons pour configurer plusieurs sources de livraison afin d'envoyer des journaux vers la même destination de livraison.
### Autorisations IAM
En fonction de la destination sélectionnée, vous devrez peut-être configurer des politiques ou des rôles IAM pour le groupe de CloudWatch journaux, le compartiment S3 et Kinesis Data Firehose afin de garantir la transmission réussie des journaux. En outre, si vous envoyez des journaux entre AWS comptes, vous devez utiliser l' PutDeliveryDestinationPolicy API pour configurer une politique IAM autorisant la livraison à destination. Consultez la [documentation sur les autorisations de CloudWatch Vended Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs) pour plus d'informations.
## Afficher vos journaux
Une fois la livraison des journaux configurée, les journaux seront livrés à la destination que vous avez spécifiée. La méthode d'accès aux journaux dépend du type de destination que vous avez choisi :
+ **CloudWatch Journaux** : affichez les journaux dans la console CloudWatch Logs, utilisez les commandes AWS CLI ou effectuez des requêtes avec CloudWatch Logs Insights
+ **Amazon S3** : accédez aux journaux sous forme d'objets dans votre compartiment S3 via la console S3, la AWS CLI ou des outils d'analyse tels qu'Amazon Athena
+ **Amazon Data Firehose** - Les journaux sont diffusés vers votre cible Firehose configurée (telle que S3, Service, Redshift OpenSearch , etc.)
## Tarification
CloudWatch Les frais de livraison et de stockage des journaux s'appliquent en fonction de la destination de livraison que vous avez choisie. CloudWatch Vended Logs permet une livraison fiable et sécurisée des journaux avec AWS authentification et autorisation intégrées à un prix réduit par rapport aux CloudWatch journaux standard. Consultez la [section Vended Logs de la page de CloudWatch tarification](https://aws.amazon.com/cloudwatch/pricing/) pour plus de détails.
### Ressources connexes
+ [Journalisation de plan de contrôle d'Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) dans la référence de l'API CloudWatch Logs
+ [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) dans la référence de l'API CloudWatch Logs
+ [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) dans la référence de l'API CloudWatch Logs
# Résolution des problèmes avec le mode automatique EKS
Avec le mode automatique d'EKS, vous AWS assumez une plus grande responsabilité pour les instances EC2 de votre AWS compte. EKS assume la responsabilité de l’exécution de conteneur sur les nœuds, du système d’exploitation sur les nœuds et de certains contrôleurs. Cela inclut un contrôleur de stockage par blocs, un contrôleur d’équilibrage de charge et un contrôleur de calcul.
Vous devez utiliser AWS Kubernetes APIs pour dépanner les nœuds. Vous pouvez effectuer les actions suivantes :
+ Utilisez une ressource `NodeDiagnostic` Kubernetes pour extraire les journaux des nœuds à l’aide de [Agent de surveillance des nœuds](#auto-node-monitoring-agent). Pour les étapes détaillées, consultez [Extraction des journaux d’un nœud géré à l’aide de kubectl et S3](auto-get-logs.md).
+ Utilisez la commande AWS EC2 CLI `get-console-output` pour récupérer la sortie de console à partir des nœuds. Pour les étapes détaillées, consultez [Obtenez la sortie de console d'une instance gérée EC2 à l'aide de la CLI AWS EC2](#auto-node-console).
+ Utilisez les *conteneurs de débogage* Kubernetes pour extraire les journaux des nœuds. Pour les étapes détaillées, consultez [Extraction des journaux des nœuds à l’aide des *conteneurs de débogage* et de la CLI `kubectl`](#auto-node-debug-logs).
**Note**
Le mode automatique EKS utilise des instances gérées EC2. Vous ne pouvez pas accéder directement à ces instances EC2, y compris par SSH.
Vous pouvez rencontrer les problèmes suivants, qui disposent de solutions spécifiques aux composants du mode automatique EKS :
+ Pods bloqués dans l’état `Pending`, qui ne sont pas planifiés sur les nœuds du mode automatique. Pour les solutions, consultez [Résolution des problèmes liés à l’échec de la planification des pods sur un nœud du mode automatique](#auto-troubleshoot-schedule).
+ Instances gérées EC2 qui ne rejoignent pas le cluster en tant que nœuds Kubernetes. Pour les solutions, consultez [Résolution problèmes liés au fait qu’un nœud ne rejoint pas le cluster](#auto-troubleshoot-join).
+ Erreurs et problèmes liés aux `NodePools`, `PersistentVolumes` et `Services` utilisant les contrôleurs intégrés au mode automatique EKS. Pour les solutions, consultez [Résolution des problèmes liés aux contrôleurs inclus dans le mode automatique](#auto-troubleshoot-controllers).
+ La sécurité renforcée des pods empêche le partage de volumes entre pods. Pour les solutions, consultez [Partage des volumes entre les pods](#auto-troubleshoot-share-pod-volumes).
Vous pouvez utiliser les méthodes suivantes pour diagnostiquer et résoudre les problèmes liés aux composants du mode automatique EKS :
+ [Obtenez la sortie de console d'une instance gérée EC2 à l'aide de la CLI AWS EC2](#auto-node-console)
+ [Extraction des journaux des nœuds à l’aide des *conteneurs de débogage* et de la CLI `kubectl`](#auto-node-debug-logs)
+ [Afficher les ressources associées au mode automatique EKS dans la AWS console](#auto-node-ec2-web)
+ [Afficher les erreurs IAM dans votre AWS compte](#auto-node-iam)
+ [Détection des problèmes de connectivité des nœuds avec l’outil `VPC Reachability Analyzer`](#auto-node-reachability)
## Agent de surveillance des nœuds
Le mode automatique EKS inclut l’agent de surveillance des nœuds Amazon EKS. Vous pouvez utiliser cet agent pour consulter les informations de diagnostic et de débogage relatives aux nœuds. L’agent de surveillance des nœuds publie les `events` Kubernetes et les `conditions` du nœud. Pour de plus amples informations, veuillez consulter [Détectez les problèmes de santé des nœuds et activez la réparation automatique des nœuds](node-health.md).
## Obtenez la sortie de console d'une instance gérée EC2 à l'aide de la CLI AWS EC2
Cette procédure permet de résoudre les problèmes survenant au démarrage ou au niveau du noyau.
Tout d’abord, déterminez l’ID de l’instance EC2 associée à votre charge de travail. Ensuite, utilisez la AWS CLI pour récupérer la sortie de la console.
1. Confirmez que `kubectl` est installé et connecté à votre cluster
1. (Facultatif) Utilisez le nom d’un déploiement Kubernetes pour afficher la liste des pods associés.
```
kubectl get pods -l app=
```
1. Utilisez le nom du pod Kubernetes pour déterminer l’ID de l’instance EC2 du nœud associé.
```
kubectl get pod -o wide
```
1. Utilisez l’ID de l’instance EC2 pour extraire le résultat de la console.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Extraction des journaux des nœuds à l’aide des *conteneurs de débogage* et de la CLI `kubectl`
La méthode recommandée pour extraire les journaux d’un nœud du mode automatique EKS consiste à utiliser la ressource `NodeDiagnostic`. Pour les étapes, consultez [Extraction des journaux d’un nœud géré à l’aide de kubectl et S3](auto-get-logs.md).
Cependant, vous pouvez également diffuser les journaux en temps réel à partir d’une instance en utilisant la commande `kubectl debug node`. Cette commande lance un nouveau pod sur le nœud à déboguer, avec lequel vous pouvez ensuite interagir.
1. Lancez un conteneur de débogage. La commande suivante utilise `i-01234567890123456` pour l’ID d’instance du nœud, `-it` pour allouer un `tty` et attacher `stdin` pour un usage interactif, et le profil `sysadmin` défini dans le fichier kubeconfig.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
L'exemple qui suit illustre un résultat.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. Depuis le shell, vous pouvez maintenant installer le `util-linux-core` qui fournit la commande `nsenter`. Utilisez `nsenter` pour entrer dans l’espace de noms de montage du PID 1 (`init`) sur l’hôte, puis exécutez la commande `journalctl` pour diffuser les journaux depuis `kubelet` :
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Pour des raisons de sécurité, l’image de conteneur Amazon Linux n’installe pas de nombreux binaires par défaut. Vous pouvez utiliser la commande `yum whatprovides` pour identifier le package à installer afin d’obtenir le binaire correspondant.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Afficher les ressources associées au mode automatique EKS dans la AWS console
Vous pouvez utiliser la AWS console pour afficher l'état des ressources associées à votre cluster EKS Auto Mode.
+ [Volumes EBS](https://console.aws.amazon.com/ec2/home#Volumes)
+ Affichage des volumes du mode automatique EKS en recherchant la clé de balise `eks:eks-cluster-name`
+ [Équilibreurs de charge](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Affichage des équilibreurs de charge du mode automatique EKS en recherchant la clé de balise `eks:eks-cluster-name`
+ [Instances EC2](https://console.aws.amazon.com/ec2/home#Instances)
+ Affichage des instances du mode automatique EKS en recherchant la clé de balise `eks:eks-cluster-name`
## Afficher les erreurs IAM dans votre AWS compte
1. Accédez à la CloudTrail console
1. Choisissez « Historique des événements » dans le volet de navigation de gauche
1. Appliquez les filtres de codes d’erreur suivants :
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Recherchez les erreurs associées à votre cluster EKS. Utilisez les messages d’erreur pour mettre à jour les entrées d’accès EKS, le rôle IAM du cluster ou le rôle IAM du nœud. Vous devrez peut-être attacher une nouvelle politique à ces rôles pour leur accorder les autorisations nécessaires au mode automatique EKS.
## Résolution des problèmes liés à l’échec de la planification des pods sur un nœud du mode automatique
Si des pods restent dans l’état `Pending` et ne sont pas planifiés sur un nœud du mode automatique, vérifiez si le manifeste de pod ou de déploiement contient un `nodeSelector`. Si un `nodeSelector` est présent, assurez-vous qu’il utilise `eks.amazonaws.com/compute-type: auto` pour être planifié sur les nœuds gérés par le mode automatique EKS. Pour plus d’informations sur les étiquettes de nœud utilisées par le mode automatique EKS, consultez [Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md).
## Résolution problèmes liés au fait qu’un nœud ne rejoint pas le cluster
Le mode automatique EKS configure automatiquement les nouvelles instances EC2 avec les informations nécessaires pour rejoindre le cluster, notamment l’adresse de point de terminaison du cluster et l’autorité de certification (CA) du cluster. Cependant, certaines instances peuvent ne pas rejoindre le cluster EKS en tant que nœuds. Exécutez les commandes suivantes pour identifier les instances qui n’ont pas rejoint le cluster :
1. Exécutez `kubectl get nodeclaim` pour vérifier les `NodeClaims` dont l’état est `Ready = False`.
```
kubectl get nodeclaim
```
1. Exécutez `kubectl describe nodeclaim ` et consultez la section **État** pour détecter tout problème empêchant le nœud de rejoindre le cluster.
```
kubectl describe nodeclaim
```
**Messages d’erreur courants :**
`Error getting launch template configs`
Cette erreur peut s’afficher si vous définissez des balises personnalisées dans `NodeClass` en utilisant les autorisations par défaut du rôle IAM du cluster. Consultez [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md).
`Error creating fleet`
Il peut s’agir d’un problème d’autorisation lié à l’appel `RunInstances` effectué via l’API EC2. Vérifiez AWS CloudTrail les erreurs et [Rôle IAM du cluster du mode automatique Amazon EKS](auto-cluster-iam-role.md) les autorisations IAM requises.
### Détection des problèmes de connectivité des nœuds avec l’outil `VPC Reachability Analyzer`
**Note**
Vous êtes facturé pour chaque analyse exécutée avec le VPC Reachability Analyzer. Pour les détails de tarification, consultez [Tarification Amazon VPC](https://aws.amazon.com/vpc/pricing/).
L’une des raisons pour lesquelles une instance n’a pas rejoint le cluster est un problème de connectivité réseau qui l’empêche d’atteindre le serveur d’API. Pour diagnostiquer ce problème, vous pouvez utiliser le [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) afin d’effectuer une analyse de la connectivité entre un nœud qui ne parvient pas à rejoindre le cluster et le serveur d’API. Vous aurez besoin de deux informations :
+ **ID d’instance** du nœud qui ne peut pas rejoindre le cluster
+ Adresse IP du **point de terminaison du serveur d’API Kubernetes**
Pour obtenir l’**ID d’instance**, vous devez créer une charge de travail sur le cluster afin que le mode automatique EKS lance une instance EC2. Cela crée également un objet `NodeClaim` dans votre cluster qui aura l’ID d’instance. Exécutez `kubectl get nodeclaim -o yaml` pour imprimer tous les éléments `NodeClaims` de votre cluster. Chaque `NodeClaim` contient l’ID d’instance en tant que champ et à nouveau dans le providerID :
```
kubectl get nodeclaim -o yaml
```
L'exemple qui suit illustre un résultat.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Vous pouvez déterminer votre **point de terminaison de serveur d’API Kubernetes** en exécutant `kubectl get endpoint kubernetes -o yaml`. Les adresses se trouvent dans le champ des adresses :
```
kubectl get endpoints kubernetes -o yaml
```
L'exemple qui suit illustre un résultat.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Avec ces deux informations, vous pouvez effectuer l’analyse de connectivité. Tout d’abord, accédez à VPC Reachability Analyzer dans la AWS Management Console.
1. Cliquez sur « Créer et analyser le chemin »
1. Donnez un nom à l’analyse (par exemple « Échec de rejoindre le nœud »)
1. Pour le « Type de source », sélectionnez « Instances »
1. Saisissez l’ID d’instance du nœud défaillant comme « Source »
1. Pour « Destination du chemin », sélectionnez « Adresse IP »
1. Saisissez l’une des adresses IP du serveur d’API comme « Adresse de destination »
1. Développez la section « Configuration d’en-têtes de paquets supplémentaires »
1. Saisissez un « Port de destination » de 443
1. Sélectionnez « Protocole » comme TCP, s’il n’est pas déjà sélectionné
1. Cliquez sur « Créer et analyser le chemin »
1. L’analyse peut prendre quelques minutes. Si les résultats de l’analyse indiquent une défaillance de connectivité, ils préciseront l’endroit exact où l’échec s’est produit dans le chemin réseau, afin que vous puissiez corriger le problème.
## Partage des volumes entre les pods
Les nœuds en mode automatique EKS sont configurés SELinux en mode d'application, ce qui permet une meilleure isolation entre les pods exécutés sur le même nœud. Lorsque cette option SELinux est activée, la plupart des pods non privilégiés se verront automatiquement appliquer leur propre étiquette de sécurité multi-catégories (MCS). Cette étiquette MCS est unique pour chaque pod et vise à garantir qu’un processus dans un pod ne puisse pas interagir avec un processus dans un autre pod ou sur l’hôte. Même si un pod étiqueté s’exécute en tant que root et dispose d’un accès au système de fichiers de l’hôte, il ne pourra pas modifier des fichiers sur l’hôte, exécuter des appels système sensibles, accéder à l’exécution du conteneur, ni obtenir les clés secrètes du kubelet.
En conséquence, vous pouvez rencontrer des problèmes lors du partage de données entre pods. Par exemple, un `PersistentVolumeClaim` avec un mode d’accès `ReadWriteOnce` ne permettra toujours pas à plusieurs pods d’accéder simultanément au volume.
Pour autoriser le partage entre pods, vous pouvez utiliser les `seLinuxOptions` du pod pour configurer la même étiquette MCS sur ces pods. Dans cet exemple, nous attribuons les trois catégories `c123,c456,c789` au pod. Cela n’entre pas en conflit avec les catégories attribuées automatiquement aux pods sur le nœud, car ces derniers ne reçoivent que deux catégories.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Affichage des événements Karpenter dans les journaux du plan de contrôle
Pour les clusters EKS disposant des journaux du plan de contrôle activés, vous pouvez analyser les actions et les décisions de Karpenter en interrogeant les journaux. Cela est particulièrement utile pour la résolution des problèmes du mode automatique EKS liés à la mise en service des nœuds, la mise à l’échelle ou la suppression des nœuds. Pour consulter les événements liés à Karpenter, utilisez la requête CloudWatch Logs Insights suivante :
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Cette requête filtre les [événements spécifiques liés à Karpenter dans les journaux d’audit](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) de kube-apiserver. Les événements incluent différents états d’interruption, des échecs de planification, des problèmes de capacité et des anomalies liées aux nœuds. En analysant ces journaux, vous pouvez mieux comprendre :
+ Pourquoi Karpenter exécute certaines actions.
+ Tout problème empêchant le provisionnement, la mise à l’échelle ou la terminaison correcte des nœuds.
+ Problèmes potentiels de capacité ou de compatibilité avec les types d’instances.
+ Événements liés au cycle de vie des nœuds, tels que les interruptions, les évictions ou les terminaisons.
Pour utiliser cette requête, procédez comme suit :
1. Accédez à la CloudWatch console
1. Sélectionnez « Logs Insights » dans le volet de navigation de gauche
1. Sélectionnez le groupe de journaux pour les journaux du plan de contrôle de votre cluster EKS
1. Collez la requête dans l’éditeur de requêtes
1. Ajustez la plage de temps selon les besoins
1. Exécuter la requête
Les résultats afficheront une chronologie des événements liés à Karpenter, ce qui vous aidera à résoudre les problèmes et à comprendre le comportement du mode automatique EKS dans votre cluster. Pour examiner les actions de Karpenter sur un nœud particulier, vous pouvez ajouter un filtre de ligne indiquant l’ID de l’instance à la requête mentionnée précédemment :
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**Note**
Pour exécuter cette requête, la journalisation du plan de contrôle doit être activée sur votre cluster EKS. Si ce n’est pas encore le cas, consultez [Envoyer les journaux du plan de contrôle à CloudWatch Logs](control-plane-logs.md).
## Résolution des problèmes liés aux contrôleurs inclus dans le mode automatique
Si vous rencontrez un problème avec un contrôleur, vérifiez les points suivants :
+ Si les ressources associées à ce contrôleur sont correctement formatées et valides.
+ Si les ressources AWS IAM et Kubernetes RBAC sont correctement configurées pour votre cluster. Pour de plus amples informations, veuillez consulter [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md).
## Ressources connexes
Utilisez ces articles de AWS Re:Post pour connaître les étapes de dépannage avancées :
+ [Comment résoudre les problèmes de mise à l’échelle courants dans le mode automatique EKS ?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [Comment résoudre les problèmes de provisionnement des groupes de nœuds et des classes de nœuds personnalisés dans le mode automatique Amazon EKS ?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [Comment résoudre les problèmes liés aux groupes de nœuds intégrés au mode automatique EKS dont l’état est inconnu ?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Consultation des notes de mise à jour du mode automatique EKS
Cette page présente les mises à jour du mode automatique Amazon EKS. Vous pouvez la consulter régulièrement pour suivre les annonces concernant les nouvelles fonctionnalités, les correctifs, les problèmes connus et les fonctionnalités obsolètes.
Pour recevoir des notifications concernant toutes les modifications apportées aux fichiers sources de cette page de documentation spécifique, vous pouvez vous abonner à l’URL suivante à l’aide d’un lecteur RSS :
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2 février 2026
**Fonctionnalité** : Ajout du support pour désactiver le trafic V4egress provenant IPv6 des pods dans les clusters en mode automatique EKS. IPv6 Pour de plus amples informations, veuillez consulter [Désactivez la IPv4 sortie des IPv6 pods en IPv6 clusters.](create-node-class.md#enableV4Egress).
## 19 décembre 2025
**Fonctionnalité** : Ajout de la prise en charge du mode IP secondaire qui fournit des adresses IP secondaires au lieu du préfixe des nœuds automatiques. Ce mode permet de conserver une adresse IP secondaire minimale IPTarget et d'économiser des ressources IP pour les clients qui n'ont pas besoin de préfixer d'autres adresses secondaires IPs ou de préfixes. Pour plus d’informations, consultez [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec) et [Mode IP secondaire pour les pods](create-node-class.md#secondary-IP-mode).
## 19 novembre 2025
**Fonctionnalité** : Activation du pull et du déballage en parallèle Seekable OCI (SOCI) pour les instances des familles G, P et Trn avec stockage local. NVMe Le pull and unpack en parallèle SOCI est toujours utilisé pour ces familles d'instances avec le mode automatique EKS et aucune modification de configuration n'est requise pour l'activer. Pour plus d'informations sur SOCI, consultez le [blog de lancement](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## 19 novembre 2025
**Fonctionnalité** : Ajout de la prise en charge des pools de nœuds à capacité statique qui maintiennent un nombre fixe de nœuds. Pour de plus amples informations, veuillez consulter [Pools de nœuds à capacité statique en mode automatique EKS](auto-static-capacity.md).
## 23 octobre 2025
**Fonctionnalité :** Les utilisateurs disposant de clusters dans les régions des États-Unis peuvent désormais demander à utiliser la compatibilité FIPS en AMIs le spécifiant `spec.advancedSecurity.fips` dans leur NodeClass définition.
## 1er octobre 2025
**Fonctionnalité :** Le mode automatique d'EKS prend désormais en charge le déploiement de nœuds dans les Zones AWS Locales. Pour de plus amples informations, veuillez consulter [Déployer des nœuds EKS Auto Mode sur des Zones Locales](auto-local-zone.md).
## 30 septembre 2025
**Fonctionnalité :** Ajout de la prise en charge d'InstanceProfile, qui s'exclut mutuellement NodeClass `spec.instanceProfile` du champ. `spec.role`
## 29 septembre 2025
Le DRA n'est actuellement pas pris en charge par le mode automatique EKS.
## 10 septembre 2025
**Tâche d’entretien :** les événements déclenchés par le contrôleur de calcul en mode automatique utiliseront désormais le nom `eks-auto-mode/compute` au lieu de `karpenter`.
## 24 août 2025
**Correction de bogue :** VPCs l'utilisation d'un ensemble d'options DHCP avec un nom de domaine personnalisé contenant des majuscules empêchait les nœuds de rejoindre le cluster en raison de la génération d'un nom d'hôte non valide. Ce problème est désormais résolu : les noms de domaine contenant des majuscules fonctionnent correctement.
## 15 août 2025
**Correction de bogue :** le Pod Identity Agent n'écoute désormais que l'adresse IPv4 Link Local dans un cluster IPv4 EKS afin d'éviter que le Pod ne puisse pas atteindre l' IPv6 adresse.
## 6 août 2025
**Fonctionnalité :** Ajout d'une nouvelle configuration NodeClass `spec.advancedNetworking.associatePublicIPAddress` qui peut être utilisée pour empêcher l'attribution d'adresses IP publiques aux nœuds en mode automatique EKS
## 30 juin 2025
**Fonctionnalité :** Le mode automatique utilise NodeClass désormais la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance, en plus du read/write volume de données. Auparavant, la clé KMS personnalisée ne servait qu’au chiffrement du volume de données.
## 20 juin 2025
**Fonctionnalité :** Support pour contrôler le déploiement des charges de travail dans les réservations de capacité à la demande EC2 ()ODCRs. Cela ajoute la clé facultative `capacityReservationSelectorTerms` au NodeClass, vous permettant de contrôler explicitement les charges de travail utilisées par ODCRs vos charges de travail. Pour de plus amples informations, veuillez consulter [Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md).
## 13 juin 2025
**Caractéristique :** prise en charge de sous-réseaux de pods distincts dans la `NodeClass`. Cela ajoute les clés facultatives ``podSubnetSelectorTerms` et `podSecurityGroupSelectorTerms` permettant de définir les sous-réseaux et les groupes de sécurité pour les pods. Pour de plus amples informations, veuillez consulter [Sous-réseaux et groupes de sécurité distincts pour les pods](create-node-class.md#pod-subnet-selector).
## 30 avril 2025
**Caractéristique :** prise en charge des serveurs proxy réseau sortant dans la `NodeClass`. Cela ajoute la clé facultative `advancedNetworking` permettant de configurer votre proxy HTTPS. Pour de plus amples informations, veuillez consulter [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec).
## 18 avril 2025
**Caractéristique :** prise en charge de la résolution des domaines .local (habituellement réservés au Multicast DNS) via DNS unicast.
## 11 avril 2025
**Caractéristique :** ajout des paramètres `certificateBundles` et `ephemeralStorage.kmsKeyID` à `NodeClass`. Pour de plus amples informations, veuillez consulter [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec).
**Caractéristique :** amélioration de la vitesse d’extraction des images, en particulier pour les types d’instances disposant d’un stockage local permettant une décompression plus rapide des images.
**Correction de bogue :** résolution d'un problème de course à l'origine FailedCreatePodSandBox d'une erreur lors de la numérotation : dial tcp 127.0.0. 1:50051 : connexion : la connexion était parfois refusée pour les pods planifiés vers un nœud immédiatement au démarrage.
## 4 avril 2025
**Caractéristique :** augmentation de `registryPullQPS` de 5 à 25 et de `registryBurst` de 10 à 50 pour réduire la limitation de débit appliquée côté client lors de l’extraction des images (`Failed to pull image xyz: pull QPS exceeded`)
## 31 mars 2025
**Correction de bogue :** résolution d’un problème où, si un pod CoreDNS s’exécutait sur un nœud du mode automatique, les requêtes DNS des pods de ce nœud étaient envoyées à ce pod CoreDNS au lieu du serveur DNS local du nœud. Désormais, les requêtes DNS provenant de pods sur un nœud du mode automatique sont systématiquement dirigées vers le DNS local du nœud.
## 21 mars 2025
**Correction de bogue :** les nœuds du mode automatique résolvent désormais correctement le domaine `kube-dns.kube-system.svc.cluster.local` lorsqu’aucun service `kube-dns` n’est installé dans le cluster. Résout GitHub le problème [\$12546](https://github.com/aws/containers-roadmap/issues/2546).
## 14 mars 2025
**Caractéristique** : activation de la sortie `IPv4` dans les clusters `IPv6`. Le trafic `IPv4` sortant depuis les clusters du mode automatique `IPv6` est désormais automatiquement traduit vers l’adresse `v4` de l’ENI primaire du nœud.