**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.
# Déployez Amazon EKS sur site avec AWS Outposts
Vous pouvez utiliser Amazon EKS pour exécuter des applications Kubernetes sur site sur AWS Outposts. Vous pouvez déployer Amazon EKS sur des Outposts avec :
+ **Clusters étendus** : exécutez le plan de contrôle Kubernetes dans une région AWS et les nœuds sur votre Outpost.
+ **Clusters locaux** : exécutez le plan de contrôle Kubernetes et les nœuds sur votre Outpost.
Pour les deux options de déploiement, le plan de contrôle Kubernetes est entièrement géré par AWS. Vous pouvez utiliser les API, les outils et la console Amazon EKS que vous utilisez dans le cloud pour créer et exécuter Amazon EKS sur des Outposts.
Le schéma suivant illustre ces options de déploiement.
![\[Options de déploiement Outpost\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/outposts-deployment-options.png)
## Quand utiliser chaque option de déploiement
Les clusters locaux et étendus sont des options de déploiement polyvalentes et peuvent être utilisées pour de nombreuses applications.
Avec les clusters locaux, vous pouvez exécuter l'intégralité du cluster Amazon EKS localement sur des Outposts. Cette option permet de réduire le risque d'interruption des applications qui pourrait résulter de déconnexions temporaires du réseau au cloud. Ces déconnexions du réseau peuvent être causées par des coupures de fibre ou des événements météorologiques. Étant donné que l'ensemble du cluster Amazon EKS s'exécute localement sur les Outposts, les applications restent disponibles. Vous pouvez effectuer des opérations de cluster en cas de déconnexion du réseau au cloud. Pour de plus amples informations, consultez [Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau](eks-outposts-network-disconnects.md). Si vous êtes préoccupé par la qualité de la connexion réseau entre vos Outposts et la région parent AWS et que vous avez besoin d’une haute disponibilité en cas de déconnexion réseau, utilisez l’option de déploiement en cluster local.
Avec les clusters étendus, vous pouvez économiser de la capacité sur votre Outpost, car le plan de contrôle Kubernetes s’exécute dans la région parent AWS. Cette option est adaptée si vous pouvez investir dans une connectivité réseau fiable et redondante entre votre Outpost et la région AWS. La qualité de la connexion réseau est essentielle pour cette option. La manière dont Kubernetes gère les déconnexions réseau entre le plan de contrôle Kubernetes et les nœuds peut entraîner des durées d’indisponibilité des applications. Pour plus d’informations sur le comportement de Kubernetes, consultez les sections [Planification, Préemption et Expulsion](https://kubernetes.io/docs/concepts/scheduling-eviction/) dans la documentation Kubernetes.
## Comparaison des options de déploiement
Le tableau suivant compare les différences entre les deux options.
| Fonctionnalité | Cluster étendu | Cluster local |
| --- | --- | --- |
| Emplacement du plan de contrôle Kubernetes | Région AWS | Outpost |
| Compte du plan de contrôle Kubernetes | Compte AWS | Votre compte |
| Disponibilité par région | consultez [points de terminaison de service](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | USA Est (Ohio), USA Est (Virginie du Nord), USA Ouest (Californie du Nord), USA Ouest (Oregon), Asie-Pacifique (Séoul), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Canada (Centre), Europe (Francfort), Europe (Irlande), Europe (Londres), Moyen-Orient (Bahreïn) et Amérique du Sud (São Paulo) |
| Versions Kubernetes mineures | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. |
| Versions de plateforme | Consulter [Version deplateforme EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | Consultez [Découvrez les versions des plateformes Kubernetes et Amazon EKS pour Outposts AWS](eks-outposts-platform-versions.md) |
| Facteurs de forme Outpost | Racks Outpost | Racks Outpost |
| Interfaces utilisateur | AWS Management Console, AWS CLI, API Amazon EKS`eksctl`, AWS CloudFormation et Terraform | AWS Management Console, AWS CLI, API Amazon EKS`eksctl`, AWS CloudFormation et Terraform |
| Politiques gérées | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) et [AWS politique gérée : Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) et [AWS politique gérée : Amazon EKSLocal OutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) |
| VPC et sous-réseaux de cluster | Consultez [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md) | Consultez [Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur AWS Outposts](eks-outposts-vpc-subnet-requirements.md) |
| Accès au point de terminaison de cluster | Public, privé ou les deux | Privés uniquement |
| Authentification du serveur d’API Kubernetes | Gestion des identités et des accès AWS (IAM) et OIDC | IAM et certificats `x.509` |
| Types de nœud | Autogérés uniquement | Autogérés uniquement |
| Types de nœuds de calcul | Amazon EC2 à la demande | Amazon EC2 à la demande |
| Types de stockage de nœuds | SSD `gp2` Amazon EBS et NVMe local | SSD `gp2` Amazon EBS et NVMe local |
| AMI optimisées pour Amazon EKS | Amazon Linux, Windows et Bottlerocket | Amazon Linux uniquement |
| Versions d'adresses IP | `IPv4` uniquement | `IPv4` uniquement |
| Modules complémentaires | Modules complémentaires ou autogérés Amazon EKS | Module complémentaire autogéré uniquement |
| Interface réseau de conteneurs par défaut | Plugin CNI Amazon VPC pour Kubernetes | Plugin CNI Amazon VPC pour Kubernetes |
| Journaux du plan de contrôle Kubernetes | Amazon CloudWatch Logs | Amazon CloudWatch Logs |
| Équilibrage de charge | Utilisez l’[AWS Load Balancer Controller](aws-load-balancer-controller.md) pour allouer des Application Load Balancers uniquement (pas de Network Load Balancers) | Utilisez l’[AWS Load Balancer Controller](aws-load-balancer-controller.md) pour allouer des Application Load Balancers uniquement (pas de Network Load Balancers) |
| Chiffrement d'enveloppe des secrets | Consultez [Chiffrer les secrets Kubernetes avec KMS sur les clusters existants](enable-kms.md) | Non pris en charge |
| Rôles IAM pour les comptes de service | Consultez [Rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md) | Non pris en charge |
| Dépannage | Consultez [Résolution des problèmes liés aux clusters et aux nœuds Amazon EKS](troubleshooting.md) | Consultez [Résoudre les problèmes liés aux clusters Amazon EKS locaux sur Outposts AWS](eks-outposts-troubleshooting.md) |
**Topics**
# Créez des clusters Amazon EKS locaux sur AWS Outposts pour une haute disponibilité
Vous pouvez utiliser des clusters locaux pour exécuter l’intégralité de votre cluster Amazon EKS localement sur AWS Outposts. Cela permet de réduire le risque d'interruption des applications qui pourrait résulter de déconnexions temporaires du réseau au cloud. Ces déconnexions peuvent être causées par des coupures de fibre ou des événements météorologiques. Étant donné que l’ensemble du cluster Kubernetes s’exécute localement sur les Outposts, les applications restent disponibles. Vous pouvez effectuer des opérations de cluster en cas de déconnexion du réseau au cloud. Pour de plus amples informations, consultez [Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau](eks-outposts-network-disconnects.md). Le schéma suivant illustre un déploiement de cluster local.
![\[Cluster local Outpost\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/outposts-local-cluster.png)
Les clusters locaux sont généralement disponibles pour une utilisation avec les racks Outposts.
## Régions AWS prises en charge
Vous pouvez créer des clusters locaux dans les régions AWS suivantes : USA Est (Ohio), USA Est (Virginie du Nord), USA Ouest (Californie du Nord), USA Ouest (Oregon), Asie-Pacifique (Séoul), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Canada (Centre), Europe (Francfort), Europe (Irlande), Europe (Londres), Moyen-Orient (Bahreïn) et Amérique du Sud (São Paulo). Pour des informations détaillées sur les fonctions prises en charge, consultez [Comparaison des options de déploiement](eks-outposts.md#outposts-overview-comparing-deployment-options).
**Topics**
# Déployez un cluster Amazon EKS sur AWS Outposts
Cette rubrique fournit une vue d'ensemble des éléments à prendre en compte lors de l'exécution d'un cluster local sur un Outpost. Elle donne également des instructions pour déployer un cluster local sur un Outpost.
**Important**
Ces considérations ne figurent pas dans la documentation Amazon EKS associée. Si d'autres rubriques de la documentation Amazon EKS entrent en conflit avec les considérations présentées ici, suivez ces dernières.
Ces considérations sont sujettes à modification et peuvent changer fréquemment. Nous vous recommandons donc de consulter régulièrement cette rubrique.
De nombreuses considérations sont différentes de celles relatives à la création d'un cluster sur le AWS cloud.
+ Les clusters locaux prennent uniquement en charge les racks Outpost. Un seul cluster local peut s'exécuter sur plusieurs racks Outpost physiques qui constituent un seul Outpost logique. Un seul cluster local ne peut pas s’exécuter sur plusieurs Outposts logiques. Chaque Outpost logique possède un seul ARN d'Outpost.
+ Les clusters locaux exécutent et gèrent le plan de contrôle Kubernetes sur votre compte sur l’Outpost. Vous ne pouvez pas exécuter de charges de travail sur les instances du plan de contrôle Kubernetes ni modifier les composants du plan de contrôle Kubernetes. Ces nœuds sont gérés par le service Amazon EKS. Les modifications apportées au plan de contrôle Kubernetes ne sont pas conservées lors des actions de gestion automatique d’Amazon EKS, telles que l’application de correctifs.
+ Les clusters locaux prennent en charge les modules complémentaires autogérés et les groupes de nœuds Amazon Linux autogérés. Le plug-in [Amazon VPC CNI pour Kubernetes](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md) et les modules complémentaires [CoreDNS](managing-coredns.md) sont automatiquement installés sur les clusters locaux.
+ Les clusters locaux nécessitent l'utilisation d'Amazon EBS sur les Outposts. Amazon EBS doit être disponible dans votre Outpost pour le stockage du plan de contrôle Kubernetes. Les Outposts prennent en charge les volumes `gp2` Amazon EBS uniquement.
+ Les Kubernetes `PersistentVolumes` basés sur Amazon EBS sont pris en charge à l’aide du pilote CSI Amazon EBS.
+ Les instances du plan de contrôle des clusters locaux sont configurées selon une [topologie empilée à haute disponibilité](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Deux des trois instances du plan de contrôle doivent être saines à tout moment pour maintenir le quorum. Si le quorum est perdu, contactez le AWS support, car certaines actions côté service seront nécessaires pour activer les nouvelles instances gérées.
**Conditions préalables**
+ Connaissance des options de [déploiement des Outposts](eks-outposts.md#outposts-overview-comparing-deployment-options)[, de la sélection des types d'instances et des groupes de placement pour les clusters Amazon EKS sur les AWS Outposts en fonction de considérations relatives à la capacité, ainsi que des exigences et considérations relatives aux](eks-outposts-capacity-considerations.md) [VPC](eks-outposts-vpc-subnet-requirements.md).
+ Un Outpost existant. Pour plus d'informations, consultez [What is AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ L'outil de ligne de commande `kubectl` est installé sur votre ordinateur 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 | 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 avec des autorisations pour `create` et `describe` 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).
Lorsqu'un cluster Amazon EKS local est créé, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui crée le cluster est ajouté de manière permanente. Le principal est spécifiquement ajouté à la table d’autorisation RBAC Kubernetes en tant qu’administrateur. Cette entité possède des autorisations `system:masters`. L’identité de cette entité n’est pas visible dans la configuration de votre cluster. Il est donc important de noter l’entité qui a créé le cluster et de veiller à ne jamais la supprimer. Initialement, seul le principal qui a créé le serveur peut effectuer des appels vers le serveur d’API Kubernetes à l’aide de `kubectl`. Si vous utilisez la console pour créer le cluster, assurez-vous que les mêmes informations d'identification IAM figurent dans la chaîne d'identification du AWS SDK lorsque vous exécutez des `kubectl` commandes sur votre cluster. Une fois votre cluster créé, vous pouvez accorder à d'autres principaux IAM l'accès à votre cluster.
## Créer un cluster local Amazon EKS
Vous pouvez créer un cluster local à l’aide des outils suivants décrits dans cette page :
+ [`eksctl`](#eksctl_create_cluster_outpost)
+ [AWS Management Console](#console_create_cluster_outpost)
Vous pouvez également utiliser la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), l'[API Amazon EKS [AWS SDKs](https://aws.amazon.com/developer/tools/)](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html)ou [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) pour créer des clusters sur Outposts.
### `eksctl`
**Pour créer un cluster avec `eksctl`**
1. Installez la version `0.215.0` ou une version ultérieure de l'outil de ligne de `eksctl` commande 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. Copiez les contenus suivants sur votre appareil. Remplacez les valeurs suivantes, puis exécutez la commande modifiée pour créer le fichier `outpost-control-plane.yaml` :
+ *region-code*Remplacez-le [par la AWS région prise en charge](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) dans laquelle vous souhaitez créer votre cluster.
+ 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 dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ Remplacez *vpc-ExampleID1* et *subnet-ExampleID1* par le IDs VPC et le sous-réseau existants. Le VPC et le sous-réseau doivent répondre aux exigences de la section Créer [un VPC et des sous-réseaux pour les clusters Amazon](eks-outposts-vpc-subnet-requirements.md) EKS sur les Outposts. AWS
+ Remplacez *uniqueid* par l'identifiant de votre avant-poste.
+ Remplacez *m5.large* par un type d'instance disponible sur votre Outpost. Avant de choisir un type d'instance, consultez [Sélection des types d’instances et des groupes de placement pour les clusters Amazon EKS sur AWS Outposts en fonction de considérations de capacité](eks-outposts-capacity-considerations.md). Trois instances du plan de contrôle sont déployées. Vous ne pouvez pas modifier ce nombre.
```
cat >outpost-control-plane.yaml <
**Pour créer votre cluster à l’aide de AWS Management Console **
1. Vous devez disposer d’un VPC et d’un sous-réseau existants qui répondent aux exigences d’Amazon EKS. Pour de plus amples informations, veuillez consulter [Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur AWS Outposts](eks-outposts-vpc-subnet-requirements.md).
1. Si vous avez déjà un rôle IAM de cluster local, 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": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Créez le rôle IAM de cluster Amazon EKS. 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 myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json"
```
1. Associez la politique gérée Amazon EKS nommée [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) 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/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole
```
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En haut de l'écran de la console, assurez-vous que vous avez sélectionné une [AWS région prise en charge](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions).
1. Choisissez **Add cluster (Ajouter un cluster)**, puis choisissez **Create (Créer)**.
1. Sur la page **Configurer le cluster**, saisissez ou sélectionnez les valeurs des champs suivants :
+ **Emplacement du plan de contrôle Kubernetes — Choisissez Outposts**. AWS
+ **ID Outpost** (ID d'Outpost) – Choisissez l'ID de l'Outpost sur lequel vous souhaitez créer votre plan de contrôle.
+ **Instance type** (Type d'instance) – Sélectionnez un type d'instance. Seuls les types d'instances disponibles dans votre Outpost sont affichés. Dans la liste déroulante, chaque type d'instance indique le nombre de nœuds pour lesquels le type d'instance est recommandé. Avant de choisir un type d'instance, consultez [Sélection des types d’instances et des groupes de placement pour les clusters Amazon EKS sur AWS Outposts en fonction de considérations de capacité](eks-outposts-capacity-considerations.md). Tous les réplicas sont déployés à l'aide du même type d'instance. Vous ne pouvez pas modifier le type d’instance une fois le cluster créé. Trois instances du plan de contrôle sont déployées. Vous ne pouvez pas modifier ce nombre.
+ **Nom** : nom de votre cluster. Il doit être unique dans votre AWS compte. 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 dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ **Version Kubernetes** : choisissez la version Kubernetes que vous souhaitez utiliser pour votre cluster. Nous vous recommandons de sélectionner la dernière version, sauf si vous devez utiliser une version antérieure.
+ **Rôle de service de cluster : choisissez le rôle** IAM du cluster Amazon EKS que vous avez créé à l'étape précédente pour permettre au plan de contrôle Kubernetes de gérer les ressources. AWS
+ **Accès administrateur du cluster Kubernetes** : si vous souhaitez que le principal IAM (rôle ou utilisateur) qui crée le cluster dispose d’un accès administrateur aux objets Kubernetes du cluster, acceptez la valeur par défaut (autoriser). Amazon EKS crée une entrée d'accès pour le principal IAM et accorde des autorisations d'administrateur du cluster à cette entrée d'accès. Pour plus d'informations sur les entrées d'accès, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
Si vous souhaitez qu’un principal IAM différent du principal qui crée le cluster dispose d’un accès administrateur aux objets du cluster Kubernetes, choisissez l’option Interdire. Après la création du cluster, tout principal IAM disposant des autorisations IAM pour créer des entrées d’accès peut ajouter des entrées d’accès pour tous les principaux IAM ayant besoin d’accéder aux objets du cluster Kubernetes. Pour plus d'informations sur les autorisations IAM requises, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) dans la Référence des autorisations de service. Si vous choisissez l’option d’interdiction et que vous ne créez aucune entrée d’accès, aucun principal IAM n’aura accès aux objets Kubernetes du cluster.
+ **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. Le VPC doit disposer d'un nombre suffisant d'adresses IP disponibles pour le cluster, pour tous les nœuds et pour les autres ressources Kubernetes que vous souhaitez créer. Votre VPC doit répondre aux exigences indiquées dans [Exigences relatives aux VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **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. Les sous-réseaux que vous choisissez doivent répondre aux exigences énoncées dans la section [Exigences et considérations relatives aux sous-réseaux](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements).
+ **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. Amazon EKS crée automatiquement 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 choisissez d’ajouter vos propres groupes de sécurité, vous ne pouvez pas modifier ceux que vous choisissez après la création du cluster. Pour que les hôtes sur site puissent communiquer avec le point de terminaison du cluster, vous devez autoriser le trafic entrant provenant du groupe de sécurité du cluster. Pour les clusters qui n’ont pas de connexion Internet entrante et sortante (également connus sous le nom de clusters privés), vous devez effectuer l’une des opérations suivantes :
+ Ajoutez le groupe de sécurité associé aux points de terminaison d'un VPC requis. Pour plus d'informations sur les points de terminaison requis, voir [Utilisation des points de terminaison de VPC d'interface](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints) la section [Accès aux AWS services par sous-réseau](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services).
+ Modifiez le groupe de sécurité qu'Amazon EKS a créé pour autoriser le trafic provenant du groupe de sécurité associé aux points de terminaison d'un VPC. Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**.
1. Sur la page **Configurer l'observabilité**, vous pouvez éventuellement choisir les options de **Métriques** et de **Journalisation du plan de contrôle** que vous voulez activer. 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 **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é.
L'approvisionnement de cluster dure plusieurs minutes.
## Afficher votre cluster local Amazon EKS
1. Une fois votre cluster créé, vous pouvez afficher les instances du plan de contrôle Amazon EC2 qui ont été créées.
```
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane
```
L'exemple qui suit illustre un résultat.
```
"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"
```
Chaque instance est rejetée avec `node-role.eks-local.amazonaws.com/control-plane` pour qu'aucune charge de travail ne soit planifiée sur les instances du plan de contrôle. Pour plus d’informations sur les rejets, consultez la section [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation Kubernetes. Amazon EKS surveille en permanence l'état des clusters locaux. Nous effectuons des actions de gestion automatiques, telles que des correctifs de sécurité et la réparation des instances défectueuses. Lorsque des clusters locaux sont déconnectés du cloud, nous prenons des mesures pour nous assurer que le cluster retrouve un état sain lors de la reconnexion.
1. Si vous avez créé votre cluster à l'aide de `eksctl`, vous pouvez sauter cette étape. `eksctl` complète cette étape pour vous. Activez `kubectl` pour communiquer avec votre cluster en ajoutant un nouveau contexte au fichier `kubectl` `config`. Pour savoir comment créer et mettre à jour le 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. Pour vous connecter au serveur d’API Kubernetes de votre cluster local, vous devez avoir accès à la passerelle locale pour le sous-réseau ou vous connecter depuis le VPC. Pour plus d'informations sur la connexion d'un rack Outpost à votre réseau local, consultez [Comment fonctionnent les passerelles locales pour les racks dans](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) le Guide de l'utilisateur d' AWS Outposts. Si vous utilisez le routage VPC direct et que le sous-réseau Outpost possède un acheminement vers votre passerelle locale, les adresses IP privées des instances du plan de contrôle Kubernetes sont automatiquement diffusées sur votre réseau local. Le point de terminaison du serveur d’API Kubernetes du cluster local est hébergé dans Amazon Route 53 (Route 53). Le point de terminaison du service d'API peut être résolu par des serveurs DNS publics vers les adresses IP privées des serveurs d'API Kubernetes.
Les instances du plan de contrôle Kubernetes des clusters locaux sont configurées avec des interfaces réseau Elastic statiques et des adresses IP privées fixes qui ne changent pas tout au long du cycle de vie du cluster. Les appareils qui interagissent avec le serveur d’API Kubernetes peuvent ne pas avoir de connectivité à Route 53 pendant les déconnexions du réseau. Si tel est le cas, nous recommandons de configurer `/etc/hosts` avec les adresses IP privées statiques pour la poursuite des opérations. Nous vous recommandons également de configurer des serveurs DNS locaux et de les connecter à votre Outpost. Pour plus d’informations, consultez la [documentation AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Exécutez la commande suivante pour confirmer que la communication est établie avec votre cluster.
```
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
```
1. (Facultatif) Testez l'authentification auprès de votre cluster local lorsqu'il est déconnecté du AWS cloud. Pour obtenir des instructions, veuillez consulter [Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau](eks-outposts-network-disconnects.md).
### Ressources internes
Amazon EKS crée les ressources suivantes sur votre cluster. Les ressources sont destinées à un usage interne d'Amazon EKS. Pour le bon fonctionnement de votre cluster, ne modifiez pas ces ressources.
+ Les [mirror pods](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod) suivants :
+ `aws-iam-authenticator-node-hostname `
+ `eks-certificates-controller-node-hostname `
+ `etcd-node-hostname `
+ `kube-apiserver-node-hostname `
+ `kube-controller-manager-node-hostname `
+ `kube-scheduler-node-hostname `
+ Les modules complémentaires autogérés suivants :
+ `kube-system/coredns`
+ `kube-system/``kube-proxy` (non créé tant que vous n’avez pas ajouté votre premier nœud)
+ `kube-system/aws-node` (non créé tant que vous n'avez pas ajouté votre premier nœud). Les clusters locaux utilisent le plug-in CNI Amazon VPC pour Kubernetes pour la mise en réseau des clusters. Ne modifiez pas la configuration des instances du plan de contrôle (pods nommés `aws-node-controlplane-*`). Il existe des variables de configuration que vous pouvez utiliser pour modifier la valeur par défaut lorsque le plugin crée de nouvelles interfaces réseau. Pour plus d'informations, consultez la [documentation](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) sur GitHub.
+ Les services suivants :
+ `default/kubernetes`
+ `kube-system/kube-dns`
+ Une politique `PodSecurityPolicy` nommée `eks.system`
+ Un rôle `ClusterRole` nommé `eks:system:podsecuritypolicy`
+ Un rôle `ClusterRoleBinding` nommé `eks:system`
+ Outre le [groupe de sécurité du cluster](sec-group-reqs.md), Amazon EKS crée un groupe de sécurité nommé dans votre AWS compte`eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Ce groupe de sécurité permet au trafic de circuler librement entre les composants Kubernetes exécutés sur les instances du plan de contrôle.
Étapes suivantes recommandées :
+ [Accordez au principal IAM qui a créé le cluster les autorisations requises pour consulter les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ [Accordez aux entités IAM l'accès à votre cluster](grant-k8s-access.md). Si vous souhaitez que les entités puissent afficher les ressources Kubernetes dans la console Amazon EKS, accordez-leur les [autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ [Configurer la journalisation de votre cluster](control-plane-logs.md)
+ Familiarisez-vous avec ce qui se passe en cas de [déconnexion du réseau](eks-outposts-network-disconnects.md).
+ [Ajouter des nœuds à votre cluster](eks-outposts-self-managed-nodes.md)
+ Envisagez de mettre en place un plan de sauvegarde pour votre `etcd`. Amazon EKS ne prend pas en charge la sauvegarde et la restauration automatisées d’`etcd` pour les clusters locaux. Pour plus d’informations, consultez la section [Sauvegarde d’un cluster etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) dans la documentation Kubernetes. Les deux options principales utilisent `etcdctl` pour automatiser la prise d'instantanés ou l'utilisation de la sauvegarde des volumes de stockage Amazon EBS.
# Découvrez les versions des plateformes Kubernetes et Amazon EKS pour Outposts AWS
Les versions de la plateforme de cluster locale représentent les capacités du cluster Amazon EKS sur AWS Outposts. Les versions comprennent les composants qui s’exécutent sur le plan de contrôle Kubernetes, pour lesquels les drapeaux du serveur d’API Kubernetes sont activés. Elles comprennent également la version actuelle du correctif Kubernetes. Une ou plusieurs versions de plateforme sont associées à chaque version mineure de Kubernetes. Les versions de plateforme pour les différentes versions mineures de Kubernetes sont indépendantes. Les versions de plateforme pour les clusters locaux et les clusters Amazon EKS dans le cloud sont indépendantes.
Lorsqu’une nouvelle version mineure de Kubernetes est disponible pour les clusters locaux, telle que `1.31`, la version initiale de la plateforme pour cette version mineure de Kubernetes commence à `eks-local-outposts.1`. Cependant, Amazon EKS publie régulièrement de nouvelles versions de plateforme pour activer de nouveaux paramètres de plan de contrôle Kubernetes et fournir des correctifs de sécurité.
Lorsque de nouvelles versions de plateforme de clusters locaux deviennent disponibles pour une version mineure :
+ Le numéro de version de plateforme est incrémenté (`eks-local-outposts.n+1`).
+ Amazon EKS met automatiquement à jour tous les clusters locaux existants vers la dernière version de plateforme pour les versions mineures Kubernetes correspondantes. Les mises à jour automatiques de versions de plateforme existantes sont déployées de façon incrémentielle. Le processus de déploiement consiste à remplacer les instances du plan de contrôle Kubernetes gérées qui s’exécutent sur Outpost, une par une, jusqu’à ce que les trois instances soient remplacées par de nouvelles.
+ Le processus de remplacement de l’instance du plan de contrôle Kubernetes s’arrêtera s’il existe un risque d’interruption du service. Amazon EKS ne tentera de remplacer une instance que si les deux autres instances du plan de contrôle Kubernetes sont en bon état et remplissent toutes les conditions de disponibilité en tant que nœud de cluster.
+ Le déploiement d’une version de plateforme prend généralement moins de 30 minutes. Si un cluster reste `UPDATING` actif pendant une période prolongée, consultez le Support [Résoudre les problèmes liés aux clusters Amazon EKS locaux sur Outposts AWS](eks-outposts-troubleshooting.md) et demandez de l' AWS aide. Ne mettez jamais fin manuellement aux instances du plan de contrôle Kubernetes, sauf indication contraire du Support. AWS
+ Amazon EKS peut publier une nouvelle AMI de nœud avec une version de correctif correspondante. Toutes les versions de correctif sont compatibles entre le plan de contrôle et le nœud Kubernetes AMIs pour une seule version mineure de Kubernetes.
Les nouvelles versions de plateforme n’introduisent pas des modifications importantes ou ne provoquent pas des interruptions de service.
Les clusters locaux sont toujours créés avec la dernière version disponible de la plateforme (`eks-local-outposts.n`) pour la version Kubernetes spécifiée.
Les versions actuelles et récentes de plateforme sont décrites dans les tableaux ci-dessous.
Pour recevoir des notifications concernant toutes les modifications apportées aux fichiers sources de cette page de documentation spécifique, vous pouvez vous abonner à l’URL suivante à l’aide d’un lecteur RSS :
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom
```
## Version de Kubernetes `1.31`
Les contrôleurs d’admission suivants sont activés pour toutes les versions de plateforme `1.31` : `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` et `ValidatingAdmissionWebhook`.
| Version de Kubernetes | Version de la plateforme Amazon EKS | Notes de mise à jour | Date de publication |
| --- | --- | --- | --- |
| `1.31.14` | `eks-local-outposts.8` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.31.14` AWS Authentificateur IAM mis à jour vers. `v0.7.8` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.4`. Version de Bottlerocket mise à jour vers `v1.52.0`. | 23 décembre 2025 |
| `1.31.12` | `eks-local-outposts.5` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.31.10` AWS Authentificateur IAM mis à jour vers. `v0.7.4` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.2`. Version de Bottlerocket mise à jour vers `v1.47.0`. | 3 octobre 2025 |
| `1.31.9` | `eks-local-outposts.4` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.31.9` AWS Authentificateur IAM mis à jour vers. `v0.7.2` Le plugin Amazon VPC CNI pour Kubernetes a été mis à jour vers la version de Bottlerocket mise à jour vers. `v1.20.0` `v1.43.0` | 9 août 2025 |
| `1.31.7` | `eks-local-outposts.3` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.31.9` AWS Authentificateur IAM mis à jour vers. `v0.7.1` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.5`. Version de Bottlerocket mise à jour vers `v1.40.0`. | 19 juin 2025 |
| `1.31.6` | `eks-local-outposts.2` | Nouvelle version de la plateforme avec des corrections de sécurité et des améliorations. Version de Bottlerocket mise à jour vers `v1.36.0`. | 24 avril 2025 |
| `1.31.6` | `eks-local-outposts.1` | Lancement initial de la version `v1.31` de Kubernetes pour les clusters locaux Amazon EKS sur des Outposts. | 9 avril 2025 |
## Version de Kubernetes `1.30`
Les contrôleurs d’admission suivants sont activés pour toutes les versions de plateforme `1.30` : `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` et `ValidatingAdmissionWebhook`.
| Version de Kubernetes | Version de la plateforme Amazon EKS | Notes de mise à jour | Date de publication |
| --- | --- | --- | --- |
| `1.30.14` | `eks-local-outposts.10` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. AWS Authentificateur IAM mis à jour vers. `v0.7.8` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.4`. Version de Bottlerocket mise à jour vers `v1.52.0`. | 23 décembre 2025 |
| `1.30.14` | `eks-local-outposts.7` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.30.14` AWS Authentificateur IAM mis à jour vers. `v0.7.4` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.2`. Version de Bottlerocket mise à jour vers `v1.47.0`. | 3 octobre 2025 |
| `1.30.13` | `eks-local-outposts.6` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.30.13` AWS Authentificateur IAM mis à jour vers. `v0.7.2` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.0`. Version de Bottlerocket mise à jour vers `v1.43.0`. | 9 août 2025 |
| `1.30.11` | `eks-local-outposts.5` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.30.11` AWS Authentificateur IAM mis à jour vers. `v0.7.1` Le plugin Amazon VPC CNI pour Kubernetes a été mis à jour vers la version de Bottlerocket mise à jour vers. `v1.19.5` `v1.40.0` | 19 juin 2025 |
| `1.30.10` | `eks-local-outposts.4` | Nouvelle version de la plateforme avec des corrections de sécurité et des améliorations. Version de Bottlerocket mise à jour vers `v1.36.0`. | 24 avril 2025 |
| `1.30.10` | `eks-local-outposts.3` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.30.10` AWS Authentificateur IAM mis à jour vers. `v0.6.29` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.2`. CoreDNS mis à jour vers. `v1.11.4` AWS Cloud Controller Manager a été mis à jour vers`v1.30.8`. Version de Bottlerocket mise à jour vers `v1.34.0`. | 27 mars 2025 |
| `1.30.7` | `eks-local-outposts.2` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.30.7` AWS Authentificateur IAM mis à jour vers. `v0.6.28` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.0`. Version de Bottlerocket mise à jour vers. `v1.29.0` | 10 janvier 2025 |
| `1.30.5` | `eks-local-outposts.1` | Lancement initial de la version `v1.30` de Kubernetes pour les clusters locaux Amazon EKS sur des Outposts. | 13 novembre 2024 |
## Version de Kubernetes `1.29`
Les contrôleurs d’admission suivants sont activés pour toutes les versions de plateforme `1.29` : `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` et `ValidatingAdmissionWebhook`.
| Version de Kubernetes | Version de la plateforme Amazon EKS | Notes de mise à jour | Date de publication |
| --- | --- | --- | --- |
| `1.29.15` | `eks-local-outposts.13` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. AWS Authentificateur IAM mis à jour vers. `v0.7.8` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.4`. Version de Bottlerocket mise à jour vers `v1.52.0`. | 23 décembre 2025 |
| `v1.29.15` | `eks-local-outposts.10` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. AWS Authentificateur IAM mis à jour vers. `v0.7.4` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.2`. Version de Bottlerocket mise à jour vers `v1.47.0`. | 3 octobre 2025 |
| `v1.29.15` | `eks-local-outposts.9` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. AWS Authentificateur IAM mis à jour vers. `v0.7.2` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.20.0`. Version de Bottlerocket mise à jour vers `v1.43.0`. | 9 août 2025 |
| `v1.29.15` | `eks-local-outposts.8` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.29.15` AWS Authentificateur IAM mis à jour vers. `v0.7.1` Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.5`. Version de Bottlerocket mise à jour vers `v1.40.0`. | 19 juin 2025 |
| `v1.29.14` | `eks-local-outposts.7` | Nouvelle version de la plateforme avec des corrections de sécurité et des améliorations. Version de Bottlerocket mise à jour vers `v1.36.0`. | 24 mars 2025 |
| `v1.29.14` | `eks-local-outposts.6` | Nouvelle version de plateforme avec des corrections de sécurité et des améliorations. kube-proxy mis à jour vers `v1.29.14`. Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.2`. CoreDNS mis à jour vers. `v1.11.4` AWS Cloud Controller Manager a été mis à jour vers`v1.29.8`. Version de Bottlerocket mise à jour vers `v1.34.0`. | 27 mars 2025 |
| `v1.29.11` | `eks-local-outposts.5` | Nouvelle version de plateforme avec des corrections de sécurité et des améliorations. kube-proxy mis à jour vers `v1.29.11`. Mise à jour du plugin CNI Amazon VPC pour Kubernetes vers `v1.19.0`. Mise à jour de l’image de CoreDNS vers `v1.11.3`. Version de Bottlerocket mise à jour vers. `v1.29.0` | 10 janvier 2025 |
| `1.29.9` | `eks-local-outposts.4` | Nouvelle version de la plateforme avec correctifs et améliorations de sécurité. Kube-proxy mis à jour vers. `v1.29.9` AWS Authentificateur IAM mis à jour vers. `v0.6.26` Version de Bottlerocket mise à jour vers. `v1.26.0` | 8 novembre 2024 |
| `1.29.6` | `eks-local-outposts.3` | Nouvelle version de la plateforme avec des corrections de sécurité et des améliorations. Version de Bottlerocket mise à jour vers. `v1.22.0` | 22 octobre 2024 |
| `1.29.6` | `eks-local-outposts.2` | Nouvelle version de la plateforme avec des corrections de sécurité et des améliorations. Version de Bottlerocket mise à jour vers. `v1.21.0` | 27 août 2024 |
| `1.29.6` | `eks-local-outposts.1` | Lancement initial de la version `v1.29` de Kubernetes pour les clusters locaux Amazon EKS sur des Outposts. | 20 août 2024 |
# Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur AWS Outposts
Lorsque vous créez un cluster local, vous spécifiez un VPC et au moins un sous-réseau privé qui fonctionne sur les Outposts. Cette rubrique fournit une vue d'ensemble des exigences et considérations spécifiques au VPC et aux sous-réseaux pour votre cluster local.
## Exigences et considérations requises pour le VPC
Lorsque vous créez un cluster local, le VPC que vous spécifiez doit répondre aux exigences et aux considérations suivantes :
+ Assurez-vous que le VPC dispose d’un nombre suffisant d’adresses IP pour le cluster local, tous les nœuds et les autres ressources Kubernetes que vous souhaitez créer. Si le VPC que vous souhaitez utiliser ne dispose pas de suffisamment d’adresses IP, augmentez le nombre d’adresses IP disponibles. Vous pouvez effectuer cette opération en [associant des blocs d'adresse CIDR (Routage inter-domaines sans classe) supplémentaires](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) avec votre VPC. Vous pouvez associer des blocs d'adresses CIDR privés (RFC 1918) et publics (non-RFC 1918) à votre VPC avant ou après la création de votre cluster. Un cluster peut prendre jusqu'à 5 heures avant qu'un bloc d'adresse CIDR associé à un VPC ne soit reconnu.
+ Le VPC ne peut pas avoir de préfixes IP ou de blocs d’adresses CIDR IPv6 attribués. En raison de ces contraintes, les informations fournies dans [Attribuer davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md) et [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md) ne s’appliquent pas à votre VPC.
+ Le VPC possède un nom d'hôte DNS et une résolution DNS activés. Sans ces fonctions, la création du cluster local échoue, et vous devez activer les fonctions et recréer votre cluster. Pour plus d'informations, consultez [Attributs DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) dans le guide de l'utilisateur d'Amazon VPC.
+ Pour accéder à votre cluster local via votre réseau local, le VPC doit être associé à la table de routage de la passerelle locale de votre Outpost. Pour plus d’informations, consultez [Associations de VPC](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) dans le Guide de l’utilisateur AWS Outposts.
## Exigences et considérations requises pour les sous-réseaux
Lorsque vous créez le cluster, spécifiez au moins un sous-réseau privé. Si vous spécifiez plusieurs sous-réseaux, les instances du plan de contrôle Kubernetes sont réparties uniformément à travers les sous-réseaux. Si plus d'un sous-réseau est spécifié, les sous-réseaux doivent exister sur le même Outpost. En outre, les sous-réseaux doivent également disposer d'un acheminement et d'autorisations de groupe de sécurité appropriés pour communiquer entre eux. Lorsque vous créez un cluster local, les sous-réseaux que vous spécifiez doivent répondre aux exigences suivantes :
+ Les sous-réseaux doivent se trouver sur le même Outpost logique.
+ Les sous-réseaux doivent disposer ensemble d’au moins trois adresses IP disponibles pour les instances du plan de contrôle Kubernetes. Si trois sous-réseaux sont spécifiés, chaque sous-réseau doit avoir au moins une adresse IP disponible. Si deux sous-réseaux sont spécifiés, chaque sous-réseau doit avoir au moins deux adresses IP disponibles. Si un sous-réseau est spécifié, le sous-réseau doit avoir au moins trois adresses IP disponibles.
+ Les sous-réseaux disposent d’une route vers la [passerelle locale](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) du rack Outpost pour accéder au serveur API Kubernetes via votre réseau local. Si les sous-réseaux ne disposent pas d’une route vers la passerelle locale du rack Outpost, vous devez communiquer avec votre serveur API Kubernetes depuis l’intérieur du VPC.
+ Les sous-réseaux doivent utiliser une dénomination basée sur une adresse IP. La [dénomination basée sur la ressource](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) Amazon EC2 n’est pas prise en charge par Amazon EKS.
## Accès au sous-réseau pour les services AWS
Les sous-réseaux privés du cluster local sur Outposts doivent pouvoir communiquer avec les services AWS régionaux. Vous pouvez y parvenir en utilisant une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) pour l'accès Internet sortant ou, si vous voulez préserver la confidentialité de tout le trafic au sein de votre VPC, en utilisant des [points de terminaison d'un VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html).
### Utiliser une passerelle NAT
Les sous-réseaux privés du cluster local sur Outposts doivent inclure une table de routage associée contenant un acheminement vers une passerelle NAT dans un sous-réseau public qui est dans la zone de disponibilité parente de l’Outpost. Le sous-réseau public doit disposer d'un acheminement vers une [passerelle Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). La passerelle NAT permet l'accès à Internet sortant et empêche les connexions entrantes non sollicitées depuis Internet vers les instances de l'Outpost.
### Utilisation des points de terminaison de VPC d'interface
Si les sous-réseaux privés du cluster local sur Outposts n’ont pas d’accès Internet sortant ou si vous voulez préserver la confidentialité de tout le trafic au sein de votre VPC, vous devez créer les points de terminaison d’un VPC d’interface et le [point de terminaison de passerelle](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) suivants dans un sous-réseau régional avant de créer votre cluster.
| Point de terminaison | Type de point de terminaison |
| --- | --- |
| `com.amazonaws.region-code.ssm` | utilisateur |
| `com.amazonaws.region-code.ssmmessages` | utilisateur |
| `com.amazonaws.region-code.ec2messages` | utilisateur |
| `com.amazonaws.region-code.ec2` | utilisateur |
| `com.amazonaws.region-code.secretsmanager` | utilisateur |
| `com.amazonaws.region-code.logs` | utilisateur |
| `com.amazonaws.region-code.sts` | utilisateur |
| `com.amazonaws.region-code.ecr.api` | utilisateur |
| `com.amazonaws.region-code.ecr.dkr` | utilisateur |
| `com.amazonaws.region-code.s3` | Passerelle |
Les points de terminaison doivent répondre aux critères suivants :
+ Créé dans un sous-réseau privé situé dans la zone de disponibilité parent de votre Outpost
+ Noms DNS privés activés
+ Avoir un groupe de sécurité attaché qui autorise le trafic HTTPS entrant à partir de la plage CIDR du sous-réseau privé d'Outpost.
La création de points de terminaison entraîne des frais. Pour plus d'informations, veuillez consulter [Tarification AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/). Si vos Pods ont besoin d’accéder à d’autres services AWS, vous devez créer des points de terminaison supplémentaires. Pour obtenir la liste complète des points de terminaison, consultez les [services AWS qui s’intègrent à AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html).
## Création d'un VPC
Vous pouvez créer un VPC qui répond aux exigences précédentes à l’aide de l’un des modèles AWS CloudFormation suivants :
+ ** [Modèle 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml) ** : le modèle crée un VPC avec un sous-réseau privé sur l’Outpost et un sous-réseau public dans la région AWS. Le sous-réseau privé dispose d’une route vers Internet via une passerelle NAT qui réside dans le sous-réseau public de la région AWS. Ce modèle peut être utilisé pour créer un cluster local dans un sous-réseau avec un accès Internet de sortie.
+ ** [Modèle 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)** : ce modèle crée un VPC avec un sous-réseau privé sur l’Outpost et l’ensemble minimal de points de terminaison d’un VPC requis pour créer un cluster local dans un sous-réseau qui ne dispose pas d’accès Internet entrant ou sortant (également appelé sous-réseau privé).
# Préparer des clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions du réseau
Si votre réseau local a perdu la connectivité avec AWS Cloud, vous pouvez continuer à utiliser votre cluster Amazon EKS local sur un Outpost. Cette rubrique explique comment préparer votre cluster local pour les déconnexions du réseau et les considérations connexes.
+ Les clusters locaux garantissent la stabilité et la continuité des opérations en cas de déconnexions réseau temporaires et imprévues. AWS Outposts reste une offre entièrement connectée qui agit comme extension de AWS Cloud dans votre centre de données. En cas de déconnexion du réseau entre votre Outpost et AWS Cloud, nous vous recommandons de tenter de rétablir votre connexion. Pour obtenir des instructions, consultez la [liste de contrôle pour le dépannage du réseau de racks AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) dans le *Guide de l’utilisateur AWS Outposts*. Pour plus d'informations sur la résolution des problèmes liés aux clusters locaux, consultez [Résoudre les problèmes liés aux clusters Amazon EKS locaux sur Outposts AWS](eks-outposts-troubleshooting.md).
+ Les Outposts génèrent une métrique `ConnectedStatus` qui permet de surveiller l'état de connectivité de votre Outpost. Pour plus d’informations, consultez la section [Outposts Metrics](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) dans le *Guide de l’utilisateur AWS Outposts*.
+ Les clusters locaux utilisent IAM comme mécanisme d’authentification par défaut à l’aide de [l’authentificateur de la gestion des identités et des accès AWS pour Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). IAM n’est pas disponible lors des déconnexions du réseau. Les clusters locaux prennent en charge un mécanisme d'authentification à l'aide des certificats `x.509` que vous pouvez utiliser pour vous connecter à votre cluster lors des déconnexions du réseau. Pour plus d'informations sur l'obtention et l'utilisation d'un certificat `x.509` pour votre cluster, consultez [Authentification auprès de votre cluster local lors d'une déconnexion du réseau](#outposts-network-disconnects-authentication).
+ Si vous ne pouvez pas accéder à Route 53 lors des déconnexions du réseau, pensez à utiliser des serveurs DNS locaux dans votre environnement sur site. Les instances du plan de contrôle Kubernetes utilisent des adresses IP statiques. Vous pouvez configurer les hôtes que vous utilisez pour vous connecter à votre cluster avec le nom d'hôte et les adresses IP du point de terminaison comme alternative à l'utilisation de serveurs DNS locaux. Pour plus d’informations, consultez la section [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) dans le *Guide de l’utilisateur AWS Outposts*.
+ Si vous prévoyez une augmentation du trafic d'applications lorsque le réseau se déconnecte, vous pouvez allouer de la capacité de calcul de réserve dans votre cluster lorsque vous êtes connecté au cloud. Les instances Amazon EC2 sont incluses dans le prix de AWS Outposts. Ainsi, l’exécution d’instances de rechange n’a pas d’impact sur votre coût d’utilisation d’AWS.
+ Lors des déconnexions du réseau pour permettre les opérations de création, de mise à jour et de mise à l'échelle des charges de travail, les images de conteneur de votre application doivent être accessibles sur le réseau local et votre cluster doit disposer d'une capacité suffisante. Les clusters locaux n’hébergent pas de registre de conteneurs pour vous. Si les pods ont déjà été exécutés sur ces nœuds, les images de conteneur sont mises en cache sur les nœuds. Si vous téléchargez généralement les images de conteneurs de votre application depuis Amazon ECR dans le cloud, envisagez d'exécuter un cache ou un registre local. Un cache ou un registre local est utile si vous avez besoin d'opérations de création, de mise à jour et de mise à l'échelle pour les ressources de la charge de travail pendant les déconnexions du réseau.
+ Les clusters locaux utilisent Amazon EBS comme classe de stockage par défaut pour les volumes persistants et le pilote CSI Amazon EBS pour gérer le cycle de vie des volumes persistants Amazon EBS. Pendant les déconnexions du réseau, les pods qui sont sauvegardés par Amazon EBS ne peuvent pas être créés, mis à jour ou mis à l’échelle. En effet, ces opérations nécessitent des appels à l'API Amazon EBS dans le cloud. Si vous déployez des charges de travail avec état sur des clusters locaux et que vous avez besoin d’opérations de création, de mise à jour ou de mise à l’échelle lors des déconnexions du réseau, envisagez d’utiliser un autre mécanisme de stockage.
+ Il est impossible de créer ou de supprimer des instantanés Amazon EBS si AWS Outposts n’a pas accès aux API pertinentes de la région AWS (telles que les API pour Amazon EBS ou Amazon S3).
+ Lors de l’intégration d’ALB (Ingress) avec AWS Certificate Manager (ACM), les certificats sont transférés et stockés dans la mémoire de l’instance AWS Outposts ALB Compute. La terminaison TLS actuelle continuera de fonctionner en cas de déconnexion de la région AWS. Dans ce contexte, les opérations de mutation (telles que les nouvelles définitions d'entrée, les nouvelles opérations d'API de certificats basés sur ACM, le dimensionnement du calcul ALB ou la rotation des certificats) échoueront. Pour plus d’informations, consultez la section [Dépannage du renouvellement des certificats gérés](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) dans le *Guide de l’utilisateur du gestionnaire de certificats AWS*.
+ Les journaux du plan de contrôle Amazon EKS sont mis en cache localement sur les instances du plan de contrôle Kubernetes lors des déconnexions du réseau. Lors de la reconnexion, les journaux sont envoyés à CloudWatch Logs dans la région AWS parent. Vous pouvez utiliser [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) ou les solutions partenaires Amazon EKS pour surveiller le cluster localement à l’aide du point de terminaison des métriques du serveur API Kubernetes ou à l’aide de Fluent Bit pour les journaux.
+ Si vous utilisez l’AWS Load Balancer Controller sur Outposts pour le trafic des applications, les pods existants gérés par l’AWS Load Balancer Controller continuent de recevoir du trafic pendant les déconnexions réseau. Les nouveaux pods créés lors de déconnexions du réseau ne reçoivent pas de trafic tant que l’Outpost n’est pas reconnecté au AWS Cloud. Envisagez de définir le nombre de réplicas pour vos applications lorsque vous êtes connecté au AWS Cloud afin de répondre à vos besoins de mise à l’échelle lors des déconnexions du réseau.
+ Le plug-in CNI Amazon VPC pour Kubernetes utilise par défaut le [mode IP secondaire.](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview) Il est configuré avec `WARM_ENI_TARGET`=`1`, qui permet au plug-in de conserver « une interface réseau entièrement Elastic » contenant les adresses IP disponibles. Pensez à modifier les valeurs `WARM_ENI_TARGET`, `WARM_IP_TARGET` et `MINIMUM_IP_TARGET` en fonction de vos besoins de mise à l'échelle lors d'un état déconnecté. Pour plus d’informations, consultez le fichier [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) pour le plug-in sur GitHub. Pour obtenir la liste du nombre maximal de pods pris en charge par chaque type d’instance, consultez le fichier [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) sur GitHub.
## Authentification auprès de votre cluster local lors d'une déconnexion du réseau
La gestion des identités et des accès AWS (IAM) n’est pas disponible en cas de déconnexions réseau. Vous ne pouvez pas vous authentifier auprès de votre cluster local à l’aide des informations d’identification IAM lorsque vous êtes déconnecté. Cependant, vous pouvez vous connecter à votre cluster sur votre réseau local à l'aide de certificats `x509` en cas de déconnexion. Vous devez télécharger et stocker un certificat `X509` client à utiliser lors des déconnexions. Dans cette rubrique, vous allez voir comment créer et utiliser le certificat pour vous authentifier auprès de votre cluster lorsqu’il est dans un état déconnecté.
1. Créer une demande de signature de certificat.
1. Générez une demande de signature de certificat.
```
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
```
1. Créez une demande de signature de certificat dans Kubernetes.
```
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
```
1. Créez une demande de signature de certificat à l'aide de `kubectl`.
```
kubectl create -f admin-csr.yaml
```
1. Vérifiez le statut de la demande de signature de certificat.
```
kubectl get csr admin-csr
```
L'exemple qui suit illustre un résultat.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
```
Kubernetes a créé la demande de signature de certificat.
1. Approuvez la demande de signature de certificat.
```
kubectl certificate approve admin-csr
```
1. Vérifiez à nouveau l'état de la demande de signature de certificat pour approbation.
```
kubectl get csr admin-csr
```
L'exemple qui suit illustre un résultat.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
```
1. Récupérez et vérifiez le certificat.
1. Récupérez le certificat.
```
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
```
1. Vérifiez le certificat.
```
cat admin.crt
```
1. Créez une liaison de rôle de cluster pour un utilisateur `admin`.
```
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
```
1. Générez un kubeconfig spécifique à l'utilisateur pour un état déconnecté.
Vous pouvez générer un fichier `kubeconfig` à l'aide des certificats `admin` téléchargés. Remplacez *my-cluster* et *apiserver-endpoint* dans les commandes suivantes.
```
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
```
```
kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
--certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
--client-certificate=admin.crt --client-key=admin.key --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
--cluster my-cluster --user admin
```
```
kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
```
1. Affichez votre fichier `kubeconfig`.
```
kubectl get nodes --kubeconfig admin.kubeconfig
```
1. Si des services sont déjà en production sur votre Outpost, ignorez cette étape. Si Amazon EKS est le seul service qui s’exécute sur votre Outpost et que ce dernier n’est pas en production, vous pouvez simuler une déconnexion du réseau. Avant de passer en production avec votre cluster local, simulez une déconnexion pour vous assurer que vous pouvez accéder à votre cluster lorsqu’il est déconnecté.
1. Appliquez les règles de pare-feu sur les appareils réseaux qui connectent votre Outpost à la région AWS. Cela déconnecte le lien de service de l'Outpost. Vous ne pouvez pas créer de nouvelles instances. Les instances en cours d’exécution perdent leur connectivité à la région AWS et à Internet.
1. Vous pouvez tester la connection à votre cluster local à l'aide du certificat `x509` en cas de déconnexion. Assurez-vous de remplacer votre `kubeconfig` par le `admin.kubeconfig` que vous avez créé à une étape précédente. Remplacez *my-cluster* par le nom de votre cluster local.
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
Si vous remarquez des problèmes avec vos clusters locaux alors qu’ils sont déconnectés, nous vous recommandons d’ouvrir un ticket de support.
# Sélection des types d’instances et des groupes de placement pour les clusters Amazon EKS sur AWS Outposts en fonction de considérations de capacité
Cette rubrique fournit des conseils sur la sélection du type d’instance de plan de contrôle Kubernetes et sur l’utilisation (facultative) de groupes de placement pour répondre aux exigences de haute disponibilité de votre cluster Amazon EKS local sur un Outpost.
Avant de sélectionner un type d’instance (telle que `m5`, `c5` ou `r5`) à utiliser pour le plan de contrôle Kubernetes de votre cluster local sur des Outposts, confirmez les types d’instances disponibles dans votre configuration Outpost. Après avoir identifié les types d'instance disponibles, sélectionnez la taille de l'instance (telle que `large`, `xlarge` ou `2xlarge`) en fonction du nombre de nœuds requis par vos charges de travail. Le tableau suivant fournit des recommandations pour choisir une taille d'instance.
**Note**
Les tailles d'instance doivent avoir été définies sur vos Outposts. Assurez-vous que vous avez suffisamment de capacité pour trois instances de la taille disponible sur vos Outposts pour la durée de vie de votre cluster local. Pour obtenir la liste des types d’instances Amazon EC2 disponibles, consultez les sections Calcul et stockage dans les [fonctionnalités des racks AWS Outposts](https://aws.amazon.com/outposts/rack/features/).
| Nombre de modèles | Taille des instances du plan de contrôle Kubernetes |
| --- | --- |
| 1-20 | `large` |
| 21–100 | `xlarge` |
| 101–250 | `2xlarge` |
| 251–500 | `4xlarge` |
Le stockage pour le plan de contrôle Kubernetes nécessite 246 Go de stockage Amazon EBS pour chaque cluster local afin de répondre aux exigences IOPS requises pour `etcd`. Lorsque le cluster local est créé, les volumes Amazon EBS sont alloués automatiquement pour vous.
## Placement du plan de contrôle
Lorsque vous ne spécifiez aucun groupe de placement avec la propriété `OutpostConfig.ControlPlanePlacement.GroupName`, les instances Amazon EC2 provisionnées pour votre plan de contrôle Kubernetes ne font l’objet d’aucune contrainte de placement matériel spécifique sur la capacité sous-jacente disponible sur votre Outpost.
Vous pouvez utiliser des groupes de placement pour répondre aux exigences de haute disponibilité de votre cluster Amazon EKS local sur un Outpost. En spécifiant un groupe de placement lors de la création du cluster, vous influencez le placement des instances de plan de contrôle Kubernetes. Les instances sont réparties sur du matériel sous-jacent indépendant (racks ou hôtes), minimisant ainsi l'impact des instances corrélées en cas de panne matérielle.
Le type de répartition que vous pouvez configurer dépend du nombre de racks Outpost dont vous disposez dans votre déploiement.
+ **Déploiements avec un ou deux racks physiques au sein d’un seul Outpost logique** : au moins trois hôtes doivent être configurés avec le type d’instance que vous choisissez pour vos instances de plan de contrôle Kubernetes. Avec un groupe de placement *par répartition* utilisant la répartition *au niveau des hôtes*, toutes les instances de plan de contrôle Kubernetes s’exécutent sur des hôtes distincts au sein des racks sous-jacents disponibles dans votre déploiement Outpost.
+ **Déploiements avec au moins trois racks physiques au sein d’un seul Outpost logique** : au moins trois hôtes doivent être configurés avec le type d’instance que vous choisissez pour vos instances de plan de contrôle Kubernetes. Avec un groupe de placement *par répartition* utilisant la répartition *au niveau des racks*, toutes les instances de plan de contrôle Kubernetes s’exécutent sur des racks distincts dans votre déploiement Outpost. Vous pouvez également utiliser le groupe de placement *par répartition au niveau des hôtes* comme décrit dans l'option précédente.
La création du groupe de placement souhaité vous incombe. Vous spécifiez le groupe de placement lorsque vous appelez l'API `CreateCluster`. Pour plus d’informations sur les groupes de placement et leur création, consultez la section [Groupes de placement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) dans le Guide de l’utilisateur Amazon EC2.
+ Lorsqu'un groupe de placement est spécifié, de la capacité doit être disponible sur votre Outpost pour créer un cluster Amazon EKS local. La capacité varie selon que vous utilisez le type de répartition au niveau des hôtes ou des racks. Si la capacité est insuffisante, le cluster reste à l’état `Creating`. Vous pouvez voir le message `Insufficient Capacity Error` dans le champ de santé de la réponse de l’API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Vous devez libérer de la capacité pour que le processus de création puisse progresser.
+ Lors des mises à jour de la plateforme et de la version du cluster local Amazon EKS, les instances de plan de contrôle Kubernetes de votre cluster sont remplacées par de nouvelles instances selon une stratégie de mise à jour continue. Au cours de ce processus de remplacement, chaque instance de plan de contrôle est arrêtée et son emplacement est libéré. Une nouvelle instance mise à jour est provisionnée à sa place. L'instance mise à jour peut être placée dans l'emplacement qui a été libéré. Si l'emplacement est occupé par une autre instance indépendante et que la capacité disponible est insuffisante pour répondre aux exigences topologiques de répartition, le cluster reste à l'état `Updating`. Vous pouvez voir le message `Insufficient Capacity Error` correspondant dans le champ de santé de la réponse de l’API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Vous devez libérer de la capacité pour que le processus de mise à jour puisse progresser et rétablir les niveaux de haute disponibilité antérieurs.
+ Vous pouvez créer un maximum de 500 groupes de placement par compte dans chaque région AWS. Pour plus d’informations, consultez la section [Règles générales et limitations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) dans le Guide de l’utilisateur Amazon EC2.
# Résoudre les problèmes liés aux clusters Amazon EKS locaux sur Outposts AWS
Cette rubrique traite de certaines erreurs courantes que vous pourriez rencontrer lorsque vous utilisez des clusters locaux, ainsi que des solutions. Les clusters locaux sont similaires aux clusters Amazon EKS dans le cloud, mais il existe quelques différences dans la façon dont ils sont gérés par Amazon EKS.
**Important**
Ne mettez jamais fin à une instance de `Kubernetes` plan de contrôle du cluster local EKS gérée exécutée sur Outpost, sauf instruction explicite du Support. AWS La fermeture de ces instances présente un risque pour la disponibilité du service de cluster local, notamment la perte du cluster local en cas de fermeture simultanée de plusieurs instances. Les instances du `Kubernetes` plan de contrôle du cluster local EKS sont identifiées par la balise `eks-local:controlplane-name` sur la console d' EC2 instance.
## Comportement de l'API
Les clusters locaux sont créés via l'API Amazon EKS, mais sont exécutés de manière asynchrone. Cela signifie que les demandes adressées à l'API Amazon EKS aboutissent immédiatement pour les clusters locaux. Toutefois, ces demandes peuvent aboutir, effectuer une interruption immédiate en raison d'erreurs de validation d'entrée, ou échouer et comporter des erreurs de validation descriptives. Ce comportement est similaire à celui de l’API Kubernetes.
Les clusters locaux ne passent pas à l’état `FAILED`. Amazon EKS tente de rapprocher l'état du cluster de l'état souhaité demandé par l'utilisateur de manière continue. Par conséquent, un cluster local peut rester dans l'état `CREATING` pendant une longue période, jusqu'à ce que le problème sous-jacent soit résolu.
## Décrire le champ de santé du cluster
Les problèmes de cluster locaux peuvent être découverts à l'aide de la commande [describe-cluster Amazon](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) EKS AWS CLI. Les problèmes liés aux clusters locaux sont signalés par le champ `cluster.health` de la réponse de la commande `describe-cluster`. Le message contenu dans ce champ inclut un code d'erreur, un message descriptif et une ressource associée IDs. Ces informations sont uniquement disponibles via l'API et la AWS CLI Amazon EKS. Dans l'exemple suivant, remplacez *my-cluster* par le nom de votre cluster local.
```
aws eks describe-cluster --name my-cluster --query 'cluster.health'
```
L'exemple qui suit illustre un résultat.
```
{
"issues": [
{
"code": "ConfigurationConflict",
"message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.",
"resourceIds": [
"my-cluster-arn"
]
}
]
}
```
Si le problème est irréparable, vous devrez peut-être supprimer le cluster local et en créer un nouveau. Par exemple, essayez d’allouer un cluster avec un type d’instance qui n’est pas disponible sur votre Outpost. Le tableau suivant répertorie les erreurs courantes liées à l'état.
| Scénario d'erreur | Code | Message | ResourceIds |
| --- | --- | --- | --- |
| Les sous-réseaux fournis sont introuvables. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | Tous les sous-réseaux fournis IDs |
| Les sous-réseaux fournis n’appartiennent pas au même VPC. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Tous les sous-réseaux fournis IDs |
| Certains sous-réseaux fournis n’appartiennent pas à l’Outpost spécifié. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | ID de sous-réseau problématique |
| Certains sous-réseaux fournis n’appartiennent à aucun Outpost. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | ID de sous-réseau problématique |
| Certains sous-réseaux fournis ne disposent pas de suffisamment d’adresses libres pour créer des interfaces réseau Elastic pour les instances du plan de contrôle. | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | ID de sous-réseau problématique |
| Le type d’instance du plan de contrôle spécifié n’est pas pris en charge sur votre Outpost. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | ARN de cluster |
| Vous avez mis fin à une EC2 instance Amazon du plan de contrôle ou vous avez `run-instance` réussi, mais l'état observé change de`Terminated`. Cela peut se produire pendant un certain temps après que votre Outpost se soit reconnecté et que des erreurs internes d'Amazon EBS aient entraîné l'échec d'un flux de travail EC2 interne d'Amazon. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | ARN de cluster |
| Vous avez une capacité insuffisante sur votre Outpost. Cela peut également se produire lors de la création d'un cluster si un avant-poste est déconnecté de la AWS région. | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | ARN de cluster |
| Votre compte a dépassé votre quota de groupes de sécurité. | `ResourceLimitExceeded` | Message d'erreur renvoyé par l' EC2 API Amazon | ID du VPC cible |
| Votre compte a dépassé votre quota d'interface réseau Elastic. | `ResourceLimitExceeded` | Message d'erreur renvoyé par l' EC2 API Amazon | l'ID du sous-réseau cible |
| Les instances du plan de contrôle n'étaient pas accessibles via AWS Systems Manager. Pour la résolution, consultez [Les instances du plan de contrôle ne sont pas accessibles via AWS Systems Manager](#outposts-troubleshooting-control-plane-instances-ssm). | `ClusterUnreachable` | Les instances du plan de contrôle Amazon EKS ne sont pas accessibles via SSM. Vérifiez votre SSM et votre configuration réseau, et consultez la documentation de résolution des problèmes EKS sur les Outposts. | EC2 Instance Amazon IDs |
| Une erreur s'est produite lors de l'obtention de détails pour un groupe de sécurité géré ou une interface réseau Elastic. | Basé sur le code d'erreur du EC2 client Amazon. | Message d'erreur renvoyé par l' EC2 API Amazon | Tous les groupes de sécurité sont gérés IDs |
| Une erreur s'est produite lors de l'autorisation ou de la révocation des règles d'entrée du groupe de sécurité. Cela s'applique à la fois aux groupes de sécurité du cluster et du plan de contrôle. | Basé sur le code d'erreur du EC2 client Amazon. | Message d'erreur renvoyé par l' EC2 API Amazon | ID de groupe de sécurité problématique |
| Une erreur s'est produite lors de la suppression d'une interface réseau Elastic d'une instance du plan de contrôle. | Basé sur le code d'erreur du EC2 client Amazon. | Message d'erreur renvoyé par l' EC2 API Amazon | ID d'interface réseau Elastoc problématique |
Le tableau suivant répertorie les erreurs provenant d'autres AWS services présentées dans le champ de santé de la `describe-cluster` réponse.
| Code EC2 d'erreur Amazon | Code de problème de santé du cluster | Description |
| --- | --- | --- |
| `AuthFailure` | `AccessDenied` | Cette erreur peut se produire pour différentes raisons. La raison la plus courante est que vous avez accidentellement supprimé une balise que le service utilise pour réduire la portée de la politique de rôle lié à un service du plan de contrôle. Dans ce cas, Amazon EKS ne pourra plus gérer ni surveiller ces AWS ressources. |
| `UnauthorizedOperation` | `AccessDenied` | Cette erreur peut se produire pour différentes raisons. La raison la plus courante est que vous avez accidentellement supprimé une balise que le service utilise pour réduire la portée de la politique de rôle lié à un service du plan de contrôle. Dans ce cas, Amazon EKS ne pourra plus gérer ni surveiller ces AWS ressources. |
| `InvalidSubnetID.NotFound` | `ResourceNotFound` | Cette erreur se produit lorsque l’ID de sous-réseau pour les règles d’entrée d’un groupe de sécurité est introuvable. |
| `InvalidPermission.NotFound` | `ResourceNotFound` | Cette erreur se produit lorsque les autorisations pour les règles d’entrée d’un groupe de sécurité ne sont pas correctes. |
| `InvalidGroup.NotFound` | `ResourceNotFound` | Cette erreur se produit lorsque le groupe des règles d’entrée d’un groupe de sécurité est introuvable. |
| `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | Cette erreur se produit lorsque l’ID de l’interface réseau pour les règles d’entrée d’un groupe de sécurité est introuvable. |
| `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | Cette erreur se produit lorsque le quota de ressources du sous-réseau est dépassé. |
| `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | Cette erreur se produit lorsque le quota de capacité de l'avant-poste est dépassé. |
| `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | Cette erreur se produit lorsque le quota de l'interface réseau Elastic est dépassé. |
| `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | Cette erreur se produit lorsque le quota du groupe de sécurité est dépassé. |
| `VcpuLimitExceeded` | `ResourceLimitExceeded` | Cela est observé lors de la création d'une EC2 instance Amazon dans un nouveau compte. L'erreur peut être similaire à ce qui suit : "`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` |
| `InvalidParameterValue` | `ConfigurationConflict` | Amazon EC2 renvoie ce code d'erreur si le type d'instance spécifié n'est pas pris en charge sur l'Outpost. |
| Toutes les autres erreurs | `InternalFailure` | Aucune |
## Impossible de créer ou de modifier des clusters
Les clusters locaux nécessitent des autorisations et des politiques différentes de celles des clusters Amazon EKS qui sont hébergés dans le cloud. Lorsqu'un cluster ne parvient pas à se créer et génère une `InvalidPermissions` erreur, vérifiez que le rôle de cluster que vous utilisez est associé à la politique EKSLocal OutpostClusterPolicy gérée par [Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). Tous les autres appels d'API nécessitent le même ensemble d'autorisations que les clusters Amazon EKS dans le cloud.
## Le cluster est bloqué à l'état `CREATING`
Le temps nécessaire à la création d'un cluster local varie en fonction de plusieurs facteurs. Ces facteurs comprennent la configuration de votre réseau, la configuration d’Outpost et la configuration du cluster. En général, un cluster local est créé et passe à l'état `ACTIVE` dans les 15 à 20 minutes. Si un cluster local reste dans l'état `CREATING`, vous pouvez appeler `describe-cluster` pour obtenir des informations sur la cause dans le champ de sortie `cluster.health`.
Les problèmes les plus courants sont les suivants :
+ Votre cluster ne peut pas se connecter à l'instance du plan de contrôle depuis la AWS région dans laquelle se trouve Systems Manager. Vous pouvez le vérifier en appelant `aws ssm start-session --target instance-id ` depuis un hôte bastion de la région. Si cette commande ne fonctionne pas, vérifiez si Systems Manager est exécuté sur l’instance du plan de contrôle. Une autre solution consiste à supprimer le cluster, puis à le recréer.
+ Les instances du plan de contrôle ne peuvent pas être créées en raison des autorisations de clé KMS pour les volumes EBS. Avec les clés KMS gérées par l’utilisateur pour les volumes EBS chiffrés, les instances du plan de contrôle seront interrompues si la clé n’est pas accessible. Si les instances sont mises hors service, passez à une clé KMS AWS gérée ou assurez-vous que votre politique de clé gérée par l'utilisateur accorde les autorisations nécessaires au rôle de cluster.
+ Il se peut que les instances du plan de contrôle de Systems Manager n'aient pas accès à Internet. Vérifiez si le sous-réseau que vous avez fourni lors de la création du cluster possède une passerelle NAT et un VPC avec une passerelle Internet. Utilisez l'analyseur d'accessibilité VPC pour vérifier si l'instance du plan de contrôle peut atteindre la passerelle Internet. Pour plus d'informations, consultez [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (langue française non garantie).
+ Le rôle ARN que vous avez fourni ne contient pas de politiques. Vérifiez si la [politique AWS gérée : Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) a été supprimée du rôle. Cela peut également se produire si une AWS CloudFormation pile est mal configurée.
+ Tous les sous-réseaux fournis doivent être associés au même Outpost et pouvoir communiquer entre eux. Lorsque plusieurs sous-réseaux sont spécifiés lors de la création d'un cluster, Amazon EKS tente de répartir les instances du plan de contrôle sur plusieurs sous-réseaux.
+ Les groupes de sécurité gérés par Amazon EKS sont appliqués sur l'interface réseau Elastic. Cependant, d'autres éléments de configuration tels que les règles de pare-feu NACL peuvent entrer en conflit avec les règles de l'interface réseau Elastic.
**La configuration du VPC et du DNS du sous-réseau est mal configurée ou manquante**
Consultez l'[article Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur Outposts](eks-outposts-vpc-subnet-requirements.md). AWS
## Le cluster est bloqué à l'état `UPDATING`
Amazon EKS met automatiquement à jour tous les clusters locaux existants vers les dernières versions de plateforme correspondant à leur version mineure Kubernetes. Pour plus d’informations sur les versions de plateforme, veuillez consulter [Découvrez les versions des plateformes Kubernetes et Amazon EKS pour Outposts AWS](eks-outposts-platform-versions.md).
Lors d’un déploiement automatique de la version de plateforme, l’état du cluster passe à `UPDATING`. Le processus de mise à jour consiste à remplacer toutes les instances du plan de contrôle Kubernetes par de nouvelles instances contenant les derniers correctifs de sécurité et les dernières corrections de bogues publiés pour la version mineure respective de Kubernetes. En général, le processus de mise à jour d’une plateforme de cluster local s’effectue en moins de 30 minutes, après quoi le cluster revient à son état `ACTIVE`. Si un cluster local reste dans l’état `UPDATING` pendant une période prolongée, vous pouvez appeler `describe-cluster` pour obtenir des informations sur la cause dans le champ de sortie `cluster.health`.
Amazon EKS garantit qu’au moins deux des trois instances du plan de contrôle Kubernetes sont des nœuds de cluster sains et opérationnels afin de maintenir la disponibilité du cluster local et d’éviter toute interruption de service. Si un cluster local est bloqué dans un état `UPDATING`, c’est généralement parce qu’un problème d’infrastructure ou de configuration empêche de garantir la disponibilité minimale de deux instances dans le cas où le processus se poursuit. Le processus de mise à jour s’arrête donc afin de protéger le service de cluster local contre toute interruption.
Il est important de dépanner un cluster local bloqué dans son état `UPDATING` et de traiter la cause profonde afin que le processus de mise à jour puisse s’achever et restaurer le cluster local sur `ACTIVE` avec la haute disponibilité de 3 instances du plan de contrôle Kubernetes.
Ne mettez fin à aucune `Kubernetes` instance de cluster local EKS gérée sur Outposts, sauf indication explicite du Support AWS . Ceci est particulièrement important pour les clusters locaux bloqués dans un état `UPDATING`, car il y a une forte probabilité qu’un autre nœud du plan de contrôle ne soit pas entièrement opérationnel et que la fermeture de la mauvaise instance puisse entraîner une interruption du service et un risque de perte de données du cluster local.
Les problèmes les plus courants sont les suivants :
+ Une ou plusieurs instances du plan de contrôle ne parviennent pas à se connecter à System Manager en raison d’une modification de la configuration réseau depuis la création initiale du cluster local. Vous pouvez le vérifier en appelant `aws ssm start-session --target instance-id ` depuis un hôte bastion de la région. Si cette commande ne fonctionne pas, vérifiez si Systems Manager est exécuté sur l’instance du plan de contrôle.
+ Les nouvelles instances du plan de contrôle ne peuvent pas être créées en raison des autorisations de clé KMS pour les volumes EBS. Avec les clés KMS gérées par l’utilisateur pour les volumes EBS chiffrés, les instances du plan de contrôle seront interrompues si la clé n’est pas accessible. Si les instances sont mises hors service, passez à une clé KMS AWS gérée ou assurez-vous que votre politique de clé gérée par l'utilisateur accorde les autorisations nécessaires au rôle de cluster.
+ Les instances du plan de contrôle Systems Manager ont peut-être perdu leur accès à Internet. Vérifiez si le sous-réseau que vous avez fourni lors de la création du cluster possède une passerelle NAT et un VPC avec une passerelle Internet. Utilisez l'analyseur d'accessibilité VPC pour vérifier si l'instance du plan de contrôle peut atteindre la passerelle Internet. Pour plus d'informations, consultez [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (langue française non garantie). Si vos réseaux privés ne disposent pas d’une connexion Internet sortante, assurez-vous que tous les points de terminaison d’un VPC et le point de terminaison de passerelle requis sont toujours présents dans le sous-réseau régional de votre cluster (voir [Accès au sous-réseau pour les services AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)).
+ Le rôle ARN que vous avez fourni ne contient pas de politiques. Vérifiez si la [politique AWS gérée : Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) n'EKSLocalOutpostClusterPolicya pas été supprimée du rôle.
+ L’une des nouvelles instances du plan de contrôle Kubernetes a peut-être subi une défaillance inattendue lors du démarrage. Veuillez envoyer une demande au [centre d’assistance AWS](https://console.aws.amazon.com/support/home) pour obtenir des conseils supplémentaires sur le dépannage et la collecte des journaux dans ce cas exceptionnel.
## Impossible de joindre des nœuds à un cluster
+ Problèmes AMI :
+ Vous utilisez une AMI incompatible. Seul Amazon Linux 2 optimisé pour Amazon EKS AMIs est pris en charge (`amazon-linux-2``amazon-linux-2-gpu`,,`amazon-linux-2-arm64`). Si vous essayez de joindre AL2 023 nœuds à EKS LocalClusters on AWS Outposts, les nœuds ne parviennent pas à rejoindre le cluster. Pour plus d'informations, consultez [Créer des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md).
+ Si vous avez utilisé un AWS CloudFormation modèle pour créer vos nœuds, assurez-vous qu'il n'utilise pas une AMI non prise en charge.
+ L'authentificateur AWS IAM est manquant `ConfigMap` : s'il est absent, vous devez le créer. Pour plus d’informations, consultez [Appliquer la `ConfigMap` `aws-auth` à votre cluster](auth-configmap.md#aws-auth-configmap).
+ Le mauvais groupe de sécurité est utilisé – Assurez-vous d'utiliser `eks-cluster-sg-cluster-name-uniqueid ` pour le groupe de sécurité de vos composants master. Le groupe de sécurité sélectionné est modifié AWS CloudFormation pour autoriser un nouveau groupe de sécurité chaque fois que la pile est utilisée.
+ Suite à des étapes inattendues liées à un VPC de lien privé – Des données CA incorrectes (`--b64-cluster-ca`) ou le mauvais point de terminaison de l'API (`--apiserver-endpoint`) sont transmis.
## Collecte des journaux
Lorsqu'un avant-poste est déconnecté de la AWS région à laquelle il est associé, le cluster Kubernetes continuera probablement à fonctionner normalement. Toutefois, si le cluster ne fonctionne pas correctement, suivez les étapes de résolution des problèmes décrites dans [Préparer les clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions réseau](eks-outposts-network-disconnects.md). Si vous rencontrez d'autres problèmes, contactez le AWS Support. AWS Support peut vous aider à télécharger et à exécuter un outil de collecte de journaux. Ainsi, vous pouvez collecter des journaux à partir de vos instances de plan de contrôle du cluster Kubernetes et les envoyer au AWS support technique pour une enquête plus approfondie.
## Les instances du plan de contrôle ne sont pas accessibles via AWS Systems Manager
Lorsque les instances du plan de contrôle Amazon EKS ne sont pas accessibles via AWS Systems Manager (Systems Manager), Amazon EKS affiche le message d'erreur suivant pour votre cluster.
```
Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.
```
Pour résoudre ce problème, assurez-vous que votre VPC et vos sous-réseaux répondent aux exigences de la section Créer [un VPC et des sous-réseaux pour les clusters Amazon EKS sur AWS Outposts et](eks-outposts-vpc-subnet-requirements.md) que vous avez suivi les étapes décrites dans Configuration du gestionnaire de [session dans le guide de l'utilisateur de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html). AWS
# Créez des nœuds Amazon Linux sur AWS Outposts
**Important**
Amazon EKS Local Clusters on Outposts prend uniquement en charge les nœuds créés à partir du système Amazon Linux 2023 optimisé pour Amazon EKS suivant : AMIs
Amazon Linux 2023 standard (`amazon-linux-2023/x86_64/standard`)
Nvidia Amazon Linux 2023 accéléré (`amazon-linux-2023/x86_64/nvidia`)
Neuron accéléré Amazon Linux 2023 () `amazon-linux-2023/x86_64/neuron`
AWS fin du support pour EKS, AL2 optimisé et AL2 accéléré AMIs, à compter du 26 novembre 2025. Bien que vous puissiez continuer à utiliser EKS AL2 AMIs après la date end-of-support (EOS) (26 novembre 2025), EKS ne publiera plus de nouvelles versions ou mises à jour de Kubernetes AL2 AMIs, y compris les versions mineures, les correctifs et les corrections de bogues après cette date. Consultez [ceci](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) pour plus d'informations sur la AL2 dépréciation.
Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds Amazon Linux sur un Outpost qui s'enregistrent auprès de votre cluster Amazon EKS. Le cluster peut se trouver dans le AWS cloud ou dans un avant-poste.
+ Un Outpost existant. Pour plus d'informations, consultez [What is AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Un cluster Amazon EKS existant. Pour déployer un cluster sur le AWS cloud, consultez[Création d’un cluster Amazon EKS](create-cluster.md). Pour déployer un cluster sur un Outpost, consultez [Créez des clusters Amazon EKS locaux sur AWS Outposts pour une haute disponibilité](eks-outposts-local-cluster-overview.md).
+ Supposons que vous créiez vos nœuds dans un cluster sur le AWS Cloud et que vous disposiez de sous-réseaux dans la AWS région où AWS Outposts, AWS Wavelength ou Local AWS Zones sont activés. Alors, ces sous-réseaux ne doivent pas avoir été transmis lors de la création de votre cluster. Si vous créez vos nœuds dans un cluster sur un Outpost, vous devez avoir transmis un sous-réseau Outpost lors de la création de votre cluster.
+ (Recommandé pour les clusters sur le AWS cloud) Le module complémentaire Amazon VPC CNI pour Kubernetes est configuré avec son propre rôle IAM auquel est attachée la politique IAM nécessaire. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). Les clusters locaux ne prennent pas en charge les rôles IAM pour les comptes de service.
Vous pouvez créer un groupe de nœuds Amazon Linux autogéré avec `eksctl` ou AWS Management Console (avec un AWS CloudFormation modèle). Vous pouvez également utiliser Terraform.
Vous pouvez créer un groupe de nœuds autogéré pour un cluster local à l’aide des outils décrits dans cette page :
+ [`eksctl`](#eksctl_create_nodes_outpost)
+ [AWS Management Console](#console_create_nodes_outpost)
**Important**
Le groupe de nœuds autogéré inclut EC2 les instances Amazon dans votre compte. Ces instances ne sont pas mises à niveau automatiquement lorsque la version du plan de contrôle est mise à jour par vous ou par Amazon EKS en votre nom. Un groupe de nœuds autogérés n’a aucune indication dans la console qu’il doit être mis à jour. Vous pouvez afficher la version `kubelet` installée sur un nœud en sélectionnant le nœud dans la boîte de dialogue **Nœuds** dans la **Présentation** de votre cluster pour déterminer quels nœuds doivent être mis à jour. Vous devez mettre à jour les nœuds manuellement. Pour de plus amples informations, veuillez consulter [Mettez à jour les nœuds autogérés de votre cluster](update-workers.md).
Les certificats utilisés par kubelet sur vos nœuds autogérés sont émis avec une durée de validité d’un an. Par défaut, la rotation des certificats **n'est pas** activée (voir : https://kubernetes). io/docs/reference/config-api/kubelet-config.v1beta1/\$1 kubelet-config-k 8 s-io-v 1beta1-KubeletConfiguration), cela signifie que si vous avez un nœud autogéré qui fonctionne depuis plus d'un an, il ne pourra plus s'authentifier auprès de l'API Kubernetes.
À titre de bonne pratique, nous recommandons aux clients de mettre régulièrement à jour leurs groupes de nœuds autogérés afin de recevoir CVEs les correctifs de sécurité de la dernière AMI optimisée pour Amazon EKS. La mise à jour de l’AMI utilisée dans les groupes de nœuds autogérés déclenche également la recréation des nœuds et garantit qu’ils ne rencontrent pas de problèmes liés à l’expiration des certificats kubelet.
Vous pouvez également activer la rotation des certificats clients (voir : https://kubernetes). io/docs/tasks/tls/certificate-rotation/) lors de la création des groupes de nœuds autogérés pour s'assurer que les certificats kubelet sont renouvelés lorsque le certificat actuel approche de son expiration.
## `eksctl`
**Pour lancer des nœuds Linux autogérés à l’aide de `eksctl` **
1. Installez la version `0.215.0` ou une version ultérieure de l'outil de ligne de `eksctl` commande installé 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. Si votre cluster se trouve AWS dans le cloud et que la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** est attachée au rôle IAM de [votre nœud Amazon EKS](create-node-role.md), nous vous recommandons de l'attribuer à un rôle IAM que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). Si votre cluster se trouve sur votre Outpost, la politique doit être associée à votre rôle de nœud.
1. La commande suivante crée un groupe de nœuds dans un cluster existant. Le cluster doit avoir été créé à l'aide d'`eksctl`. Remplacer *al-nodes* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Remplacez *my-cluster* par le nom de 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 dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Si votre cluster existe sur un Outpost, remplacez *id* par l'ID d'un sous-réseau Outpost. Si votre cluster existe dans le AWS cloud, remplacez-le *id* par l'ID d'un sous-réseau que vous n'avez pas spécifié lors de la création de votre cluster. Remplacez la valeur d’exemple restante par vos propres valeurs. Par défaut, les nœuds sont créés avec la même version de Kubernetes que le plan de contrôle.
Remplacez *instance-type* par un type d'instance disponible sur votre Outpost.
*my-key*Remplacez-le par le nom de votre paire de EC2 clés Amazon ou de votre clé publique. Cette clé est utilisée pour SSH dans vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*.
Créez votre groupe de nœuds avec la commande suivante.
```
eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \
--nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \
--node-volume-type gp2 --subnet-ids subnet-id \
--node-ami-family AmazonLinux2023
```
Si votre cluster est déployé sur le AWS cloud :
+ Le groupe de nœuds que vous déployez peut attribuer des adresses `IPv4` aux pods à partir d’un bloc CIDR différent de celui de l’instance. Pour de plus amples informations, veuillez consulter [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md).
+ Le groupe de nœuds que vous déployez ne nécessite pas d’accès Internet sortant. Pour de plus amples informations, veuillez consulter [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
Pour obtenir la liste complète de toutes les options disponibles et des paramètres par défaut, consultez la section [Assistance AWS Outposts](https://eksctl.io/usage/outposts/) dans la documentation `eksctl`.
+ Si les nœuds ne parviennent pas à rejoindre le cluster, consultez [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) [les sections Résolution des problèmes liés aux clusters et nœuds Amazon EKS et](troubleshooting.md) [Résoudre les problèmes liés [Impossible de joindre des nœuds à un cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) aux clusters Amazon EKS locaux sur AWS Outposts](eks-outposts-troubleshooting.md).
+ L'exemple qui suit illustre un résultat. Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Linux.
## AWS Management Console
**Étape 1 : lancer les nœuds Linux autogérés à l’aide de la AWS Management Console **
1. Téléchargez la dernière version du AWS CloudFormation modèle.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml
```
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Choisissez **Create stack (Créer une pile)**, puis sélectionnez **Avec de nouvelles ressources (standard)**.
1. Pour **Spécifier un modèle**, sélectionnez ** Upload a template file (Télécharger un fichier de modèle)**, puis sélectionnez **Choose file (Choisir un fichier)**. Sélectionnez le fichier `amazon-eks-nodegroup.yaml` que vous avez téléchargé à une étape précédente, puis sélectionnez **Next** (Suivant).
1. Dans la page **Specify stack details** (Spécifier les détails de la pile), saisissez les paramètres suivants, puis choisissez **Next** (Suivant) :
+ **Nom de pile** : Choisissez un nom de pile pour votre AWS CloudFormation pile. Par exemple, vous pouvez l'appeler *al-nodes*. 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 dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ **ApiServerEndpoint**: Entrez le point de terminaison du serveur d'API Kubernetes, visible dans la console EKS ou via l'API. DescribeCluster
+ **ClusterName**: Entrez le nom de votre cluster. Si ce nom ne correspond pas à celui de votre cluster, vos nœuds ne peuvent pas rejoindre le cluster.
+ **ClusterId**: Entrez l'identifiant attribué au cluster par le service EKS. Visible via DescribeCluster l'API. Si cet identifiant ne correspond pas à votre identifiant de cluster, vos nœuds ne peuvent pas rejoindre le cluster.
+ **CertificateAuthority**: Entrez la chaîne codée en base64 de l'autorité de certification Kubernetes. Visible dans la console EKS ou via DescribeCluster l'API.
+ **ServiceCidr**: Entrez le CIDR des services Kubernetes. Visible dans la console EKS ou via DescribeCluster l'API.
+ **ClusterControlPlaneSecurityGroup**: Choisissez la **SecurityGroups**valeur à partir de la AWS CloudFormation sortie que vous avez générée lors de la création de votre [VPC](creating-a-vpc.md).
Les étapes suivantes montrent une opération permettant de récupérer le groupe applicable.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster.
1. Choisissez l'onglet **Networking (Mise en réseau)**.
1. Utilisez la valeur **Groupes de sécurité supplémentaires** comme référence lorsque vous effectuez une sélection **ClusterControlPlaneSecurityGroup**dans la liste déroulante.
+ **NodeGroupName**: Entrez le nom de votre groupe de nœuds. Ce nom peut être utilisé ultérieurement pour identifier le groupe de nœuds autoscaling qui est créé pour vos nœuds.
+ **NodeAutoScalingGroupMinSize**: Entrez le nombre minimum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeAutoScalingGroupDesiredCapacity**: Entrez le nombre de nœuds que vous souhaitez atteindre lors de la création de votre pile.
+ **NodeAutoScalingGroupMaxSize**: Entrez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeInstanceType**: Choisissez un type d'instance pour vos nœuds. Si votre cluster s'exécute sur le AWS Cloud, pour plus d'informations, consultez[Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md). Si votre cluster s'exécute sur un Outpost, vous ne pouvez sélectionner qu'un type d'instance disponible sur votre Outpost.
+ **NodeImageIdSSMParam**: prérempli avec le paramètre Amazon EC2 Systems Manager d'une AMI récemment optimisée pour Amazon EKS pour une version variable de Kubernetes. Pour utiliser une autre version mineure de Kubernetes prise en charge avec Amazon EKS, remplacez *1.XX* par une autre [version prise en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Nous vous recommandons de spécifier la même version de Kubernetes que celle de votre cluster.
Pour utiliser une AMI accélérée optimisée pour Amazon EKS, mettez à jour *NodeImageIdSSMParam* la valeur selon le paramètre SSM souhaité. Découvrez comment récupérer l'AMI EKS IDs à partir de SSM [ici.](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html)
**Note**
Le nœud Amazon EKS AMIs est basé sur Amazon Linux. Vous pouvez suivre les événements liés à la sécurité ou à la confidentialité pourAmazon Linux dans le [centre de sécurité Amazon Linux](https://alas.aws.amazon.com/) en sélectionnant l’onglet correspondant à la version souhaitée. Vous pouvez également vous abonner au flux RSS applicable. Les événements de sécurité et de confidentialité incluent une présentation du problème, les packages concernés et la manière de mettre à jour vos instances pour résoudre le problème.
+ **NodeImageId**: (Facultatif) Si vous utilisez votre propre AMI personnalisée (au lieu d'une AMI optimisée pour Amazon EKS), entrez un ID d'AMI de nœud pour votre AWS région. Si vous spécifiez une valeur ici, elle remplace toutes les valeurs du **NodeImageIdSSMParam**champ.
+ **NodeVolumeSize**: Spécifiez une taille de volume racine pour vos nœuds, en GiB.
+ **NodeVolumeType**: Spécifiez un type de volume racine pour vos nœuds.
+ **KeyName**: Entrez le nom d'une paire de clés Amazon EC2 SSH que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*.
**Note**
Si vous ne fournissez pas de paire de clés ici, la création de la AWS CloudFormation pile échoue.
+ **Désactiver IMDSv1** : par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) et IMDSv2. Vous pouvez le désactiver IMDSv1. Pour empêcher l'utilisation des futurs nœuds et pods du groupe de nœuds IMDSv1, définissez **Disable IMDSv1** sur **true**. Pour de plus amples informations au sujet d'IMDS, consultez [Configuration du service des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Pour plus d'informations sur la façon d'en restreindre l'accès sur vos nœuds, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ **VpcId**: Entrez l'ID du [VPC](creating-a-vpc.md) que vous avez créé. Avant de choisir un VPC, examinez les [exigences et les considérations relatives au VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Subnets** : si votre cluster se trouve sur un Outpost, choisissez au moins un sous-réseau privé dans votre VPC. Avant de choisir les sous-réseaux, consultez [Exigences et considérations requises pour les sous-réseaux](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). Vous pouvez consulter les sous-réseaux privés en ouvrant le lien de chaque sous-réseau depuis l'onglet **Networking** (Mise en réseau) de votre cluster.
1. Sélectionnez les choix que vous souhaitez sur la page **Configure stack options** (Configurer les options de la pile), puis choisissez **Next** (Suivant).
1. Cochez la case à gauche de **J'accuse réception AWS CloudFormation susceptible de créer des ressources IAM**. , puis choisissez **Create stack**.
1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties).
1. Enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé. Vous en aurez besoin lors de la configuration de vos nœuds pour Amazon EKS.
**Étape 2 : autoriser les nœuds à rejoindre votre cluster**
1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Si vous voyez un `ConfigMap` `aws-auth`, mettez-le à jour si nécessaire.
1. Ouvrez le `ConfigMap` pour le modifier.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Ajoutez une nouvelle entrée `mapRoles` si nécessaire. Définissez la `rolearn` valeur sur la **NodeInstanceRole**valeur que vous avez enregistrée lors de la procédure précédente.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
1. Si vous avez reçu un message d'erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le stock `ConfigMap`.
1. Téléchargez la mappe de configuration.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dans le `aws-auth-cm.yaml` fichier, définissez la `rolearn` **NodeInstanceRole**valeur que vous avez enregistrée lors de la procédure précédente. Pour ce faire, utilisez un éditeur de texte ou remplacez *my-node-instance-role* et exécutez la commande suivante :
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes.
```
kubectl apply -f aws-auth-cm.yaml
```
1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`.
```
kubectl get nodes --watch
```
Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell.
**Note**
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes.
Si les nœuds ne parviennent pas à rejoindre le cluster, consultez [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) [les sections Résolution des problèmes liés aux clusters et nœuds Amazon EKS et](troubleshooting.md) [Résoudre les problèmes liés [Impossible de joindre des nœuds à un cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) aux clusters Amazon EKS locaux sur AWS Outposts](eks-outposts-troubleshooting.md).
1. Installez le pilote CSI Amazon EBS. Pour plus d'informations, consultez la section [Installation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) sur GitHub. Dans la section **Set up driver permission** (Configurer les autorisations du pilote), assurez-vous de suivre les instructions de l'option **Using IAM instance profile** (Utilisation du profil d'instance IAM). Vous devez utiliser la classe de stockage `gp2`. La classe de stockage `gp3` n’est pas prise en charge.
Pour créer une classe de stockage `gp2` sur votre cluster, suivez les étapes suivantes.
1. Exécutez la commande ci-dessous pour créer un fichier`gp2-storage-class.yaml`.
```
cat >gp2-storage-class.yaml <