**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 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``apt-get`, ou Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. 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. + 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 d'avoir 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.