**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.
# Cycle de vie et configuration des clusters Amazon EKS
Cette section fournit des conseils détaillés sur la gestion complète du cycle de vie des clusters Kubernetes et sur les différentes manières de les configurer. Elle couvre la création d’un cluster, la surveillance de son état, la mise à jour des versions Kubernetes et la suppression du cluster. Il inclut également des sujets avancés sur la façon de configurer l'accès aux terminaux, le support enable/disable Windows, la configuration de clusters privés, la mise en œuvre de l'autoscaling et la manière d'améliorer la résilience grâce au changement de zone pour la redirection du trafic dans les configurations multi-AZ.
**Topics**
+ [Création d’un cluster du mode automatique Amazon EKS](create-cluster-auto.md)
+ [Création d’un cluster Amazon EKS](create-cluster.md)
+ [Plan de contrôle provisionné Amazon EKS](eks-provisioned-control-plane.md)
+ [Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters](cluster-insights.md)
+ [Mettre à jour un cluster existant vers une nouvelle version de Kubernetes](update-cluster.md)
+ [Supprimer un cluster](delete-cluster.md)
+ [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md)
+ [Déployer des nœuds Windows sur des clusters EKS](windows-support.md)
+ [Désactiver la prise en charge Windows](disable-windows-support.md)
+ [Déployer des clusters privés avec un accès Internet limité](private-clusters.md)
+ [Mise à l’échelle du calcul du cluster avec Karpenter et Cluster Autoscaler](autoscaling.md)
+ [Découvrez le changement de zone du contrôleur de récupération d’application (ARC) Amazon dans Amazon EKS](zone-shift.md)
+ [Activer le changement de zone EKS pour éviter les zones de disponibilité défaillantes](zone-shift-enable.md)
# Création d’un cluster du mode automatique Amazon EKS
Cette rubrique fournit des instructions détaillées pour créer un cluster du mode automatique Amazon EKS à l’aide d’options de configuration avancées. Il couvre les prérequis, les options de mise en réseau et la configuration des modules complémentaires. Le processus comprend la création des rôles IAM, la configuration des paramètres du cluster, la spécification des paramètres réseau et la sélection des modules complémentaires. Les utilisateurs peuvent créer des clusters à l'aide de la CLI AWS Management Console ou de la AWS CLI, avec step-by-step des instructions fournies pour les deux méthodes.
Pour les utilisateurs recherchant un processus d’installation moins complexe, consultez la section correspondante pour connaître les étapes simplifiées de création de cluster :
+ [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)
Ce guide de configuration avancée s’adresse aux utilisateurs souhaitant un contrôle plus précis sur la configuration de leur cluster du mode automatique EKS et ayant une bonne connaissance des concepts et exigences Amazon EKS. Avant de poursuivre la configuration avancée, assurez-vous d’avoir satisfait à tous les prérequis et de bien comprendre les exigences en matière de mise en réseau et d’IAM pour les clusters du mode automatique EKS.
Le mode automatique EKS nécessite des autorisations IAM supplémentaires. Pour en savoir plus, consultez :
+ [Rôles IAM des clusters du mode automatique EKS](automode-get-started-cli.md#auto-mode-create-roles)
+ [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md)
**Note**
Si vous souhaitez créer un cluster sans le mode automatique EKS, consultez [Création d’un cluster Amazon EKS](create-cluster.md).
Cette rubrique traite de la configuration avancée. Si vous souhaitez simplement commencer avec le mode automatique EKS, consultez [Création d’un cluster avec le mode automatique Amazon EKS](create-auto.md).
## Conditions préalables
+ Un VPC et des sous-réseaux existants qui répondent aux [exigences Amazon EKS](network-reqs.md). Avant de déployer un cluster pour une utilisation en production, nous vous recommandons de bien connaître les exigences du VPC et du sous-réseau. Si vous n'avez pas de VPC ni de sous-réseaux, vous pouvez les créer à l'aide d'un modèle fourni par [Amazon EKS](creating-a-vpc.md). AWS CloudFormation
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. 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/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*.
+ Un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) disposant des autorisations nécessaires pour créer et modifier les ressources EKS et IAM est requis.
## Créer un cluster - AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez **Add cluster (Ajouter un cluster)**, puis choisissez **Create (Créer)**.
1. Sous *Options de configuration*, sélectionnez **Configuration personnalisée**.
+ Cette rubrique traite de la configuration personnalisée. Pour plus d’informations sur la configuration rapide, consultez [Création d’un cluster du mode automatique EKS à l’aide de la AWS Management Console](automode-get-started-console.md).
1. Vérifiez que l’option **Utiliser le mode automatique EKS** est activée.
+ Cette rubrique décrit la création de clusters avec le mode automatique EKS. Pour plus d’informations sur la création de clusters sans le mode automatique EKS, consultez [Création d’un cluster Amazon EKS](create-cluster.md).
1. Sur la page **Configurer le cluster**, renseignez les champs suivants :
+ **Nom** : nom de votre cluster. Le nom ne peut contenir que des caractères alphanumériques (sensibles à la casse), des tirets et des traits de soulignement. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ Rôle **IAM du cluster : choisissez le rôle** IAM du cluster Amazon EKS que vous avez créé pour permettre au plan de contrôle Kubernetes de gérer AWS les ressources en votre nom. Si vous n’avez pas encore créé de rôle IAM de cluster pour le mode automatique EKS, sélectionnez le bouton **Créer le rôle recommandé** pour créer le rôle avec les autorisations requises dans la console IAM.
+ **Version Kubernetes** : version de Kubernetes à utiliser pour votre cluster. Nous vous recommandons de sélectionner la dernière version, sauf si vous avez besoin d'une version antérieure.
+ **Politique de mise à niveau** : politique de version Kubernetes que vous souhaitez définir pour votre cluster. Si vous souhaitez que votre cluster fonctionne uniquement sur une version en prise en charge standard, choisissez **Standard**. Si vous souhaitez que votre cluster passe en prise en charge étendue à la fin de la période de prise en charge standard, choisissez **Étendue**. Si vous sélectionnez une version de Kubernetes déjà en prise en charge étendue, vous ne pouvez pas choisir la prise en charge standard comme option.
1. Dans la section **Calcul en mode automatique** de la page de configuration du cluster, renseignez les champs suivants :
+ **Groupes de nœuds** : déterminez si vous souhaitez utiliser les groupes de nœuds intégrés. Pour de plus amples informations, veuillez consulter [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ **Rôle IAM de nœud** : si vous activez un ou plusieurs groupes de nœuds intégrés, vous devez sélectionner un rôle IAM de nœud. Le mode automatique EKS attribuera ce rôle aux nouveaux nœuds. Vous ne pourrez plus modifier cette valeur après la création du cluster. Si vous n’avez pas encore créé de rôle IAM de nœud pour le mode automatique EKS, sélectionnez le bouton Créer le rôle recommandé pour créer le rôle avec les autorisations nécessaires. Pour plus d’informations sur ce rôle, consultez [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md).
1. Dans la section **Accès au cluster** de la page de configuration du cluster, renseignez les champs suivants :
+ **Amorcer l’accès administrateur au cluster** : le créateur du cluster devient automatiquement administrateur Kubernetes. Si vous souhaitez désactiver cet accès automatique, sélectionnez **Refuser l’accès administrateur au cluster**.
+ **Mode d’authentification du cluster** : le mode automatique EKS nécessite des entrées d’accès EKS, correspondant au mode d’authentification de l’API EKS. Vous pouvez éventuellement activer le mode `ConfigMap` d'authentification en sélectionnant **EKS API et ConfigMap**.
1. Saisissez les autres champs figurant sur la page de configuration du cluster :
+ **Chiffrement des secrets** : (facultatif) choisissez d'activer le chiffrement des secrets Kubernetes à l'aide d'une clé KMS. Vous pouvez également activer cette option une fois que vous avez créé votre cluster. Avant d’activer cette fonctionnalité, assurez-vous d’avoir pris connaissance des informations mentionnées dans [Chiffrer les secrets Kubernetes avec KMS sur les clusters existants](enable-kms.md).
+ **Changement de zone ARC** : le mode automatique EKS ne prend pas en charge le changement de zone ARC.
+ **Identifications**∘: (facultatif) ajoutez des identifications à votre cluster. Pour de plus amples informations, veuillez consulter [Organiser les ressources Amazon EKS à l’aide de balises](eks-using-tags.md).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Spécifier les réseaux** sélectionnez des valeurs pour les champs suivants :
+ **VPC** : choisissez un VPC existant qui répond aux [exigences relatives au VPC Amazon EKS](network-reqs.md#network-requirements-vpc) pour y créer votre cluster. Avant de sélectionner un VPC, nous vous recommandons de bien connaître toutes les exigences et considérations de [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md). Vous ne pouvez pas modifier le VPC que vous souhaitez utiliser après la création du cluster. Si aucun VPCs n'est répertorié, vous devez d'abord en créer un. Pour de plus amples informations, veuillez consulter [Création d’un VPC Amazon pour votre cluster Amazon EKS](creating-a-vpc.md).
+ **Sous-réseaux** : par défaut, tous les sous-réseaux disponibles dans le VPC spécifié dans le champ précédent sont présélectionnés. Vous devez en sélectionner au moins deux.
Les sous-réseaux que vous choisissez doivent respecter les [exigences relatives aux sous-réseaux d'Amazon EKS](network-reqs.md#network-requirements-subnets). Avant de sélectionner les sous-réseaux, assurez-vous de bien comprendre toutes les [exigences et considérations relatives aux VPC et sous-réseaux Amazon EKS](network-reqs.md).
**Groupes de sécurité** : (facultatif) spécifiez un ou plusieurs groupes de sécurité créant des interfaces réseau auxquelles vous souhaitez associer Amazon EKS.
Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d'informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Vous pouvez modifier les règles dans le groupe de sécurité de cluster créé par Amazon EKS.
+ **Choisissez la famille d'adresses IP du cluster** : vous pouvez choisir l'une ou l'autre **IPv4**et **IPv6**.
Kubernetes attribue par défaut des adresses `IPv4` aux pods et aux services. Avant de décider d’utiliser la famille `IPv6`, assurez-vous de bien connaître toutes les considérations et exigences mentionnées dans les rubriques [Exigences et considérations relatives au VPC](network-reqs.md#network-requirements-vpc), [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets), [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Si vous choisissez la famille `IPv6`, vous ne pouvez pas spécifier une plage d’adresses à partir de laquelle Kubernetes doit attribuer les adresses de service `IPv6`, comme c’est possible avec la famille `IPv4`. Kubernetes attribue les adresses de service à partir de la plage d’adresses locales uniques (`fc00::/7`).
+ (Facultatif) Choisissez **Configurer la plage d'adresses IP du service Kubernetes** et spécifiez une **gamme de services `IPv4`**.
La spécification de votre propre plage peut aider à prévenir les conflits entre les services Kubernetes et d’autres réseaux appairés ou connectés à votre VPC. Entrez une plage en notation CIDR. Par exemple : `10.2.0.0/16`.
Le bloc d'adresse CIDR doit répondre aux critères suivants :
+ Être situé dans l'une des plages suivantes : `10.0.0.0/8`, `172.16.0.0/12`, ou `192.168.0.0/16`.
+ Avoir une taille minimale de `/24` et une taille maximale de `/12`.
+ Ne pas chevaucher la plage du VPC pour vos ressources Amazon EKS.
Vous ne pouvez spécifier cette option que lorsque vous utilisez la famille d'adresses `IPv4` et uniquement lors de la création du cluster. Si vous ne spécifiez pas cela, alors Kubernetes attribue des adresses IP de service à partir des blocs CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Pour **Accès au point de terminaison de cluster**, sélectionnez une option. Une fois votre cluster créé, vous pouvez modifier cette option. Avant de sélectionner une option autre que par défaut, assurez-vous de vous familiariser avec les options et leurs implications. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. (Facultatif) Sur la page **Configurer l'observabilité**, choisissez quelles options de **Métriques** et de **Journalisation du plan de contrôle** doivent être activées. Par défaut, chaque type de journal est désactivé.
+ Pour plus d’informations sur l’option de métriques Prometheus, consultez [Étape 1 : activer les métriques Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Pour plus d'informations sur les options de **Journalisation du plan de contrôle**, consultez [Envoyer les journaux du plan de contrôle à CloudWatch Logs](control-plane-logs.md).
+ Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Select add-ons** (Sélectionner les modules complémentaires), choisissez les modules complémentaires que vous souhaitez ajouter à votre cluster. Vous pouvez choisir autant de modules complémentaires **Amazon EKS et de modules** **complémentaires AWS Marketplace** que vous le souhaitez. Si les **modules complémentaires AWS Marketplace** que vous souhaitez installer ne figurent pas dans la liste, vous pouvez cliquer sur la numérotation des pages pour afficher des résultats supplémentaires ou rechercher les **modules complémentaires AWS Marketplace** disponibles en saisissant du texte dans le champ de recherche. Vous pouvez également filtrer les résultats par **catégorie**, **fournisseur** ou **modèle de tarification**, puis sélectionner les modules complémentaires affichés dans les résultats de recherche. Lorsque vous créez un cluster, vous pouvez afficher, sélectionner et installer tout module complémentaire compatible avec les identités de pod EKS, comme indiqué dans [Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md).
+ Le mode automatique EKS automatise les fonctionnalités de certains modules complémentaires. Si vous prévoyez de déployer des groupes de nœuds gérés par EKS sur votre cluster du mode automatique EKS, sélectionnez **Modules complémentaires Amazon EKS supplémentaires** et consultez les options. Vous devrez peut-être installer des modules complémentaires tels que CoreDNS et kube-proxy. EKS installera les modules complémentaires de cette section uniquement sur des nœuds et des groupes de nœuds autogérés.
+ Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Configurer les paramètres de modules complémentaires sélectionnés**, sélectionnez la version que vous voulez installer. Vous pourrez toujours effectuer une mise à jour vers une version ultérieure après la création du cluster.
Pour les modules complémentaires compatibles avec EKS Pod Identities, vous pouvez utiliser la console pour générer automatiquement le rôle avec le nom, la politique AWS gérée et la politique de confiance préremplis spécifiquement pour le module complémentaire. Vous pouvez réutiliser des rôles existants ou créer de nouveaux rôles pour les modules complémentaires pris en charge. Pour les étapes permettant d’utiliser la console afin de créer des rôles pour les modules complémentaires qui prennent en charge les identités de pod EKS, consultez [Créer un module complémentaire (AWS console)](creating-an-add-on.md#create_add_on_console). Si un module complémentaire ne prend pas en charge l’identité du pod EKS, un message s’affiche avec des instructions pour utiliser l’assistant afin de créer les rôles IAM pour comptes de service (IRSA) après la création du cluster.
Vous pourrez mettre à jour la configuration de chaque module complémentaire après la création du cluster. Pour plus d'informations sur la configuration des modules complémentaires, consultez [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md). Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Vérifier et créer**, passez en revue les informations que vous avez saisies ou sélectionnées sur les pages précédentes. Si vous devez apporter des modifications, choisissez **Modifier**. Quand vous êtes satisfait, choisissez **Créer**. Le champ **État** affiche **EN COURS DE CRÉATION** pendant que le cluster est provisionné.
**Note**
Il est possible que vous receviez un message d’erreur indiquant que l’une des zones de disponibilité de votre demande ne dispose pas d’une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour de plus amples informations, veuillez consulter [Capacité insuffisante](troubleshooting.md#ice).
L'approvisionnement de cluster dure plusieurs minutes.
## Créer un cluster - AWS CLI
Les instructions CLI suivantes concernent la création de ressources IAM et la création du cluster.
### 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éer un cluster
1. Créez votre cluster à l'aide de la commande suivante. Avant d'exécuter la commande, effectuez les remplacements suivants :
+ *region-code*Remplacez-le par la AWS région dans laquelle vous souhaitez créer votre cluster.
+ Remplacez *my-cluster* par un nom pour votre cluster. Le nom ne peut contenir que des caractères alphanumériques (sensibles à la casse), des tirets et des traits de soulignement. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ Remplacez la version *1.30* par n'importe quelle [version prise en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Remplacez *111122223333* par votre identifiant de compte
+ Si vous avez créé des rôles IAM nommés différemment pour les rôles de cluster et de nœud, remplacez le ARNs.
+ Remplacez les valeurs de `subnetIds` par vos propres valeurs. Vous pouvez également en ajouter d'autres IDs. Vous devez spécifier au moins deux sous-réseaux IDs.
Les sous-réseaux que vous choisissez doivent respecter les [exigences relatives aux sous-réseaux d'Amazon EKS](network-reqs.md#network-requirements-subnets). Avant de sélectionner les sous-réseaux, assurez-vous de bien comprendre toutes les [exigences et considérations relatives aux VPC et sous-réseaux Amazon EKS](network-reqs.md).
+ Si vous ne voulez pas spécifier un ID de groupe de sécurité, supprimez `,securityGroupIds=sg-` depuis la commande. Si vous souhaitez spécifier un ou plusieurs groupes de sécurité IDs, remplacez les valeurs de par `securityGroupIds` les vôtres. Vous pouvez également en ajouter d'autres IDs.
Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d'informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Vous pouvez modifier les règles dans le groupe de sécurité de cluster créé par Amazon EKS.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws: iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws: iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**Note**
Il est possible que vous receviez un message d’erreur indiquant que l’une des zones de disponibilité de votre demande ne dispose pas d’une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour de plus amples informations, veuillez consulter [Capacité insuffisante](troubleshooting.md#ice).
Les paramètres suivants sont des paramètres facultatifs qui, si nécessaire, doivent être ajoutés à la commande précédente. Vous pouvez activer ces options uniquement lorsque vous créez le cluster, et non après.
+ Si vous souhaitez spécifier à partir de quel bloc de routage inter-domaines sans classe (CIDR) `IPv4` Kubernetes attribue des adresses IP de service, vous devez le spécifier en ajoutant le `--kubernetes-network-config serviceIpv4Cidr=` à la commande suivante.
La spécification de votre propre plage peut aider à prévenir les conflits entre les services Kubernetes et d’autres réseaux appairés ou connectés à votre VPC. Entrez une plage en notation CIDR. Par exemple : `10.2.0.0/16`.
Le bloc d'adresse CIDR doit répondre aux critères suivants :
+ Être situé dans l'une des plages suivantes : `10.0.0.0/8`, `172.16.0.0/12`, ou `192.168.0.0/16`.
+ Avoir une taille minimale de `/24` et une taille maximale de `/12`.
+ Ne pas chevaucher la plage du VPC pour vos ressources Amazon EKS.
Vous ne pouvez spécifier cette option que lorsque vous utilisez la famille d'adresses `IPv4` et uniquement lors de la création du cluster. Si vous ne spécifiez pas cela, alors Kubernetes attribue des adresses IP de service à partir des blocs CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Si vous créez un cluster et que vous souhaitez qu’il attribue des adresses `IPv6` aux pods et aux services au lieu d’adresses `IPv4`, ajoutez `--kubernetes-network-config ipFamily=ipv6` à la commande suivante.
Kubernetes attribue par défaut des adresses `IPv4` aux pods et aux services. Avant de décider d’utiliser la famille `IPv6`, assurez-vous de bien connaître toutes les considérations et exigences mentionnées dans les rubriques [Exigences et considérations relatives au VPC](network-reqs.md#network-requirements-vpc), [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets), [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Si vous choisissez la famille `IPv6`, vous ne pouvez pas spécifier une plage d’adresses à partir de laquelle Kubernetes doit attribuer les adresses de service `IPv6`, comme c’est possible avec la famille `IPv4`. Kubernetes attribue les adresses de service à partir de la plage d’adresses locales uniques (`fc00::/7`).
1. Le provisionnement du cluster prend quelques minutes. Vous pouvez vérifier le statut de votre cluster avec la commande suivante.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Étapes suivantes
+ [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md)
+ [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md)
+ [Activer le chiffrement des secrets pour votre cluster](enable-kms.md).
+ [Configurer la journalisation de votre cluster](control-plane-logs.md).
+ [Ajouter des nœuds à votre cluster](eks-compute.md).
# Création d’un cluster Amazon EKS
**Note**
Cette rubrique traite de la création de clusters Amazon EKS sans le mode automatique EKS.
Pour obtenir des instructions détaillées sur la création d’un cluster du mode automatique EKS, consultez [Création d’un cluster du mode automatique Amazon EKS](create-cluster-auto.md).
Pour démarrer avec le mode automatique EKS, consultez [Démarrage avec Amazon EKS – Mode automatique EKS](getting-started-automode.md).
Cette rubrique fournit une vue d'ensemble des options disponibles et décrit les éléments à prendre en compte lorsque vous créez un cluster Amazon EKS. Si vous devez créer un cluster en utilisant votre infrastructure sur site comme capacité de calcul pour les nœuds, consultez [Créer un cluster Amazon EKS avec des nœuds hybrides](hybrid-nodes-cluster-create.md). Si vous créez un cluster Amazon EKS pour la première fois, nous vous recommandons de suivre l’un des guides dans [Mise en route avec Amazon EKS](getting-started.md). Ces guides vous aident à créer un cluster par défaut simple sans développer toutes les options disponibles.
## Conditions préalables
+ Un VPC et des sous-réseaux existants qui répondent aux [exigences Amazon EKS](network-reqs.md). Avant de déployer un cluster pour une utilisation en production, nous vous recommandons de bien connaître les exigences du VPC et du sous-réseau. Si vous n'avez pas de VPC ni de sous-réseaux, vous pouvez les créer à l'aide d'un modèle fourni par [Amazon EKS](creating-a-vpc.md). AWS CloudFormation
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*.
+ Un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) disposant des autorisations `create` et `describe` sur un cluster Amazon EKS. Pour plus d’informations, consultez [Créer un cluster Kubernetes local sur un Outpost](security-iam-id-based-policy-examples.md#policy-create-local-cluster) et [Affichage de la liste ou description de tous les clusters](security-iam-id-based-policy-examples.md#policy-example2).
## Étape 1 : créer un rôle IAM de cluster
1. Si vous avez déjà un rôle IAM de cluster, ou si vous allez créer votre cluster avec `eksctl`, vous pouvez ignorer cette étape. Par défaut, `eksctl` crée un rôle pour vous.
1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Créez le rôle IAM de cluster Amazon EKS. Si nécessaire, faites précéder *eks-cluster-role-trust-policy.json* par le chemin d'accès sur votre ordinateur sur lequel vous avez enregistré le fichier lors de l'étape précédente. La commande associe la politique d'approbation que vous avez créée lors de l'étape précédente à ce rôle. Pour créer un rôle IAM, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui crée le rôle doit se voir attribuer l'action (autorisation) IAM `iam:CreateRole`.
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Vous pouvez attribuer la politique gérée par Amazon EKS ou créer votre propre politique personnalisée. Pour connaître les autorisations minimales que vous devez utiliser dans votre politique personnalisée, consultez [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md).
Associez la politique gérée par Amazon EKS nommée [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) au rôle. Pour attacher une politique IAM à un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), le principal qui attache la politique doit se voir attribuer l'une des actions (autorisations) IAM `iam:AttachUserPolicy` ou `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Rôle lié à un service
Amazon EKS crée automatiquement un rôle lié à un service appelé `AWSServiceRoleForAmazonEKS`.
Ce rôle s’ajoute au rôle IAM du cluster. Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Ce rôle permet à Amazon EKS de gérer les clusters de votre compte. Pour de plus amples informations, veuillez consulter [Utilisation de rôles pour les clusters Amazon EKS](using-service-linked-roles-eks.md).
L’identité IAM que vous utilisez pour créer le cluster EKS doit disposer de l’autorisation nécessaire pour créer ce rôle lié à un service. Cela inclut l’autorisation `iam:CreateServiceLinkedRole`.
Si le rôle lié à un service n’existe pas déjà et que votre rôle IAM actuel ne dispose pas des autorisations nécessaires pour le créer, l’opération de création du cluster échouera.
## Étape 2 : créer un cluster
Vous pouvez créer un cluster à l’aide de :
+ [`eksctl`](#step2-eksctl)
+ [le AWS Management Console](#step2-console)
+ [la AWS CLI](#step2-cli)
### Créer un cluster – eksctl
1. Vous avez besoin d'`0.215.0`une version ou d'une version ultérieure de l'outil de ligne de `eksctl` commande installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`.
1. Créez un `IPv4` cluster Amazon EKS avec la version par défaut d'Amazon EKS Kubernetes dans votre région par défaut. AWS Avant d'exécuter la commande, effectuez les remplacements suivants :
1. *region-code*Remplacez-le par la AWS région dans laquelle vous souhaitez créer votre cluster.
1. Remplacez *my-cluster* par un nom pour votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique au sein de la AWS région et du AWS compte dans lesquels vous créez le cluster.
1. Remplacez la version *1.35* par n'importe quelle [version prise en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Modifiez les valeurs de `vpc-private-subnets` pour répondre à vos besoins. Vous pouvez également en ajouter d'autres IDs. Vous devez spécifier au moins deux sous-réseaux IDs. Si vous préférez spécifier des sous-réseaux publics, vous pouvez remplacer `--vpc-private-subnets` par `--vpc-public-subnets`. Les sous-réseaux publics ont une table de routage associée avec un routage vers une passerelle Internet, mais les sous-réseaux privés n’ont pas de table de routage associée. Nous recommandons d'utiliser des sous-réseaux privés dans la mesure du possible.
Les sous-réseaux que vous choisissez doivent respecter les [exigences relatives aux sous-réseaux d'Amazon EKS](network-reqs.md#network-requirements-subnets). Avant de sélectionner les sous-réseaux, assurez-vous de bien comprendre toutes les [exigences et considérations relatives aux VPC et sous-réseaux Amazon EKS](network-reqs.md).
1. Exécutez la commande suivante :
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
L'approvisionnement de cluster dure plusieurs minutes. Pendant la création du cluster, plusieurs lignes de sortie apparaissent. La dernière ligne de sortie est similaire à celle de l'exemple suivant.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Continuez avec [Étape 3 : mettre à jour kubeconfig](#step3)
#### Paramètres facultatifs
Pour afficher la plupart des options qui peuvent être spécifiées lors de la création d'un cluster avec `eksctl`, utilisez la commande `eksctl create cluster --help`. Pour consulter toutes les options disponibles, vous pouvez utiliser un fichier `config`. Pour plus d'informations, consultez [Utilisation des fichiers de configuration](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) et du [schéma du fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. Vous pouvez trouver des [exemples de fichiers de configuration](https://github.com/weaveworks/eksctl/tree/master/examples) sur GitHub.
Les paramètres suivants sont des paramètres facultatifs qui, si nécessaire, doivent être ajoutés à la commande précédente. Vous pouvez activer ces options uniquement lorsque vous créez le cluster, et non après. Si vous devez spécifier ces options, vous devez créer le cluster à l’aide d’un f[ichier de configuration eksctl](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) et définir les paramètres dans ce fichier plutôt qu’en utilisant la commande précédente.
+ Si vous souhaitez spécifier un ou plusieurs groupes de sécurité qu’Amazon EKS doit attribuer aux interfaces réseau qu’il crée, utilisez l’option [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup).
Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d'informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Vous pouvez modifier les règles dans le groupe de sécurité de cluster créé par Amazon EKS.
+ [Si vous souhaitez spécifier le bloc de routage interdomaine `IPv4` sans classe (CIDR) à partir duquel Kubernetes attribue les adresses IP de service, spécifiez l'option CIDR du service. IPv4](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR)
La spécification de votre propre plage peut aider à prévenir les conflits entre les services Kubernetes et d’autres réseaux appairés ou connectés à votre VPC. Entrez une plage en notation CIDR. Par exemple : `10.2.0.0/16`.
Le bloc d'adresse CIDR doit répondre aux critères suivants :
+ Être situé dans l'une des plages suivantes : `10.0.0.0/8`, `172.16.0.0/12`, ou `192.168.0.0/16`.
+ Avoir une taille minimale de `/24` et une taille maximale de `/12`.
+ Ne pas chevaucher la plage du VPC pour vos ressources Amazon EKS.
Vous ne pouvez spécifier cette option que lorsque vous utilisez la famille d'adresses `IPv4` et uniquement lors de la création du cluster. Si vous ne spécifiez pas cela, alors Kubernetes attribue des adresses IP de service à partir des blocs CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Si vous créez un cluster et souhaitez que le cluster attribue des adresses `IPv6` aux pods et aux services au lieu d’adresses `IPv4`, utilisez l’option [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily).
Kubernetes attribue par défaut des adresses `IPv4` aux pods et aux services. Avant de décider d’utiliser la famille `IPv6`, assurez-vous de bien connaître toutes les considérations et exigences mentionnées dans les rubriques [Exigences et considérations requises pour le VPC](network-reqs.md#network-requirements-vpc), [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets), [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Si vous choisissez la famille `IPv6`, vous ne pouvez pas spécifier une plage d’adresses à partir de laquelle Kubernetes doit attribuer les adresses de service `IPv6`, comme c’est possible avec la famille `IPv4`. Kubernetes attribue les adresses de service à partir de la plage d’adresses locales uniques (`fc00::/7`).
### Créer un cluster - AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez **Add cluster (Ajouter un cluster)**, puis choisissez **Create (Créer)**.
1. Sous **Options de configuration**, sélectionnez **Configuration personnalisée**
+ Pour plus d’informations sur la création rapide d’un cluster avec le mode automatique EKS, consultez [Création d’un cluster du mode automatique EKS à l’aide de la AWS Management Console](automode-get-started-console.md).
1. Sous **Mode automatique EKS**, désactivez l’option **Utiliser le mode automatique EKS**.
+ Pour plus d’informations sur la création d’un cluster du mode automatique EKS avec une configuration personnalisée, consultez [Création d’un cluster du mode automatique Amazon EKS](create-cluster-auto.md).
1. Sur la page **Configurer le cluster**, renseignez les champs suivants :
+ **Nom** : nom de votre cluster. Le nom ne peut contenir que des caractères alphanumériques (sensibles à la casse), des tirets et des traits de soulignement. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique au sein de la AWS région et du AWS compte dans lesquels vous créez le cluster.
+ Rôle **IAM du cluster : choisissez le rôle** IAM du cluster Amazon EKS que vous avez créé pour permettre au plan de contrôle Kubernetes de gérer AWS les ressources en votre nom.
+ **Version Kubernetes** : version de Kubernetes à utiliser pour votre cluster. Nous vous recommandons de sélectionner la dernière version, sauf si vous avez besoin d'une version antérieure.
+ **Type de prise en charge** : la politique de version Kubernetes que vous souhaitez définir pour votre cluster. Si vous souhaitez que votre cluster fonctionne uniquement sur une version en prise en charge standard, sélectionnez **Prise en charge standard**. Si vous souhaitez que votre cluster bénéficie d’une prise en charge étendue à la fin de la période de prise en charge standard, sélectionnez **Prise en charge étendue**. Si vous sélectionnez une version de Kubernetes déjà en prise en charge étendue, vous ne pouvez pas choisir la prise en charge standard comme option.
+ **Chiffrement des secrets** : (facultatif) choisissez d'activer le chiffrement des secrets Kubernetes à l'aide d'une clé KMS. Vous pouvez également activer cette option une fois que vous avez créé votre cluster. Avant d’activer cette fonctionnalité, assurez-vous d’avoir pris connaissance des informations mentionnées dans [Chiffrer les secrets Kubernetes avec KMS sur les clusters existants](enable-kms.md).
+ **Identifications**∘: (facultatif) ajoutez des identifications à votre cluster. Pour de plus amples informations, veuillez consulter [Organiser les ressources Amazon EKS à l’aide de balises](eks-using-tags.md).
+ **Changement de zone ARC** : (facultatif) vous pouvez utiliser le contrôleur de récupération d’application Route 53 pour atténuer les interruptions dans les zones de disponibilité défaillantes. Pour de plus amples informations, veuillez consulter [Découvrez le changement de zone du contrôleur de récupération d’application (ARC) Amazon dans Amazon EKS](zone-shift.md).
1. Dans la section **Accès au cluster** de la page de configuration du cluster, renseignez les champs suivants :
+ **Amorcer l’accès administrateur au cluster** : le créateur du cluster devient automatiquement administrateur Kubernetes. Si vous souhaitez désactiver cet accès automatique, sélectionnez **Refuser l’accès administrateur au cluster**.
+ **Mode d'authentification du cluster** : déterminez comment vous souhaitez accorder aux utilisateurs et aux rôles IAM l'accès à APIs Kubernetes. Pour de plus amples informations, veuillez consulter [Définition du mode d’authentification du cluster](grant-k8s-access.md#set-cam).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Spécifier les réseaux** sélectionnez des valeurs pour les champs suivants :
+ **VPC** : choisissez un VPC existant qui répond aux [exigences relatives au VPC Amazon EKS](network-reqs.md#network-requirements-vpc) pour y créer votre cluster. Avant de sélectionner un VPC, nous vous recommandons de bien connaître toutes les exigences et considérations de [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md). Vous ne pouvez pas modifier le VPC que vous souhaitez utiliser après la création du cluster. Si aucun VPCs n'est répertorié, vous devez d'abord en créer un. Pour de plus amples informations, veuillez consulter [Création d’un VPC Amazon pour votre cluster Amazon EKS](creating-a-vpc.md).
+ **Sous-réseaux** : par défaut, tous les sous-réseaux disponibles dans le VPC spécifié dans le champ précédent sont présélectionnés. Vous devez en sélectionner au moins deux.
Les sous-réseaux que vous choisissez doivent respecter les [exigences relatives aux sous-réseaux d'Amazon EKS](network-reqs.md#network-requirements-subnets). Avant de sélectionner les sous-réseaux, assurez-vous de bien comprendre toutes les [exigences et considérations relatives aux VPC et sous-réseaux Amazon EKS](network-reqs.md).
**Groupes de sécurité** : (facultatif) spécifiez un ou plusieurs groupes de sécurité créant des interfaces réseau auxquelles vous souhaitez associer Amazon EKS.
Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d'informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Vous pouvez modifier les règles dans le groupe de sécurité de cluster créé par Amazon EKS.
+ **Choisissez la famille d'adresses IP du cluster** : vous pouvez choisir l'une ou l'autre **IPv4**et **IPv6**.
Kubernetes attribue par défaut des adresses `IPv4` aux pods et aux services. Avant de décider d’utiliser la famille `IPv6`, assurez-vous de bien connaître toutes les considérations et exigences mentionnées dans les rubriques [Exigences et considérations relatives au VPC](network-reqs.md#network-requirements-vpc), [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets), [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Si vous choisissez la famille `IPv6`, vous ne pouvez pas spécifier une plage d’adresses à partir de laquelle Kubernetes doit attribuer les adresses de service `IPv6`, comme c’est possible avec la famille `IPv4`. Kubernetes attribue les adresses de service à partir de la plage d’adresses locales uniques (`fc00::/7`).
+ (Facultatif) Choisissez **Configurer la plage d'adresses IP du service Kubernetes** et spécifiez une **gamme de services `IPv4`**.
La spécification de votre propre plage peut aider à prévenir les conflits entre les services Kubernetes et d’autres réseaux appairés ou connectés à votre VPC. Entrez une plage en notation CIDR. Par exemple : `10.2.0.0/16`.
Le bloc d'adresse CIDR doit répondre aux critères suivants :
+ Être situé dans l'une des plages suivantes : `10.0.0.0/8`, `172.16.0.0/12`, ou `192.168.0.0/16`.
+ Avoir une taille minimale de `/24` et une taille maximale de `/12`.
+ Ne pas chevaucher la plage du VPC pour vos ressources Amazon EKS.
Vous ne pouvez spécifier cette option que lorsque vous utilisez la famille d'adresses `IPv4` et uniquement lors de la création du cluster. Si vous ne spécifiez pas cela, alors Kubernetes attribue des adresses IP de service à partir des blocs CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Pour **Accès au point de terminaison de cluster**, sélectionnez une option. Une fois votre cluster créé, vous pouvez modifier cette option. Avant de sélectionner une option autre que par défaut, assurez-vous de vous familiariser avec les options et leurs implications. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. (Facultatif) Sur la page **Configurer l'observabilité**, choisissez quelles options de **Métriques** et de **Journalisation du plan de contrôle** doivent être activées. Par défaut, chaque type de journal est désactivé.
+ Pour plus d’informations sur l’option de métriques Prometheus, consultez [Étape 1 : activer les métriques Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Pour plus d'informations sur les options de **Journalisation du plan de contrôle**, consultez [Envoyer les journaux du plan de contrôle à CloudWatch Logs](control-plane-logs.md).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Select add-ons** (Sélectionner les modules complémentaires), choisissez les modules complémentaires que vous souhaitez ajouter à votre cluster. Certains modules complémentaires sont présélectionnés. Vous pouvez choisir autant de modules complémentaires **Amazon EKS et de modules** **complémentaires AWS Marketplace** que vous le souhaitez. Si les **modules complémentaires AWS Marketplace** que vous souhaitez installer ne figurent pas dans la liste, vous pouvez cliquer sur la numérotation des pages pour afficher des résultats supplémentaires ou rechercher les **modules complémentaires AWS Marketplace** disponibles en saisissant du texte dans le champ de recherche. Vous pouvez également filtrer les résultats par **catégorie**, **fournisseur** ou **modèle de tarification**, puis sélectionner les modules complémentaires affichés dans les résultats de recherche. Lorsque vous créez un cluster, vous pouvez afficher, sélectionner et installer tout module complémentaire compatible avec les identités de pod EKS, comme indiqué dans [Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md).
Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
Certains modules complémentaires, tels qu’Amazon VPC, CoreDNS et kube-proxy, sont installés par défaut. Si vous désactivez l’un des modules complémentaires par défaut, cela peut affecter votre capacité à exécuter des applications Kubernetes.
1. Sur la page **Configurer les paramètres de modules complémentaires sélectionnés**, sélectionnez la version que vous voulez installer. Vous pourrez toujours effectuer une mise à jour vers une version ultérieure après la création du cluster.
Pour les modules complémentaires compatibles avec EKS Pod Identities, vous pouvez utiliser la console pour générer automatiquement le rôle avec le nom, la politique AWS gérée et la politique de confiance préremplis spécifiquement pour le module complémentaire. Vous pouvez réutiliser des rôles existants ou créer de nouveaux rôles pour les modules complémentaires pris en charge. Pour les étapes permettant d’utiliser la console afin de créer des rôles pour les modules complémentaires qui prennent en charge les identités de pod EKS, consultez [Créer un module complémentaire (AWS console)](creating-an-add-on.md#create_add_on_console). Si un module complémentaire ne prend pas en charge l’identité du pod EKS, un message s’affiche avec des instructions pour utiliser l’assistant afin de créer les rôles IAM pour comptes de service (IRSA) après la création du cluster.
Vous pourrez mettre à jour la configuration de chaque module complémentaire après la création du cluster. Pour plus d'informations sur la configuration des modules complémentaires, consultez [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md). Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Vérifier et créer**, passez en revue les informations que vous avez saisies ou sélectionnées sur les pages précédentes. Si vous devez apporter des modifications, choisissez **Modifier**. Quand vous êtes satisfait, choisissez **Créer**. Le champ **État** affiche **EN COURS DE CRÉATION** pendant que le cluster est provisionné.
**Note**
Il est possible que vous receviez un message d’erreur indiquant que l’une des zones de disponibilité de votre demande ne dispose pas d’une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour de plus amples informations, veuillez consulter [Capacité insuffisante](troubleshooting.md#ice).
L'approvisionnement de cluster dure plusieurs minutes.
1. Continuez avec [Étape 3 : mettre à jour kubeconfig](#step3)
### Créer un cluster - AWS CLI
1. Créez votre cluster à l'aide de la commande suivante. Avant d'exécuter la commande, effectuez les remplacements suivants :
+ *region-code*Remplacez-le par la AWS région dans laquelle vous souhaitez créer votre cluster.
+ Remplacez *my-cluster* par un nom pour votre cluster. Le nom ne peut contenir que des caractères alphanumériques (sensibles à la casse), des tirets et des traits de soulignement. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique au sein de la AWS région et du AWS compte dans lesquels vous créez le cluster.
+ Remplacez la version *1.35* par n'importe quelle [version prise en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Remplacez *111122223333* par l'ID de votre compte et *myAmazonEKSClusterRole* par le nom de votre rôle IAM de cluster.
+ Remplacez les valeurs de `subnetIds` par vos propres valeurs. Vous pouvez également en ajouter d'autres IDs. Vous devez spécifier au moins deux sous-réseaux IDs.
Les sous-réseaux que vous choisissez doivent respecter les [exigences relatives aux sous-réseaux d'Amazon EKS](network-reqs.md#network-requirements-subnets). Avant de sélectionner les sous-réseaux, assurez-vous de bien comprendre toutes les [exigences et considérations relatives aux VPC et sous-réseaux Amazon EKS](network-reqs.md).
+ Si vous ne voulez pas spécifier un ID de groupe de sécurité, supprimez `,securityGroupIds=sg-` depuis la commande. Si vous souhaitez spécifier un ou plusieurs groupes de sécurité IDs, remplacez les valeurs de par `securityGroupIds` les vôtres. Vous pouvez également en ajouter d'autres IDs.
Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d'informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Vous pouvez modifier les règles dans le groupe de sécurité de cluster créé par Amazon EKS.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws: iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**Note**
Il est possible que vous receviez un message d’erreur indiquant que l’une des zones de disponibilité de votre demande ne dispose pas d’une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour de plus amples informations, veuillez consulter [Capacité insuffisante](troubleshooting.md#ice).
Les paramètres suivants sont des paramètres facultatifs qui, si nécessaire, doivent être ajoutés à la commande précédente. Vous pouvez activer ces options uniquement lorsque vous créez le cluster, et non après.
+ Par défaut, EKS installe plusieurs modules complémentaires réseau lors de la création du cluster. Cela inclut le plug-in Amazon VPC CNI, CoreDNS et kube-proxy.
Si vous souhaitez désactiver l’installation de ces modules complémentaires réseau par défaut, utilisez le paramètre ci-dessous. Cela peut être utilisé comme alternative CNIs, comme le cilium. Pour plus d’informations, consultez la [Référence de l’API EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Si vous souhaitez spécifier à partir de quel bloc de routage inter-domaines sans classe (CIDR) `IPv4` Kubernetes attribue des adresses IP de service, vous devez le spécifier en ajoutant le `--kubernetes-network-config serviceIpv4Cidr=` à la commande suivante.
La spécification de votre propre plage peut aider à prévenir les conflits entre les services Kubernetes et d’autres réseaux appairés ou connectés à votre VPC. Entrez une plage en notation CIDR. Par exemple : `10.2.0.0/16`.
Le bloc d'adresse CIDR doit répondre aux critères suivants :
+ Être situé dans l'une des plages suivantes : `10.0.0.0/8`, `172.16.0.0/12`, ou `192.168.0.0/16`.
+ Avoir une taille minimale de `/24` et une taille maximale de `/12`.
+ Ne pas chevaucher la plage du VPC pour vos ressources Amazon EKS.
Vous ne pouvez spécifier cette option que lorsque vous utilisez la famille d'adresses `IPv4` et uniquement lors de la création du cluster. Si vous ne spécifiez pas cela, alors Kubernetes attribue des adresses IP de service à partir des blocs CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Si vous créez un cluster et que vous souhaitez qu’il attribue des adresses `IPv6` aux pods et aux services au lieu d’adresses `IPv4`, ajoutez `--kubernetes-network-config ipFamily=ipv6` à la commande suivante.
Kubernetes attribue par défaut des adresses `IPv4` aux pods et aux services. Avant de décider d’utiliser la famille `IPv6`, assurez-vous de bien connaître toutes les considérations et exigences mentionnées dans les rubriques [Exigences et considérations relatives au VPC](network-reqs.md#network-requirements-vpc), [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets), [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Si vous choisissez la famille `IPv6`, vous ne pouvez pas spécifier une plage d’adresses à partir de laquelle Kubernetes doit attribuer les adresses de service `IPv6`, comme c’est possible avec la famille `IPv4`. Kubernetes attribue les adresses de service à partir de la plage d’adresses locales uniques (`fc00::/7`).
1. Le provisionnement du cluster prend quelques minutes. Vous pouvez vérifier le statut de votre cluster avec la commande suivante.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`.
1. Continuez avec [Étape 3 : mettre à jour kubeconfig](#step3)
## Étape 3 : mettre à jour kubeconfig
1. Si vous avez créé votre cluster à l'aide de `eksctl`, vous pouvez ignorer cette étape. Cela est dû au fait que `eksctl` a déjà terminé cette étape pour vous. Activez `kubectl` pour communiquer avec votre cluster en ajoutant un nouveau contexte au fichier `kubectl` `config`. Pour plus d'informations sur la création et la mise à jour du fichier, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
L'exemple qui suit illustre un résultat.
```
Added new context arn:aws: eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Confirmez la communication avec votre cluster en exécutant la commande suivante.
```
kubectl get svc
```
L'exemple qui suit illustre un résultat.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## Étape 4 : configuration du cluster
1. (Recommandé) Pour utiliser certains modules complémentaires Amazon EKS ou pour permettre à des charges de travail Kubernetes individuelles de disposer d'autorisations spécifiques de gestion des AWS identités et des accès (IAM), [créez un fournisseur IAM OpenID Connect (OIDC](enable-iam-roles-for-service-accounts.md)) pour votre cluster. Vous n'avez besoin de créer un fournisseur OIDC IAM pour votre cluster qu'une seule fois. Pour en savoir plus sur les modules complémentaires Amazon EKS, consultez [Modules complémentaires Amazon EKS](eks-add-ons.md). Pour en savoir plus sur l'attribution des autorisations IAM spécifiques à vos applications, consultez [Rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md).
1. (Recommandé) Configurez votre cluster pour le plug-in Amazon VPC CNI avant de déployer des nœuds Amazon EC2 sur votre cluster. Par défaut, le plugin a été installé avec votre cluster. Lorsque vous ajoutez des nœuds Amazon EC2 à votre cluster, le plugin est automatiquement déployé sur chaque nœud Amazon EC2 que vous ajoutez. Ce plug-in nécessite l’ajout de l’une des politiques IAM suivantes à un rôle IAM. Si votre cluster utilise la famille `IPv4`, utilisez la politique IAM gérée [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Si votre cluster utilise la famille `IPv6`, utilisez une [politique IAM que vous créez](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
Le rôle IAM auquel vous attachez la politique peut être le rôle IAM du nœud ou un rôle dédié utilisé uniquement pour le plugin. Nous vous recommandons d'associer la politique à ce rôle. Pour plus d’informations sur la création du rôle, consultez [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md) ou [Rôle IAM du nœud Amazon EKS](create-node-role.md).
1. Si vous avez déployé votre cluster à l'aide du AWS Management Console, vous pouvez ignorer cette étape. AWS Management Console Déploie le plug-in Amazon VPC CNI pour les modules complémentaires Kubernetes, CoreDNS et Amazon EKS, par défaut. `kube-proxy`
Si vous déployez votre cluster à l'aide de l'une `eksctl` ou de l'autre ou de la AWS CLI, le plug-in Amazon VPC CNI pour Kubernetes, CoreDNS et les modules complémentaires autogérés sont déployés. `kube-proxy` Vous pouvez migrer le plug-in Amazon VPC CNI pour Kubernetes, CoreDNS, et les modules complémentaires autogérés `kube-proxy` déployés avec votre cluster vers des modules complémentaires Amazon EKS. Pour de plus amples informations, veuillez consulter [Modules complémentaires Amazon EKS](eks-add-ons.md).
1. (Facultatif) Si ce n’est pas déjà fait, vous pouvez activer les métriques Prometheus pour votre cluster. Pour plus d'informations, consultez [Création d'un scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) dans le *Guide de l'utilisateur Amazon Managed Service for Prometheus*.
1. Si vous prévoyez de déployer des charges de travail utilisant des volumes Amazon EBS, vous devez installer le module complémentaire [Amazon EBS CSI](ebs-csi.md) dans votre cluster avant de déployer ces charges de travail.
## Étapes suivantes
+ Le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui a créé le cluster est le seul principal à avoir accès au cluster. [Accordez des autorisations à d’autres principaux IAM](grant-k8s-access.md) afin qu’ils puissent accéder à votre cluster.
+ Si le principal IAM qui a créé le cluster ne dispose que des autorisations IAM minimales référencées dans les prérequis, vous pouvez alors ajouter des autorisations Amazon EKS supplémentaires pour ce principal. Pour plus d'informations sur l'octroi d'autorisations Amazon EKS aux principaux IAM, consultez la rubrique [Gestion des identités et des accès pour Amazon EKS](security-iam.md).
+ Si vous souhaitez que le principal IAM qui a créé le cluster, ou tout autre principal, puisse visualiser les ressources Kubernetes dans la console Amazon EKS, accordez les [autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions) à ces entités.
+ Si vous souhaitez que les nœuds et les principaux IAM accèdent à votre cluster depuis votre VPC, activez le point de terminaison privé pour votre cluster. Le point de terminaison public est activé par défaut. Vous pouvez désactiver le point de terminaison public après avoir activé le point de terminaison privé, si vous le souhaitez. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
+ [Activer le chiffrement des secrets pour votre cluster](enable-kms.md).
+ [Configurer la journalisation de votre cluster](control-plane-logs.md).
+ [Ajouter des nœuds à votre cluster](eks-compute.md).
# Plan de contrôle provisionné Amazon EKS
## Présentation de
Le plan de contrôle provisionné Amazon EKS est une fonctionnalité qui permet aux administrateurs de clusters de choisir parmi un ensemble de niveaux de dimensionnement et de désigner le niveau de leur choix pour des performances très élevées et prévisibles depuis le plan de contrôle du cluster. Cela permet aux administrateurs de clusters de s'assurer que le plan de contrôle est toujours approvisionné avec la capacité spécifiée.
Amazon EKS propose deux modes de fonctionnement pour le plan de contrôle de votre cluster. Par défaut, les clusters Amazon EKS utilisent le **mode standard**, dans lequel le plan de contrôle augmente ou diminue automatiquement en fonction des exigences de votre charge de travail. Le mode standard alloue de manière dynamique une capacité suffisante du plan de contrôle pour répondre aux besoins de votre charge de travail et constitue la solution recommandée dans la plupart des cas d'utilisation. Toutefois, pour les charges de travail spécialisées qui ne peuvent tolérer aucune variabilité des performances due à la mise à l'échelle du plan de contrôle ou celles qui nécessitent une très grande capacité du plan de contrôle, vous pouvez éventuellement utiliser le mode **provisionné**. Le mode provisionné vous permet de préallouer une capacité du plan de contrôle toujours prête à répondre aux exigences de charge de travail exigeantes.
**Note**
Le mode provisionné est un mode de fonctionnement du plan de contrôle supplémentaire en plus du mode standard par défaut. L'introduction du mode provisionné ne modifie pas le comportement du mode standard.
Avec le plan de contrôle provisionné EKS, les administrateurs du cluster peuvent préprovisionner la capacité du plan de contrôle souhaitée à l'avance, offrant ainsi des performances prévisibles et élevées à partir du plan de contrôle du cluster, qui est toujours disponible. Le plan de contrôle provisionné EKS permet également aux administrateurs de clusters de fournir la même capacité de plan de contrôle dans tous les environnements, qu'il s'agisse de sites de préparation, de production ou de reprise après sinistre. Cela est important pour garantir que les performances du plan de contrôle obtenues dans tous les environnements sont cohérentes et prévisibles. Enfin, EKS Provisioned Control Plane vous donne accès à de très hauts niveaux de performance du plan de contrôle, ce qui permet d'exécuter des charges de travail d'IA extrêmement évolutives, des calculs à haute performance et des charges de travail de traitement de données à grande échelle sur Kubernetes.
Tous les clusters Amazon EKS existants et nouveaux fonctionnent en mode standard par défaut. Pour les clusters nécessitant des performances élevées et prévisibles de la part du plan de contrôle, vous pouvez choisir d'utiliser la fonction EKS Provisioned Control Plane. Vous serez facturé au taux horaire correspondant au niveau de mise à l'échelle du plan de contrôle concerné, en plus des frais horaires EKS pour le support standard ou prolongé. Pour plus d'informations sur la tarification, consultez la section [Tarification d'Amazon EKS](https://aws.amazon.com/eks/pricing/).
![\[Modes du plan de contrôle Amazon EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/control-plane-modes.png)
## Cas d’utilisation
Le plan de contrôle provisionné EKS est conçu pour répondre à des scénarios spécifiques dans lesquels des performances élevées et prévisibles du plan de contrôle sont essentielles à vos opérations. La compréhension de ces cas d'utilisation peut vous aider à déterminer si EKS Provisioned Control Plane est la solution adaptée à vos charges de travail.
Charges de **travail critiques pour les performances : pour les charges** de travail qui nécessitent une latence minimale et des performances maximales de la part du plan de contrôle Kubernetes, le plan de contrôle provisionné EKS fournit une capacité qui élimine la variabilité des performances grâce à la mise à l'échelle du plan de contrôle.
**Charges de travail extrêmement évolutives — Si vous exécutez des charges** de travail hautement évolutives telles que la formation et l'inférence basées sur l'IA, le calcul haute performance ou le traitement de données à grande échelle nécessitant l'exécution d'un grand nombre de nœuds dans le cluster, le plan de contrôle provisionné fournit la capacité de plan de contrôle nécessaire pour prendre en charge ces charges de travail exigeantes.
**Événements à forte demande prévus** — Lorsque vous vous attendez à une augmentation soudaine du nombre de demandes de plans de contrôle en raison d'un événement à venir, tel que des ventes ou des promotions sur le commerce électronique, des lancements de produits, des périodes de shopping des fêtes ou des événements sportifs ou de divertissement majeurs, le plan de contrôle provisionné vous permet d'augmenter la capacité de votre plan de contrôle à l'avance. Cette approche proactive garantit que votre plan de contrôle est prêt à faire face à l'augmentation de la charge sans attendre le dimensionnement automatique pour répondre à la demande.
**Cohérence de l'environnement** : le plan de contrôle provisionné vous permet de faire correspondre la capacité et les performances du plan de contrôle entre les environnements de préparation et de production, ce qui vous aide à identifier les problèmes potentiels à un stade précoce avant le déploiement en production. En conservant le même niveau de plan de contrôle dans tous les environnements, vous pouvez vous assurer que les résultats des tests reflètent précisément le comportement de production, réduisant ainsi le risque de surprises liées aux performances lors du déploiement.
**Reprise après sinistre et continuité** des activités : pour les scénarios de reprise après sinistre, le plan de contrôle provisionné vous permet de fournir des environnements de basculement avec le même niveau de capacité que votre environnement principal. Cela garantit une interruption minimale et une restauration rapide en cas de basculement, car votre cluster de reprise après sinistre aura des caractéristiques de performance de plan de contrôle identiques à celles de votre cluster de production dès son activation.
## Niveaux de dimensionnement du plan de contrôle
EKS Provisioned Control Plane propose des niveaux d'échelle nommés selon les tailles de t-shirt (XL, 2XL, 4XL et 8XL). Chaque niveau définit sa capacité par le biais de trois attributs Kubernetes clés qui déterminent les caractéristiques de performance du plan de contrôle de votre cluster. La compréhension de ces attributs vous permet de sélectionner le niveau adapté aux exigences de votre charge de travail.
La **simultanéité des demandes d'API** mesure le nombre de demandes que le serveur d'API du plan de contrôle Kubernetes peut traiter simultanément, ce qui est essentiel pour les charges de travail à haut débit.
Le **taux de planification des pods** indique la rapidité avec laquelle le planificateur Kubernetes par défaut peut planifier les pods sur les nœuds, mesurée en pods par seconde.
La **taille de la base de données du cluster** indique l'espace de stockage alloué à etcd, la base de données qui contient l'état et les métadonnées du cluster.
Lorsque vous configurez le plan de contrôle de votre cluster sur un certain niveau de scalabilité à l'aide du plan de contrôle provisionné, EKS garantit que le plan de contrôle de votre cluster maintient les limites correspondant à ce niveau. Les limites des niveaux de dimensionnement du plan de contrôle varient selon la version de Kubernetes, comme indiqué dans les tableaux suivants.
### EKS v1.28 et v1.29
| Niveau de mise à l'échelle du plan de contrôle provisionné | Concurrence des demandes d'API (sièges) | Débit de planification des pods (pods/sec) | Taille de la base de données du cluster (Go) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 et versions ultérieures
| Niveau de mise à l'échelle du plan de contrôle provisionné | Concurrence des demandes d'API (sièges) | Débit de planification des pods (pods/sec) | Taille de la base de données du cluster (Go) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### Surveillance du plan de contrôle, échelonnement de l'utilisation des niveaux
Amazon EKS fournit plusieurs indicateurs pour vous aider à surveiller l'utilisation des niveaux de votre plan de contrôle. Ces métriques sont publiées sous forme de [ CloudWatch métriques Amazon](cloudwatch.md) et sont accessibles via la console EKS CloudWatch et EKS. [De plus, ces métriques peuvent être extraites du point de terminaison Prometheus de votre cluster EKS (voir ici).](prometheus.md)
| | **Prometheus Metric** | **CloudWatch Métrique** |
| --- | --- | --- |
| **Concurrence des demandes d'API** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Taux de planification des pods** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts total, Scheduler\$1Schedule\$1Attempts\$1Scheduled, Scheduler\$1Schedule\$1Attempts\$1Unschedulable |
| **Taille de base de données du cluster** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Vous pouvez consulter l'utilisation du plan de contrôle dans la console Amazon EKS. Sur la page de présentation de votre cluster, choisissez **Surveiller le cluster** pour accéder au tableau de bord d'observabilité, puis sélectionnez l'onglet **Surveillance du plan de contrôle** pour afficher l'utilisation du plan de contrôle dans la section **Mise à l'échelle du plan de contrôle**.
![\[Surveiller le cluster EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/monitor-cluster.png)
![\[Surveillance du plan de contrôle EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/control-plane-monitoring.png)
### Comprendre la capacité du niveau Tier par rapport aux performances réelles
Lorsque vous sélectionnez un niveau de dimensionnement du plan de contrôle provisionné, les attributs du niveau représentent les configurations sous-jacentes qu'Amazon EKS applique à votre plan de contrôle. Cependant, les performances réelles que vous obtenez dépendent de vos modèles de charge de travail spécifiques, de vos configurations et du respect des meilleures pratiques de Kubernetes. Par exemple, alors qu'un niveau 4XL configure la priorité et l'équité des API (APF) avec 6 800 postes de requêtes simultanés, le débit de demandes réel que vous obtenez à partir du plan de contrôle dépend des types d'opérations effectuées. [Par exemple, Kubernetes pénalise davantage les requêtes de liste que les requêtes de type get, de sorte que le nombre effectif de demandes de liste traitées simultanément par le plan de contrôle est inférieur à celui des demandes get (voir ici).](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) De même, bien que le planificateur par défaut QPS soit défini sur 400 pour un niveau 4XL, le taux réel de planification de vos pods dépend de facteurs tels que le fait que les nœuds soient prêts et sains pour la planification. Pour obtenir des performances optimales, assurez-vous que vos applications respectent les meilleures pratiques de Kubernetes (voir [ici](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) et sont correctement configurées en fonction des caractéristiques de votre charge de travail.
## Considérations
+ **Capacité du plan de contrôle standard** — Le mode plan de contrôle standard d'EKS offre le meilleur rapport qualité/prix et constitue l'option recommandée pour la grande majorité des cas d'utilisation. Toutefois, pour les charges de travail spécialisées qui ne peuvent tolérer aucune variabilité des performances due à la mise à l'échelle du plan de contrôle ou celles qui nécessitent une très grande capacité du plan de contrôle, vous pouvez éventuellement envisager d'utiliser le mode provisionné.
+ **Inscription requise** : les clusters existants ne passeront pas automatiquement du plan de contrôle standard à un niveau plus [onéreux](https://aws.amazon.com/eks/pricing/) du plan de contrôle provisionné EKS. Vous devez explicitement adhérer à l'un des nouveaux niveaux de dimensionnement du plan de contrôle provisionné par EKS.
+ **Restriction de sortie** : le mode plan de contrôle standard prend en charge jusqu'à 8 Go de taille de base de données de cluster (etcd). Si la taille de la base de données de votre cluster dépasse 8 Go en mode provisionné, vous ne pouvez pas revenir en mode standard tant que vous n'avez pas réduit la taille de la base de données à moins de 8 Go. Par exemple, si vous utilisez 14 Go de stockage de base de données en mode provisionné, vous devez d'abord réduire l'utilisation de votre base de données à moins de 8 Go avant de revenir en mode standard.
+ **Pas de mise à l'échelle automatique des niveaux** : le plan de contrôle provisionné EKS ne passe pas automatiquement d'un niveau à l'autre. Une fois que vous avez sélectionné un niveau de scalabilité, le plan de contrôle de votre cluster reste attaché à ce niveau, garantissant ainsi des performances constantes et prévisibles. Cependant, vous avez la possibilité de mettre en œuvre votre propre solution de dimensionnement automatique en surveillant les indicateurs d'utilisation des niveaux et en utilisant le plan de contrôle provisionné EKS APIs pour augmenter ou diminuer lorsque ces indicateurs dépassent les seuils que vous définissez, vous donnant ainsi un contrôle total sur votre stratégie de dimensionnement et l'optimisation des coûts.
+ **Affichage du niveau actuel** : vous pouvez utiliser la console Amazon EKS, la CLI Amazon Web Services ou l'API pour afficher le niveau de dimensionnement actuel du plan de contrôle. Dans la CLI, vous pouvez exécuter la `describe-cluster` commande suivante : `aws eks describe-cluster --name cluster-name`
+ **Temps de transition entre les niveaux** : vous pouvez utiliser la console Amazon EKS, Amazon EKS APIs ou la CLI pour quitter ou passer d'un niveau de dimensionnement à un autre. Amazon EKS a introduit un nouveau type de mise à jour de cluster appelé`ScalingTierConfigUpdate`, que vous pouvez inspecter pour suivre la progression de la transition. Après avoir exécuté une commande de changement de niveau, vous pouvez répertorier les mises à jour sur le cluster pour voir une nouvelle mise à jour de type `ScalingTierConfigUpdate` avec statut`Updating`. Le statut passe à `Successful` la fin de la mise à jour ou en `Failed` cas d'erreur. Le champ d'erreur de la mise à jour indique la raison de l'échec. Il n'y a aucune restriction quant à la fréquence à laquelle vous pouvez passer d'un niveau à l'autre. La modification du niveau du plan de contrôle prend plusieurs minutes. Il n'y a aucune interruption du serveur d'API pendant ce processus, car EKS met en place de nouveaux serveurs d'API avant de fermer les anciens.
+ **Sélection du niveau optimal** : pour déterminer le niveau de mise à l'échelle du plan de contrôle provisionné optimal pour votre cluster, vous pouvez effectuer des tests de charge en provisionnant votre cluster sur le niveau le plus élevé (8XL). Effectuez ensuite un test de charge pour simuler le pic de demande sur le plan de contrôle de votre cluster. Observez les mesures d'utilisation du niveau du plan de contrôle au pic de charge et utilisez ces observations comme facteur directeur pour sélectionner le niveau approprié pour le mode provisionné.
+ **Tarification du plan de contrôle provisionné** : vous serez facturé au taux horaire correspondant au niveau de dimensionnement du plan de contrôle provisionné auquel se trouve votre cluster. Cela s'ajoute aux frais horaires de support standard ou prolongé. Consultez la [page](https://aws.amazon.com/eks/pricing/) de tarification d'Amazon EKS pour plus de détails.
+ **Niveau de mise à l'échelle supérieur** : si vous avez l'intention d'exécuter votre cluster sur un niveau de mise à l'échelle supérieur à 8XL, contactez l'équipe chargée de votre compte Amazon Web Services pour obtenir des informations tarifaires supplémentaires.
+ **Support des versions et des régions de Kubernetes** : le plan de contrôle provisionné par EKS est pris en charge dans toutes les régions commerciales d'Amazon Web Services GovCloud et en Chine. Le plan de contrôle provisionné fonctionne sur EKS v1.28 et versions ultérieures.
# Commencer à utiliser le plan de contrôle provisionné Amazon EKS
Ce guide vous explique les étapes de configuration et d'utilisation du plan de contrôle provisionné EKS à l'aide de la AWS CLI et AWS Management Console.
## Conditions préalables
Avant de commencer, assurez-vous de disposer des éléments suivants :
+ ** AWS CLI** : outil de ligne de commande permettant de travailler avec AWS des services, notamment Amazon EKS. Pour plus d'informations, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dans le *guide de l'utilisateur de l'interface de ligne de AWS commande*. Après avoir installé la AWS CLI, nous vous recommandons de la configurer également. Pour plus d'informations, consultez la section [Configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. Notez que la AWS CLI v2 est requise pour utiliser l'option **update-kubeconfig** présentée sur cette page.
+ **Autorisations IAM requises** : le principal de sécurité IAM que vous utilisez doit être autorisé à utiliser les rôles IAM Amazon EKS, les rôles liés à un service, AWS CloudFormation un VPC et les ressources associées. Pour plus d'informations, consultez les sections [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) et [utilisation de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) dans le guide de l'utilisateur *IAM*. Vous devez effectuer toutes les étapes de ce guide avec le même utilisateur. Exécutez la commande suivante pour vérifier l'utilisateur actuel :
```
aws sts get-caller-identity
```
**Note**
Nous vous recommandons de terminer les étapes de cette rubrique dans un shell Bash. Si vous n’utilisez pas de shell Bash, certaines commandes de script telles que les caractères de continuation de ligne et la façon dont les variables sont définies et utilisées nécessitent un ajustement pour votre shell. En outre, les règles de votre shell en matière de guillemets peuvent être différentes. Pour plus d'informations, consultez la section [Utilisation de guillemets avec des chaînes dans la AWS CLI du](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) *Guide de l'utilisateur de l'interface de ligne de AWS commande*.
## Plan de contrôle provisionné EKS - CLI AWS
### Créez un cluster avec le niveau de mise à l'échelle du plan de contrôle provisionné par EKS
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Réponse :
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Afficher le niveau de mise à l'échelle du plan de contrôle du cluster
```
aws eks describe-cluster --name prod-cluster
```
Réponse :
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Mettre à jour le cluster pour utiliser le plan de contrôle provisionné EKS
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Réponse :
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Afficher la mise à jour du dimensionnement du plan de contrôle
```
aws eks list-updates --name example
```
Réponse :
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Passer du plan de contrôle provisionné au plan de contrôle standard
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Réponse :
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Plan de contrôle provisionné EKS - AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez **Créer un cluster**.
1. Sous *Options de configuration*, sélectionnez **Configuration personnalisée**.
1. Faites défiler l'écran vers le bas jusqu'au **niveau de dimensionnement du plan de contrôle**. Sélectionnez **Utiliser un niveau de dimensionnement** pour activer le plan de contrôle provisionné.
1. Sélectionnez le niveau de mise à l'échelle du plan de contrôle que vous souhaitez configurer pour le cluster parmi les différentes options de niveau de mise à l'échelle, telles que XL, 2XL, 4XL et 8XL.
1. Sélectionnez d'autres options de configuration de cluster selon vos besoins. À la dernière étape, sélectionnez **Créer un cluster**. Notez que la création du cluster peut prendre plusieurs minutes.
# Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters
Les informations sur les clusters Amazon EKS détectent les problèmes et fournissent des recommandations pour vous aider à gérer votre cluster. Chaque cluster Amazon EKS est soumis à des contrôles automatiques et récurrents par rapport à une liste d'informations organisée par Amazon EKS. Ces *vérifications d’informations* sont entièrement gérées par Amazon EKS et incluent des recommandations pour résoudre les problèmes détectés.
## Types d’informations sur le cluster
+ **Informations sur la configuration** : identifient les erreurs de configuration dans la configuration de vos nœuds hybrides EKS susceptibles d’affecter les fonctionnalités de votre cluster ou de vos charges de travail.
+ **Informations sur la mise à niveau** : identifient les problèmes susceptibles d’affecter votre capacité à effectuer la mise à niveau vers les nouvelles versions Kubernetes.
## Considérations
+ **Fréquence** : Amazon EKS actualise les informations sur les clusters toutes les 24 heures, ou vous pouvez les actualiser manuellement pour voir l’état le plus récent. Par exemple, vous pouvez actualiser manuellement les informations sur les clusters après avoir résolu un problème pour voir s’il a été résolu.
+ **Autorisations** : Amazon EKS crée automatiquement une entrée d’accès au cluster pour obtenir des informations sur les clusters dans chaque cluster EKS. Cette entrée autorise EKS à afficher des informations sur votre cluster. Amazon EKS utilise ces informations pour générer d’autres informations. Pour de plus amples informations, consultez [Amazon EKSCluster InsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Cas d’utilisation
Les informations sur les clusters d’Amazon EKS offrent des vérifications automatisées pour maintenir la santé, la fiabilité et une configuration optimale de vos clusters Kubernetes. Vous trouverez ci-dessous les principaux cas d’utilisation pour obtenir des informations sur les clusters, notamment la préparation à la mise à niveau et la résolution des problèmes de configuration.
### Informations sur la mise à niveau
Les informations sur la mise à niveau constituent un type spécifique de vérifications d’informations au sein des informations sur les clusters. Ces vérifications renvoient des informations relatives à l’état de préparation de la mise à niveau des versions Kubernetes. Amazon EKS effectue des vérifications des informations sur la mise à niveau sur chaque cluster EKS.
**Important**
Amazon EKS a temporairement supprimé une fonctionnalité qui vous obligeait à utiliser un indicateur `--force` pour mettre à niveau votre cluster en cas de problèmes liés aux informations sur le cluster. Pour plus d’informations, consultez la section [Annulation temporaire de l’application des informations sur la mise à niveau lors de la mise à jour de la version du cluster](https://github.com/aws/containers-roadmap/issues/2570) sur Github.
Pour plus d’informations sur la mise à niveau de votre cluster, consultez [Étape 3 : mettre à jour le plan de contrôle du cluster](update-cluster.md#update-cluster-control-plane).
Avant de mettre à jour la version Kubernetes de votre cluster, utilisez l’onglet **Informations sur la mise à niveau** du tableau de bord d’observabilité dans la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). Si votre cluster présente des problèmes identifiés, examinez-les et apportez les correctifs nécessaires. Chaque problème est accompagné de liens vers la documentation Amazon EKS et Kubernetes. Une fois le problème résolu, actualisez les informations sur les clusters à la demande pour obtenir les informations les plus récentes. Si tous les problèmes ont été résolus, [mettez à jour votre cluster](update-cluster.md).
Amazon EKS renvoie des informations relatives à l’état de préparation de la mise à niveau des versions Kubernetes. Les informations sur la mise à niveau identifient les problèmes potentiels susceptibles d’avoir un impact sur les mises à niveau des clusters Kubernetes. Cela réduit au minimum le temps de préparation des administrateurs et améliore la fiabilité des applications sur les nouvelles versions Kubernetes. Les clusters sont automatiquement analysés par Amazon EKS sur la base d’une liste de problèmes connus pouvant impacter les mises à niveau Kubernetes. Amazon EKS met fréquemment à jour la liste des vérifications des informations en fonction des révisions des modifications apportées à chaque version Kubernetes.
Les informations de mise à niveau d'Amazon EKS accélèrent le processus de test et de vérification des nouvelles versions. Elles permettent également aux administrateurs de cluster et aux développeurs d’applications d’adopter plus rapidement les nouvelles fonctionnalités Kubernetes en identifiant les points d’attention et en fournissant des recommandations de remédiation.
### Informations sur la configuration
EKS Cluster Insights analyse automatiquement les clusters Amazon EKS dotés de nœuds hybrides afin d’identifier les problèmes de configuration qui entravent la communication entre le plan de contrôle Kubernetes et le webhook, les commandes kubectl telles que exec et logs, etc. Les informations sur la configuration permettent de détecter les problèmes et de fournir des recommandations pour y remédier, accélérant ainsi le délai de configuration de nœuds hybrides entièrement fonctionnels.
## Mise en route
Pour consulter la liste des vérifications effectuées et les éventuels problèmes identifiés par Amazon EKS, vous pouvez utiliser la AWS Management Console, la CLI AWS, les kits SDK AWS et l’opération d’API `ListInsights` Amazon EKS correspondante. Consultez [Afficher les informations sur le cluster](view-cluster-insights.md) pour démarrer.
# Afficher les informations sur le cluster
Amazon EKS fournit deux types d’informations : **Informations sur la configuration** et **Informations sur la mise à niveau**. **Informations sur la configuration** identifie les erreurs de configuration dans votre configuration de nœuds hybrides Amazon EKS qui pourraient nuire au fonctionnement de votre cluster ou de vos charges de travail. **Informations sur la mise à niveau** identifie les problèmes qui pourraient affecter votre capacité à mettre à niveau vers de nouvelles versions de Kubernetes.
Pour consulter la liste des vérifications d'informations effectuées et les éventuels problèmes pertinents identifiés par Amazon EKS, vous pouvez appeler le fonctionnement de look in the AWS Management Console, de la AWS CLI et de l'`ListInsights`API Amazon EKS. AWS SDKs
## Afficher les informations de configuration (console)
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans la liste de clusters, choisissez le nom du cluster Amazon EKS pour lequel vous souhaitez obtenir des informations.
1. Sélectionnez **Surveiller le cluster**.
1. Sélectionnez l’onglet **État du cluster**.
1. Dans le tableau **Informations de configuration**, vous verrez les colonnes suivantes :
+ **Nom** : vérification effectuée par Amazon EKS par rapport au cluster.
+ **Statut de l’information** : une information dont le statut est `Error` signifie qu’il existe une erreur de configuration susceptible d’affecter le fonctionnement du cluster. Une information dont le statut est `Warning` signifie que la configuration ne correspond pas à l’approche documentée, mais que le cluster peut fonctionner si vous l’avez configuré intentionnellement. Une information dont le statut est `Passing` signifie qu’Amazon EKS n’a détecté aucun problème associé à ce contrôle de statut dans votre cluster.
+ **Version** : la version applicable.
+ **Dernière heure d’actualisation** : heure à laquelle le statut de l’information a été actualisé pour la dernière fois pour ce cluster.
+ **Description** : informations provenant de la vérification des informations, qui incluent l'alerte et les mesures correctives recommandées.
## Afficher les informations de mise à niveau (console)
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans la liste de clusters, choisissez le nom du cluster Amazon EKS pour lequel vous souhaitez obtenir des informations.
1. Sélectionnez **Surveiller le cluster**.
1. Sélectionnez l’onglet **Informations de mise à niveau**.
1. Pour afficher les dernières données, cliquez sur le bouton **Actualiser les informations** et attendez que l’opération d’actualisation soit terminée.
1. Dans le tableau **Informations de mise à niveau**, vous verrez les colonnes suivantes :
+ **Nom** : vérification effectuée par Amazon EKS par rapport au cluster.
+ **Statut de l’information** : une information dont le statut est « Erreur » signifie généralement que la version Kubernetes concernée est N\$11 de la version actuelle du cluster, tandis qu’un statut « Avertissement » signifie que l’information s’applique à une future version Kubernetes N\$12 ou supérieure. Une information dont le statut est « Réussi » signifie qu'Amazon EKS n'a détecté aucun problème associé à cette vérification d'informations dans votre cluster. Une information dont le statut est « Inconnu » signifie qu'Amazon EKS n'est pas en mesure de déterminer si votre cluster est concerné par cette vérification des informations.
+ **Version** : la version Kubernetes pour laquelle l’information a vérifié les problèmes éventuels.
+ **Dernière heure d’actualisation** : heure à laquelle le statut de l’information a été actualisé pour la dernière fois pour ce cluster.
+ **Dernière transition** : heure à laquelle le statut de cette information a été modifié pour la dernière fois.
+ **Description** : informations provenant de la vérification des informations, qui incluent l'alerte et les mesures correctives recommandées.
## Afficher les informations sur le cluster (AWS CLI)
1. Pour afficher les dernières données, actualisez les informations pour un cluster spécifié. Apportez les modifications suivantes à la commande si nécessaire, puis exécutez la commande modifiée.
+ *region-code*Remplacez-le par le code de votre AWS région.
+ Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Pour suivre l’état d’actualisation des informations, exécutez la commande suivante. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
L'exemple qui suit illustre un résultat.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Répertoriez les informations pour un cluster spécifié. Apportez les modifications suivantes à la commande si nécessaire, puis exécutez la commande modifiée.
+ *region-code*Remplacez-le par le code de votre AWS région.
+ Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
L'exemple qui suit illustre un résultat.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Pour obtenir des informations descriptives sur une information, exécutez la commande suivante. Apportez les modifications suivantes à la commande si nécessaire, puis exécutez la commande modifiée.
+ *region-code*Remplacez-le par le code de votre AWS région.
+ *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222*Remplacez-le par un ID d'aperçu extrait de la liste des informations du cluster.
+ Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
L'exemple qui suit illustre un résultat.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Mettre à jour un cluster existant vers une nouvelle version de Kubernetes
**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.
Dès qu'une nouvelle version Kubernetes est disponible dans Amazon EKS, vous pouvez mettre à jour votre cluster Amazon EKS.
**Important**
Une fois que vous avez mis à niveau un cluster, vous ne pouvez pas revenir à une version antérieure. Avant de mettre à jour vers une nouvelle version de Kubernetes, nous vous recommandons de consulter les informations dans [Comprendre le cycle de vie des versions de Kubernetes sur EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) et les étapes de mise à niveau dans cette rubrique.
Les nouvelles versions de Kubernetes introduisent parfois des modifications importantes. Nous vous recommandons donc de comparer la version actuelle de vos applications à la toute nouvelle version Kubernetes avant de procéder à la mise à jour sur vos clusters de production. Pour ce faire, créez un flux d'intégration continue afin de tester le comportement de votre application avant de passer à une nouvelle version Kubernetes.
Dans le processus de mise à jour, Amazon EKS lance de nouveaux nœuds de serveur d'API avec la version de Kubernetes mise à jour pour remplacer les versions existantes. Amazon EKS effectue la surveillance de l’état standard de l’infrastructure et de la disponibilité pour le trafic réseau sur ces nouveaux nœuds afin de vérifier qu’ils fonctionnent comme prévu. Cependant, une fois que vous avez lancé la mise à niveau du cluster, vous ne pouvez plus la suspendre ni l’arrêter. Si l'une de ces vérifications échoue, Amazon EKS annule le déploiement d'infrastructure, et votre cluster reste dans la version Kubernetes précédente. Les applications en cours d’exécution ne sont pas affectées et votre cluster ne se retrouve jamais dans un état non déterministe ou irrécupérable. Amazon EKS sauvegarde régulièrement tous les clusters gérés, et des mécanismes existent pour récupérer des clusters si nécessaire. Nous évaluons et améliorons constamment nos processus de gestion de l’infrastructure Kubernetes.
Pour mettre à jour le cluster, Amazon EKS requiert jusqu'à cinq adresses IP disponibles correspondant aux sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Amazon EKS crée de nouvelles interfaces réseau élastiques de cluster (interfaces réseau) dans l'un des sous-réseaux que vous avez spécifiés. Les interfaces réseau peuvent être créées dans des sous-réseaux différents de ceux dans lesquels se trouvent vos interfaces réseau existantes. Assurez-vous donc que les règles de votre groupe de sécurité autorisent la [communication de cluster requise](sec-group-reqs.md) pour tous les sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Si l’un des sous-réseaux que vous avez spécifiés lors de la création du cluster n’existe pas, ne dispose pas d’adresses IP disponibles en nombre suffisant ou ne dispose pas de règles de groupe de sécurité permettant la communication nécessaire au cluster, la mise à jour peut échouer.
Pour garantir que le point de terminaison du serveur API de votre cluster soit toujours accessible, Amazon EKS fournit un plan de contrôle Kubernetes hautement disponible et effectue des mises à jour propagées des instances du serveur API pendant les opérations de mise à jour. Afin de tenir compte des changements d’adresses IP des instances du serveur API prenant en charge votre point de terminaison du serveur API Kubernetes, vous devez vous assurer que vos clients du serveur API gèrent efficacement les reconnexions. Les versions récentes de `kubectl` et des [bibliothèques](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) clientes Kubernetes officiellement prises en charge effectuent ce processus de reconnexion de manière transparente.
**Note**
Pour en savoir plus sur le contenu d’une mise à jour de cluster, consultez [Bonnes pratiques pour les mises à niveau de cluster](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) dans le Guide des bonnes pratiques EKS. Cette ressource vous aide à planifier une mise à niveau et à comprendre la stratégie de mise à niveau d’un cluster.
## Considérations relatives au mode automatique Amazon EKS
+ La capacité de calcul du mode automatique Amazon EKS contrôle la version Kubernetes des nœuds. Après avoir mis à niveau le plan de contrôle, le mode automatique EKS commencera à mettre à jour progressivement les nœuds gérés. Le mode automatique EKS respecte les budgets de perturbation des pods.
+ Vous n’avez pas besoin de mettre à niveau manuellement les capacités du mode automatique Amazon EKS, notamment les capacités d’autoscaling de calcul, de stockage en bloc et d’équilibrage de charge.
## Résumé
Voici un résumé général du processus de mise à niveau du cluster Amazon EKS :Le résumé général du processus de mise à niveau du cluster Amazon EKS est le suivant :
1. Assurez-vous que votre cluster est dans un état permettant la mise à niveau. Cela inclut la vérification des Kubernetes APIs utilisés par les ressources déployées dans le cluster, afin de s'assurer que le cluster ne présente aucun problème de santé. Nous vous recommandons d’utiliser les informations de mise à niveau Amazon EKS pour évaluer l’état de préparation de votre cluster à la mise à niveau.
1. Mettez à niveau le plan de contrôle vers la version mineure suivante (par exemple, de la version 1.34 à la version 1.35).
1. Mettez à niveau les nœuds du plan de données pour qu’ils correspondent à ceux du plan de contrôle.
1. Mettez à niveau toutes les applications supplémentaires qui s’exécutent sur le cluster (par exemple, `cluster-autoscaler`).
1. Mettez à niveau les modules complémentaires fournis par Amazon EKS, tels que ceux inclus par défaut :
+ [Version recommandée du CNI Amazon VPC](managing-vpc-cni.md)
+ [Version recommandée de CoreDNS](managing-coredns.md)
+ [Version recommandée de `kube-proxy`](managing-kube-proxy.md)
1. Mettez à niveau tous les clients qui communiquent avec le cluster (par exemple, `kubectl`).
## Étape 1 : préparer la mise à niveau
Comparez la version Kubernetes de votre plan de contrôle de cluster à celle de vos nœuds.
+ Obtenez la version Kubernetes du plan de contrôle de votre cluster.
```
kubectl version
```
+ Obtenez la version Kubernetes de vos nœuds. Cette commande renvoie tous les nœuds Amazon EC2, Fargate et hybrides autogérés et gérés. Chaque pod Fargate est répertorié comme son propre nœud.
```
kubectl get nodes
```
Avant de mettre à jour votre plan de contrôle vers une nouvelle version de Kubernetes, assurez-vous que la version mineure de Kubernetes des nœuds gérés et des nœuds Fargate de votre cluster est identique à celle de votre plan de contrôle. Par exemple, si votre plan de contrôle exécute la version `1.29` et que l’un de vos nœuds exécute la version `1.28`, vous devez mettre à jour vos nœuds vers la version `1.29` avant de mettre à jour votre plan de contrôle vers la version 1.30. Nous vous recommandons également de mettre à jour vos nœuds autogérés et hybrides vers la même version que votre plan de contrôle avant de mettre à jour ce dernier. Pour plus d’informations, consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md), [Mettez à jour les nœuds autogérés de votre cluster](update-workers.md) et [Mettre à niveau les nœuds hybrides pour votre cluster](hybrid-nodes-upgrade.md). Si vous disposez de nœuds Fargate dont la version mineure est inférieure à celle du plan de contrôle, veuillez d’abord supprimer le pod représenté par le nœud. Mettez ensuite à jour votre plan de contrôle. Les pods restants seront mis à niveau vers la nouvelle version après leur redéploiement.
## Étape 2 : examiner les considérations relatives à la mise à niveau
Amazon EKS Cluster Insights analyse automatiquement les clusters par rapport à une liste de problèmes potentiels liés à la mise à niveau de la version Kubernetes, tels que l’utilisation d’API Kubernetes obsolètes. Amazon EKS met régulièrement à jour la liste des vérifications à effectuer en fonction des évaluations des modifications apportées au projet Kubernetes. Amazon EKS met également à jour la liste des vérifications à mesure que des modifications sont introduites dans le service Amazon EKS avec les nouvelles versions. Pour de plus amples informations, veuillez consulter [Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters](cluster-insights.md).
Veuillez consulter le [Guide de migration des API obsolètes](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) dans la documentation Kubernetes.
### Vérifiez les informations relatives à la mise à niveau
Utilisez les informations relatives à la mise à niveau d’Amazon EKS pour identifier les problèmes. Pour de plus amples informations, veuillez consulter [Afficher les informations de mise à niveau (console)](view-cluster-insights.md#view-upgrade-insights-console).
### Considérations détaillées
+ Dans la mesure où Amazon EKS exécute un plan de contrôle hautement disponible, vous devez mettre à jour une seule version mineure à la fois. Pour plus d'informations sur cette exigence, consultez [Kubernetes Version and Version Skew Support Policy](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver) (Politique de prise en charge des versions et versions asymétriques de Kubernetes). Supposez que la version actuelle de votre cluster soit la version `1.28` et que vous souhaitiez la mettre à jour vers la version `1.30`. Vous devez d'abord mettre à jour la version `1.28` de votre cluster vers la version `1.29`, puis mettre à jour la version `1.29` de votre cluster vers la version `1.30`.
+ Vérifiez le décalage de version entre le `kube-apiserver` Kubernetes et le `kubelet` sur vos nœuds.
+ À partir de la version `1.28` de Kubernetes, le `kubelet` peut être jusqu’à trois versions mineures plus anciennes que le `kube-apiserver`. Voir la [politique d'asymétrie des versions en amont de Kubernetes](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Si le `kubelet` de vos nœuds gérés et Fargate est en version Kubernetes `1.25` ou supérieure, vous pouvez mettre à jour votre cluster jusqu’à trois versions sans mettre à jour la version du `kubelet`. Par exemple, si la version du `kubelet` est `1.25`, vous pouvez mettre à jour la version de votre cluster Amazon EKS de `1.25` vers `1.26` ou vers `1.27` et vers `1.28` alors que le `kubelet` reste sur la version `1.25`.
+ Avant de commencer une mise à jour, il est recommandé de vous assurer que le `kubelet` de vos nœuds est à la même version Kubernetes que votre plan de contrôle.
+ Si votre cluster est configuré avec une version du plug-in CNI Amazon VPC pour Kubernetes antérieure à `1.8.0`, nous vous recommandons de mettre à jour le plug-in vers la dernière version avant de mettre à jour votre cluster. Pour mettre à jour le plugin, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).
+ Vous pouvez effectuer une sauvegarde de votre cluster Amazon EKS afin de restaurer l'état de votre cluster Amazon EKS et son stockage persistant en cas de défaillance lors du processus de mise à niveau. Consultez [Sauvegardez vos clusters EKS avec AWS Backup](integration-backup.md)
## Étape 3 : mettre à jour le plan de contrôle du cluster
**Important**
Amazon EKS a temporairement supprimé une fonctionnalité qui vous obligeait à utiliser un indicateur `--force` pour mettre à niveau votre cluster en cas de problèmes liés aux informations sur le cluster. Pour plus d'informations, voir Annulation [temporaire de l'application des informations de mise à niveau lors de la mise à jour de la version du cluster sur](https://github.com/aws/containers-roadmap/issues/2570). GitHub
Amazon EKS actualise les informations sur le cluster 24 h après la « dernière heure d’actualisation ». Vous pouvez comparer l’heure à laquelle vous avez résolu un problème à la « dernière heure d’actualisation » des informations sur le cluster.
De plus, la mise à jour du statut des informations peut prendre jusqu’à 30 jours après la résolution d’un problème d’utilisation d’une API obsolète. Mettre à niveau les informations recherche toujours les utilisations d’API obsolètes sur une période de 30 jours consécutifs.
Vous pouvez soumettre la demande de mettre à niveau la version de votre plan de contrôle EKS à l’aide de :
+ [eksctl](#step3-eksctl)
+ [la AWS console](#step3-console)
+ [la AWS CLI](#step3-cli)
### Mettre à jour le cluster – eksctl
Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante :
```
eksctl version
```
Pour les instructions d'installation et de mise à jour de `eksctl`, consultez la rubrique [Installation](https://eksctl.io/installation) dans la documentation `eksctl`.
Mettez à jour la version Kubernetes de votre plan de contrôle Amazon EKS. Remplacez `` par le nom de votre cluster. Remplacez `` par le numéro de version pris en charge par Amazon EKS vers lequel vous voulez mettre à niveau votre cluster. Pour obtenir la liste des numéros de version pris en charge, consultez [Versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
Cette mise à jour peut prendre plusieurs minutes.
Passez au [Étape 4 : mettre à jour les composants du cluster](#step4).
### Cluster de mise à jour - AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Sélectionnez **Mettre à niveau maintenant** pour le cluster que vous souhaitez mettre à niveau.
1. Sélectionnez la version vers laquelle vous souhaitez mettre à jour votre cluster, puis choisissez **Mettre à niveau**.
1. Cette mise à jour peut prendre plusieurs minutes. Passez au [Étape 4 : mettre à jour les composants du cluster](#step4).
### Mettre à jour le cluster - AWS CLI
1. Vérifiez que la AWS CLI est installée et que vous êtes connecté. Pour plus d'informations, voir [Installation ou mise à jour vers la dernière version de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Mettez à jour votre cluster Amazon EKS à l'aide de la commande AWS CLI suivante. Remplacez `` et `` par le nom et le code de région du cluster que vous voulez mettre à niveau. Remplacez `` par le numéro de version pris en charge par Amazon EKS vers lequel vous voulez mettre à niveau votre cluster. Pour obtenir la liste des numéros de version pris en charge, consultez [Versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
L'exemple qui suit illustre un résultat.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. Cette mise à jour peut prendre plusieurs minutes. Contrôlez l'état de mise à jour de votre cluster avec la commande suivante. En plus d’utiliser le même `` et ``, utilisez l’`` renvoyé par la commande précédente.
```
aws eks describe-update --name \
--region --update-id
```
Lorsqu'un état `Successful` s'affiche, la mise à jour est terminée.
1. Passez au [Étape 4 : mettre à jour les composants du cluster](#step4).
## Étape 4 : mettre à jour les composants du cluster
1. Une fois la mise à jour de votre cluster terminée, mettez à jour vos nœuds vers la même version Kubernetes que celle de votre cluster mis à jour. Pour plus d’informations, consultez [Mettez à jour les nœuds autogérés de votre cluster](update-workers.md), [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md) et [Mettre à niveau les nœuds hybrides pour votre cluster](hybrid-nodes-upgrade.md). Tous les nouveaux pods lancés sur Fargate ont une version `kubelet` qui correspond à la version de votre cluster. Les pods Fargate existants ne sont pas modifiés.
1. (Facultatif) Si vous avez déployé le composant Kubernetes Cluster Autoscaler sur votre cluster avant de mettre à jour le cluster, mettez ce composant à jour vers la version la plus récente correspondant à la version majeure et mineure de Kubernetes vers laquelle vous avez effectué la mise à jour.
1. Ouvrez la page [versions](https://github.com/kubernetes/autoscaler/releases) de Cluster Autoscaler dans un navigateur Web et recherchez la dernière version de Cluster Autoscaler qui correspond à la version majeure et mineure de Kubernetes de votre cluster. Par exemple, si la version Kubernetes de votre cluster est `1.30`, recherchez la dernière version publiée de Cluster Autoscaler qui commence par `1.30`. Enregistrez le numéro de version sémantique (`1.30.n`, par exemple) de cette version à utiliser à l'étape suivante.
1. Identifiez l'image Cluster Autoscaler sur la version que vous avez enregistrée à l'étape précédente avec la commande suivante. Si nécessaire, remplacez `X.XX.X` par votre propre valeur.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Clusters dotés de nœuds GPU uniquement) Si votre cluster possède des groupes de nœuds compatibles avec le GPU (par exemple,`p3.2xlarge`), vous devez mettre à jour le [plug-in d'appareil NVIDIA pour Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) DaemonSet sur votre cluster. ``Remplacez-le par la s-device-plugin version [Nvidia/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) de votre choix avant d'exécuter la commande suivante.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Mettez à jour le plug-in CNI Amazon VPC pour Kubernetes, CoreDNS et les modules complémentaires `kube-proxy`. Nous vous recommandons de mettre à jour les modules complémentaires avec les versions minimales répertoriées dans les [jetons de compte de service](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Si vous utilisez des modules complémentaires Amazon EKS, dans la console Amazon EKS, sélectionnez **Clusters**, puis le nom du cluster que vous avez mis à jour dans le volet gauche. Les notifications s'affichent dans la console. Elles vous informent qu'une nouvelle version est disponible pour chaque module complémentaire disposant d'une mise à jour disponible. Pour mettre à jour un module complémentaire, sélectionnez l'onglet **Add-ons** (Modules complémentaires). Dans l'une des zones d'un module complémentaire dont une mise à jour est disponible, sélectionnez **Update now (Mettre à jour maintenant)**, sélectionnez une version disponible, puis cliquez sur **Update (Mise à jour)**.
+ Vous pouvez également utiliser la AWS CLI ou mettre `eksctl` à jour des modules complémentaires. Pour de plus amples informations, veuillez consulter [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md).
1. Si nécessaire, mettez à jour votre version de `kubectl`. Vous devez utiliser une version `kubectl` qui se situe à une différence de version mineure près du plan de contrôle de votre cluster Amazon EKS.
## Réduire la version Kubernetes d’un cluster Amazon EKS
Il n’est pas possible de réduire la version Kubernetes d’un cluster Amazon EKS. À la place, créez un nouveau cluster sur une version Amazon EKS précédente et migrer les charges de travail.
# Supprimer un cluster
Lorsque vous avez terminé d’utiliser un cluster Amazon EKS, vous devez supprimer les ressources qui lui sont associées afin de ne pas entraîner de coûts superflus.
Vous pouvez supprimer un cluster à l'aide `eksctl` de la AWS Management Console CLI ou de la AWS CLI.
## Considérations
+ Si vous recevez une erreur en raison de la suppression du créateur du cluster, reportez-vous à [cet article](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error) pour la résoudre.
+ Les ressources du service géré Amazon pour Prometheus ne font pas partie du cycle de vie du cluster et doivent être gérées indépendamment de celui-ci. Lorsque vous supprimez votre cluster, veillez à supprimer également tous les scrapers concernés afin de mettre fin aux coûts applicables. Pour plus d’informations, consultez [Rechercher et supprimer des scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) dans le *Guide de l’utilisateur du Service géré Amazon pour Prometheus*.
+ Pour supprimer un cluster connecté, reportez-vous à la section [Désenregistrer un cluster Kubernetes depuis la console Amazon EKS](deregister-connected-cluster.md)
+ Avant de supprimer un cluster, assurez-vous que la protection contre la suppression est désactivée pour votre cluster.
### Considérations relatives au mode automatique EKS
+ Tous les nœuds du mode automatique EKS seront supprimés, y compris les instances gérées EC2.
+ Tous les équilibreurs de charge seront supprimés.
Pour de plus amples informations, veuillez consulter [Désactivation du mode automatique EKS](auto-disable.md).
## Etapes prérequises
Vous devez d'abord effectuer les étapes suivantes avant de pouvoir supprimer un cluster. Ces étapes s'appliquent quelle que soit la méthode que vous utilisez pour supprimer votre cluster.
1. Répertoriez tous les services qui s'exécutent dans votre cluster.
```
kubectl get svc --all-namespaces
```
1. Supprimez tous les services qui ont une valeur `EXTERNAL-IP` associée. Ces services ont un équilibreur de charge Elastic Load Balancing en avant-plan, et vous devez les supprimer dans Kubernetes pour que l'équilibreur de charge et les ressources associées soient correctement libérés. Remplacez *service-name* par le nom de chaque service répertorié comme décrit.
```
kubectl delete svc service-name
```
1. Supprimez également toutes les ressources d'entrée. Si vous ne supprimez pas les ressources d'entrée, l'équilibreur de charge de l'application est conservé même si vous avez supprimé le cluster. *ingress-name*Remplacez-le par le nom de vos ressources d'entrée.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Supprimer le cluster (eksctl)
Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante :
```
eksctl version
```
Pour les instructions d'installation ou de mise à niveau de `eksctl`, consultez la rubrique [Installation](https://eksctl.io/installation) dans la documentation `eksctl`.
1. Suivez les [étapes préalables](#prerequisite-steps). Ensuite, supprimez votre cluster et les nœuds associés à l'aide de la commande suivante, en les *prod* remplaçant par le nom de votre cluster.
```
eksctl delete cluster --name prod
```
Sortie :
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Supprimer le cluster (AWS console)
1. Suivez les [étapes préalables](#prerequisite-steps). Ensuite, supprimez tous les groupes de nœuds et les profils Fargate.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters** Amazon EKS, puis dans la liste à onglets des clusters, sélectionnez le nom du cluster que vous voulez supprimer.
1. Sélectionnez l'onglet **Calcul** et choisissez un groupe de nœuds à supprimer. Sélectionnez **Supprimer**, saisissez le nom du groupe de nœuds, puis sélectionnez **Supprimer**. Supprimez tous les groupes de nœuds du cluster.
**Note**
Tous les groupes de nœuds répertoriés sont des [groupes de nœuds gérés](managed-node-groups.md).
1. Sélectionnez un **profil Fargate** à supprimer, choisissez **Supprimer**, saisissez le nom du profil, puis sélectionnez **Supprimer**. Supprimez tous les profils Fargate dans le cluster.
1. Supprimez toutes les [piles de nœuds AWS CloudFormation autogérées](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez la pile du nœud à supprimer, puis choisissez **Supprimer**.
1. Dans la boîte de dialogue de confirmation **Delete stack (Supprimer la pile)**, choisissez **Delete stack (Supprimer la pile)**. Supprimez toutes les piles de nœuds autogérées dans le cluster.
1. Supprimez le cluster.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Sélectionnez le cluster à supprimer, puis choisissez **Supprimer**.
1. Dans l'écran de confirmation de suppression du cluster, choisissez **Delete** (Supprimer).
1. (Facultatif) Supprimez la pile VPC. AWS CloudFormation
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez la pile VPC à supprimer, puis choisissez **Delete (Supprimer)**.
1. Dans la boîte de dialogue de confirmation **Delete stack (Supprimer la pile)**, choisissez **Delete stack (Supprimer la pile)**.
## Supprimer le cluster (AWS CLI)
1. Suivez les [étapes préalables](#prerequisite-steps). Ensuite, supprimez tous les groupes de nœuds et les profils Fargate.
1. Répertoriez les groupes de nœuds de votre cluster à l'aide de la commande suivante.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**Note**
Tous les groupes de nœuds répertoriés sont des [groupes de nœuds gérés](managed-node-groups.md).
1. Supprimez chaque groupe de nœuds à l'aide de la commande suivante. Supprimez tous les groupes de nœuds du cluster.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Répétez les profils Fargate dans votre cluster à l'aide de la commande suivante.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Supprimez chaque profil Fargate avec la commande suivante. Supprimez tous les profils Fargate dans le cluster.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Supprimez toutes les [piles de nœuds AWS CloudFormation autogérées](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Répertoriez vos AWS CloudFormation piles disponibles à l'aide de la commande suivante. Identifiez le nom du modèle du nœud dans la sortie obtenue.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Supprimez chaque pile de nœud avec la commande suivante, en remplaçant *node-stack* par le nom de votre pile de nœuds. Supprimez toutes les piles de nœuds autogérées dans le cluster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Supprimez le cluster avec la commande suivante, en remplaçant *my-cluster* par le nom de votre cluster.
```
aws eks delete-cluster --name my-cluster
```
1. (Facultatif) Supprimez la pile VPC. AWS CloudFormation
1. Répertoriez vos AWS CloudFormation piles disponibles à l'aide de la commande suivante. Recherchez le nom du modèle VPC dans la sortie obtenue.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Supprimez la pile VPC avec la commande suivante, en remplaçant *my-vpc-stack* par le nom de votre pile VPC.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Protection des clusters EKS contre toute suppression accidentelle
La suppression accidentelle d’un cluster EKS peut nuire au fonctionnement du cluster Kubernetes.
Vous pouvez désormais protéger les clusters EKS contre toute suppression accidentelle. Si vous activez la protection contre la suppression sur un cluster, vous devez d’abord désactiver cette protection avant de pouvoir supprimer le cluster.
Le but de la protection contre les suppressions est de prévenir les accidents. Vous devez limiter avec soin les personnes autorisées à supprimer des clusters.
Si vous essayez de supprimer un cluster actif dont la protection contre la suppression est activée, vous recevrez un `InvalidRequestException`.
**Important**
**Si vous activez la protection contre la suppression sur un cluster, vous devez disposer des autorisations IAM UpdateClusterConfig et des autorisations DeleteCluster IAM pour d'abord supprimer la protection contre la suppression, puis supprimer le cluster.**
**Note**
Si l’état du cluster est en cours de création, a échoué ou est en cours de suppression, vous pouvez supprimer le cluster même si la protection contre la suppression est activée.
## Pour activer la protection contre la suppression d’un cluster existant
Vous ne pouvez exécuter cette opération que sur un cluster en état actif.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## Pour désactiver la protection contre la suppression d’un cluster existant
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Point de terminaison du serveur d’API du cluster
Cette rubrique vous aide à activer l’accès privé pour le point de terminaison de serveur d’API Kubernetes de votre cluster Amazon EKS et à désactiver complètement l’accès public afin que celui-ci ne soit pas accessible depuis Internet.
Lorsque vous créez un cluster, Amazon EKS crée un point de terminaison pour le serveur d'API Kubernetes géré que vous utilisez pour communiquer avec votre cluster (à l'aide d'outils de gestion Kubernetes comme `kubectl`). Par défaut, ce point de terminaison du serveur d'API est public sur Internet, et l'accès au serveur d'API est sécurisé à l'aide d'une combinaison d' AWS Identity and Access Management (IAM) et de contrôle d'accès basé sur le [rôle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes natif. Ce point de terminaison est connu sous le nom de *point de terminaison public du cluster*. Il existe également un *point de terminaison privé du cluster*. Pour plus d’informations sur le point de terminaison privé du cluster, consultez la section [Point de terminaison privé du cluster](#cluster-endpoint-private) suivante.
## Format du point de terminaison du cluster `IPv6`
EKS crée un point de terminaison à double pile unique selon le format ci-dessous pour tout nouveau cluster `IPv6` créé après octobre 2024. Un *IPv6 cluster* est un cluster que vous sélectionnez `IPv6` dans le paramètre IP family (`ipFamily`) du cluster.
**Example**
Point de public/private terminaison du cluster EKS : `eks-cluster.region.api.aws`
Point de public/private terminaison du cluster EKS : `eks-cluster.region.api.aws`
Point de public/private terminaison du cluster EKS : `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**Note**
Le point de terminaison de cluster à double pile a été introduit en octobre 2024. Pour plus d’informations sur les clusters `IPv6`, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). Les clusters créés avant octobre 2024 utilisent plutôt le format de point de terminaison suivant.
## Format du point de terminaison du cluster `IPv4`
EKS crée un point de terminaison unique au format suivant pour chaque cluster avec `IPv4` sélectionné dans le paramètre de famille d’adresses IP (ipFamily) du cluster :
**Example**
public/private Point final du cluster EKS `eks-cluster.region.eks.amazonaws.com`
public/private Point final du cluster EKS `eks-cluster.region.eks.amazonaws.com`
public/private Point final du cluster EKS `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**Note**
Avant octobre 2024, les clusters `IPv6` utilisaient également ce format de point de terminaison. Pour ces clusters, les points de terminaison public et privé ne résolvaient que des adresses `IPv4`.
## Point de terminaison privé du cluster
Vous pouvez activer l'accès privé au serveur d'API Kubernetes pour que toutes les communications entre vos nœuds et le serveur d'API restent au sein de votre VPC. Vous pouvez limiter les adresses IP qui peuvent accéder à votre serveur API à partir d'Internet, ou désactiver complètement l'accès Internet au serveur d'API.
**Note**
Comme ce point de terminaison est destiné au serveur d'API Kubernetes et n'est pas un point de AWS PrivateLink terminaison traditionnel pour communiquer avec une AWS API, il n'apparaît pas en tant que point de terminaison dans la console Amazon VPC.
Lorsque vous activez l’accès privé au point de terminaison de votre cluster, Amazon EKS crée automatiquement une zone hébergée privée Route 53 et l’associe au VPC de votre cluster. Cette zone hébergée privée est gérée par Amazon EKS et n’apparaît pas dans vos ressources Route 53. Pour que la zone hébergée privée achemine correctement le trafic vers votre serveur d'API, votre VPC doit avoir `enableDnsHostnames` et `enableDnsSupport` définis sur `true`, et les options DHCP définies pour votre VPC doivent inclure `AmazonProvidedDNS` dans leur liste de serveurs de nom de domaine. Pour plus d'informations, consultez [Mise à jour du support DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dans le *Guide de l'utilisateur d'Amazon VPC*.
Vous pouvez définir les exigences d'accès au point de terminaison de votre serveur d'API lorsque vous créez un nouveau cluster, et vous pouvez mettre à jour l'accès au point de terminaison du serveur d'API pour un cluster à tout moment.
## Modification de l'accès au point de terminaison de cluster
Utilisez les procédures de cette section afin de modifier l'accès au point de terminaison pour un cluster existant. Le tableau suivant présente les combinaisons d'accès au point de terminaison de serveur d'API prises en charge et leur comportement.
| Accès public au point de terminaison | Accès privé au point de terminaison | Attitude |
| --- | --- | --- |
| Activé | Désactivé | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/cluster-endpoint.html) |
| Activé | Activé | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/cluster-endpoint.html) |
| Désactivé | Activé | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/cluster-endpoint.html) |
**Contrôles d'accès aux terminaux**
Notez que chacune des méthodes suivantes pour contrôler l'accès au point de terminaison n'affecte que le point de terminaison concerné.
*Groupe de sécurité du cluster*
Le groupe de sécurité du cluster contrôle deux types de connexions : les connexions à l'*API kubelet et* le point de terminaison privé. Les connexions à l'`kubelet`API sont utilisées dans les `kubectl port-forward` commandes `kubectl attach` `kubectl cp``kubectl exec`,`kubectl logs`,, et. Le groupe de sécurité du cluster n'affecte pas le point de terminaison public.
*Accès public CIDRs*
L'*accès public CIDRs contrôle l'*accès au point de terminaison public par une liste de blocs CIDR. Notez que l'accès public n'affecte CIDRs pas le point de terminaison privé. L'accès public CIDRs se comporte différemment sur les `IPv6` `IPv4` clusters et les clusters en fonction de leur date de création, décrite ci-dessous :
**Blocs CIDR dans le point de terminaison public (cluster `IPv6`)**
Vous pouvez ajouter des blocs CIDR `IPv6` et `IPv4` au point de terminaison public d’un cluster `IPv6`, car le point de terminaison public est double pile. Cette option ne s’applique qu’aux nouveaux clusters dont la `ipFamily` est définie sur `IPv6` et qui sont créés en octobre 2024 ou après. Vous pouvez identifier ces clusters grâce à leur nouveau nom de domaine de point de terminaison `api.aws`.
**Blocs CIDR dans le point de terminaison public (cluster `IPv4`)**
Vous pouvez ajouter des blocs CIDR `IPv4` au point de terminaison public d’un cluster `IPv4`. Vous ne pouvez pas ajouter des blocs CIDR `IPv6` au point de terminaison public d’un cluster `IPv4`. Si vous essayez, EKS renvoie le message d’erreur suivant : `The following CIDRs are invalid in publicAccessCidrs`
**Blocs CIDR dans le point de terminaison public (cluster `IPv6` créé avant octobre 2024)**
Vous pouvez ajouter des blocs CIDR `IPv4` au point de terminaison public des anciens clusters `IPv6` que vous avez créés avant octobre 2024. Vous pouvez identifier ces clusters grâce au point de terminaison `eks.amazonaws.com`. Vous ne pouvez pas ajouter des blocs CIDR `IPv6` au point de terminaison public de ces anciens clusters `IPv6` que vous avez créés avant octobre 2024. Si vous essayez, EKS renvoie le message d’erreur suivant : `The following CIDRs are invalid in publicAccessCidrs`
## Accès à un serveur d'API privé uniquement
Si vous avez désactivé l’accès public au point de terminaison du serveur d’API Kubernetes de votre cluster, vous ne pouvez accéder à l’API serveur que depuis votre VPC ou un [réseau connecté](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Voici quelques méthodes d'accès possibles au point de terminaison du serveur d'API Kubernetes :
**Réseau connecté**
Connectez votre réseau au VPC à l'aide d'une [passerelle de transit AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) ou d'une autre option de [connectivité](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html), puis utilisez un ordinateur dans le réseau connecté. Vous devez vous assurer que le groupe de sécurité de votre plan de contrôle Amazon EKS contient des règles pour autoriser le trafic entrant sur le port 443 depuis votre réseau connecté.
**Hôte Amazon EC2 Bastion**
Vous pouvez lancer une EC2 instance Amazon dans un sous-réseau public du VPC de votre cluster, puis vous connecter via SSH à cette instance pour exécuter des commandes. `kubectl` Pour plus d'informations, consultez la section [Hôtes bastions Linux sur AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). Vous devez vous assurer que le groupe de sécurité de votre plan de contrôle Amazon EKS contient des règles pour autoriser le trafic entrant sur le port 443 depuis l'hôte bastion. Pour de plus amples informations, veuillez consulter [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md).
Lorsque vous configurez `kubectl` votre hôte bastion, veillez à utiliser des AWS informations d'identification déjà mappées à la configuration RBAC de votre cluster, ou ajoutez le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que votre bastion utilisera à la configuration RBAC avant de supprimer l'accès public du point de terminaison. Pour plus d’informations, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md) et [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized).
**Environnement de développement intégré AWS Cloud9**
AWS Cloud9 est un environnement de développement intégré (IDE) basé sur le cloud qui vous permet d'écrire, d'exécuter et de déboguer votre code avec un simple navigateur. Vous pouvez créer un IDE AWS Cloud9 dans le VPC de votre cluster et utiliser l'IDE pour communiquer avec votre cluster. Pour plus d'informations, consultez [Création d'un environnement dans AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). Vous devez vous assurer que votre groupe de sécurité de plan de contrôle Amazon EKS contient des règles permettant d'autoriser le trafic entrant sur le port 443 à partir de votre groupe de sécurité IDE. Pour de plus amples informations, veuillez consulter [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md).
Lorsque vous configurez `kubectl` votre IDE AWS Cloud9, veillez à utiliser des AWS informations d'identification déjà mappées à la configuration RBAC de votre cluster, ou ajoutez le principal IAM que votre IDE utilisera à la configuration RBAC avant de supprimer l'accès public des terminaux. Pour plus d’informations, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md) et [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized).
📝 [Modifiez cette page sur GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Configuration de l’accès réseau au point de terminaison du serveur d’API du cluster
Vous pouvez modifier l'accès aux points de terminaison de votre serveur API de cluster à l'aide de la AWS CLI AWS Management Console ou dans les sections suivantes.
## Configuration de l'accès aux points de terminaison - AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster pour afficher les informations le concernant.
1. Sélectionnez l’onglet **Réseau**, puis **Gérer l’accès au point de terminaison**.
1. Pour **Accès privé**, choisissez d’activer ou de désactiver l’accès privé au point de terminaison du serveur d’API Kubernetes de votre cluster. Si vous activez l’accès privé, les requêtes d’API Kubernetes provenant de l’intérieur du VPC de votre cluster utilisent le point de terminaison d’un VPC privé. Vous devez activer l'accès privé pour désactiver l'accès public.
1. Pour **Accès public**, choisissez d’activer ou de désactiver l’accès public au point de terminaison du serveur d’API Kubernetes de votre cluster. Si vous désactivez l’accès public, le serveur d’API Kubernetes de votre cluster peut uniquement recevoir des requêtes provenant de l’intérieur du VPC du cluster.
1. (Facultatif) Si vous avez activé **l’accès public**, vous pouvez spécifier les adresses IP Internet autorisées à communiquer avec le point de terminaison public. Sélectionnez **Advanced Settings (Paramètres avancés)**. Entrez un bloc CIDR, tel que *203.0.113.5/32*. Le bloc ne peut pas inclure d'[adresses réservées](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Vous pouvez entrer des blocs supplémentaires en sélectionnant **Add Source (Ajouter une source)**. Vous pouvez spécifier un nombre maximal de blocs CIDR. Pour de plus amples informations, veuillez consulter [Afficher et gérer les quotas de service Amazon EKS et Fargate](service-quotas.md). Si vous ne spécifiez aucun bloc CIDR, le point de terminaison public du serveur d’API reçoit des requêtes provenant de toutes les adresses IP pour les `IPv4` (`0.0.0.0/0`) et également pour les `IPv6` (`::/0`) dans un cluster `IPv6` à double pile. Si vous limitez l’accès à votre point de terminaison public à l’aide de blocs CIDR, il est recommandé d’activer également l’accès au point de terminaison privé, afin que les nœuds et les pods Fargate Pods (le cas échéant) puissent communiquer avec le cluster. Sans le point de terminaison privé activé, vos sources CIDR de point d’accès public doivent inclure les sources de sortie de votre VPC. Par exemple, si vous avez un nœud dans un sous-réseau privé qui communique à Internet via une passerelle NAT, vous devez ajouter l'adresse IP sortante de la passerelle NAT dans le cadre d'un bloc CIDR autorisé sur votre point de terminaison public.
1. Choisissez **Update** (Mettre à jour) pour terminer.
## Configuration de l'accès aux points de terminaison - AWS CLI
Effectuez les étapes suivantes à l'aide de la version AWS CLI `1.27.160` ou ultérieure. Vous pouvez vérifier votre version actuelle avec `aws --version`. Pour installer ou mettre à niveau la AWS CLI, reportez-vous à la section [Installation de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Mettez à jour l'accès aux points de terminaison de votre serveur d'API de cluster à l'aide de la commande AWS CLI suivante. Remplacez les valeurs par le nom de votre cluster et les valeurs d'accès au point de terminaison souhaitées. Si vous définissez `endpointPublicAccess=true`, vous pouvez (éventuellement) entrer un seul bloc CIDR ou une liste de blocs CIDR séparés par des virgules pour `publicAccessCidrs`. Les blocs ne peuvent pas inclure d'[adresses réservées](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Si vous spécifiez des blocs CIDR, le point de terminaison du serveur d'API public ne recevra que les demandes des blocs répertoriés. Vous pouvez spécifier un nombre maximal de blocs CIDR. Pour de plus amples informations, veuillez consulter [Afficher et gérer les quotas de service Amazon EKS et Fargate](service-quotas.md). Si vous limitez l'accès à votre point de terminaison public à l'aide de blocs CIDR, il est recommandé d'activer également l'accès au point de terminaison privé afin que les nœuds et les Pods Fargate (si vous les utilisez) puissent communiquer avec le cluster. Sans le point de terminaison privé activé, vos sources CIDR de point d’accès public doivent inclure les sources de sortie de votre VPC. Par exemple, si vous avez un nœud dans un sous-réseau privé qui communique à Internet via une passerelle NAT, vous devez ajouter l'adresse IP sortante de la passerelle NAT dans le cadre d'un bloc CIDR autorisé sur votre point de terminaison public. Si vous ne spécifiez aucun bloc CIDR, le point de terminaison public du serveur d’API reçoit des requêtes provenant de toutes les adresses IP (0.0.0.0/0), ainsi que des `IPv6` (`::/0`) dans le cas d’un cluster `IPv6` à double pile.
**Note**
La commande suivante active l'accès privé et l'accès public à partir d'une adresse IP unique pour le point de terminaison du serveur API. Remplacez *203.0.113.5/32* par un seul bloc CIDR ou une liste de blocs CIDR séparés par des virgules auxquels vous souhaitez restreindre l'accès réseau.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
L'exemple qui suit illustre un résultat.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Surveillez le statut de la mise à jour de l'accès à votre point de terminaison avec la commande suivante, en indiquant le nom de votre cluster et l'ID de mise à jour qui a été renvoyé par la commande précédente. Votre mise à jour est terminée lorsqu'elle affiche l'état `Successful`.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
L'exemple qui suit illustre un résultat.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Modifiez cette page sur GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Déployer des nœuds Windows sur des clusters EKS
Découvrez comment activer et gérer la prise en charge de Windows pour votre cluster Amazon EKS afin d’exécuter des conteneurs Windows parallèlement à des conteneurs Linux.
## Considérations
Avant de déployer des nœuds Windows, veuillez tenir compte des considérations suivantes.
+ Le mode automatique EKS ne prend pas en charge les nœuds Windows
+ Vous pouvez utiliser le réseau hôte sur les nœuds Windows à l'aide des pods `HostProcess`. Pour plus d'informations, consultez la section [Créer une fenêtre HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) dans la documentation de Kubernetes.
+ Les clusters Amazon EKS doivent contenir un ou plusieurs nœuds Linux ou Fargate pour exécuter les pods système de base qui ne fonctionnent que sous Linux, tels que CoreDNS.
+ Les journaux d’événements `kubelet` et `kube-proxy` sont journalisés vers le journal d’événements `EKS Windows` et sont limités à 200 Mo.
+ Vous ne pouvez pas utiliser [Attribuer des groupes de sécurité à des pods individuels](security-groups-for-pods.md) avec des pods s’exécutant sur des nœuds Windows.
+ Vous ne pouvez pas utiliser la [mise en réseau personnalisée](cni-custom-network.md) avec des nœuds Windows.
+ Il n’est pas possible d’utiliser `IPv6` avec les nœuds Windows.
+ Les nœuds Windows prennent en charge une interface réseau Elastic par nœud. Par défaut, le nombre de pods pouvant être exécutés par nœud Windows est égal au nombre d’adresses IP disponibles par interface réseau Elastic pour le type d’instance du nœud, moins un. Pour plus d'informations, consultez la section [Adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) dans le *guide de EC2 l'utilisateur Amazon*.
+ Dans un cluster Amazon EKS, un seul service avec un équilibreur de charge peut prendre en charge jusqu’à 1 024 pods dorsaux. Chaque pod a sa propre adresse IP. La limite précédente de 64 pods n’est plus le cas, après [une mise à jour de Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) à partir de [OS Build 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4).
+ Les conteneurs Windows ne sont pas pris en charge pour les pods Amazon EKS sur Fargate.
+ Vous ne pouvez pas utiliser les nœuds hybrides Amazon EKS avec Windows comme système d’exploitation pour l’hôte.
+ Vous ne pouvez pas journaliser les journaux à partir du pod `vpc-resource-controller`. Vous le pouviez auparavant lorsque vous déployiez le contrôleur sur le plan de données.
+ Il y a un temps de stabilisation avant qu'une adresse `IPv4` ne soit affectée à un nouveau pod. Cela empêche le trafic de s'écouler vers un pod plus ancien avec la même adresse `IPv4` en raison de règles `kube-proxy` périmées.
+ La source du contrôleur est gérée sur GitHub. Pour contribuer ou signaler des problèmes contre le contrôleur, consultez le [projet](https://github.com/aws/amazon-vpc-resource-controller-k8s) sur GitHub.
+ Lorsque vous spécifiez un ID AMI personnalisé pour les groupes de nœuds gérés par Windows, ajoutez-le `eks:kube-proxy-windows` à votre carte de configuration AWS IAM Authenticator. Pour de plus amples informations, veuillez consulter [Limites et conditions lors de la spécification d'un ID d'AMI](launch-templates.md#mng-ami-id-conditions).
+ S'il est essentiel de préserver IPv4 les adresses disponibles pour votre sous-réseau, reportez-vous au [Guide des meilleures pratiques d'EKS - Gestion des adresses IP réseau Windows](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) pour obtenir des conseils.
+ Considérations relatives aux entrées d’accès EKS
+ Les entrées d’accès à utiliser avec les nœuds Windows doivent être de type `EC2_WINDOWS`. Pour de plus amples informations, veuillez consulter [Créer des entrées d’accès](creating-access-entries.md).
Pour créer une entrée d’accès pour un nœud Windows :
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/ --type EC2_Windows
```
## Conditions préalables
+ Un cluster existant.
+ Votre cluster doit comporter au moins un nœud Linux ou un pod Fargate (nous recommandons au moins deux) pour exécuter CoreDNS. Si vous activez la prise en charge Windows héritée, vous devez utiliser un nœud Linux (vous ne pouvez pas utiliser un pod Fargate) pour exécuter CoreDNS.
+ Un [rôle IAM de cluster Amazon EKS](cluster-iam-role.md) existant.
## Activer la prise en charge de Windows
1. Si votre cluster ne comporte pas de nœuds Amazon Linux et que vous utilisez des groupes de sécurité pour les pods, passez à l’étape suivante. Sinon, confirmez que la politique gérée `AmazonEKSVPCResourceController` est attachée à votre [rôle de cluster](cluster-iam-role.md). Remplacez *eksClusterRole* par le nom de rôle de votre cluster.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
L'exemple qui suit illustre un résultat.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Si la politique est attachée, comme c'est le cas dans la sortie précédente, passez à l'étape suivante.
1. Associez la politique gérée par **[Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** au [rôle IAM de votre cluster Amazon EKS](cluster-iam-role.md). Remplacez *eksClusterRole* par le nom de rôle de votre cluster.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
1. Mettez à jour le VPC CNI ConfigMap pour activer Windows IPAM. Notez que si le VPC CNI est installé sur votre cluster à l'aide d'un graphique Helm ou en tant que module complémentaire Amazon EKS, vous ne pourrez peut-être pas modifier directement le. ConfigMap Pour plus d’informations sur la configuration des modules complémentaires Amazon EKS, consultez [Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS](kubernetes-field-management.md).
1. Créez un fichier nommé *vpc-resource-controller-configmap.yaml* avec les contenus suivants.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Appliquer le `ConfigMap` à votre cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Si le mode d’authentification de votre cluster est défini pour activer la configmap `aws-auth` :
+ Vérifiez que votre `aws-auth` `ConfigMap` contient un mappage pour le rôle d’instance du nœud Windows afin d’inclure le groupe d’autorisation RBAC `eks:kube-proxy-windows`. Vous pouvez vérifier en exécutant la commande suivante.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
L'exemple qui suit illustre un résultat.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws: iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
Vous devriez voir `eks:kube-proxy-windows` répertorié sous les groupes. Si le groupe n’est pas spécifié, vous devez mettre à jour votre `ConfigMap` ou le créer pour inclure le groupe requis. Pour en savoir plus sur `ConfigMap` `aws-auth`, consultez [Appliquer la `ConfigMap` `aws-auth` à votre cluster](auth-configmap.md#aws-auth-configmap).
1. Si le mode d’authentification de votre cluster est défini pour désactiver la configmap `aws-auth`, vous pouvez utiliser les entrées d’accès EKS. Créez un nouveau rôle de nœud à utiliser avec les instances Windows, et EKS créera automatiquement une entrée d’accès de type `EC2_WINDOWS`.
## Déployer des pods Windows
Lorsque vous déployez des pods sur votre cluster, vous devez spécifier le système d’exploitation qu’ils utilisent si vous exécutez plusieurs types de nœuds.
Pour les pods Linux, utilisez le texte de sélecteur de nœud suivant dans vos manifestes.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Pour les pods Windows, utilisez le texte de sélecteur de nœud suivant dans vos manifestes.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
Vous pouvez déployer un [exemple d'application](sample-deployment.md) pour voir les sélecteurs de nœuds utilisés.
## Prise en charge d’une densité de pods plus élevée sur les nœuds Windows
Dans Amazon EKS, chaque pod se voit attribuer une adresse `IPv4` provenant de votre VPC. De ce fait, le nombre de pods que vous pouvez déployer sur un nœud est limité par les adresses IP disponibles, même si les ressources sont suffisantes pour exécuter davantage de pods sur le nœud. Étant donné qu'une seule interface réseau élastique est prise en charge par un nœud Windows, par défaut, le nombre maximal d'adresses IP disponibles sur un nœud Windows est égal à :
```
Number of private IPv4 addresses for each interface on the node - 1
```
Une adresse IP est utilisée comme adresse IP principale de l’interface réseau, elle ne peut donc pas être attribuée aux pods.
Vous pouvez activer une densité de pods plus élevée sur les nœuds Windows en activant la délégation de préfixe IP. Cette fonctionnalité vous permet d'attribuer un préfixe `/28` `IPv4` à l'interface réseau principale, au lieu d'attribuer des adresses secondaires `IPv4`. L'attribution d'un préfixe IP augmente le nombre maximum d'adresses `IPv4` disponibles sur le nœud à :
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Grâce à ce nombre considérablement plus important d’adresses IP disponibles, celles-ci ne devraient plus limiter votre capacité à faire évoluer le nombre de pods sur vos nœuds. Pour de plus amples informations, veuillez consulter [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md).
# Désactiver la prise en charge Windows
1. Si votre cluster contient des nœuds Amazon Linux et que vous utilisez des [groupes de sécurité pour les pods](security-groups-for-pods.md) avec eux, passez cette étape.
Supprimez la politique IAM gérée `AmazonVPCResourceController` de votre [rôle de cluster](cluster-iam-role.md). Remplacez *eksClusterRole* par le nom de votre rôle de cluster.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Désactivez Windows IPAM dans le ConfigMap `amazon-vpc-cni`.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Déployer des clusters privés avec un accès Internet limité
Cette rubrique décrit comment déployer un cluster Amazon EKS déployé sur le AWS cloud, mais ne disposant pas d'un accès Internet sortant. Si vous avez un cluster local sur AWS Outposts, consultez[Créez des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md), au lieu de cette rubrique.
Si vous n’êtes pas familier avec la mise en réseau Amazon EKS, consultez [Démystifier la mise en réseau des clusters pour les composants master Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Si votre cluster ne dispose pas d’un accès Internet sortant, il doit répondre aux exigences suivantes :
## Exigences en matière d’architecture de cluster
+ Votre cluster doit extraire les images d’un registre de conteneurs situé dans votre VPC. Vous pouvez créer un registre de conteneurs Amazon Elastic Container Registry dans votre VPC et y copier des images de conteneurs pour que vos nœuds puissent les extraire. Pour de plus amples informations, veuillez consulter [Copier une image de conteneur d'un référentiel vers un autre référentiel](copy-image-to-repository.md).
+ Votre cluster doit avoir un accès privé au point de terminaison activé. Ceci est nécessaire pour que les nœuds s'enregistrent auprès du point de terminaison du cluster. L'accès public au point de terminaison est facultatif. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
## Exigences relatives aux nœuds
+ Les nœuds Linux et Windows autogérés doivent inclure les arguments de démarrage suivants avant leur lancement. Ces arguments contournent l’introspection Amazon EKS et ne nécessitent pas d’accès à l’API Amazon EKS depuis le VPC.
1. Déterminez la valeur du point de terminaison de votre cluster à l’aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
L'exemple qui suit illustre un résultat.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Déterminez la valeur de l’autorité de certification de votre cluster à l’aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
La sortie renvoyée est une longue chaîne.
1. Remplacez les valeurs de `apiServerEndpoint` et contenues `certificateAuthority` dans l' NodeConfig objet par les valeurs renvoyées dans le résultat des commandes précédentes. Pour plus d'informations sur la spécification des arguments bootstrap lors du lancement de nœuds Amazon Linux 2023 autogérés, consultez [Créer des nœuds Amazon Linux autogérés](launch-workers.md) et. [Créer des nœuds Microsoft Windows autogérés](launch-windows-workers.md)
+ Pour les nœuds Linux :
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Pour des arguments supplémentaires, consultez le [script bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub.
+ Pour les nœuds Windows :
**Note**
Si vous utilisez un CIDR de service personnalisé, vous devez le spécifier à l’aide du paramètre `-ServiceCIDR`. Sinon, la résolution DNS pour les pods dans le cluster échouera.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Pour des arguments supplémentaires, consultez [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ Le `aws-auth` `ConfigMap` de votre cluster doit être créé à partir de votre VPC. Pour plus d'informations sur la création et l'ajout d'entrées dans la `ConfigMap` `aws-auth`, entrez `eksctl create iamidentitymapping --help` dans votre terminal. Si le `ConfigMap` n’existe pas sur votre serveur, `eksctl` le créera lorsque vous utiliserez la commande pour ajouter un mappage d’identité.
## Exigences relatives aux pods
+ **Identité du pod** : les pods configurés avec l’identité du pod EKS obtiennent leurs informations d’identification à partir de l’API EKS Auth. S’il n’y a pas d’accès Internet sortant, vous devez créer et utiliser un point de terminaison d’un VPC pour l’API EKS Auth : `com.amazonaws.region-code.eks-auth`. Pour plus d’informations sur les points de terminaison d’un VPC EKS et EKS Auth, consultez [Accéder à Amazon EKS à l’aide d’AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA** - Les pods configurés avec des [rôles IAM pour les comptes de service obtiennent des](iam-roles-for-service-accounts.md) informations d'identification à partir d'un appel d'API du AWS Security Token Service (AWS STS). S'il n'y a pas d'accès Internet sortant, vous devez créer et utiliser un point de terminaison VPC AWS STS dans votre VPC. La plupart AWS `v1` SDKs utilisent le point de terminaison AWS STS global par défaut (`sts.amazonaws.com`), qui n'utilise pas le point de terminaison VPC AWS STS. Pour utiliser le point de terminaison VPC AWS STS, vous devrez peut-être configurer votre SDK pour utiliser le point de terminaison AWS STS régional (). `sts.region-code.amazonaws.com` Pour de plus amples informations, veuillez consulter [Configurer le point de terminaison du service de jetons de sécurité AWS pour un compte de service](configure-sts-endpoint.md).
+ Les sous-réseaux VPC de votre cluster doivent disposer d'un point de terminaison d'interface VPC pour tous les AWS services auxquels vos pods doivent accéder. Pour plus d'informations, consultez [Accéder à un AWS service à l'aide d'un point de terminaison VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Certains services et points de terminaison couramment utilisés sont répertoriés dans le tableau suivant. Pour une liste complète des points de terminaison, consultez [Services AWS qui s'intègrent à AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) dans le [Guide AWS PrivateLink ](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Nous vous recommandons d'[activer les noms DNS privés](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) pour vos points de terminaison VPC, afin que les charges de travail puissent continuer à utiliser les points de terminaison de AWS service public sans problème.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/private-clusters.html)
+ Tous les nœuds autogérés doivent être déployés sur des sous-réseaux qui disposent des points de terminaison de l'interface VPC dont vous avez besoin. Si vous créez un groupe de nœuds gérés, le groupe de sécurité des points de terminaison de l'interface VPC doit autoriser le CIDR pour les sous-réseaux, ou vous devez ajouter le groupe de sécurité des nœuds créé au groupe de sécurité des points de terminaison de l'interface VPC.
+ **Stockage EFS** : si vos pods utilisent des volumes Amazon EFS, avant de déployer le [système de fichiers élastique Store avec Amazon EFS, le fichier](efs-csi.md) [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) du pilote doit être modifié pour que les images du conteneur utilisent la AWS même région que le cluster Amazon EKS.
+ Route53 ne prend pas en charge. AWS PrivateLink Vous ne pouvez pas gérer les enregistrements DNS Route53 à partir d’un cluster Amazon EKS privés. Cela a un impact sur Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns).
+ Si vous utilisez l’AMI optimisée EKS, vous devez activer le point de terminaison `ec2` dans le tableau ci-dessus. Vous pouvez également définir manuellement le nom DNS du nœud. L'AMI optimisée permet EC2 APIs de définir automatiquement le nom DNS du nœud.
+ Vous pouvez utiliser le [AWS Load Balancer Controller pour déployer des équilibreurs](aws-load-balancer-controller.md) de charge AWS d'application (ALB) et des équilibreurs de charge réseau sur votre cluster privé. Lors de son déploiement, vous devez utiliser les [indicateurs de ligne de commande](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) pour définir `enable-shield`, `enable-waf` et `enable-wafv2` sur false. La [détection de certificats](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) avec des noms d’hôte provenant d’objets Ingress n’est pas prise en charge. Cela est dû au fait que le contrôleur doit atteindre AWS Certificate Manager, qui ne possède pas de point de terminaison d'interface VPC.
Le contrôleur prend en charge les Network Load Balancers avec des cibles IP, qui sont nécessaires pour une utilisation avec Fargate. Pour plus d’informations, consultez [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) et [Créer un équilibreur de charge de réseau](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) est pris en charge. Lors du déploiement de pods Cluster Autoscaler, assurez-vous que la ligne de commande inclut `--aws-use-static-instance-list=true`. Pour plus d'informations, consultez la section [Utiliser une liste d'instances statiques](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) sur GitHub. Le VPC du nœud de travail doit également inclure le point de terminaison VPC STS et le point de AWS terminaison VPC à mise à l'échelle automatique.
+ Certains logiciels de conteneur utilisent des appels d'API qui accèdent au AWS Marketplace Metering Service pour surveiller l'utilisation. Les clusters privés n’autorisent pas ces appels, vous ne pouvez donc pas utiliser ces types de conteneurs dans les clusters privés.
# Mise à l’échelle du calcul du cluster avec Karpenter et Cluster Autoscaler
La scalabilité automatique est une fonction qui augmente ou diminue automatiquement vos ressources en fonction de l'évolution de la demande. Il s'agit d'une fonction majeure de Kubernetes qui, autrement, nécessiterait des ressources humaines importantes pour être exécutée manuellement.
## Mode automatique EKS
Le mode automatique Amazon EKS met automatiquement à l’échelle les ressources de cluster computing. Si un pod ne peut pas être planifié sur les nœuds existants, le mode automatique EKS en crée un nouveau. Le mode automatique EKS consolide également les charges de travail et supprime les nœuds inutilisés. Le mode automatique EKS s’appuie sur Karpenter.
Pour plus d’informations, consultez :
+ [Automatisation de l’infrastructure du cluster avec le mode automatique EKS](automode.md)
+ [Create a Node Pool for EKS Auto Mode](create-node-pool.md)
+ [Déploiement d’une charge de travail de gonflement dans un cluster du mode automatique Amazon EKS](automode-workload.md)
## Solutions supplémentaires
Amazon EKS prend en charge deux produits d’autoscaling supplémentaires :
**Karpenter**
Karpenter est un autoscaler de cluster Kubernetes flexible et performant qui permet d'améliorer la disponibilité des applications et l'efficacité du cluster. Karpenter lance des ressources de calcul dimensionnées adéquatement (par exemple, des instances Amazon EC2) en moins d’une minute, en réponse à la variation de la charge des applications. Grâce à l'intégration de Kubernetes avec AWS, Karpenter peut allouer des ressources de calcul juste-à-temps qui répondent précisément aux exigences de votre charge de travail. Karpenter alloue automatiquement de nouvelles ressources de calcul en fonction des exigences spécifiques des charges de travail du cluster. Celles-ci comprennent les exigences en matière de calcul, de stockage, d'accélération et de planification. Amazon EKS prend en charge les clusters utilisant Karpenter, bien que Karpenter fonctionne avec tout cluster Kubernetes conforme. Pour en savoir plus, veuillez consulter la documentation [Karpenter](https://karpenter.sh/docs/).
Karpenter est un logiciel open source que les clients AWS sont responsables d’installer, de configurer et de gérer dans leurs clusters Kubernetes. AWS fournit un soutien technique lorsque Karpenter est exécuté sans modification, dans une version compatible, sur des clusters Amazon EKS. Il est essentiel que les clients maintiennent la disponibilité et la sécurité du contrôleur Karpenter ainsi que les procédures de test appropriées lors de sa mise à niveau ou du cluster Kubernetes dans lequel il s’exécute, comme tout autre logiciel géré par le client. Karpenter n’a pas de Contrat de niveau de service (SLA) AWS, et il revient aux clients de s’assurer que les instances EC2 lancées par Karpenter répondent à leurs exigences opérationnelles.
**Cluster Autoscaler**
Le Kubernetes Cluster Autoscaler ajuste automatiquement le nombre de nœuds dans votre cluster lorsque les pods échouent ou sont reprogrammés sur d'autres nœuds. Le Cluster Autoscaler utilise des groupes Auto Scaling. Pour plus d'informations, consultez [Cluster Autoscaler sur AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
# Découvrez le changement de zone du contrôleur de récupération d’application (ARC) Amazon dans Amazon EKS
Kubernetes dispose de fonctionnalités natives qui vous permettent de rendre vos applications plus résilientes face à des événements tels que la dégradation de l’état ou la défaillance d’une zone de disponibilité (AZ). Lorsque vous exécutez vos charges de travail dans un cluster Amazon EKS, vous pouvez améliorer davantage la tolérance aux pannes et la récupération de votre environnement d’application en utilisant le [changement de zone du contrôleur de récupération d’application (ARC) Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) ou le [changement automatique de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html). Le changement de zone ARC est conçu comme une mesure temporaire qui vous permet de déplacer le trafic d’une ressource hors d’une AZ défaillante jusqu’à l’expiration du changement de zone ou jusqu’à ce que vous l’annuliez. Vous pouvez prolonger le changement de zone si nécessaire.
Vous pouvez démarrer un changement de zone pour un cluster EKS, ou vous pouvez autoriser AWS le transfert de trafic pour vous en activant le changement automatique de zone. Ce changement met à jour le flux de trafic east-to-west réseau dans votre cluster afin de ne considérer que les points de terminaison réseau des pods exécutés sur des nœuds de travail comme sains AZs. En outre, tout ALB ou NLB gérant le trafic entrant pour les applications de votre cluster EKS acheminera automatiquement le trafic vers les cibles saines. AZs Pour les clients qui recherchent une disponibilité maximale, dans le cas où une zone de disponibilité serait défaillante, il peut être important de pouvoir détourner tout le trafic de la zone défaillante jusqu’à ce qu’elle soit rétablie. Pour cela, vous pouvez également [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html).
## Comprendre le flux de trafic réseau est-ouest entre les pod
Le diagramme suivant illustre deux exemples de charges de travail, Orders et Products. Le but de cet exemple est de montrer comment les charges de travail et les pods AZs communiquent entre eux dans différents environnements.
![\[Illustration du trafic réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Illustration du trafic réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Pour que Orders puisse communiquer avec Products, Orders doit d’abord résoudre le nom DNS du service de destination. Orders communique avec CoreDNS pour récupérer l’adresse IP virtuelle (IP du cluster) de ce service. Une fois que Orders a résolu le nom du service Products, il envoie le trafic vers cette adresse IP cible.
1. Le kube-proxy s'exécute sur chaque nœud du cluster et surveille en permanence [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)les services. Lorsqu'un service est créé, un EndpointSlice est créé et géré en arrière-plan par le EndpointSlice contrôleur. Chacun EndpointSlice possède une liste ou un tableau de points de terminaison contenant un sous-ensemble d'adresses Pod, ainsi que les nœuds sur lesquels ils s'exécutent. Le kube-proxy configure des règles de routage pour chacun de ces points de terminaison de pods à l’aide de `iptables` sur les nœuds. Le kube-proxy est également responsable d’une forme basique d’équilibrage de charge, redirigeant le trafic destiné à l’adresse IP du cluster d’un service vers l’adresse IP d’un pod directement. Le kube-proxy effectue cette opération en réécrivant l’adresse IP de destination sur la connexion sortante.
1. Les paquets réseau sont ensuite envoyés au Products Pod dans AZ 2 en utilisant ENIs les nœuds respectifs, comme indiqué dans le schéma précédent.
### Comprendre le changement de zone ARC dans Amazon EKS
En cas de défaillance d’une zone de disponibilité dans votre environnement, vous pouvez initier un changement de zone pour votre environnement de cluster Amazon EKS. Vous pouvez également autoriser la gestion du trafic changeant AWS à votre place grâce à l'autoshift zonal. Grâce à l'autoshift zonal, il AWS surveille l'état général de la zone Z et répond à une éventuelle détérioration de la zone Z en transférant automatiquement le trafic vers l'autre zone affectée dans votre environnement de cluster.
Une fois que le décalage de zone est activé avec ARC sur votre cluster Amazon EKS, vous pouvez démarrer un changement de zone ou activer le décalage automatique de zone à l'aide de la console ARC, de la AWS CLI ou du décalage zonal et du décalage automatique de zone. APIs Lors d’un changement de zone EKS, les opérations suivantes sont effectuées automatiquement :
+ Tous les nœuds de la zone de disponibilité affectée sont isolés. Cela empêche le planificateur Kubernetes de planifier de nouveaux pods sur les nœuds de la zone de disponibilité défaillante.
+ Si vous utilisez des [groupes de nœuds gérés](managed-node-groups.md), le [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) est suspendu et votre groupe Auto Scaling est mis à jour pour garantir que les nouveaux nœuds du plan de données EKS ne sont lancés qu'en bon AZs état.
+ Les nœuds de la zone de disponibilité défaillante ne sont pas résiliés et les pods ne sont pas expulsés des nœuds. Cela garantit que lorsque le changement de zone expire ou est annulé, votre trafic peut être renvoyé en toute sécurité vers la zone de disponibilité pour une capacité maximale.
+ Le EndpointSlice contrôleur trouve tous les points de terminaison du Pod dans la zone AZ altérée et les retire de la zone correspondante EndpointSlices. Cela garantit que seuls les terminaux Pod sains AZs sont ciblés pour recevoir du trafic réseau. Lorsqu'un décalage de zone est annulé ou expire, le EndpointSlice contrôleur le met à jour EndpointSlices pour inclure les points de terminaison dans l'AZ restaurée.
Les diagrammes suivants fournissent une vue d’ensemble de la manière dont le changement de zone EKS garantit que seuls les points de terminaison de pods sains sont ciblés dans votre environnement de cluster.
![\[Illustration du trafic réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Illustration du trafic réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Exigences relatives au changement de zone EKS
Pour que le changement de zone fonctionne correctement avec EKS, vous devez configurer votre environnement de cluster à l’avance afin qu’il soit résilient en cas de défaillance d’une zone de disponibilité. Voici une liste d’options de configuration qui contribuent à garantir la résilience.
+ Provisionnez les nœuds de travail de votre cluster sur plusieurs AZs
+ Provisionnez une capacité de calcul suffisante pour faire face à la suppression d’une seule AZ
+ Pré-dimensionnez vos pods, y compris CoreDNS, dans chaque AZ
+ Répartissez plusieurs répliques de Pod sur l'ensemble du site AZs, afin de garantir que lorsque vous abandonnerez un seul AZ, vous disposerez toujours d'une capacité suffisante
+ Effectuez la colocalisation des pods interdépendants ou liés dans la même zone de disponibilité
+ Vérifiez que votre environnement de cluster fonctionne comme prévu sans une zone de disponibilité en démarrant manuellement un changement de zone à partir d’une zone de disponibilité. Vous pouvez également activer le transfert automatique de zone et vous fier aux essais de transfert automatique. Il n’est pas nécessaire de tester les déplacements manuels ou les tests de déplacement de zone pour que le changement de zone fonctionne dans EKS, mais cela est fortement recommandé.
### Provisionnez vos composants master EKS dans plusieurs zones de disponibilité
AWS Les régions disposent de plusieurs sites distincts dotés de centres de données physiques, appelés zones de disponibilité (AZs). AZs sont conçus pour être physiquement isolés les uns des autres afin d'éviter un impact simultané susceptible d'affecter une région entière. Lorsque vous provisionnez un cluster EKS, nous vous recommandons de déployer vos nœuds de travail sur plusieurs nœuds au AZs sein d'une même région. Cela permet de rendre votre environnement de cluster plus résilient face à la détérioration d'une seule AZ et vous permet de maintenir une haute disponibilité pour vos applications qui s'exécutent dans l'autre AZs. Lorsque vous amorcez un changement de zone par rapport à l'AZ concernée, le réseau intégré au cluster de votre environnement EKS se met automatiquement à jour pour n'utiliser que les zones saines AZs, afin de maintenir la haute disponibilité de votre cluster.
Le fait de disposer d’une configuration multi-AZ pour votre environnement EKS améliore la fiabilité globale de votre système. Cependant, les environnements multi-AZ influencent la manière dont les données des applications sont transférées et traitées, ce qui a un impact sur les frais de réseau de votre environnement. Plus précisément, le trafic sortant fréquent entre les zones (trafic réparti entre les zones AZs) peut avoir un impact majeur sur les coûts liés à votre réseau. Vous pouvez appliquer différentes stratégies pour contrôler le volume de trafic inter-zones entre les pods de votre cluster EKS et réduire les coûts associés. Pour plus d’informations sur la manière d’optimiser les coûts réseau lors de l’exécution d’environnements EKS hautement disponibles, consultez [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
Le schéma suivant illustre un environnement EKS à haute disponibilité avec trois environnements sains. AZs
![\[Illustration du réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-ha-before-failure.png)
Le schéma suivant montre comment un environnement EKS composé de trois AZs est résilient à une déficience de l'AZ et reste hautement disponible car il en reste deux en bonne santé AZs.
![\[Illustration du réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-ha-after-failure.png)
### Provisionner une capacité de calcul suffisante pour faire face à la suppression d’une seule zone de disponibilité
Afin d’optimiser l’utilisation des ressources et les coûts de votre infrastructure de calcul dans le plan de données EKS, il est une bonne pratique d’aligner la capacité de calcul sur les exigences de votre charge de travail. Cependant, **si tous vos composants master sont à pleine capacité**, vous devez ajouter de nouveaux composants master au plan de données EKS avant de pouvoir planifier de nouveaux pods. Lorsque vous exécutez des charges de travail critiques, il est généralement recommandé de disposer d’une capacité redondante en ligne pour faire face à des scénarios tels que des augmentations soudaines de la charge et des problèmes d’état des nœuds. Si vous prévoyez d’utiliser le changement de zone, vous envisagez de supprimer toute la capacité d’une zone de disponibilité en cas de défaillance. Cela signifie que vous devez ajuster votre capacité de calcul redondante de manière à ce qu'elle soit suffisante pour gérer la charge, même en AZs mode hors ligne.
Lorsque vous mettez à l’échelle vos ressources de calcul, le processus d’ajout de nouveaux nœuds au plan de données EKS prend un certain temps. Cela peut avoir des implications sur les performances en temps réel et la disponibilité de vos applications, en particulier en cas de défaillance de zone. Votre environnement EKS doit être capable d’absorber la charge liée à la perte d’une zone de disponibilité sans entraîner de dégradation de l’expérience pour vos utilisateurs finaux ou vos clients. Cela implique de réduire au minimum ou d’éliminer le décalage entre le moment où un nouveau pod est nécessaire et celui où il est effectivement planifié sur un composants master.
En outre, en cas d'altération de la zone, vous devez vous efforcer d'atténuer le risque de vous heurter à une contrainte de capacité de calcul qui empêcherait l'ajout de nouveaux nœuds à votre plan de données EKS en mode sain. AZs
Pour réduire le risque de ces impacts négatifs potentiels, nous vous recommandons de surallouer la capacité de calcul de certains nœuds de travail de chacun des AZs. Ce faisant, le planificateur Kubernetes dispose d'une capacité préexistante pour le placement de nouveaux pods, ce qui est particulièrement important lorsque vous perdez l'un d'entre eux dans votre environnement. AZs
### Exécuter et répartir plusieurs réplicas de pod entre les zones de disponibilité
Kubernetes vous permet de mettre à l’échelle vos charges de travail à l’avance en exécutant plusieurs instances (réplicas de pod) d’une même application. L’exécution de plusieurs réplicas de pods pour une application élimine les points de défaillance uniques et augmente les performances globales en réduisant la pression sur les ressources d’un seul réplica. Toutefois, pour bénéficier à la fois d’une haute disponibilité et d’une meilleure tolérance aux pannes pour vos applications, nous vous recommandons d’exécuter plusieurs réplicas de votre application et de répartir les réplicas sur différents domaines de défaillance, également appelés domaines topologiques. Dans ce scénario, les domaines de défaillance sont les zones de disponibilité. En utilisant des [contraintes de répartition topologique](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), vous pouvez configurer vos applications pour qu’elles bénéficient d’une stabilité statique préexistante. Ensuite, en cas de défaillance de l'AZ, votre environnement disposera de suffisamment de répliques en bon état AZs pour gérer immédiatement les pics ou les pics de trafic.
Le schéma suivant illustre un environnement EKS où le east-to-west trafic est fluide lorsque tout le monde est AZs en bonne santé.
![\[Illustration du réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-spread-constraints.png)
Le schéma suivant illustre un environnement EKS caractérisé par un flux de east-to-west trafic dans lequel un seul AZ est défaillant et où vous avez entamé un changement de zone.
![\[Illustration du réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-spread-constraints-2.png)
L’extrait de code suivant est un exemple de configuration de votre charge de travail avec plusieurs réplicas dans Kubernetes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Il est essentiel d’exécuter plusieurs réplicas de votre logiciel de serveur DNS (CoreDNS/kube-dns) et d’appliquer des contraintes de répartition topologique similaires, si elles ne sont pas configurées par défaut. Cela permet de garantir qu'en cas de défaillance d'AZ unique, vous disposez de suffisamment de pods DNS sains pour continuer AZs à traiter les demandes de découverte de service pour les autres pods communicants du cluster. Le module complémentaire [CoreDNS EKS](managing-coredns.md) possède des paramètres par défaut pour les modules CoreDNS qui garantissent que, si AZs plusieurs nœuds sont disponibles, ils sont répartis dans les zones de disponibilité de votre cluster. Si vous le souhaitez, vous pouvez remplacer ces paramètres par défaut par vos propres configurations personnalisées.
Lorsque vous installez [CoreDNS avec Helm](https://github.com/coredns/helm/tree/master), vous pouvez mettre à jour le `replicaCount` dans le [fichier values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) afin de vous assurer que vous disposez d’un nombre suffisant de réplicas dans chaque zone de disponibilité. En outre, pour vous assurer que ces répliques sont réparties entre les différents AZs environnements de votre cluster, veillez à mettre à jour la `topologySpreadConstraints` propriété dans le même `values.yaml` fichier. L’extrait de code suivant illustre comment vous pouvez configurer CoreDNS pour cela.
**CoreDNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
En cas de défaillance d’une zone de disponibilité, vous pouvez absorber la charge accrue sur les pods CoreDNS en utilisant un système autoscaling pour CoreDNS. Le nombre d’instances DNS dont vous aurez besoin dépend du nombre de charges de travail exécutées dans votre cluster. CoreDNS est lié au CPU, ce qui lui permet de s’adapter en fonction du CPU à l’aide du [Horizontal Pod Autoscaler (HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa). Voici un exemple que vous pouvez modifier en fonction de vos besoins.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
EKS peut également gérer l’autoscaling du déploiement CoreDNS dans la version du module complémentaire EKS de CoreDNS. Cet autoscaler CoreDNS surveille en continu l’état du cluster, y compris le nombre de nœuds et le nombre de cœurs de processeur. Sur la base de ces informations, le contrôleur ajuste dynamiquement le nombre de réplicas du déploiement CoreDNS dans un cluster EKS.
Pour activer la [configuration de l’autoscaling dans le module complémentaire CoreDNS EKS](coredns-autoscaling.md), utilisez le paramètre de configuration suivant :
```
{
"autoScaling": {
"enabled": true
}
}
```
Vous pouvez également utiliser le [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) ou l'[autoscaler proportionnel au cluster pour dimensionner](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) CoreDNS. Pour plus d’informations, consultez [Mise à l’échelle horizontale de CoreDNS](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally).
### Colocaliser les pod interdépendants dans la même zone de disponibilité
Généralement, les applications ont des charges de travail distinctes qui doivent communiquer entre elles pour mener à bien un end-to-end processus. Si ces applications distinctes sont réparties entre différentes zones AZs et ne sont pas hébergées dans la même zone, une seule altération de la zone Z peut avoir un impact sur le end-to-end processus. **Par exemple, si **l'application A** possède plusieurs répliques en AZ 1 et AZ 2, mais que **l'application B** possède toutes ses répliques en AZ 3, la perte de l'AZ 3 affectera les end-to-end processus entre les deux charges de travail, l'**application A et l'application** B.** Si vous combinez les contraintes de dispersion topologique avec l'affinité des pods, vous pouvez améliorer la résilience de votre application en répartissant les pods sur l'ensemble du site. AZs De plus, cela permet de configurer une relation entre certains pods afin de garantir leur colocalisation.
Grâce aux [règles d’affinité des pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), vous pouvez définir des relations entre les charges de travail afin d’influencer le comportement du planificateur Kubernetes, de manière à ce qu’il effectue la colocalisation des pods sur le même nœud de travail ou dans la même AZ. Vous pouvez également configurer le niveau de rigueur des contraintes de planification.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
Le diagramme suivant montre plusieurs pods que le planificateur a colocalisés sur le même nœud à l’aide des règles d’affinité des pods.
![\[Illustration du réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Vérifier que votre environnement de cluster peut gérer la perte d’une zone de disponibilité
Une fois que vous avez rempli les conditions décrites dans les sections précédentes, l’étape suivante consiste à vérifier que vous disposez d’une capacité de calcul et de charge de travail suffisante pour gérer la perte d’une zone de disponibilité. Pour ce faire, vous pouvez lancer manuellement un changement de zone dans EKS. Vous pouvez également activer le transfert automatique de zone et configurer des essais, qui permettent également de vérifier que vos applications fonctionnent comme prévu avec une zone de disponibilité en moins dans votre environnement de cluster.
## Questions fréquentes (FAQ)
**Pourquoi utiliser cette fonctionnalité ?**
En utilisant le changement de zone ARC ou le transfert automatique de zone dans votre cluster EKS, vous pouvez mieux maintenir la disponibilité des applications Kubernetes en automatisant le processus de récupération rapide consistant à transférer le trafic réseau du cluster hors d’une zone de disponibilité défaillante. Avec ARC, vous pouvez éviter les étapes longues et compliquées qui peuvent entraîner une période de récupération prolongée lors d’événements de défaillance d’une zone de disponibilité.
**Comment fonctionne cette fonctionnalité avec les autres AWS services ?**
EKS s'intègre à ARC, qui fournit l'interface principale dans laquelle vous pouvez effectuer des opérations de restauration AWS. Afin de garantir que le routage du trafic au sein du cluster soit correctement acheminé hors d’une zone de disponibilité défaillante, EKS modifie la liste des points de terminaison réseau pour les pods s’exécutant dans le plan de données Kubernetes. Si vous utilisez Elastic Load Balancing pour le routage du trafic externe vers le cluster, vous pouvez enregistrer vos équilibreurs de charge auprès d’ARC et lancer un changement de zone sur ceux-ci afin d’empêcher le trafic d’affluer vers la zone de disponibilité dégradée. Zonal Shift fonctionne également avec les groupes Amazon EC2 Auto Scaling créés par des groupes de nœuds gérés par EKS. Afin d’empêcher qu’une zone de disponibilité défaillante ne soit utilisée pour de nouveaux pods Kubernetes ou le lancement de nouveaux nœuds, EKS supprime la zone de disponibilité défaillante des groupes Auto Scaling.
**En quoi cette fonctionnalité diffère-t-elle des protections Kubernetes par défaut ?**
Cette fonctionnalité fonctionne en tandem avec plusieurs protections intégrées à Kubernetes qui contribuent à la résilience des applications des clients. Vous pouvez configurer des sondes de disponibilité et de vitalité des pods qui déterminent quand un pod doit prendre en charge le trafic. Lorsque ces sondes échouent, Kubernetes supprime ces pods en tant que cibles pour un service, et le trafic n’est plus envoyé au pod. Bien que cela soit utile, il n’est pas simple pour les clients de configurer ces surveillances de l’état de manière à garantir leur échec lorsqu’une AZ est dégradée. La fonctionnalité de changement de zone ARC fournit un filet de sécurité supplémentaire qui vous aide à isoler entièrement une AZ dégradée lorsque les protections natives de Kubernetes ne sont pas suffisantes. Le changement de zone vous offre également un moyen simple de tester la disponibilité opérationnelle et la résilience de votre architecture.
**Puis-je AWS commencer un changement de zone en mon nom ?**
Oui, si vous voulez utiliser le changement de zone ARC de manière entièrement automatisée, vous pouvez activer le changement automatique de zone ARC. Avec le changement automatique de zone, vous pouvez compter sur vous AWS pour surveiller l'état de santé de votre cluster EKS et AZs pour démarrer automatiquement un changement de zone lorsqu'une altération de l'AZ est détectée.
**Que se passe-t-il si j’utilise cette fonctionnalité et que mes composants master et mes charges de travail ne sont pas mis à l’échelle au préalable ?**
Si vous n’avez pas effectué de mise à l’échelle préalable et que vous comptez sur le provisionnement de nœuds ou de pod supplémentaires pendant un changement de zone, vous risquez un retard dans la récupération. Le processus d’ajout de nouveaux nœuds au plan de données Kubernetes prend un certain temps, ce qui peut avoir un impact sur les performances en temps réel et la disponibilité de vos applications, en particulier en cas de défaillance de zone. En outre, en cas d'altération de la zone, vous pouvez rencontrer une contrainte de capacité de calcul potentielle qui pourrait empêcher l'ajout de nouveaux nœuds au nœud sain AZs.
Si vos charges de travail ne sont pas prédimensionnées et réparties sur l'ensemble AZs de votre cluster, une altération zonale peut avoir un impact sur la disponibilité d'une application exécutée uniquement sur les nœuds de travail dans une zone de zone affectée. Afin d’atténuer le risque d’une interruption complète de la disponibilité de votre application, EKS dispose d’un dispositif de sécurité qui permet d’envoyer le trafic vers les points de terminaison des pods dans une zone défaillante si cette charge de travail a tous ses points de terminaison dans la zone de disponibilité défaillante. Cependant, nous vous recommandons vivement de pré-dimensionner et de répartir vos applications sur l'ensemble du AZs site afin de maintenir la disponibilité en cas de problème de zone.
**Comment cela fonctionne-t-il si j’exécute une application avec état ?**
Si vous exécutez une application avec état, vous devez évaluer sa tolérance aux pannes en fonction de votre cas d’utilisation et de votre architecture. Si vous avez une active/standby architecture ou un modèle, il se peut que l'actif se trouve dans un AZ altéré. Au niveau de l’application, si l’instance de secours n’est pas activée, vous risquez de rencontrer des problèmes avec votre application. Vous pouvez également rencontrer des problèmes lorsque de nouveaux pods Kubernetes sont lancés en bon état AZs, car ils ne pourront pas se connecter aux volumes persistants liés à l'AZ altérée.
**Cette fonctionnalité est-elle compatible avec Karpenter ?**
La prise en charge de Karpenter n’est actuellement pas disponible avec le changement de zone ARC et le changement automatique de zone dans EKS. Si un AZ est altéré, vous pouvez ajuster la NodePool configuration Karpenter correspondante en supprimant l'AZ défectueux afin que les nouveaux nœuds de travail ne soient lancés que dans l'autre AZs.
**Cette fonctionnalité est-elle compatible avec EKS Fargate ?**
Cette fonctionnalité n’est pas compatible avec EKS Fargate. Par défaut, lorsqu'EKS Fargate reconnaît un événement sanitaire dans une zone, Pods préfère fonctionner dans l'autre zone. AZs
**Le plan de contrôle Kubernetes géré par Amazon EKS sera-t-il affecté ?**
Non, par défaut, Amazon EKS exécute et adapte le plan de contrôle Kubernetes sur plusieurs plans afin de garantir une AZs haute disponibilité. Le changement de zone ARC et le déplacement automatique de zone n’agissent que sur le plan de données Kubernetes.
**Cette nouvelle fonctionnalité entraîne-t-elle des coûts supplémentaires ?**
Vous pouvez utiliser le changement de zone ARC et le changement automatique de zone dans votre cluster EKS sans frais supplémentaires. Cependant, vous continuerez à payer les instances provisionnées et nous vous recommandons vivement de mettre à l’échelle au préalable votre plan de données Kubernetes avant d’utiliser cette fonctionnalité. Il est important de trouver un équilibre entre le coût et la disponibilité des applications.
## Ressources supplémentaires
+ [Comment fonctionne un changement de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Bonnes pratiques pour le changement de zone dans ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Ressources et scénarios pris en charge pour le changement de zone et le changement automatique de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Exécution de charges de travail résilientes sur Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Élimination du décalage de mise à l’échelle des nœuds Kubernetes grâce à la priorité des pods et au surprovisionnement](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Mise à l’échelle des pods CoreDNS pour un trafic DNS élevé](coredns-autoscaling.md)
# Activer le changement de zone EKS pour éviter les zones de disponibilité défaillantes
Amazon Application Recovery Controller (ARC) vous aide à gérer et à coordonner la restauration de vos applications dans toutes les zones de disponibilité (AZs) et fonctionne avec de nombreux services, dont Amazon EKS. Grâce à la prise en charge par EKS du changement de zone ARC, vous pouvez déplacer le trafic réseau au sein du cluster hors d’une AZ défaillante. Vous pouvez également autoriser AWS à surveiller l'état de votre AZ en mauvais état AZs et à transférer temporairement le trafic réseau hors de portée en votre nom.
**Comment utiliser le changement de zone EKS :**
1. Activez votre cluster EKS avec le contrôleur de récupération d’application (ARC) Amazon. Cela se fait au niveau du cluster à l'aide de la console Amazon EKS, de la AWS CLI ou de eksctl. CloudFormation
1. Une fois activé, vous pouvez gérer les changements de zone ou les changements automatiques de zone à l'aide de la console ARC, de la AWS CLI ou du décalage zonal et du décalage automatique de zone. APIs
Veuillez noter qu’après avoir enregistré un cluster EKS avec ARC, vous devez encore configurer ARC. Par exemple, vous pouvez utiliser la console ARC pour configurer le changement de zone.
Pour plus d’informations sur le fonctionnement du changement de zone EKS et sur la conception de vos charges de travail pour gérer les zones de disponibilité défaillantes, consultez [Découvrez le changement de zone du contrôleur de récupération d’application (ARC) Amazon dans Amazon EKS](zone-shift.md).
## Considérations
+ Le mode automatique EKS ne prend pas en charge le contrôleur de récupération d’application Amazon, le changement de zone et le déplacement automatique de zone.
+ Nous vous recommandons d’attendre au moins 60 secondes entre chaque opération de changement de zone afin de garantir le traitement correct de chaque demande.
Si vous essayez d’effectuer des changements de zone successifs (à moins de 60 secondes d’intervalle), le service Amazon EKS risque de ne pas traiter correctement toutes les demandes de changement. Cela est dû au mécanisme de sondage actuel qui met à jour l’état de zone du cluster. Si vous devez effectuer plusieurs changements de zone, veillez à laisser suffisamment de temps entre les opérations pour que le système puisse traiter chaque changement.
## Qu’est-ce qu’Amazon Application Recovery Controller ?
Le contrôleur de récupération d’application (ARC) Amazon vous aide à vous préparer et à accélérer la récupération des applications exécutées sur AWS. Le changement de zone vous permet de vous remettre rapidement en cas de défaillance d'une zone de disponibilité (AZ), en déplaçant temporairement le trafic d'une ressource prise en charge d'une zone Z vers un trafic normal AZs dans la AWS région.
[En savoir plus sur le contrôleur de récupération d’application (ARC) Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## Qu’est-ce que le changement de zone ?
Le changement de zone est une fonctionnalité d'ARC qui vous permet de déplacer le trafic vers une ressource telle qu'un cluster EKS ou un Elastic Load Balancer hors d'une zone de disponibilité d' AWS une région afin d'atténuer rapidement un problème et de récupérer rapidement votre application. Vous pouvez choisir de déplacer le trafic, par exemple, parce qu’un mauvais déploiement entraîne des problèmes de latence ou parce que la zone de disponibilité est défaillante. Un changement de zone ne nécessite aucune configuration préalable.
[En savoir plus sur le changement de zone ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## Qu’est-ce que le changement de zone autoshift ?
L'autoshift zonal est une fonctionnalité d'ARC que vous pouvez activer pour autoriser AWS le transfert du trafic d'un AZ pour les ressources prises en charge, en votre nom, vers un trafic sain AZs dans la AWS région. AWS lance un changement automatique lorsque la télémétrie interne indique la présence d'une anomalie dans un AZ d'une région susceptible d'avoir un impact sur les clients. La télémétrie interne intègre des métriques provenant de plusieurs sources, notamment le AWS réseau et les services Amazon EC2 et Elastic Load Balancing.
AWS met fin aux changements automatiques lorsque les indicateurs indiquent qu'il n'y a plus de problème ou de problème potentiel.
[En savoir plus sur le changement automatique de zone ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## Que fait EKS pendant un changement automatique ?
EKS met à jour les configurations réseau pour éviter de rediriger le trafic vers des zones altérées AZs. De plus, si vous utilisez des groupes de nœuds gérés, EKS ne lancera de nouveaux nœuds dans les nœuds sains que AZs lors d'un changement de zone. Lorsque le changement de zone expire ou est annulé, les configurations réseau seront restaurées pour inclure l’AZ qui avait été précédemment détectée comme non fonctionnelle.
[En savoir plus sur le changement de zone EKS](zone-shift.md).
## Enregistrer le cluster EKS auprès d'Amazon Application Recovery Controller (ARC) (AWS console)
1. Recherchez le nom et la région du cluster EKS que vous voulez enregistrer avec ARC.
1. Accédez à la [console EKS](https://console.aws.amazon.com/eks) dans cette région et sélectionnez votre cluster.
1. Sur la page **Informations sur le cluster**, sélectionnez l’onglet **Vue d’ensemble**.
1. Sous l’en-tête **Changement de zone**, sélectionnez le bouton **Gérer**.
1. Sélectionnez **activer** ou **désactiver** pour *Changement de zone EKS*.
Votre cluster EKS est désormais enregistré auprès d’ARC.
Si vous souhaitez AWS détecter et éviter les zones de disponibilité altérées, vous devez configurer l'autoshift par zone ARC. Vous pouvez par exemple le faire dans la console ARC.
## Étapes suivantes
+ Découvrez comment [activer le changement automatique de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Découvrez comment [lancer manuellement un changement de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html).