**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. # Présentation des nœuds hybrides Amazon EKS Avec les *nœuds hybrides Amazon EKS*, vous pouvez utiliser votre infrastructure sur site et en périphérie comme nœuds dans les clusters Amazon EKS. AWS gère le plan de contrôle Kubernetes hébergé par AWS du cluster Amazon EKS, et vous gérez les nœuds hybrides qui s’exécutent dans vos environnements sur site ou en périphérie. Cela unifie la gestion de Kubernetes dans tous vos environnements et décharge la gestion du plan de contrôle Kubernetes vers AWS pour vos applications sur site et en périphérie. Les nœuds hybrides Amazon EKS fonctionnent avec n’importe quel matériel ou machine virtuelle sur site, apportant l’efficacité, la capacité de mise à l’échelle et la disponibilité d’Amazon EKS partout où vos applications doivent être exécutées. Vous pouvez utiliser un large éventail de fonctionnalités Amazon EKS avec les nœuds hybrides Amazon EKS, notamment les modules complémentaires Amazon EKS, l’identité du pod Amazon EKS, les entrées d’accès au cluster, les informations sur le cluster et la prise en charge étendue des versions Kubernetes. Les nœuds hybrides Amazon EKS s’intègre nativement à des services AWS tels que Systems Manager AWS, Rôles Anywhere IAM AWS, le service géré Amazon pour Prometheus et Amazon CloudWatch pour la surveillance centralisée, la journalisation et la gestion des identités. Avec les nœuds hybrides Amazon EKS, il n’y a pas d’engagement préalable ni de frais minimums, et vous êtes facturé à l’heure pour les ressources vCPU de vos nœuds hybrides lorsqu’ils sont connectés à vos clusters Amazon EKS. Pour plus d’informations sur les tarifs, consultez la page [Tarifs Amazon EKS](https://aws.amazon.com/eks/pricing/). [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/tFn9IdlddBw?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/tFn9IdlddBw?rel=0) ## Fonctionnalités Les nœuds hybrides EKS présentent les caractéristiques générales suivantes : + **Plan de contrôle Kubernetes géré** : AWS gère le plan de contrôle Kubernetes hébergé AWS du cluster EKS, et vous gérez les nœuds hybrides qui s’exécutent dans vos environnements sur site ou en périphérie. Cela unifie la gestion de Kubernetes dans tous vos environnements et décharge la gestion du plan de contrôle Kubernetes vers AWS pour vos applications sur site et en périphérie. En déplaçant le plan de contrôle Kubernetes vers AWS, vous pouvez conserver la capacité sur site pour vos applications et être assuré que le plan de contrôle Kubernetes s’adapte à vos charges de travail. + **Expérience EKS cohérente** : la plupart des fonctionnalités EKS sont prises en charge par les nœuds hybrides EKS pour une expérience EKS cohérente dans vos environnements sur site et dans le cloud, notamment les modules complémentaires EKS, l’identité du pod EKS, les entrées d’accès au cluster, les informations sur le cluster, la prise en charge étendue des versions Kubernetes, etc. Pour plus d’informations, consultez la section [Configurer les modules complémentaires pour les nœuds hybrides](hybrid-nodes-add-ons.md) consacrée aux modules complémentaires EKS pris en charge par les nœuds hybrides EKS. + **Observabilité centralisée et gestion des identités** : les nœuds hybrides EKS s’intègrent nativement à des services AWS tels qu’AWS Systems Manager, Rôles Anywhere IAM AWS, le service géré Amazon pour Prometheus et Amazon CloudWatch pour la surveillance centralisée, la journalisation et la gestion des identités. + **Burst-to-cloud ou ajout de capacité sur site** : Un seul cluster EKS peut être utilisé pour exécuter des nœuds hybrides et des nœuds dans des régions AWS, des zones locales AWS ou de AWS Outposts afin d’ajouter de la capacité burst-to-cloud ou sur site à vos clusters EKS. Pour plus d’informations, consultez la section [Considérations relatives aux clusters en mode mixte](hybrid-nodes-webhooks.md#hybrid-nodes-considerations-mixed-mode). + **Infrastructure flexible** : les nœuds hybrides EKS suivent une approche *« apportez votre propre infrastructure »* et sont indépendants de l’infrastructure que vous utilisez pour les nœuds hybrides. Vous pouvez exécuter des nœuds hybrides sur des machines physiques ou virtuelles, ainsi que sur des architectures x86 et ARM, ce qui permet de migrer les charges de travail sur site s’exécutant sur des nœuds hybrides vers différents types d’infrastructures. + **Réseau flexible** : Avec les nœuds hybrides EKS, la communication entre le plan de contrôle EKS et les nœuds hybrides est acheminée via le VPC et les sous-réseaux que vous transmettez lors de la création du cluster, ce qui s’appuie sur le [mécanisme existant](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html) dans EKS pour la mise en réseau du plan de contrôle vers les nœuds. Cette solution s’adapte à votre méthode préférée pour connecter vos réseaux sur site à un VPC dans AWS. Plusieurs [options documentées](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) sont disponibles, notamment le VPN site à site AWS, Direct Connect AWS ou votre propre solution VPN. Vous pouvez choisir la méthode qui correspond le mieux à votre cas d’utilisation. ## Limites + Jusqu’à 15 CIDR pour les réseaux de nœuds distants et 15 CIDR pour les réseaux de pods distants par cluster sont pris en charge. ## Considérations + Les nœuds hybrides EKS peuvent être utilisés avec des clusters EKS nouveaux ou existants. + Les nœuds hybrides EKS sont disponibles dans toutes les régions AWS, à l’exception des régions AWS GovCloud (États-Unis) et AWS Chine. + Les nœuds hybrides EKS doivent disposer d’une connexion fiable entre votre environnement sur site et AWS. Les nœuds hybrides EKS ne sont pas adaptés aux environnements déconnectés, perturbés, intermittents ou limités (DDIL). Si vous utilisez un environnement DDIL, envisagez [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/). Consultez les [meilleures pratiques pour les nœuds hybrides EKS](https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnections.html) pour obtenir des informations sur le comportement des nœuds hybrides en cas de déconnexion réseau. + L’exécution de nœuds hybrides EKS sur une infrastructure cloud, y compris les régions AWS, les zones locales AWS, AWS Outposts ou d’autres clouds, n’est pas prise en charge. Des frais liés aux nœuds hybrides vous seront facturés si vous exécutez des nœuds hybrides sur des instances Amazon EC2. + La facturation des nœuds hybrides commence lorsque les nœuds rejoignent le cluster EKS et s’arrête lorsqu’ils sont supprimés du cluster. Veillez à supprimer vos nœuds hybrides de votre cluster EKS si vous ne les utilisez pas. ## Ressources supplémentaires + [https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/](https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/) : instructions étape par étape pour déployer des nœuds hybrides EKS dans un environnement de démonstration. + [https://www.youtube.com/watch?v=ZxC7SkemxvU](https://www.youtube.com/watch?v=ZxC7SkemxvU) : AWS session re:Invent présentant le lancement des nœuds hybrides EKS avec un client qui montre comment il utilise les nœuds hybrides EKS dans son environnement. + [https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes](https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes) : article expliquant différentes méthodes de configuration de la mise en réseau pour les nœuds hybrides EKS. + [https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/](https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/) : article de blog expliquant comment exécuter l’inférence de l’IA générative dans différents environnements avec les nœuds hybrides EKS. # Configuration préalable requise pour les nœuds hybrides Pour utiliser les nœuds hybrides Amazon EKS, vous devez disposer d'une connectivité privée depuis votre environnement sur site vers/depuis AWS, des serveurs bare metal ou des machines virtuelles dotés d'un système d'exploitation compatible, et des activations hybrides AWS IAM Roles Anywhere ou AWS Systems Manager (SSM) configurées. Vous êtes responsable de la gestion de ces prérequis tout au long du cycle de vie des nœuds hybrides. + Connectivité réseau hybride depuis votre environnement sur site vers/depuis AWS + Infrastructure sous forme de machines physiques ou virtuelles + Système d’exploitation compatible avec les nœuds hybrides + Fournisseur d’informations d’identification IAM sur site configuré ![\[Connectivité réseau à nœuds hybrides.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## Connectivité réseau hybride La communication entre le plan de contrôle Amazon EKS et les nœuds hybrides est acheminée via le VPC et les sous-réseaux que vous transmettez lors de la création du cluster, qui s’appuie sur le [mécanisme existant](https://aws.github.io/aws-eks-best-practices/networking/subnets/) dans Amazon EKS pour la mise en réseau du plan de contrôle vers les nœuds. Plusieurs [options documentées](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) vous permettent de connecter votre environnement sur site à votre VPC, AWS Site-to-Site notamment le VPN, AWS Direct Connect ou votre propre connexion VPN. Consultez les guides d'utilisation du [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) et de [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) pour plus d'informations sur l'utilisation de ces solutions pour votre connexion réseau hybride. Pour une expérience optimale, nous vous recommandons de disposer d'une connectivité réseau fiable d'au moins 100 Mbits/s et d'une latence aller-retour maximale de 200 ms pour la connexion des nœuds hybrides à la AWS région. Il s’agit d’une recommandation générale qui s’applique à la plupart des cas d’utilisation, mais qui ne constitue pas une exigence stricte. Les exigences en matière de bande passante et de latence peuvent varier en fonction du nombre de nœuds hybrides et des caractéristiques de votre charge de travail, telles que la taille de l'image de l'application, l'élasticité de l'application, les configurations de surveillance et de journalisation, ainsi que les dépendances des applications en matière d'accès aux données stockées dans d'autres AWS services. Nous vous recommandons d’effectuer des tests avec vos propres applications et environnements avant le déploiement en production afin de vérifier que votre configuration réseau répond aux exigences de vos charges de travail. ## Configuration du réseau local Vous devez activer l’accès réseau entrant depuis le plan de contrôle Amazon EKS vers votre environnement sur site afin de permettre au plan de contrôle Amazon EKS de communiquer avec les nœuds hybrides en cours d’exécution `kubelet` et, éventuellement, avec les webhooks exécutés sur vos nœuds hybrides. En outre, vous devez activer l’accès au réseau sortant pour vos nœuds hybrides et les composants qui s’exécutent sur ceux-ci afin de communiquer avec le plan de contrôle Amazon EKS. Vous pouvez configurer cette communication pour qu'elle reste totalement privée avec votre AWS Direct Connect, votre AWS Site-to-Site VPN ou votre propre connexion VPN. Les plages de routage interdomaines sans classe (CIDR) que vous utilisez pour vos réseaux de nœuds et de pods locaux doivent utiliser des plages d'adresses IPv4 RFC-1918 ou CGNAT. Votre routeur local doit être configuré avec des routes vers vos nœuds locaux et, éventuellement, vers vos pods. Pour plus d’informations sur les exigences réseau sur site, y compris la liste complète des ports et protocoles requis qui doivent être activés dans votre pare-feu et votre environnement sur site, consultez [Configuration réseau sur site](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem). ## Configuration du cluster EKS Pour minimiser la latence, nous vous recommandons de créer votre cluster Amazon EKS dans la AWS région la plus proche de votre environnement sur site ou périphérique. Vous transmettez votre nœud et votre pod locaux CIDRs lors de la création du cluster Amazon EKS via deux champs d'API : `RemoteNodeNetwork` et`RemotePodNetwork`. Vous devrez peut-être discuter avec votre équipe réseau sur site pour identifier votre nœud et votre pod sur site. CIDRs Le CIDR du nœud est attribué à partir de votre réseau local et le CIDR du pod est attribué à partir de l’interface réseau de conteneur (CNI) que vous utilisez si vous utilisez un réseau superposé pour votre CNI. Cilium et Calico utilisent par défaut des réseaux superposés. Le nœud et le pod sur site CIDRs que vous configurez via les `RemotePodNetwork` champs `RemoteNodeNetwork` et sont utilisés pour configurer le plan de contrôle Amazon EKS afin d'acheminer le trafic via votre VPC vers `kubelet` les pods exécutés sur vos nœuds hybrides. Votre nœud et votre pod sur site CIDRs ne peuvent pas se chevaucher, ni avec le CIDR VPC que vous transmettez lors de la création du cluster, ni avec la configuration du IPv4 service pour votre cluster Amazon EKS. En outre, le Pod CIDRs doit être unique à chaque cluster EKS afin que votre routeur local puisse acheminer le trafic. Nous vous recommandons d’utiliser un accès public ou privé pour le point de terminaison du serveur API Amazon EKS Kubernetes. Si vous choisissez « Public et privé », le point de terminaison du serveur d'API Amazon EKS Kubernetes indiquera toujours au public IPs les nœuds hybrides exécutés en dehors de votre VPC, ce qui peut empêcher vos nœuds hybrides de rejoindre le cluster. Lorsque vous utilisez l'accès au point de terminaison public, le point de terminaison du serveur d'API Kubernetes devient public IPs et les communications entre les nœuds hybrides et le plan de contrôle Amazon EKS sont acheminées via Internet. Lorsque vous choisissez un accès de point de terminaison privé, le point de terminaison du serveur d'API Kubernetes devient privé IPs et les communications entre les nœuds hybrides et le plan de contrôle Amazon EKS seront acheminées via votre lien de connectivité privé, dans la plupart des cas Direct AWS Connect ou VPN. AWS Site-to-Site ## Configuration VPC Vous devez configurer le VPC que vous transmettez lors de la création du cluster Amazon EKS avec des routes dans sa table de routage pour votre nœud sur site et, éventuellement, des réseaux de pods avec votre passerelle privée virtuelle (VGW) ou votre passerelle de transit (TGW) comme cible. Un exemple est illustré ci-dessous. Remplacez `REMOTE_NODE_CIDR` et `REMOTE_POD_CIDR` par les valeurs correspondant à votre réseau sur site. | Destination | Cible | Description | | --- | --- | --- | | 10.226.0.0/16 | local | Trafic local vers les routes VPC au sein du VPC | | REMOTE\$1NODE\$1CIDR | tgw-abcdef123456 | CIDR du nœud sur site, acheminer le trafic vers le TGW | | REMODE\$1POD\$1CIDR | tgw-abcdef123456 | CIDR du pod sur site, acheminer le trafic vers le TGW | ## Configuration du groupe de sécurité Lorsque vous créez un cluster, Amazon EKS crée un groupe de sécurité nommé `eks-cluster-sg--`. Vous ne pouvez pas modifier les règles entrantes de ce groupe de sécurité de cluster, mais vous pouvez restreindre les règles sortantes. Vous devez ajouter un groupe de sécurité supplémentaire à votre cluster pour permettre au kubelet et, éventuellement, aux webhooks s’exécutant sur vos nœuds hybrides de contacter le plan de contrôle Amazon EKS. Les règles entrantes requises pour ce groupe de sécurité supplémentaire sont indiquées ci-dessous. Remplacez `REMOTE_NODE_CIDR` et `REMOTE_POD_CIDR` par les valeurs correspondant à votre réseau sur site. | Nom | ID de règle du groupe de sécurité | Versions d’adresses IP | Type | Protocole | Plage de ports | Source | | --- | --- | --- | --- | --- | --- | --- | | Nœud entrant sur site | sgr-abcdef123456 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1NODE\$1CIDR | | Envoi du pod sur site | sgr-abcdef654321 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1POD\$1CIDR | ## Infrastructures Vous devez disposer de serveurs de matériel nu ou de machines virtuelles pouvant être utilisés comme nœuds hybrides. Les nœuds hybrides sont indépendants de l’infrastructure sous-jacente et prennent en charge les architectures x86 et ARM. Les nœuds hybrides Amazon EKS suivent une approche « apportez votre propre infrastructure », dans laquelle vous êtes responsable de l’approvisionnement et de la gestion des serveurs de matériel nu ou des machines virtuelles que vous utilisez pour les nœuds hybrides. Bien qu’il n’y ait pas d’exigence minimale stricte en matière de ressources, nous vous recommandons d’utiliser des hôtes disposant d’au moins 1 vCPU et 1 Go de RAM pour les nœuds hybrides. ## Système d’exploitation Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu et RHEL sont validés en permanence pour être utilisés comme système d'exploitation de nœuds pour les nœuds hybrides. Bottlerocket est uniquement pris en charge dans les environnements AWS vSphere VMware . AL2023 n'est pas couvert par les plans de AWS Support lorsqu'il est exécuté en dehors d'Amazon EC2. AL2023 ne peut être utilisé que dans des environnements virtualisés sur site. Consultez le [guide de l'utilisateur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) pour plus d'informations. AWS prend en charge l'intégration des nœuds hybrides avec les systèmes d'exploitation Ubuntu et RHEL, mais ne fournit pas de support pour le système d'exploitation lui-même. Vous êtes responsable de la mise à disposition et de la gestion du système d’exploitation. Lorsque vous testez des nœuds hybrides pour la première fois, il est plus simple d’exécuter la CLI des nœuds hybrides Amazon EKS (`nodeadm`) sur un hôte déjà provisionné. Pour les déploiements en production, nous vous recommandons d’inclure `nodeadm` dans vos images de système d’exploitation de référence une configuration permettant leur exécution en tant que service systemd afin de joindre automatiquement les hôtes aux clusters Amazon EKS au démarrage de l’hôte. ## Fournisseur d’informations d’identification IAM sur site Les nœuds hybrides Amazon EKS utilisent des informations d'identification IAM temporaires fournies par des activations hybrides AWS SSM ou par AWS IAM Roles Anywhere pour s'authentifier auprès du cluster Amazon EKS. Vous devez utiliser des activations hybrides AWS SSM ou des rôles AWS IAM Anywhere avec la CLI Amazon EKS Hybrid Nodes (). `nodeadm` Nous vous recommandons d'utiliser les activations hybrides AWS SSM si vous ne possédez pas d'infrastructure à clé publique (PKI) existante dotée d'une autorité de certification (CA) et de certificats pour vos environnements sur site. Si vous disposez d'une infrastructure PKI et de certificats sur site, utilisez AWS IAM Roles Anywhere. Comme pour [Rôle IAM de nœud Amazon EKS](create-node-role.md) avec les nœuds exécutés sur Amazon EC2, vous allez créer un rôle IAM pour les nœuds hybrides avec les autorisations nécessaires pour joindre les nœuds hybrides aux clusters Amazon EKS. Si vous utilisez AWS IAM Roles Anywhere, configurez une politique de confiance qui permet à AWS IAM Roles Anywhere d'assumer le rôle IAM de nœuds hybrides et configurez votre profil AWS IAM Roles Anywhere avec le rôle IAM de nœuds hybrides comme rôle assumé. Si vous utilisez AWS SSM, configurez une politique de confiance qui permet à AWS SSM d'assumer le rôle IAM des nœuds hybrides et de créer l'activation hybride avec le rôle IAM des nœuds hybrides. Consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md) pour découvrir comment créer le rôle IAM des nœuds hybrides avec les autorisations requises. # Préparer la mise en réseau pour les nœuds hybrides Cette rubrique fournit une vue d’ensemble de la configuration réseau que vous devez avoir configurée avant de créer votre cluster Amazon EKS et d’y attacher des nœuds hybrides. Ce guide part du principe que vous avez satisfait aux exigences requises pour la connectivité réseau hybride à l'aide d'[AWS Site-to-Site un VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html), de [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) ou de votre propre solution VPN. ![\[Connectivité réseau à nœuds hybrides.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## Configuration réseau sur site ### Configuration réseau minimale requise Pour une expérience optimale, nous vous recommandons de disposer d'une connectivité réseau fiable d'au moins 100 Mbits/s et d'une latence aller-retour maximale de 200 ms pour la connexion des nœuds hybrides à la AWS région. Il s’agit d’une recommandation générale qui s’applique à la plupart des cas d’utilisation, mais qui ne constitue pas une exigence stricte. Les exigences en matière de bande passante et de latence peuvent varier en fonction du nombre de nœuds hybrides et des caractéristiques de votre charge de travail, telles que la taille de l'image de l'application, l'élasticité de l'application, les configurations de surveillance et de journalisation, ainsi que les dépendances des applications en matière d'accès aux données stockées dans d'autres AWS services. Nous vous recommandons d’effectuer des tests avec vos propres applications et environnements avant le déploiement en production afin de vérifier que votre configuration réseau répond aux exigences de vos charges de travail. ### Nœud et module sur site CIDRs Identifiez le nœud et le pod CIDRs que vous utiliserez pour vos nœuds hybrides et les charges de travail qui y sont exécutées. Le CIDR du nœud est attribué à partir de votre réseau local et le CIDR du pod est attribué à partir de votre interface réseau de conteneur (CNI) si vous utilisez un réseau superposé pour votre CNI. Vous transmettez votre nœud CIDRs et votre pod locaux CIDRs en tant qu'entrées lorsque vous créez votre cluster EKS avec les `RemotePodNetwork` champs `RemoteNodeNetwork` et. Votre nœud local CIDRs doit être routable sur votre réseau local. Consultez la section suivante pour obtenir des informations sur la routabilité CIDR du pod sur site. Les blocs CIDR des nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages `IPv4` RFC-1918 suivantes :`10.0.0.0/8`, ou `172.16.0.0/12``192.168.0.0/16`, ou dans la plage CGNAT définie par la RFC 6598 :. `100.64.0.0/10` 1. Ne pas se chevaucher entre eux, le CIDR VPC pour votre cluster EKS ou votre CIDR de service Kubernetes `IPv4`. ### Routage du réseau de pods sur site Lorsque vous utilisez des nœuds hybrides EKS, nous vous recommandons généralement de rendre votre module sur site CIDRs routable sur votre réseau local afin de permettre une communication et des fonctionnalités complètes entre les environnements cloud et sur site. **Réseaux de pods routables** Si vous êtes en mesure de rendre votre réseau de pods routable sur votre réseau local, suivez les instructions ci-dessous. 1. Configurez le champ `RemotePodNetwork` pour votre cluster EKS avec votre CIDR de pod sur site, vos tables de routage VPC avec votre CIDR de pod sur site et votre groupe de sécurité de cluster EKS avec votre CIDR de pod sur site. 1. Il existe plusieurs techniques que vous pouvez utiliser pour rendre votre pod CIDR sur site routable sur votre réseau sur site, notamment le protocole de passerelle frontière (BGP), les routes statiques ou d’autres solutions de routage personnalisées. Le BGP est la solution recommandée car elle est plus évolutive et plus facile à gérer que les solutions alternatives qui nécessitent une configuration de routage personnalisée ou manuelle. AWS prend en charge les fonctionnalités BGP de Cilium et Calico pour les modules publicitaires CIDRs, voir [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) et [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) pour plus d'informations. 1. Les webhooks peuvent s’exécuter sur des nœuds hybrides, car le plan de contrôle EKS est capable de communiquer avec les adresses IP des pods attribuées aux webhooks. 1. Les charges de travail exécutées sur les nœuds cloud peuvent communiquer directement avec les charges de travail exécutées sur les nœuds hybrides du même cluster EKS. 1. D'autres AWS services, tels que les équilibreurs de charge des AWS applications et Amazon Managed Service for Prometheus, sont capables de communiquer avec les charges de travail exécutées sur des nœuds hybrides afin d'équilibrer le trafic réseau et de récupérer les métriques des pods. **Réseaux de pods non routables** Si vous ne parvenez *pas* à rendre vos réseaux de pods routables sur votre réseau local, suivez les instructions ci-dessous. 1. Les webhooks ne peuvent pas s’exécuter sur des nœuds hybrides, car ils nécessitent une connectivité entre le plan de contrôle EKS et les adresses IP des pods attribuées aux webhooks. Dans ce cas, nous vous recommandons d’exécuter les webhooks sur les nœuds cloud du même cluster EKS que vos nœuds hybrides. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). 1. Les charges de travail exécutées sur des nœuds cloud ne peuvent pas communiquer directement avec les charges de travail exécutées sur des nœuds hybrides lorsque vous utilisez VPC CNI pour les nœuds cloud et Cilium ou Calico pour les nœuds hybrides. 1. Utilisez la distribution du trafic de service pour maintenir le trafic local dans la zone d’où il provient. Pour plus d’informations sur la distribution du trafic de service, voir [Configuration de la distribution du trafic de service](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution). 1. Configurez votre CNI pour utiliser le masquage de sortie ou la traduction d’adresses réseau (NAT) pour le trafic des pods lorsqu’il quitte vos hôtes sur site. Cette fonctionnalité est activée par défaut dans Cilium. Calico a besoin que `natOutgoing` soit défini sur `true`. 1. D'autres AWS services, tels que les équilibreurs de charge d' AWS application et Amazon Managed Service for Prometheus, ne sont pas en mesure de communiquer avec les charges de travail exécutées sur des nœuds hybrides. ### Accès requis pendant l’installation et la mise à niveau des nœuds hybrides Vous devez avoir accès aux domaines suivants pendant le processus d’installation où vous installez les dépendances des nœuds hybrides sur vos hôtes. Ce processus peut être effectué une seule fois lors de la création des images de votre système d’exploitation ou sur chaque hôte au moment de l’exécution. Cela inclut l’installation initiale et la mise à niveau de la version Kubernetes de vos nœuds hybrides. Certains paquets sont installés à l’aide du gestionnaire de paquets par défaut du système d’exploitation. Pour AL2023 et RHEL, la `yum` commande est utilisée pour installer `containerd``ca-certificates`, `iptables` et`amazon-ssm-agent`. Pour Ubuntu, `apt` est utilisé pour installer `containerd`, `ca-certificates`, et `iptables`, et `snap` sert à installer `amazon-ssm-agent`. | Composant | URL | Protocole | Port | | --- | --- | --- | --- | | Artefacts du nœud EKS (S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 | | [Points de terminaison du service EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks. *region*.amazonaws.com | HTTPS | 443 | | [Points de terminaison du service ECR](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr. *region*.amazonaws.com | HTTPS | 443 | | Points de terminaison EKS ECR | Voir [Affichage des registres d’images conteneurs Amazon pour les modules complémentaires Amazon EKS](add-ons-images.md) pour les points terminaux régionaux. | HTTPS | 443 | | Point de terminaison binaire SSM 1 | https://amazon-ssm - *region* .s3. *region*.amazonaws.com | HTTPS | 443 | | [Point de terminaison du service SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm. *region*.amazonaws.com | HTTPS | 443 | | Point de terminaison binaire IAM Anywhere 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 | | [Point de terminaison du service IAM](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) Anywhere 2 | https://rolesanywhere. *region*.amazonaws.com | HTTPS | 443 | | Points de terminaison du gestionnaire de paquets du système d’exploitation | Les points de terminaison du référentiel de paquets sont spécifiques au système d’exploitation et peuvent varier selon la région géographique. | HTTPS | 443 | **Note** 1 L'accès aux points de terminaison AWS SSM n'est requis que si vous utilisez des activations hybrides AWS SSM pour votre fournisseur d'informations d'identification IAM sur site. 2 L'accès aux points de terminaison AWS IAM n'est requis que si vous utilisez AWS IAM Roles Anywhere comme fournisseur d'informations d'identification IAM sur site. ### Accès requis pour les opérations de cluster en cours L’accès réseau suivant pour votre pare-feu local est nécessaire pour le fonctionnement continu du cluster. **Important** En fonction du CNI que vous avez choisi, vous devez configurer des règles d’accès réseau supplémentaires pour les ports CNI. Pour plus d’informations, consultez la [documentation Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules) et la [documentation Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements). | Type | Protocole | Direction | Port | Source | Destination | Usage | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | Sortant | 443 | CIDR des nœuds distants | Cluster EKS IPs 1 | kubelet vers le serveur API Kubernetes | | HTTPS | TCP | Sortant | 443 | CIDR de pod distant(s) | Cluster EKS IPs 1 | Pod vers serveur API Kubernetes | | HTTPS | TCP | Sortant | 443 | CIDR des nœuds distants | [Point de terminaison du service SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | Actualisation des informations d’identification des activations hybrides SSM et pulsations SSM toutes les 5 minutes | | HTTPS | TCP | Sortant | 443 | CIDR des nœuds distants | [Point de terminaison du service IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | Actualisation des informations d’identification Rôles Anywhere IAM | | HTTPS | TCP | Sortant | 443 | CIDR de pod distant(s) | [Point de terminaison régional STS](https://docs.aws.amazon.com/general/latest/gr/sts.html) | Pod vers point de terminaison STS, requis uniquement pour IRSA | | HTTPS | TCP | Sortant | 443 | CIDR des nœuds distants | [Point de terminaison du service d’authentification Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | Nœud vers le point de terminaison d’authentification Amazon EKS, requis uniquement pour l’identité du pod Amazon EKS | | HTTPS | TCP | Entrant | 10250 | Cluster EKS IPs 1 | CIDR des nœuds distants | Serveur API Kubernetes vers kubelet | | HTTPS | TCP | Entrant | Ports Webhook | Cluster EKS IPs 1 | CIDR de pod distant(s) | Serveur API Kubernetes vers webhooks | | HTTPS | TCP, UDP | Entrant, sortant | 53 | CIDR de pod distant(s) | CIDR de pod distant(s) | Pod vers CoreDNS. Si vous exécutez au moins un réplica de CoreDNS dans le cloud, vous devez autoriser le trafic DNS vers le VPC où CoreDNS est exécuté. | | Défini par l’utilisateur | Défini par l’utilisateur | Entrant, sortant | Ports d’applications | CIDR de pod distant(s) | CIDR de pod distant(s) | Pod à pod | **Note** 1 Celui IPs du cluster EKS. Consultez la section suivante sur les interfaces réseau Elastic Amazon EKS. ### Interfaces réseau Amazon EKS Amazon EKS associe des interfaces réseau aux sous-réseaux du VPC que vous transmettez lors de la création du cluster afin de permettre la communication entre le plan de contrôle EKS et votre VPC. Les interfaces réseau créées par Amazon EKS se trouvent après la création du cluster dans la console Amazon EC2 ou à l'aide de la CLI AWS . Les interfaces réseau d’origine sont supprimées et de nouvelles interfaces réseau sont créées lorsque des modifications sont appliquées à votre cluster EKS, telles que les mises à niveau de version Kubernetes. Vous pouvez restreindre la plage d'adresses IP des interfaces réseau Amazon EKS en utilisant des tailles de sous-réseaux limitées pour les sous-réseaux que vous transmettez lors de la création du cluster, ce qui facilite la configuration de votre pare-feu sur site afin de permettre la inbound/outbound connectivité à cet ensemble connu et restreint de. IPs Pour contrôler les sous-réseaux dans lesquels les interfaces réseau sont créées, vous pouvez limiter le nombre de sous-réseaux que vous spécifiez lors de la création d’un cluster ou mettre à jour les sous-réseaux après avoir créé le cluster. Les interfaces réseau fournies par Amazon EKS ont une description au format `Amazon EKS your-cluster-name `. Consultez l'exemple ci-dessous pour une commande AWS CLI que vous pouvez utiliser pour trouver les adresses IP des interfaces réseau approvisionnées par Amazon EKS. Remplacez par l’ID du VPC que vous avez transmis lors de la création du cluster par `VPC_ID`. ``` aws ec2 describe-network-interfaces \ --query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress' ``` ## AWS Configuration du VPC et du sous-réseau Les [exigences existantes en matière de VPC et de sous-réseau](network-reqs.md) pour Amazon EKS s’appliquent aux clusters avec des nœuds hybrides. En outre, votre VPC CIDR ne peut pas chevaucher votre nœud et votre pod locaux. CIDRs Vous devez configurer les itinéraires dans votre table de routage VPC pour votre nœud local et éventuellement pour votre pod. CIDRs Ces routes doivent être configurées pour acheminer le trafic vers la passerelle que vous utilisez pour votre connectivité réseau hybride, qui est généralement une passerelle privée virtuelle (VGW) ou une passerelle de transit (TGW). Si vous utilisez TGW ou VGW pour connecter votre VPC à votre environnement sur site, vous devez créer une connexion TGW ou VGW pour votre VPC. Votre VPC doit prend en charge le nom d'hôte DNS et la résolution DNS. Les étapes suivantes utilisent la AWS CLI. Vous pouvez également créer ces ressources dans AWS Management Console ou avec d'autres interfaces telles que AWS CloudFormation AWS CDK ou Terraform. ### Étape 1 : créer un VPC 1. Exécutez la commande suivante pour créer un VPC. Remplacez VPC\$1CIDR par une plage d'adresses IPv4 CIDR qui est soit RFC 1918 (privée), CGNAT (RFC 6598), soit non-RFC 1918/non-CGNAT (public) (par exemple, 10.0.0.0/16). Remarque : la résolution DNS, qui est une exigence EKS, est activée par défaut pour le VPC. ``` aws ec2 create-vpc --cidr-block VPC_CIDR ``` 1. Activez les noms d’hôte DNS pour votre VPC. Remarque : la résolution DNS est activée par défaut pour le VPC. Remplacez `VPC_ID` par l’ID du VPC que vous avez créé à l’étape précédente. ``` aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames ``` ### Étape 2 : créer des sous-réseaux Créez au moins 2 sous-réseaux. Amazon EKS utilise ces sous-réseaux pour les interfaces réseau du cluster. Pour plus d’informations, consultez la section [Exigences et considérations relatives aux sous-réseaux](network-reqs.md#network-requirements-subnets). 1. Vous pouvez trouver les zones de disponibilité d'une AWS région à l'aide de la commande suivante. Remplacez `us-west-2` par votre région. ``` aws ec2 describe-availability-zones \ --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName' ``` 1. Créez un sous-réseau. Remplacez `VPC_ID` par l’ID du VPC. Remplacez `SUBNET_CIDR` par le bloc CIDR de votre sous-réseau (par exemple 10.0.1.0/24). Remplacez `AZ` par la zone de disponibilité dans laquelle le sous-réseau sera créé (par exemple us-west-2a). Les sous-réseaux que vous créez doivent se trouver dans au moins deux zones de disponibilité différentes. ``` aws ec2 create-subnet \ --vpc-id VPC_ID \ --cidr-block SUBNET_CIDR \ --availability-zone AZ ``` ### (Facultatif) Étape 3 : associer un VPC à la passerelle privée virtuelle Amazon VPC Transit Gateway (TGW) ou AWS Direct Connect (VGW) Si vous utilisez un TGW ou un VGW, connectez votre VPC au TGW ou au VGW. Pour plus d’informations, consultez la section [Pièces jointes Amazon VPC dans les passerelles de transit Amazon VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) ou [Associations de passerelles privées virtuelles Direct Connect AWS](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway). **Passerelle de transit** Exécutez la commande suivante pour connecter une passerelle Transit Gateway. Remplacez `VPC_ID` par l’ID du VPC. Remplacez `SUBNET_ID1` et `SUBNET_ID2` par IDs les sous-réseaux que vous avez créés à l'étape précédente. Remplacez `TGW_ID` par l’ID de votre TGW. ``` aws ec2 create-transit-gateway-vpc-attachment \ --vpc-id VPC_ID \ --subnet-ids SUBNET_ID1 SUBNET_ID2 \ --transit-gateway-id TGW_ID ``` **Passerelle privée virtuelle** Exécutez la commande suivante pour connecter une passerelle Transit Gateway. Remplacez `VPN_ID` par l’ID de votre VGW. Remplacez `VPC_ID` par l’ID du VPC. ``` aws ec2 attach-vpn-gateway \ --vpn-gateway-id VPN_ID \ --vpc-id VPC_ID ``` ### (Facultatif) Étape 4 : créer une table de routage Vous pouvez modifier la table de routage principale pour le VPC ou créer une table de routage personnalisée. Les étapes suivantes créent une table de routage personnalisée avec les itinéraires vers le nœud et le pod CIDRs locaux. Pour plus d’informations, consultez [Tables de routage de sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html). Remplacez `VPC_ID` par l’ID du VPC. ``` aws ec2 create-route-table --vpc-id VPC_ID ``` ### Étape 5 : créer des routes pour les nœuds et les pods sur site Créez des routes dans la table de routage pour chacun de vos nœuds distants sur site. Vous pouvez modifier la table de routage principale pour le VPC ou utiliser la table de routage personnalisée que vous avez créée à l’étape précédente. Les exemples ci-dessous montrent comment créer des itinéraires pour votre nœud et votre pod CIDRs locaux. Dans les exemples, une passerelle de transit (TGW) est utilisée pour connecter le VPC à l’environnement sur site. Si vous disposez de plusieurs nœuds et pods sur site CIDRs, répétez les étapes pour chaque CIDR. + Si vous utilisez une passerelle Internet ou une passerelle privée virtuelle (VGW), remplacez `--transit-gateway-id` par `--gateway-id`. + Remplacez `RT_ID` par l’ID de la table de routage que vous avez créée à l’étape précédente. + Remplacez `REMOTE_NODE_CIDR` par la plage CIDR que vous utiliserez pour vos nœuds hybrides. + Remplacez `REMOTE_POD_CIDR` par la plage CIDR que vous utiliserez pour les pods s’exécutant sur des nœuds hybrides. La plage CIDR du pod correspond à la configuration CNI (Container Networking Interface), qui utilise le plus souvent un réseau superposé sur site. Pour de plus amples informations, veuillez consulter [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). + Remplacez `TGW_ID` par l’ID de votre TGW. **Réseau de nœuds distants** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_NODE_CIDR \ --transit-gateway-id TGW_ID ``` **Réseau de pods distants** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_POD_CIDR \ --transit-gateway-id TGW_ID ``` ### (Facultatif) Étape 6 : associer les sous-réseaux à la table de routage Si vous avez créé une table de routage personnalisée à l’étape précédente, associez chacun des sous-réseaux que vous avez créés à l’étape précédente à votre table de routage personnalisée. Si vous modifiez la table de routage principale du VPC, les sous-réseaux sont automatiquement associés à la table de routage principale du VPC et vous pouvez ignorer cette étape. Exécutez la commande suivante pour chacun des sous-réseaux que vous avez créés lors des étapes précédentes. Remplacer `RT_ID` par la table de routage que vous avez créée à l’étape précédente. Remplacer `SUBNET_ID` par l’ID d’un sous-réseau. ``` aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID ``` ## Configuration du groupe de sécurité du cluster L’accès suivant pour votre groupe de sécurité de cluster EKS est nécessaire pour le fonctionnement continu du cluster. Amazon EKS crée automatiquement les règles de groupe de sécurité **entrantes** requises pour les nœuds hybrides lorsque vous créez ou mettez à jour votre cluster avec des réseaux de nœuds distants et de pods configurés. Étant donné que les groupes de sécurité autorisent par défaut tout le trafic **sortant**, Amazon EKS ne modifie pas automatiquement les règles **sortantes** du groupe de sécurité du cluster pour les nœuds hybrides. Si vous souhaitez personnaliser le groupe de sécurité du cluster, vous pouvez limiter le trafic aux règles indiquées dans le tableau suivant. | Type | Protocole | Direction | Port | Source | Destination | Usage | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | Entrant | 443 | CIDR des nœuds distants | N/A | Kubelet vers le serveur API Kubernetes | | HTTPS | TCP | Entrant | 443 | CIDR de pod distant(s) | N/A | Pods nécessitant un accès au serveur API K8s lorsque le CNI n’utilise pas NAT pour le trafic des pods. | | HTTPS | TCP | Sortant | 10250 | N/A | CIDR des nœuds distants | Serveur API Kubernetes vers Kubelet | | HTTPS | TCP | Sortant | Ports Webhook | N/A | CIDR de pod distant(s) | Serveur API Kubernetes vers webhook (si vous exécutez des webhooks sur des nœuds hybrides) | **Important** **Limites des règles des groupes de sécurité** : les groupes de sécurité Amazon EC2 ont un maximum de 60 règles entrantes par défaut. Les règles entrantes du groupe de sécurité peuvent ne pas s’appliquer si le groupe de sécurité de votre cluster approche cette limite. Dans ce cas, il peut être nécessaire d’ajouter manuellement les règles entrantes manquantes. **Responsabilité du nettoyage CIDR** : si vous supprimez des réseaux de nœuds distants ou de pods des clusters EKS, EKS ne supprime pas automatiquement les règles de groupe de sécurité correspondantes. Vous êtes responsable de la suppression manuelle des réseaux de nœuds distants ou de pods inutilisés de vos règles de groupe de sécurité. 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). ### (Facultatif) Configuration manuelle du groupe de sécurité Si vous devez créer des groupes de sécurité supplémentaires ou modifier les règles créées automatiquement, vous pouvez utiliser les commandes suivantes comme référence. Par défaut, la commande ci-dessous crée un groupe de sécurité qui autorise tous les accès sortants. Vous pouvez restreindre l’accès sortant afin qu’il n’inclue que les règles ci-dessus. Si vous envisagez de limiter les règles sortantes, nous vous recommandons de tester minutieusement toutes vos applications et la connectivité des pods avant d’appliquer vos règles modifiées à un cluster de production. + Dans la première commande, remplacez `SG_NAME` par le nom de votre groupe de sécurité. + Dans la première commande, remplacez `VPC_ID` par l’ID du VPC que vous avez créé à l’étape précédente. + Dans la deuxième commande, remplacez `SG_ID` par l’ID du groupe de sécurité que vous avez créé dans la première commande. + Dans la deuxième commande, remplacez `REMOTE_NODE_CIDR` et `REMOTE_POD_CIDR` par les valeurs correspondant à vos nœuds hybrides et à votre réseau local. ``` aws ec2 create-security-group \ --group-name SG_NAME \ --description "security group for hybrid nodes" \ --vpc-id VPC_ID ``` ``` aws ec2 authorize-security-group-ingress \ --group-id SG_ID \ --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]' ``` # Préparer le système d’exploitation pour les nœuds hybrides Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu et RHEL sont validés en permanence pour être utilisés comme système d'exploitation de nœuds pour les nœuds hybrides. Bottlerocket est uniquement pris en charge dans les environnements AWS vSphere VMware . AL2Le 023 n'est pas couvert par les plans de AWS Support lorsqu'il est exécuté en dehors d'Amazon EC2. AL2Le 023 ne peut être utilisé que dans des environnements virtualisés sur site. Consultez le [guide de l'utilisateur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) pour plus d'informations. AWS prend en charge l'intégration des nœuds hybrides avec les systèmes d'exploitation Ubuntu et RHEL, mais ne fournit pas de support pour le système d'exploitation lui-même. Vous êtes responsable de la mise à disposition et de la gestion du système d’exploitation. Lorsque vous testez des nœuds hybrides pour la première fois, il est plus simple d’exécuter la CLI des nœuds hybrides Amazon EKS (`nodeadm`) sur un hôte déjà provisionné. Pour les déploiements en production, nous vous recommandons d’inclure `nodeadm` dans vos images de système d’exploitation une configuration permettant leur exécution en tant que service systemd afin de joindre automatiquement les hôtes aux clusters Amazon EKS au démarrage de l’hôte. Si vous utilisez Bottlerocket comme système d’exploitation de nœud sur vSphere, vous n’avez pas besoin d’utiliser `nodeadm`, car Bottlerocket contient déjà les dépendances requises pour les nœuds hybrides et se connectera automatiquement au cluster que vous configurez au démarrage de l’hôte. ## Compatibilité des versions Le tableau ci-dessous présente les versions de système d’exploitation compatibles et validées pour être utilisées comme système d’exploitation de nœud pour les nœuds hybrides. Si vous utilisez d'autres variantes ou versions de système d'exploitation qui ne sont pas incluses dans ce tableau, la compatibilité des nœuds hybrides avec la variante ou la version de votre système d'exploitation n'est pas couverte par le AWS Support. Les nœuds hybrides sont indépendants de l’infrastructure sous-jacente et prennent en charge les architectures x86 et ARM. | Système d’exploitation | Versions | | --- | --- | | Amazon Linux | Amazon Linux 2023 (AL2023) | | Flacon Rocket | Variantes v1.37.0 et supérieures exécutant Kubernetes v1.28 et VMware versions ultérieures | | Ubuntu | Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04 | | Utilisation de Red Hat Enterprise Linux | RHEL 8, RHEL 9 | ## Considérations relatives au système d’exploitation ### Général + La CLI des nœuds hybrides Amazon EKS (`nodeadm`) peut être utilisée pour simplifier l’installation et la configuration des composants et des dépendances des nœuds hybrides. Vous pouvez exécuter le processus `nodeadm install` pendant la création des pipelines d’image de votre système d’exploitation ou au moment de l’exécution sur chaque hôte sur site. Pour plus d’informations sur les composants installés `nodeadm`, consultez le [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). + Si vous utilisez un proxy dans votre environnement sur site pour accéder à Internet, une configuration supplémentaire du système d’exploitation est nécessaire pour les processus d’installation et de mise à niveau afin de configurer votre gestionnaire de paquets pour qu’il utilise le proxy. Pour obtenir des instructions, consultez [Configurer le proxy pour les nœuds hybrides](hybrid-nodes-proxy.md). ### Flacon Rocket + Les étapes et les outils nécessaires pour connecter un nœud Bottlerocket diffèrent de ceux utilisés pour les autres systèmes d’exploitation et sont décrits séparément dans [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md), plutôt que dans [Connecter les nœuds hybrides](hybrid-nodes-join.md). + Les étapes pour Bottlerocket n’utilisent pas la CLI des nœuds hybrides, `nodeadm`. + Seules les VMware variantes de la version v1.37.0 et supérieures de Bottlerocket sont prises en charge avec les nœuds hybrides EKS. VMware des variantes de Bottlerocket sont disponibles pour les versions v1.28 et supérieures de Kubernetes. Les [autres variantes de Bottlerocket](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) ne sont pas prises en charge en tant que système d’exploitation des nœuds hybrides. REMARQUE : les VMware variantes de Bottlerocket ne sont disponibles que pour l'architecture x86\$164. ### Containerd + Containerd est l’exécution de conteneur Kubernetes standard et est une dépendance pour les nœuds hybrides, ainsi que pour tous les types de calcul de nœuds Amazon EKS. La CLI des nœuds hybrides Amazon EKS (`nodeadm`) tente d’installer containerd pendant le processus `nodeadm install`. Vous pouvez configurer l’installation de containerd lors de l’exécution `nodeadm install` à l’aide de l’option de ligne de commande `--containerd-source`. Les options valides sont `none`, `distro` et `docker`. Si vous utilisez RHEL, `distro` n’est pas une option valide. Vous pouvez soit configurer `nodeadm` pour installer la version de containerd à partir des référentiels Docker, soit installer containerd manuellement. Lorsque vous utilisez AL2 023 ou Ubuntu, installez `nodeadm` par défaut containerd à partir de la distribution du système d'exploitation. Si vous ne souhaitez pas que nodeadm installe containerd, utilisez l’option `--containerd-source none`. ### Ubuntu + Si vous utilisez Ubuntu 24.04, vous devrez peut-être mettre à jour votre version de containerd ou modifier AppArmor votre configuration pour adopter un correctif permettant aux pods de s'arrêter correctement, [voir](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423) Ubuntu \$12065423. Un redémarrage est nécessaire pour appliquer les modifications au AppArmor profil. La dernière version d’Ubuntu 24.04 dispose d’une version mise à jour de containerd dans son gestionnaire de paquets avec le correctif (containerd version 1.7.19\$1). ### ARM + Si vous utilisez du matériel ARM, un processeur compatible ARMv8 .2 avec l'extension de cryptographie (ARMv8.2\$1crypto) est requis pour exécuter les versions 1.31 et supérieures du module complémentaire EKS kube-proxy. Tous les systèmes Raspberry Pi antérieurs au Raspberry Pi 5, ainsi que les processeurs basés sur Cortex-A72, ne répondent pas à cette exigence. Comme solution de contournement, vous pouvez continuer à utiliser la version 1.30 du module complémentaire EKS kube-proxy jusqu’à la fin de son support étendu en juillet 2026 (voir le [calendrier des versions Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)), ou utiliser une image kube-proxy personnalisée provenant de l’amont. + Le message d’erreur suivant dans le journal kube-proxy indique cette incompatibilité : ``` Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later. ``` ## Création d’images du système d’exploitation Amazon EKS fournit des [exemples de modèles Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer) que vous pouvez utiliser pour créer des images de système d’exploitation qui incluent `nodeadm` et configurent Packer pour qu’il s’exécute au démarrage de l’hôte. Ce processus est recommandé pour éviter de tirer individuellement les dépendances des nœuds hybrides sur chaque hôte et pour automatiser le processus de démarrage des nœuds hybrides. Vous pouvez utiliser les modèles Packer fournis à titre d’exemple avec une image ISO Ubuntu 22.04, Ubuntu 24.04, RHEL 8 ou RHEL 9 et générer des images aux formats suivants : OVA, Qcow2 ou raw. ### Conditions préalables Avant d’utiliser les modèles Packer fournis à titre d’exemple, vous devez avoir installé les éléments suivants sur la machine à partir de laquelle vous exécutez Packer. + Packer version 1.11.0 ou supérieure. Pour obtenir des instructions sur l’installation de Packer, consultez la section [Installer Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) dans la documentation Packer. + En cas de compilation OVAs, VMware vSphere plugin 1.4.0 ou version ultérieure + Si vous créez `Qcow2` ou des images brutes, utilisez le plug-in QEMU version 1.x. ### Définir les variables d'environnement Avant d’exécuter la compilation Packer, définissez les variables d’environnement suivantes sur la machine à partir de laquelle vous exécutez Packer. **Général** Les variables d’environnement suivantes doivent être définies pour créer des images avec tous les systèmes d’exploitation et formats de sortie. | Variable d’environnement | Type | Description | | --- | --- | --- | | PKR\$1SSH\$1PASSWORD | String | Packer utilise les variables `ssh_username` et `ssh_password` pour se connecter via SSH à la machine créée lors du provisionnement. Cela doit correspondre aux mots de passe utilisés pour créer l’utilisateur initial dans les fichiers kickstart ou user-data du système d’exploitation concerné. La valeur par défaut est définie comme « builder » ou « ubuntu » selon le système d’exploitation. Lorsque vous définissez votre mot de passe, veillez à le modifier dans le fichier `ks.cfg` ou `user-data` correspondant afin qu’il corresponde. | | ISO\$1URL | String | URL de l’ISO à utiliser. Peut être un lien Web pour télécharger depuis un serveur ou un chemin absolu vers un fichier local | | ISO\$1CHECKSUM | String | Somme de contrôle associée pour l’ISO fournie. | | CREDENTIAL\$1PROVIDER | String | Fournisseur d’informations d’identification pour les nœuds hybrides. Les valeurs valides sont `ssm` (par défaut) pour les activations hybrides SSM et `iam` pour Rôles Anywhere IAM | | K8S\$1VERSION | String | Version Kubernetes pour les nœuds hybrides (par exemple `1.31`). Pour connaître les versions Kubernetes prises en charge, consultez la page [Versions Amazon EKS prises en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). | | NODEADM\$1ARCH | String | Architecture pour `nodeadm install`. Sélectionnez `amd` ou `arm`. | **RHEL** Si vous utilisez RHEL, les variables d’environnement suivantes doivent être définies. | Variable d’environnement | Type | Description | | --- | --- | --- | | RH\$1USERNAME | String | Nom d’utilisateur du gestionnaire d’abonnement RHEL | | RH\$1PASSWORD | String | Mot de passe du gestionnaire d’abonnements RHEL | | RHEL\$1VERSION | String | Version Rhel iso utilisée. Les valeurs valides sont `8` ou `9`. | **Ubuntu** Aucune variable d’environnement spécifique à Ubuntu n’est requise. **vSphere** Si vous créez un VMware vSphere OVA, les variables d'environnement suivantes doivent être définies. | Variable d’environnement | Type | Description | | --- | --- | --- | | VSPHERE\$1SERVER | String | Adresse du serveur vSphere | | VSPHERE\$1USER | String | Nom d’utilisateur vSphere | | VSPHERE\$1PASSWORD | String | Mot de passe vSphere | | VSPHERE\$1DATACENTER | String | Nom du centre de données vSphere | | VSPHERE\$1CLUSTER | String | Nom du cluster vSphere | | VSPHERE\$1DATASTORE | String | Nom de l’entrepôt de données vSphere | | VSPHERE\$1NETWORK | String | Nom du réseau vSphere | | VSPHERE\$1OUTPUT\$1FOLDER | String | Dossier de sortie vSphere pour les modèles | **QEMU** | Variable d’environnement | Type | Description | | --- | --- | --- | | PACKER\$1OUTPUT\$1FORMAT | String | Format de sortie pour le générateur QEMU. Les valeurs valides sont `qcow2` et `raw`. | **Valider le modèle** Avant d’exécuter votre build, validez votre modèle à l’aide de la commande suivante après avoir défini vos variables d’environnement. Remplacez `template.pkr.hcl` si vous utilisez un nom différent pour votre modèle. ``` packer validate template.pkr.hcl ``` ### Créer des images Créez vos images à l’aide des commandes suivantes et utilisez l’indicateur `-only` pour spécifier la cible et le système d’exploitation de vos images. Remplacez `template.pkr.hcl` si vous utilisez un autre nom pour votre modèle. **vSphere OVAs** **Note** Si vous utilisez RHEL avec vSphere, vous devez convertir les fichiers Kickstart en une image OEMDRV et la transmettre sous forme d’ISO pour démarrer à partir de celle-ci. Pour plus d'informations, consultez le fichier [Packer Readme](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) dans le référentiel EKS Hybrid Nodes GitHub . **Ubuntu 22.04 OVA** ``` packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl ``` **Ubuntu 24.04 OVA** ``` packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl ``` **RHEL 8 OVA** ``` packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl ``` **RHEL 9 OVA** ``` packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl ``` **QEMU** **Note** Si vous créez une image pour un processeur hôte spécifique qui ne correspond pas à votre hôte de compilation, consultez la documentation [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) pour trouver le nom qui correspond à votre processeur hôte et utilisez l’indicateur `-cpu` avec le nom du processeur hôte lorsque vous exécutez les commandes suivantes. **Ubuntu 22.04 Qcow2 / Raw** ``` packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl ``` **Ubuntu 24.04 Qcow2 / Raw** ``` packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl ``` **RHEL 8 Qcow2 / Raw** ``` packer build -only=general-build.qemu.rhel8 template.pkr.hcl ``` **RHEL 9 Qcow2 / Raw** ``` packer build -only=general-build.qemu.rhel9 template.pkr.hcl ``` ### Transmettre la configuration nodeadm via les données utilisateur Vous pouvez transmettre la configuration pour `nodeadm` dans vos données utilisateur via cloud-init afin de configurer et de connecter automatiquement les nœuds hybrides à votre cluster EKS au démarrage de l’hôte. Vous trouverez ci-dessous un exemple de la manière d'y parvenir lorsque vous utilisez VMware vSphere comme infrastructure pour vos nœuds hybrides. 1. Installez la `govc` CLI en suivant les instructions du [fichier readme govc](https://github.com/vmware/govmomi/blob/main/govc/README.md) on. GitHub 1. Après avoir exécuté la compilation Packer dans la section précédente et provisionné votre modèle, vous pouvez cloner votre modèle pour créer plusieurs nœuds différents à l’aide de la commande suivante. Vous devez cloner le modèle pour chaque nouvelle machine virtuelle que vous créez et qui sera utilisée pour les nœuds hybrides. Remplacez les variables dans la commande ci-dessous par les valeurs correspondant à votre environnement. La `VM_NAME` commande ci-dessous est utilisée comme vôtre `NODE_NAME` lorsque vous injectez les noms de votre VMs via votre `metadata.yaml` fichier. ``` govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \ -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME" ``` 1. Après avoir cloné le modèle pour chacun de vos nouveaux modèles VMs, créez un `userdata.yaml` et `metadata.yaml` pour votre VMs. VMs Vous pouvez les partager `userdata.yaml` `metadata.yaml` et vous les remplirez par machine virtuelle en suivant les étapes ci-dessous. La configuration `nodeadm` est créée et définie dans la section `write_files` de votre `userdata.yaml`. L'exemple ci-dessous utilise les activations hybrides AWS SSM comme fournisseur d'informations d'identification sur site pour les nœuds hybrides. Pour plus d’informations sur la configuration `nodeadm`, consultez le [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). **userdata.yaml :** ``` #cloud-config users: - name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu. passwd: # password to login. Default is 'builder' for RHEL. groups: [adm, cdrom, dip, plugdev, lxd, sudo] lock-passwd: false sudo: ALL=(ALL) NOPASSWD:ALL shell: /bin/bash write_files: - path: /usr/local/bin/nodeConfig.yaml permissions: '0644' content: | apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Cluster Name region: # AWS region hybrid: ssm: activationCode: # Your ssm activation code activationId: # Your ssm activation id runcmd: - /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1 ``` **métadonnées.yaml :** Créez un `metadata.yaml` pour votre environnement. Conservez le format variable `"$NODE_NAME"` dans le fichier, car il sera rempli avec des valeurs lors d’une étape ultérieure. ``` instance-id: "$NODE_NAME" local-hostname: "$NODE_NAME" network: version: 2 ethernets: nics: match: name: ens* dhcp4: yes ``` 1. Ajoutez les fichiers `userdata.yaml` et `metadata.yaml` sous forme de chaînes `gzip+base64` à l’aide des commandes suivantes. Les commandes suivantes doivent être exécutées pour chacune des commandes VMs que vous créez. Remplacez `VM_NAME` par le nom de la machine virtuelle que vous mettez à jour. ``` export NODE_NAME="VM_NAME" export USER_DATA=$(gzip -c9 metadata.yaml.tmp export METADATA=$(gzip -c9 Les nœuds hybrides Amazon EKS utilisent des informations d'identification IAM temporaires fournies par des activations hybrides AWS SSM ou par AWS IAM Roles Anywhere pour s'authentifier auprès du cluster Amazon EKS. Vous devez utiliser des activations hybrides AWS SSM ou des rôles AWS IAM Anywhere avec la CLI Amazon EKS Hybrid Nodes (). `nodeadm` Vous ne devez pas utiliser à la fois les activations hybrides AWS SSM et les rôles AWS IAM Anywhere. Nous vous recommandons d'utiliser les activations hybrides AWS SSM si vous ne possédez pas d'infrastructure à clé publique (PKI) existante dotée d'une autorité de certification (CA) et de certificats pour vos environnements sur site. Si vous disposez d'une infrastructure PKI et de certificats sur site, utilisez AWS IAM Roles Anywhere. ## Rôle IAM des nœuds hybrides Avant de pouvoir connecter des nœuds hybrides à votre cluster Amazon EKS, vous devez créer un rôle IAM qui sera utilisé avec les activations hybrides AWS SSM ou AWS IAM Roles Anywhere pour les informations d'identification de vos nœuds hybrides. Après la création du cluster, vous utiliserez ce rôle avec une entrée d'accès Amazon EKS ou `aws-auth` ConfigMap une entrée pour associer le rôle IAM au contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. Pour plus d’informations sur l’association du rôle IAM des nœuds hybrides avec Kubernetes RBAC, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). Le rôle IAM des nœuds hybrides doit disposer des autorisations suivantes. + Autorisations `nodeadm` permettant d'utiliser l'`eks:DescribeCluster`action pour recueillir des informations sur le cluster auquel vous souhaitez connecter des nœuds hybrides. Si vous n'activez pas l'`eks:DescribeCluster`action, vous devez transmettre votre point de terminaison d'API Kubernetes, votre bundle CA de cluster et votre IPv4 CIDR de service dans la configuration du nœud que vous transmettez à la commande. `nodeadm init` + Autorisations `nodeadm` permettant d'utiliser l'`eks:ListAccessEntries`action pour répertorier les entrées d'accès du cluster auquel vous souhaitez connecter des nœuds hybrides. Si vous n'activez pas l'`eks:ListAccessEntries`action, vous devez passer le `--skip cluster-access-validation` drapeau lorsque vous exécutez la `nodeadm init` commande. + [Autorisations permettant au kubelet d'utiliser des images de conteneur issues d'Amazon Elastic Container Registry (Amazon ECR), conformément à la politique d'Amazon. EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) + Si vous utilisez AWS SSM, autorisations `nodeadm init` pour utiliser les activations hybrides AWS SSM telles que définies dans la politique. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) + Si vous utilisez AWS SSM, autorisations d'utilisation de l'`ssm:DeregisterManagedInstance`action et de l'`ssm:DescribeInstanceInformation`action pour `nodeadm uninstall` désenregistrer les instances. + (Facultatif) Autorisations permettant à l'agent d'identité du pod Amazon EKS d'utiliser l'action `eks-auth:AssumeRoleForPodIdentity` pour récupérer les informations d'identification pour les pods. ## Configuration des activations hybrides AWS SSM Avant de configurer les activations hybrides AWS SSM, vous devez avoir créé et configuré un rôle IAM de nœuds hybrides. Pour de plus amples informations, veuillez consulter [Création du rôle IAM des nœuds hybrides](#hybrid-nodes-create-role). Suivez les instructions de la [section Créer une activation hybride pour enregistrer des nœuds auprès de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html) dans le guide de l'utilisateur de AWS Systems Manager afin de créer une activation hybride AWS SSM pour vos nœuds hybrides. Le code d’activation et l’identifiant que vous recevez sont utilisés avec `nodeadm` lorsque vous enregistrez vos hôtes en tant que nœuds hybrides avec votre cluster Amazon EKS. Vous pourrez revenir à cette étape ultérieurement après avoir créé et préparé vos clusters Amazon EKS pour les nœuds hybrides. **Important** Systems Manager renvoie immédiatement le code d'activation et l'ID à la console ou la fenêtre de commande, selon la méthode de création de l'activation. Copiez ces informations et stockez-les en lieu sûr. Si vous quittez la console ou fermez la fenêtre de commande, vous risquez de perdre ces informations. Si vous les perdez, vous devrez recréer une activation. Par défaut, les activations hybrides AWS SSM sont actives pendant 24 heures. Vous pouvez également spécifier un `--expiration-date` lorsque vous créez votre activation hybride, par exemple `2024-08-01T00:00:00`. Lorsque vous utilisez AWS SSM comme fournisseur d'informations d'identification, le nom du nœud de vos nœuds hybrides n'est pas configurable et est généré automatiquement par SSM. AWS Vous pouvez consulter et gérer les instances gérées par AWS SSM dans la console AWS Systems Manager sous Fleet Manager. Vous pouvez enregistrer jusqu'à 1 000 [nœuds hybrides](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html) standard par compte et par AWS région sans frais supplémentaires. Toutefois, pour enregistrer plus de 1 000 nœuds hybrides, vous avez besoin d'activer le niveau d'instances avancées. L’utilisation du niveau Advanced Instances entraîne des frais qui ne sont pas inclus dans la tarification des [nœuds hybrides Amazon EKS](https://aws.amazon.com/eks/pricing/). Pour plus d’informations, consultez la section [Tarifs de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/). Consultez l'exemple ci-dessous pour savoir comment créer une activation hybride AWS SSM avec votre rôle IAM Hybrid Nodes. Lorsque vous utilisez des activations hybrides AWS SSM pour les informations d'identification de vos nœuds hybrides, les noms de vos nœuds hybrides auront le même format `mi-012345678abcdefgh` et les informations d'identification temporaires fournies par AWS SSM sont valides pendant 1 heure. Vous ne pouvez pas modifier le nom du nœud ou la durée des informations d'identification lorsque vous utilisez AWS SSM comme fournisseur d'informations d'identification. Les informations d'identification temporaires sont automatiquement modifiées par AWS SSM et la rotation n'a aucun impact sur l'état de vos nœuds ou applications. Nous vous recommandons d'utiliser une activation hybride AWS SSM par cluster EKS pour définir l'`ssm:DeregisterManagedInstance`autorisation AWS SSM du rôle IAM des nœuds hybrides afin de ne pouvoir désenregistrer que les instances associées à votre activation hybride SSM. AWS Dans l'exemple de cette page, une balise avec l'ARN du cluster EKS est utilisée, qui peut être utilisée pour mapper votre activation hybride AWS SSM au cluster EKS. Vous pouvez également utiliser votre balise et votre méthode préférées pour délimiter les autorisations AWS SSM en fonction de vos limites et exigences en matière d'autorisation. L'`REGISTRATION_LIMIT`option de la commande ci-dessous est un entier utilisé pour limiter le nombre de machines pouvant utiliser l'activation hybride AWS SSM (par exemple`10`) ``` aws ssm create-activation \ --region AWS_REGION \ --default-instance-name eks-hybrid-nodes \ --description "Activation for EKS hybrid nodes" \ --iam-role AmazonEKSHybridNodesRole \ --tags Key=EKSClusterARN,Value=arn:aws: eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME \ --registration-limit REGISTRATION_LIMIT ``` Consultez les instructions de la section [Créer une activation hybride pour enregistrer des nœuds auprès de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html) pour plus d'informations sur les paramètres de configuration disponibles pour les activations hybrides AWS SSM. ## Configurer des rôles AWS IAM n'importe où Suivez les instructions de la section [Démarrage avec Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html) du guide de l’utilisateur Rôles Anywhere IAM pour configurer l’ancre d’approbation et le profil que vous utiliserez pour les informations d’identification IAM temporaires de votre rôle IAM des nœuds hybrides. Lorsque vous créez votre profil, vous pouvez le créer sans ajouter de rôles. Vous pouvez créer ce profil, revenir à ces étapes pour créer votre rôle IAM des nœuds hybrides, puis ajouter votre rôle à votre profil une fois celui-ci créé. Vous pouvez également AWS CloudFormation suivre les étapes décrites plus loin sur cette page pour terminer la configuration d'IAM Roles Anywhere pour les nœuds hybrides. Lorsque vous ajoutez le rôle IAM Hybrid Nodes à votre profil, sélectionnez **Accepter le nom de session du rôle personnalisé** **dans le panneau Nom de session du rôle personnalisé** au bas de la page **Modifier le profil** de la console AWS IAM Roles Anywhere. Cela correspond au champ [acceptRoleSessionNom](https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html#rolesanywhere-CreateProfile-request-acceptRoleSessionName) de l'`CreateProfile`API. Cela vous permet de fournir un nom de nœud personnalisé pour vos nœuds hybrides dans la configuration que vous transmettez à `nodeadm` au cours du processus d’amorçage. Il est nécessaire de passer un nom de nœud personnalisé pendant le processus `nodeadm init`. Vous pouvez mettre à jour votre profil pour accepter un nom de session personnalisé après avoir créé votre profil. Vous pouvez configurer la durée de validité des informations d'identification avec AWS IAM Roles Anywhere via le champ DurationSeconds de votre [profil IAM Roles Anywhere.](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session#credentials-object) AWS La durée par défaut est de 1 heure avec un maximum de 12 heures. Le `MaxSessionDuration` paramètre de votre rôle IAM Hybrid Nodes doit être supérieur à celui `durationSeconds` de votre profil AWS IAM Roles Anywhere. Pour plus d'informations`MaxSessionDuration`, consultez la [documentation de UpdateRole l'API](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateRole.html). Les certificats et clés par machine que vous générez à partir de votre autorité de certification (CA) doivent être placés dans le répertoire `/etc/iam/pki` de chaque nœud hybride avec les noms de fichier `server.pem` correspondant au certificat et `server.key` pour la clé. ## Création du rôle IAM des nœuds hybrides Pour exécuter les étapes décrites dans cette section, le principal IAM utilisant la AWS console ou la AWS CLI doit disposer des autorisations suivantes. + `iam:CreatePolicy` + `iam:CreateRole` + `iam:AttachRolePolicy` + Si vous utilisez AWS IAM Roles Anywhere + `rolesanywhere:CreateTrustAnchor` + `rolesanywhere:CreateProfile` + `iam:PassRole` ### AWS CloudFormation Installez et configurez la AWS CLI, si ce n'est pas déjà fait. Voir [Installation ou mise à jour vers la dernière version de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Étapes pour les AWS activations hybrides SSM** La CloudFormation pile crée le rôle IAM des nœuds hybrides avec les autorisations décrites ci-dessus. Le CloudFormation modèle ne crée pas l'activation hybride AWS SSM. 1. Téléchargez le CloudFormation modèle AWS SSM pour les nœuds hybrides : ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml' ``` 1. Créez un `cfn-ssm-parameters.json` avec les options suivantes : 1. Remplacez `ROLE_NAME` par le nom de votre rôle IAM des nœuds hybrides. Par défaut, le CloudFormation modèle utilise `AmazonEKSHybridNodesRole` comme nom du rôle qu'il crée si vous ne spécifiez aucun nom. 1. `TAG_KEY`Remplacez-la par la clé de balise de ressource AWS SSM que vous avez utilisée lors de la création de votre AWS activation hybride SSM. La combinaison de la clé de balise et de la valeur de balise est utilisée `ssm:DeregisterManagedInstance` à condition que le rôle IAM des nœuds hybrides ne soit autorisé qu'à désenregistrer les instances gérées par AWS SSM associées à votre AWS activation hybride SSM. Dans le CloudFormation modèle, la `TAG_KEY` valeur par défaut est. `EKSClusterARN` 1. `TAG_VALUE`Remplacez-la par la valeur de balise de ressource AWS SSM que vous avez utilisée lors de la création de votre AWS activation hybride SSM. La combinaison de la clé de balise et de la valeur de balise est utilisée `ssm:DeregisterManagedInstance` à condition que le rôle IAM des nœuds hybrides ne soit autorisé qu'à désenregistrer les instances gérées par AWS SSM associées à votre AWS activation hybride SSM. Si vous utilisez la valeur par défaut `TAG_KEY` ou `EKSClusterARN`, transmettez l’ARN de votre cluster EKS en tant que `TAG_VALUE`. Les clusters EKS ARNs ont le format` arn:aws: eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`. ``` { "Parameters": { "RoleName": "ROLE_NAME", "SSMDeregisterConditionTagKey": "TAG_KEY", "SSMDeregisterConditionTagValue": "TAG_VALUE" } } ``` 1. Déployez la CloudFormation pile. Remplacez `STACK_NAME` par le nom de la CloudFormation pile. ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --template-file hybrid-ssm-cfn.yaml \ --parameter-overrides file://cfn-ssm-parameters.json \ --capabilities CAPABILITY_NAMED_IAM ``` **Étapes à suivre pour jouer AWS des rôles partout dans le monde** La CloudFormation pile crée l'ancre de confiance AWS IAM Roles Anywhere auprès de l'autorité de certification (CA) que vous configurez, crée le profil AWS IAM Roles Anywhere et crée le rôle IAM Hybrid Nodes avec les autorisations décrites précédemment. 1. Pour configurer une autorité de certification (CA) 1. Pour utiliser une ressource d'autorité de certification AWS privée, ouvrez la [console AWS Private Certificate Authority](https://console.aws.amazon.com/acm-pca/home). Suivez les instructions du [Guide de l’utilisateur de l’autorité de certification privée AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). 1. Pour utiliser une autorité de certification externe, suivez les instructions fournies par celle-ci. Vous fournirez le corps du certificat lors d’une étape ultérieure. 1. Les certificats émis par le public CAs ne peuvent pas être utilisés comme points d'ancrage de confiance. 1. Téléchargez le CloudFormation modèle AWS IAM Roles Anywhere pour les nœuds hybrides ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ira-cfn.yaml' ``` 1. Créez un `cfn-iamra-parameters.json` avec les options suivantes : 1. Remplacez `ROLE_NAME` par le nom de votre rôle IAM des nœuds hybrides. Par défaut, le CloudFormation modèle utilise `AmazonEKSHybridNodesRole` comme nom du rôle qu'il crée si vous ne spécifiez aucun nom. 1. Remplacez `CERT_ATTRIBUTE` par l’attribut de certificat par machine qui identifie de manière unique votre hôte. L’attribut de certificat que vous utilisez doit correspondre au nodeName que vous utilisez pour la configuration `nodeadm` lorsque vous connectez des nœuds hybrides à votre cluster. Pour de plus amples informations, veuillez consulter [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Par défaut, le CloudFormation modèle utilise `${aws:PrincipalTag/x509Subject/CN}` as le`CERT_ATTRIBUTE`, qui correspond au champ CN de vos certificats par machine. Vous pouvez également faire passer `$(aws:PrincipalTag/x509SAN/Name/CN}` comme votre `CERT_ATTRIBUTE`. 1. Remplacez `CA_CERT_BODY` par le corps du certificat de votre autorité de certification sans sauts de ligne. Le `CA_CERT_BODY` doit être au format PEM (Privacy Enhanced Mail). Si vous disposez d’un certificat CA au format PEM, supprimez les sauts de ligne et les lignes BEGIN CERTIFICATE et END CERTIFICATE avant d’insérer le corps du certificat CA dans votre fichier `cfn-iamra-parameters.json`. ``` { "Parameters": { "RoleName": "ROLE_NAME", "CertAttributeTrustPolicy": "CERT_ATTRIBUTE", "CABundleCert": "CA_CERT_BODY" } } ``` 1. Déployez le CloudFormation modèle. Remplacez `STACK_NAME` par le nom de la CloudFormation pile. ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --template-file hybrid-ira-cfn.yaml \ --parameter-overrides file://cfn-iamra-parameters.json --capabilities CAPABILITY_NAMED_IAM ``` ### AWS CLI Installez et configurez la AWS CLI, si ce n'est pas déjà fait. Voir [Installation ou mise à jour vers la dernière version de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Créer une politique de cluster EKS Describe** 1. Créez un fichier nommé `eks-describe-cluster-policy.json` avec le contenu suivant : ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "*" } ] } ``` 1. Créez la politique à l’aide de la commande suivante : ``` aws iam create-policy \ --policy-name EKSDescribeClusterPolicy \ --policy-document file://eks-describe-cluster-policy.json ``` **Étapes pour les AWS activations hybrides SSM** 1. Créez un fichier nommé `eks-hybrid-ssm-policy.json` avec les contenus suivants. La politique autorise deux actions `ssm:DescribeInstanceInformation` et `ssm:DeregisterManagedInstance`. La politique restreint l'`ssm:DeregisterManagedInstance`autorisation aux instances gérées AWS SSM associées à votre activation hybride AWS SSM en fonction de la balise de ressource que vous spécifiez dans votre politique de confiance. 1. Remplacez `AWS_REGION` par la AWS région pour votre activation hybride AWS SSM. 1. Remplacez `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. 1. `TAG_KEY`Remplacez-la par la clé de balise de ressource AWS SSM que vous avez utilisée lors de la création de votre AWS activation hybride SSM. La combinaison de la clé de balise et de la valeur de balise est utilisée `ssm:DeregisterManagedInstance` à condition que le rôle IAM des nœuds hybrides ne soit autorisé qu'à désenregistrer les instances gérées par AWS SSM associées à votre AWS activation hybride SSM. Dans le CloudFormation modèle, la `TAG_KEY` valeur par défaut est. `EKSClusterARN` 1. `TAG_VALUE`Remplacez-la par la valeur de balise de ressource AWS SSM que vous avez utilisée lors de la création de votre AWS activation hybride SSM. La combinaison de la clé de balise et de la valeur de balise est utilisée `ssm:DeregisterManagedInstance` à condition que le rôle IAM des nœuds hybrides ne soit autorisé qu'à désenregistrer les instances gérées par AWS SSM associées à votre AWS activation hybride SSM. Si vous utilisez la valeur par défaut `TAG_KEY` ou `EKSClusterARN`, transmettez l’ARN de votre cluster EKS en tant que `TAG_VALUE`. Les clusters EKS ARNs ont le format` arn:aws: eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ssm:DescribeInstanceInformation", "Resource": "*" }, { "Effect": "Allow", "Action": "ssm:DeregisterManagedInstance", "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*", "Condition": { "StringEquals": { "ssm:resourceTag/TAG_KEY": "TAG_VALUE" } } } ] } ``` 1. Créez la politique à l’aide de la commande suivante ``` aws iam create-policy \ --policy-name EKSHybridSSMPolicy \ --policy-document file://eks-hybrid-ssm-policy.json ``` 1. Créez un fichier nommé `eks-hybrid-ssm-trust.json`. `AWS_REGION`Remplacez-le par la AWS région de votre activation hybride AWS SSM et `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*" } } } ] } ``` 1. Créez le rôle à l’aide de la commande suivante. ``` aws iam create-role \ --role-name AmazonEKSHybridNodesRole \ --assume-role-policy-document file://eks-hybrid-ssm-trust.json ``` 1. Joignez le `EKSDescribeClusterPolicy` et le `EKSHybridSSMPolicy` que vous avez créés lors des étapes précédentes. Remplacez `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy ``` ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::AWS_ACCOUNT_ID:policy/EKSHybridSSMPolicy ``` 1. Joignez les politiques `AmazonEC2ContainerRegistryPullOnly` et les politiques `AmazonSSMManagedInstanceCore` AWS gérées. ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::aws:policy/AmazonSSMManagedInstanceCore ``` **Étapes à suivre pour jouer AWS des rôles partout dans le monde** Pour utiliser AWS IAM Roles Anywhere, vous devez configurer votre ancre de confiance AWS IAM Roles Anywhere avant de créer le rôle IAM Hybrid Nodes. Pour obtenir des instructions, consultez [Configurer des rôles AWS IAM n'importe où](#hybrid-nodes-iam-roles-anywhere). 1. Créez un fichier nommé `eks-hybrid-iamra-trust.json`. Remplacez `TRUST_ANCHOR ARN` par l’ARN de l’ancre d’approbation que vous avez créée au cours des étapes [Configurer des rôles AWS IAM n'importe où](#hybrid-nodes-iam-roles-anywhere). La condition énoncée dans cette politique de confiance limite la capacité d' AWS IAM Roles Anywhere à assumer le rôle Hybrid Nodes IAM pour échanger des informations d'identification IAM temporaires uniquement lorsque le nom de session du rôle correspond au CN figurant dans le certificat x509 installé sur vos nœuds hybrides. Vous pouvez également utiliser d’autres attributs de certificat pour identifier de manière unique votre nœud. L’attribut de certificat que vous utilisez dans la stratégie de confiance doit correspondre au `nodeName` que vous avez défini dans votre configuration `nodeadm`. Pour de plus amples informations, veuillez consulter [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:TagSession", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } }, { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}", "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } } ] } ``` 1. Créez le rôle à l’aide de la commande suivante. ``` aws iam create-role \ --role-name AmazonEKSHybridNodesRole \ --assume-role-policy-document file://eks-hybrid-iamra-trust.json ``` 1. Attachez le `EKSDescribeClusterPolicy` que vous avez créé lors des étapes précédentes. Remplacez `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy ``` 1. Joindre la politique `AmazonEC2ContainerRegistryPullOnly` AWS gérée ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` ### AWS Management Console **Créer une politique de cluster EKS Describe** 1. Ouvrez la [console Amazon IAM](https://console.aws.amazon.com/iam/home). 1. Dans le volet de navigation de gauche, choisissez **Politiques**. 1. Sur la page **Politiques**, choisissez **Créer une politique**. 1. Sur la page Spécifier les autorisations, dans le panneau Sélectionner un service, choisissez EKS. 1. Filtrez les actions pour **DescribeCluster**et sélectionnez l'action **DescribeCluster**Lire. 1. Choisissez **Suivant**. 1. Sur la page **Réviser et créer** 1. Saisissez un **nom pour votre politique**, par exemple `EKSDescribeClusterPolicy`. 1. Choisissez **Create Policy** (Créer une politique). **Étapes pour les AWS activations hybrides SSM** 1. Ouvrez la [console Amazon IAM](https://console.aws.amazon.com/iam/home). 1. Dans le volet de navigation de gauche, choisissez **Politiques**. 1. Sur la page **Politiques**, choisissez **Créer une politique**. 1. Sur la page **Spécifier les autorisations**, dans le menu de navigation en haut à droite de **l’éditeur de stratégie**, sélectionnez **JSON**. Collez l’extrait suivant. Remplacez `AWS_REGION` par la AWS région de votre activation hybride AWS SSM et remplacez `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. Remplacez `TAG_KEY` et `TAG_VALUE` par la clé de balise de ressource AWS SSM que vous avez utilisée lors de la création de votre activation hybride AWS SSM. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ssm:DescribeInstanceInformation", "Resource": "*" }, { "Effect": "Allow", "Action": "ssm:DeregisterManagedInstance", "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*", "Condition": { "StringEquals": { "ssm:resourceTag/TAG_KEY": "TAG_VALUE" } } } ] } ``` 1. Choisissez **Suivant**. 1. Sur la page **Réviser et créer** 1. Saisissez un nom pour votre **politique**, par exemple `EKSHybridSSMPolicy`. 1. Choisissez **Create Policy** (Créer une politique). 1. Dans le volet de navigation de gauche, choisissez **Rôles**. 1. Sur la page **Rôles**, choisissez **Créer un rôle**. 1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit : 1. Dans la section **Type d’entité approuvée**, sélectionnez **Stratégie d’approbation personnalisée**. Collez ce qui suit dans l’éditeur de stratégie de confiance personnalisée. `AWS_REGION`Remplacez-le par la AWS région de votre activation hybride AWS SSM et `AWS_ACCOUNT_ID` par votre identifiant de AWS compte. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*" } } } ] } ``` 1. Choisissez Suivant. 1. Sur la page **Ajouter des autorisations**, associez une stratégie personnalisée ou procédez comme suit : 1. Dans la zone **Stratégies de filtre**, saisissez `EKSDescribeClusterPolicy`, ou le nom de la stratégie que vous avez créée ci-dessus. Cochez la case située à gauche du nom de votre police dans les résultats de recherche. 1. Dans la zone **Stratégies de filtre**, saisissez `EKSHybridSSMPolicy`, ou le nom de la stratégie que vous avez créée ci-dessus. Cochez la case située à gauche du nom de votre police dans les résultats de recherche. 1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEC2ContainerRegistryPullOnly`. Cochez la case à gauche de `AmazonEC2ContainerRegistryPullOnly` dans les résultats de recherche. 1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonSSMManagedInstanceCore`. Cochez la case à gauche de `AmazonSSMManagedInstanceCore` dans les résultats de recherche. 1. Choisissez **Suivant**. 1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit : 1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSHybridNodesRole`. 1. Pour **Description**, remplacez le texte actuel par un texte descriptif tel que `Amazon EKS - Hybrid Nodes role`. 1. Choisissez **Créer un rôle**. **Étapes à suivre pour jouer AWS des rôles partout dans le monde** Pour utiliser AWS IAM Roles Anywhere, vous devez configurer votre ancre de confiance AWS IAM Roles Anywhere avant de créer le rôle IAM Hybrid Nodes. Pour obtenir des instructions, consultez [Configurer des rôles AWS IAM n'importe où](#hybrid-nodes-iam-roles-anywhere). 1. Ouvrez la [console Amazon IAM](https://console.aws.amazon.com/iam/home). 1. Dans le volet de navigation de gauche, choisissez **Rôles**. 1. Sur la page **Rôles**, choisissez **Créer un rôle**. 1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit : 1. Dans la section **Type d’entité approuvée**, sélectionnez **Stratégie d’approbation personnalisée**. Collez ce qui suit dans l’éditeur de stratégie de confiance personnalisée. Remplacez `TRUST_ANCHOR ARN` par l’ARN de l’ancre d’approbation que vous avez créée au cours des étapes [Configurer des rôles AWS IAM n'importe où](#hybrid-nodes-iam-roles-anywhere). La condition énoncée dans cette politique de confiance limite la capacité d' AWS IAM Roles Anywhere à assumer le rôle Hybrid Nodes IAM pour échanger des informations d'identification IAM temporaires uniquement lorsque le nom de session du rôle correspond au CN figurant dans le certificat x509 installé sur vos nœuds hybrides. Vous pouvez également utiliser d’autres attributs de certificat pour identifier de manière unique votre nœud. L’attribut de certificat que vous utilisez dans la stratégie de confiance doit correspondre au nom de nœud que vous avez défini dans votre configuration nodeadm. Pour de plus amples informations, veuillez consulter [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:TagSession", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } }, { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}", "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } } ] } ``` 1. Choisissez Suivant. 1. Sur la page **Ajouter des autorisations**, associez une stratégie personnalisée ou procédez comme suit : 1. Dans la zone **Stratégies de filtre**, saisissez `EKSDescribeClusterPolicy`, ou le nom de la stratégie que vous avez créée ci-dessus. Cochez la case située à gauche du nom de votre police dans les résultats de recherche. 1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEC2ContainerRegistryPullOnly`. Cochez la case à gauche de `AmazonEC2ContainerRegistryPullOnly` dans les résultats de recherche. 1. Choisissez **Suivant**. 1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit : 1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSHybridNodesRole`. 1. Pour **Description**, remplacez le texte actuel par un texte descriptif tel que `Amazon EKS - Hybrid Nodes role`. 1. Choisissez **Créer un rôle**. # Créer un cluster Amazon EKS avec des nœuds hybrides Cette rubrique fournit une vue d’ensemble des options disponibles et décrit les éléments à prendre en compte lors de la création d’un cluster Amazon EKS hybride compatible avec les nœuds. Les nœuds hybrides EKS prennent en charge la [même version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que les clusters Amazon EKS avec nœuds cloud, y compris la prise en charge standard et étendue. Si vous ne prévoyez pas d’utiliser les nœuds hybrides EKS, consultez la documentation principale sur la création de clusters Amazon EKS à l’adresse [Création d’un cluster Amazon EKS](create-cluster.md). ## Conditions préalables + Le [Configuration préalable requise pour les nœuds hybrides](hybrid-nodes-prereqs.md) terminé. Avant de créer votre cluster compatible avec les nœuds hybrides, vous devez CIDRs identifier votre nœud local et éventuellement votre pod, créer votre VPC et vos sous-réseaux conformément aux exigences d'EKS et aux exigences relatives aux nœuds hybrides, ainsi que votre groupe de sécurité avec des règles d'entrée pour votre espace sur site et éventuellement pour votre espace. CIDRs Pour plus d’informations sur ces prérequis, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + La dernière version de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. 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 CLI. AWS Pour installer la dernière version, reportez-vous aux sections [Installation ou mise à jour de la dernière version de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [Configuration des paramètres de la AWS CLI dans le](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) Guide de l'utilisateur de l'interface de ligne de AWS commande. + Un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) disposant des autorisations nécessaires pour créer des rôles IAM et associer des politiques, ainsi que pour créer et décrire des clusters EKS ## Considérations + Votre cluster doit utiliser soit `API` ou `API_AND_CONFIG_MAP` pour le mode d’authentification du cluster. + Votre cluster doit utiliser une famille IPv4 d'adresses. + Votre cluster doit utiliser une connectivité de point de terminaison de cluster publique ou privée. Votre cluster ne peut pas utiliser la connectivité de point de terminaison de cluster « public et privé », car le point de terminaison du serveur d'API Amazon EKS Kubernetes sera transmis au public IPs pour les nœuds hybrides exécutés en dehors de votre VPC. + L’authentification OIDC est prise en charge pour les clusters EKS avec des nœuds hybrides. + Vous pouvez ajouter, modifier ou supprimer la configuration des nœuds hybrides d’un cluster existant. Pour de plus amples informations, veuillez consulter [Activation de nœuds hybrides sur un cluster Amazon EKS existant ou modification de la configuration](hybrid-nodes-cluster-update.md). ## Étape 1 : créer un rôle IAM de cluster Si vous possédez déjà un rôle IAM dans le cluster, ou si vous allez créer votre cluster avec `eksctl` ou AWS CloudFormation, vous pouvez ignorer cette étape. Par défaut, `eksctl` le AWS CloudFormation modèle crée le rôle IAM du cluster pour vous. 1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Créez le rôle IAM de cluster Amazon EKS. Si nécessaire, préfacez eks-cluster-role-trust -policy.json avec le chemin sur l'ordinateur où vous avez écrit le fichier à l'étape précédente. La commande associe la politique d'approbation que vous avez créée lors de l'étape précédente à ce rôle. Pour créer un rôle IAM, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) qui crée le rôle doit se voir attribuer l'action (autorisation) IAM `iam:CreateRole`. ``` aws iam create-role \ --role-name myAmazonEKSClusterRole \ --assume-role-policy-document file://"eks-cluster-role-trust-policy.json" ``` 1. Vous pouvez attribuer la politique gérée par Amazon EKS ou créer votre propre politique personnalisée. Pour connaître les autorisations minimales que vous devez utiliser dans votre politique personnalisée, consultez [Rôle IAM de nœud Amazon EKS](create-node-role.md). Attachez la politique gérée par Amazon EKS appelée `AmazonEKSClusterPolicy` au rôle. Pour attacher une politique IAM à un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal), le principal qui attache la politique doit se voir attribuer l'une des actions (autorisations) IAM `iam:AttachUserPolicy` ou `iam:AttachRolePolicy`. ``` aws iam attach-role-policy \ --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy \ --role-name myAmazonEKSClusterRole ``` ## Étape 2 : créer un cluster compatible avec les nœuds hybrides Vous pouvez créer un cluster à l’aide de : + [eksctl](#hybrid-nodes-cluster-create-eksctl) + [AWS CloudFormation](#hybrid-nodes-cluster-create-cfn) + [AWS INTERFACE DE LIGNE DE COMMANDE (CLI)](#hybrid-nodes-cluster-create-cli) + [AWS Management Console](#hybrid-nodes-cluster-create-console) ### Création d’un cluster compatible avec les nœuds hybrides – eksctl Vous devez installer la dernière version de l’outil en ligne de commande `eksctl`. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. 1. Créez `cluster-config.yaml` pour définir un cluster Amazon EKS IPv4 compatible avec les nœuds hybrides. Effectuez les remplacements suivants dans votre fichier `cluster-config.yaml`. Pour une liste complète des paramètres, consultez la documentation [eksctl](https://eksctl.io/getting-started/). 1. Remplacez `CLUSTER_NAME` 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. 1. `AWS_REGION`Remplacez-le par la AWS région dans laquelle vous souhaitez créer votre cluster. 1. Remplacez la version `K8S_VERSION` par n'importe quelle [version prise en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). 1. Remplacez `CREDS_PROVIDER` par `ssm` ou `ira` en fonction du fournisseur d’informations d’identification que vous avez configuré dans les étapes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. `CA_BUNDLE_CERT`Remplacez-le si votre fournisseur d'informations d'identification est défini sur`ira`, ce qui utilise AWS IAM Roles Anywhere comme fournisseur d'informations d'identification. CA\$1BUNDLE\$1CERT est l’autorité de certification (CA) et dépend de votre choix de CA. Le certificat doit être au format PEM (Privacy Enhanced Mail). 1. Remplacez `GATEWAY_ID` par l’ID de votre passerelle privée virtuelle ou passerelle de transit à associer à votre VPC. 1. Remplacez `REMOTE_NODE_CIDRS` par le CIDR du nœud sur site pour vos nœuds hybrides. 1. Remplacez `REMOTE_POD_CIDRS` par le CIDR du pod sur site pour les charges de travail exécutées sur des nœuds hybrides ou supprimez la ligne de votre configuration si vous n’exécutez pas de webhooks sur des nœuds hybrides. Vous devez configurer votre `REMOTE_POD_CIDRS` si votre CNI n’utilise pas la traduction d’adresses réseau (NAT) ou le masquage pour les adresses IP des pods lorsque le trafic des pods quitte vos hôtes sur site. Vous devez configurer `REMOTE_POD_CIDRS` si vous exécutez des webhooks sur des nœuds hybrides. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). 1. Les blocs CIDR de vos nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages de la IPv4 RFC-1918 :`10.0.0.0/8`, ou `172.16.0.0/12``192.168.0.0/16`, ou dans la plage CGNAT définie par la RFC 6598 :. `100.64.0.0/10` 1. Pas de chevauchement entre eux, `VPC CIDR` pour votre cluster ou pour votre service Kubernetes CIDR IPv4 ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: CLUSTER_NAME region: AWS_REGION version: "K8S_VERSION" remoteNetworkConfig: iam: provider: CREDS_PROVIDER # default SSM, can also be set to IRA # caBundleCert: CA_BUNDLE_CERT vpcGatewayID: GATEWAY_ID remoteNodeNetworks: - cidrs: ["REMOTE_NODE_CIDRS"] remotePodNetworks: - cidrs: ["REMOTE_POD_CIDRS"] ``` 1. Exécutez la commande suivante : ``` eksctl create cluster -f cluster-config.yaml ``` L'approvisionnement de cluster dure plusieurs minutes. Pendant la création du cluster, plusieurs lignes de sortie apparaissent. La dernière ligne de sortie est similaire à celle de l'exemple suivant. ``` [✓] EKS cluster "CLUSTER_NAME" in "REGION" region is ready ``` 1. Poursuivez avec [Étape 3 : mettre à jour kubeconfig](#hybrid-nodes-cluster-create-kubeconfig). ### Créez un cluster compatible avec les nœuds hybrides - AWS CloudFormation La CloudFormation pile crée le rôle IAM du cluster EKS et un cluster EKS avec le `RemoteNodeNetwork` et `RemotePodNetwork` que vous spécifiez. Modifiez le CloudFormation modèle si vous devez personnaliser les paramètres de votre cluster EKS qui ne sont pas exposés dans le CloudFormation modèle. 1. Téléchargez le CloudFormation modèle. ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml' ``` 1. Créez un `cfn-eks-parameters.json` et spécifiez votre configuration pour chaque valeur. 1. `CLUSTER_NAME` : nom du cluster EKS à créer 1. `CLUSTER_ROLE_NAME` : nom du rôle IAM du cluster EKS à créer. La valeur par défaut du modèle est « EKSCluster Rôle ». 1. `SUBNET1_ID` : l’ID du premier sous-réseau que vous avez créé lors des étapes préalables 1. `SUBNET2_ID` : l’ID du deuxième sous-réseau que vous avez créé dans les étapes préalables. 1. `SG_ID` : l’ID du groupe de sécurité que vous avez créé lors des étapes préalables. 1. `REMOTE_NODE_CIDRS` : le CIDR du nœud sur site pour vos nœuds hybrides 1. `REMOTE_POD_CIDRS` : le CIDR du pod sur site pour les charges de travail exécutées sur des nœuds hybrides. Vous devez configurer votre `REMOTE_POD_CIDRS` si votre CNI n’utilise pas la traduction d’adresses réseau (NAT) ou le masquage pour les adresses IP des pods lorsque le trafic des pods quitte vos hôtes sur site. Vous devez configurer `REMOTE_POD_CIDRS` si vous exécutez des webhooks sur des nœuds hybrides. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). 1. Les blocs CIDR de vos nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages de la IPv4 RFC-1918 :`10.0.0.0/8`, ou `172.16.0.0/12``192.168.0.0/16`, ou dans la plage CGNAT définie par la RFC 6598 :. `100.64.0.0/10` 1. Ne vous chevauchez pas, ni avec le CIDR `VPC CIDR` de votre cluster, ni avec le CIDR de votre service Kubernetes. IPv4 1. `CLUSTER_AUTH` : le mode d’authentification du cluster pour votre cluster. Les valeurs valides sont `API` et `API_AND_CONFIG_MAP`. La valeur par défaut dans le modèle est `API_AND_CONFIG_MAP`. 1. `CLUSTER_ENDPOINT` : la connectivité du point de terminaison de votre cluster. Les valeurs valides sont « Public » et « Privé ». La valeur par défaut dans le modèle est Privé, ce qui signifie que vous ne pourrez vous connecter au point de terminaison de l’API Kubernetes qu’à partir de votre VPC. 1. `K8S_VERSION` : la version de Kubernetes à utiliser pour votre cluster. Consultez les [versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). ``` { "Parameters": { "ClusterName": "CLUSTER_NAME", "ClusterRoleName": "CLUSTER_ROLE_NAME", "SubnetId1": "SUBNET1_ID", "SubnetId2": "SUBNET2_ID", "SecurityGroupId" "SG_ID", "RemoteNodeCIDR": "REMOTE_NODE_CIDRS", "RemotePodCIDR": "REMOTE_POD_CIDRS", "ClusterAuthMode": "CLUSTER_AUTH", "ClusterEndpointConnectivity": "CLUSTER_ENDPOINT", "K8sVersion": "K8S_VERSION" } } ``` 1. Déployez la CloudFormation pile. `STACK_NAME`Remplacez-le par le nom de la CloudFormation pile et `AWS_REGION` par AWS la région dans laquelle le cluster sera créé. ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --region AWS_REGION \ --template-file hybrid-eks-cfn.yaml \ --parameter-overrides file://cfn-eks-parameters.json \ --capabilities CAPABILITY_NAMED_IAM ``` L'approvisionnement de cluster dure plusieurs minutes. Vous pouvez vérifier l’état de votre pile à l’aide de la commande suivante. `STACK_NAME`Remplacez-le par le nom de la CloudFormation pile et `AWS_REGION` par AWS la région dans laquelle le cluster sera créé. ``` aws cloudformation describe-stacks \ --stack-name STACK_NAME \ --region AWS_REGION \ --query 'Stacks[].StackStatus' ``` 1. Poursuivez avec [Étape 3 : mettre à jour kubeconfig](#hybrid-nodes-cluster-create-kubeconfig). ### Créer un cluster compatible avec les nœuds hybrides - CLI AWS 1. Exécutez la commande suivante pour créer un cluster EKS hybride compatible avec les nœuds. Avant d’exécuter la commande, remplacez ce qui suit par vos paramètres. Pour obtenir la liste complète des paramètres, consultez la documentation [Création d’un cluster Amazon EKS](create-cluster.md). 1. `CLUSTER_NAME` : nom du cluster EKS à créer 1. `AWS_REGION`: AWS région dans laquelle le cluster sera créé. 1. `K8S_VERSION` : la version de Kubernetes à utiliser pour votre cluster. Consultez les versions prises en charge par Amazon EKS. 1. `ROLE_ARN` : le rôle Amazon EKS que vous avez configuré pour votre cluster. Pour plus d’informations, consultez la section Rôle IAM du cluster Amazon EKS. 1. `SUBNET1_ID` : l’ID du premier sous-réseau que vous avez créé lors des étapes préalables 1. `SUBNET2_ID` : l’ID du deuxième sous-réseau que vous avez créé dans les étapes préalables. 1. `SG_ID` : l’ID du groupe de sécurité que vous avez créé lors des étapes préalables. 1. Vous pouvez utiliser `API` et `API_AND_CONFIG_MAP` pour votre mode d’authentification d’accès au cluster. Dans la commande ci-dessous, le mode d’authentification d’accès au cluster est défini sur `API_AND_CONFIG_MAP`. 1. Vous pouvez utiliser les paramètres `endpointPublicAccess` et `endpointPrivateAccess` pour activer ou désactiver l’accès public et privé au point de terminaison de serveur d’API Kubernetes de votre cluster. Dans la commande ci-dessous, `endpointPublicAccess` est défini sur false et `endpointPrivateAccess` est défini sur true. 1. `REMOTE_NODE_CIDRS` : le CIDR du nœud sur site pour vos nœuds hybrides. 1. `REMOTE_POD_CIDRS` (facultatif) : le CIDR du pod sur site pour les charges de travail exécutées sur des nœuds hybrides. 1. Les blocs CIDR de vos nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages de la IPv4 RFC-1918 :`10.0.0.0/8`, ou `172.16.0.0/12``192.168.0.0/16`, ou dans la plage CGNAT définie par la RFC 6598 :. `100.64.0.0/10` 1. Ne vous chevauchez pas, que ce soit `VPC CIDR` pour votre cluster Amazon EKS ou pour le CIDR de votre service Kubernetes. IPv4 ``` aws eks create-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --kubernetes-version K8S_VERSION \ --role-arn ROLE_ARN \ --resources-vpc-config subnetIds=SUBNET1_ID,SUBNET2_ID,securityGroupIds=SG_ID,endpointPrivateAccess=true,endpointPublicAccess=false \ --access-config authenticationMode=API_AND_CONFIG_MAP \ --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}' ``` 1. Le provisionnement du cluster prend quelques minutes. Vous pouvez vérifier le statut de votre cluster avec la commande suivante. Remplacez `CLUSTER_NAME` par le nom du cluster que vous créez et `AWS_REGION` par la AWS région dans laquelle le cluster est créé. Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`. ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` 1. Poursuivez avec [Étape 3 : mettre à jour kubeconfig](#hybrid-nodes-cluster-create-kubeconfig). ### Créez un cluster compatible avec les nœuds hybrides - AWS Management Console 1. Ouvrez la console Amazon EKS à l’adresse [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez Add cluster (Ajouter un cluster), puis choisissez Create (Créer). 1. Sur la page Configurer le cluster, renseignez les champs suivants : 1. **Nom** : nom de votre cluster. Le nom ne peut contenir que des caractères alphanumériques (sensibles à la casse), des tirets et des traits de soulignement. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. 1. Rôle **IAM du cluster : choisissez le rôle** IAM du cluster Amazon EKS que vous avez créé pour permettre au plan de contrôle Kubernetes de gérer AWS les ressources en votre nom. 1. **Version Kubernetes** : version de Kubernetes à utiliser pour votre cluster. Nous vous recommandons de sélectionner la dernière version, sauf si vous avez besoin d'une version antérieure. 1. **Politique de mise à niveau** : choisissez Extended ou Standard. 1. **Étendu :** Cette option prend en charge la version de Kubernetes pendant 26 mois après la date de sortie. La période de support prolongée a un coût horaire supplémentaire qui commence après la fin de la période de support standard. À la fin du support étendu, votre cluster sera automatiquement mis à niveau vers la version suivante. 1. **Standard :** Cette option prend en charge la version de Kubernetes pendant 14 mois après la date de sortie. Il n’y a aucun coût supplémentaire. À la fin du support standard, votre cluster sera automatiquement mis à niveau vers la version suivante. 1. **Accès au cluster** : Choisissez d’autoriser ou de refuser l’accès à l’administrateur du cluster et sélectionnez un mode d’authentification. Les modes d’authentification suivants sont pris en charge pour les clusters compatibles avec les nœuds hybrides. 1. **API EKS** : le cluster s'approvisionnera en principaux IAM authentifiés uniquement à partir de l'entrée d'accès EKS. APIs 1. **API EKS et ConfigMap** : Le cluster fournira des principes IAM authentifiés à la fois à partir de l'entrée APIs d'accès EKS et du. `aws-auth` ConfigMap 1. **Chiffrement des secrets** : (facultatif) choisissez d'activer le chiffrement des secrets Kubernetes à l'aide d'une clé KMS. Vous pouvez également activer cette option une fois que vous avez créé votre cluster. Avant d’activer cette fonctionnalité, assurez-vous d’avoir pris connaissance des informations mentionnées dans [Chiffrer les secrets Kubernetes avec KMS sur les clusters existants](enable-kms.md). 1. **Déplacement de zone ARC** : Si cette option est activée, EKS enregistrera votre cluster auprès du déplacement de zone ARC afin de vous permettre d’utiliser le déplacement de zone pour détourner le trafic applicatif d’une zone de disponibilité. 1. **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). 1. 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 : 1. **VPC** : choisissez un VPC existant qui répond à [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md) et aux exigences des [nœuds hybrides Amazon EKS](hybrid-nodes-prereqs.md). Avant de choisir un VPC, nous vous recommandons de vous familiariser avec toutes les exigences et considérations décrites dans la section Consulter les exigences réseau Amazon EKS pour les VPC, les sous-réseaux et les nœuds hybrides. Vous ne pouvez pas modifier le VPC que vous souhaitez utiliser après la création du cluster. Si aucun VPCs n'est répertorié, vous devez d'abord en créer un. Pour plus d’informations, consultez [Création d’un VPC Amazon pour votre cluster Amazon EKS](creating-a-vpc.md) ainsi que les exigences réseau des [nœuds hybrides Amazon EKS](hybrid-nodes-prereqs.md). 1. **Sous-réseaux** : par défaut, tous les sous-réseaux disponibles dans le VPC spécifié dans le champ précédent sont présélectionnés. Vous devez en sélectionner au moins deux. 1. **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. Au moins l'un des groupes de sécurité que vous spécifiez doit disposer de règles entrantes pour votre nœud local et éventuellement pour votre pod. CIDRs Pour plus d’informations, consultez les [exigences réseau des nœuds hybrides Amazon EKS](hybrid-nodes-networking.md). Que vous choisissiez ou non un groupe de sécurité, Amazon EKS crée un groupe de sécurité qui permet la communication entre votre cluster et votre VPC. Amazon EKS associe ce groupe de sécurité, et tout ce que vous choisissez, aux interfaces réseau qu'il crée. Pour plus d’informations sur le groupe de sécurité de cluster créé par Amazon EKS, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md) Vous pouvez modifier les règles du groupe de sécurité de cluster créé par Amazon EKS. 1. **Choisissez la famille d'adresses IP du cluster** : vous devez choisir IPv4 des clusters compatibles avec les nœuds hybrides. 1. **(Facultatif) Choisissez **Configurer la plage d'adresses IP du service Kubernetes et spécifiez une plage** de services. IPv4 ** 1. **Choisissez Configurer les réseaux distants pour activer les nœuds hybrides** et spécifiez votre nœud local et votre pod CIDRs pour les nœuds hybrides. 1. Vous devez configurer le CIDR de votre pod distant si votre CNI n’utilise pas la traduction d’adresses réseau (NAT) ou le masquage pour les adresses IP des pods lorsque le trafic des pods quitte vos hôtes sur site. Vous devez configurer le CIDR du pod distant si vous exécutez des webhooks sur des nœuds hybrides. 1. Les blocs CIDR de vos nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages de la IPv4 RFC-1918 :`10.0.0.0/8`, ou `172.16.0.0/12``192.168.0.0/16`, ou dans la plage CGNAT définie par la RFC 6598 :. `100.64.0.0/10` 1. Pas de chevauchement entre eux, `VPC CIDR` pour votre cluster ou pour votre service Kubernetes CIDR IPv4 1. Pour **Accès au point de terminaison de cluster**, sélectionnez une option. Une fois votre cluster créé, vous pouvez modifier cette option. Pour les clusters compatibles avec les nœuds hybrides, vous devez choisir entre Public et Privé. Avant de sélectionner une option autre que par défaut, assurez-vous de vous familiariser avec les options et leurs implications. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md). 1. Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**. 1. (Facultatif) Sur la page **Configurer** l’observabilité, choisissez les options de métriques et de journalisation du plan de contrôle à activer. Par défaut, chaque type de journal est désactivé. 1. Pour plus d’informations sur l’option Prometheus metrics, consultez [Surveiller les métriques de votre cluster avec Prometheus](prometheus.md). 1. Pour plus d’informations sur les options de journalisation de contrôle EKS, voir [Envoyer les journaux du plan de contrôle à CloudWatch Logs](control-plane-logs.md). 1. Lorsque vous avez terminé d'utiliser cette page, choisissez **Suivant**. 1. Sur la page **Select add-ons** (Sélectionner les modules complémentaires), choisissez les modules complémentaires que vous souhaitez ajouter à votre cluster. 1. Vous pouvez choisir autant de modules complémentaires **Amazon EKS et de modules** **complémentaires AWS Marketplace** que vous le souhaitez. Les modules complémentaires Amazon EKS qui ne sont pas compatibles avec les nœuds hybrides sont signalés par la mention « Non compatible avec les nœuds hybrides » et sont soumis à une règle d’anti-affinité afin d’empêcher leur exécution sur les nœuds hybrides. Pour plus d’informations, consultez la section Configuration des modules complémentaires pour les nœuds hybrides. Si les modules complémentaires ** AWS Marketplace** que vous souhaitez installer ne figurent pas dans la liste, vous pouvez rechercher les **modules complémentaires AWS Marketplace** disponibles en saisissant du texte dans le champ de recherche. Vous pouvez également effectuer une recherche par **catégorie**, **fournisseur** ou **modèle de tarification**, puis choisir les modules complémentaires dans les résultats de la recherche. 1. Certains modules complémentaires, tels que CoreDNS et kube-proxy, sont installés par défaut. Si vous désactivez l’un des modules complémentaires par défaut, cela peut affecter votre capacité à exécuter des applications Kubernetes. 1. Lorsque vous avez terminé cette page, sélectionnez `Next`. 1. Sur la page **Configurer les paramètres de modules complémentaires sélectionnés**, sélectionnez la version que vous voulez installer. 1. Vous pourrez toujours effectuer une mise à jour vers une version ultérieure après la création du cluster. Vous pourrez mettre à jour la configuration de chaque module complémentaire après la création du cluster. Pour plus d'informations sur la configuration des modules complémentaires, consultez [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md). Pour les versions des modules complémentaires compatibles avec les nœuds hybrides, voir [Configurer les modules complémentaires pour les nœuds hybrides](hybrid-nodes-add-ons.md). 1. 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. 1. Poursuivez avec [Étape 3 : mettre à jour kubeconfig](#hybrid-nodes-cluster-create-kubeconfig). ## Étape 3 : mettre à jour kubeconfig Si vous avez créé votre cluster à l'aide de `eksctl`, vous pouvez ignorer cette étape. Cela est dû au fait que `eksctl` a déjà terminé cette étape pour vous. Activez `kubectl` la communication avec votre cluster en ajoutant un nouveau contexte au fichier de configuration `kubectl`. Pour plus d'informations sur la création et la mise à jour du fichier, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). ``` aws eks update-kubeconfig --name CLUSTER_NAME --region AWS_REGION ``` L'exemple qui suit illustre un résultat. ``` Added new context arn:aws: eks:AWS_REGION:111122223333:cluster/CLUSTER_NAME to /home/username/.kube/config ``` Confirmez la communication avec votre cluster en exécutant la commande suivante. ``` kubectl get svc ``` L'exemple qui suit illustre un résultat. ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 443/TCP 28h ``` ## Étape 4 : configuration du cluster Ensuite, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md) pour activer l’accès pour que vos nœuds hybrides puissent rejoindre votre cluster. # Activation de nœuds hybrides sur un cluster Amazon EKS existant ou modification de la configuration Cette rubrique fournit une vue d’ensemble des options disponibles et décrit les éléments à prendre en compte lorsque vous ajoutez, modifiez ou supprimez la configuration des nœuds hybrides pour un cluster Amazon EKS. Pour permettre à un cluster Amazon EKS d’utiliser des nœuds hybrides, ajoutez les plages CIDR d’adresses IP de votre nœud sur site et, éventuellement, le réseau de pods dans la configuration `RemoteNetworkConfig`. EKS utilise cette liste CIDRs pour activer la connectivité entre le cluster et vos réseaux locaux. Pour obtenir la liste complète des options lors de la mise à jour de la configuration de votre cluster, consultez le [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)manuel *Amazon EKS API Reference*. Vous pouvez effectuer l’une des actions suivantes sur la configuration réseau des nœuds hybrides EKS dans un cluster : + [Ajoutez une configuration réseau à distance pour activer les nœuds hybrides EKS dans un cluster existant](#hybrid-nodes-cluster-enable-existing). + [Ajoutez, modifiez ou supprimez les réseaux de nœuds distants ou les réseaux de pods distants dans un cluster existant](#hybrid-nodes-cluster-update-config). + [Supprimez toutes les plages CIDR du réseau des nœuds distants pour désactiver les nœuds hybrides EKS dans un cluster existant](#hybrid-nodes-cluster-disable). ## Conditions préalables + Avant d’activer votre cluster Amazon EKS pour les nœuds hybrides, assurez-vous que votre environnement répond aux exigences décrites à [Configuration préalable requise pour les nœuds hybrides](hybrid-nodes-prereqs.md), et détaillées à [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md), [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md), et [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). + Votre cluster doit utiliser une famille IPv4 d'adresses. + Votre cluster doit utiliser soit `API` ou `API_AND_CONFIG_MAP` pour le mode d’authentification du cluster. La procédure de modification du mode d’authentification du cluster est décrite à l’adresse [Modifier le mode d’authentification pour utiliser les entrées d’accès](setting-up-access-entries.md). + Nous vous recommandons d’utiliser soit l’accès public, soit l’accès privé pour le point de terminaison du serveur API Amazon EKS Kubernetes, mais pas les deux. Si vous choisissez « Public et privé », le point de terminaison du serveur d'API Amazon EKS Kubernetes indiquera toujours au public IPs les nœuds hybrides exécutés en dehors de votre VPC, ce qui peut empêcher vos nœuds hybrides de rejoindre le cluster. La procédure permettant de modifier l’accès réseau à votre cluster est décrite à l’adresse [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md). + La dernière version de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. 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 CLI. AWS Pour installer la dernière version, reportez-vous aux sections [Installation ou mise à jour vers la dernière version de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [Configuration des paramètres de la AWS CLI dans le](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) Guide de l'utilisateur de l'interface de ligne de AWS commande. + Un [responsable IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) autorisé à appeler [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)votre cluster Amazon EKS. + Mettez à jour les modules complémentaires vers des versions compatibles avec les nœuds hybrides. Pour les versions des modules complémentaires compatibles avec les nœuds hybrides, voir [Configurer les modules complémentaires pour les nœuds hybrides](hybrid-nodes-add-ons.md). + Si vous utilisez des modules complémentaires qui ne sont pas compatibles avec les nœuds hybrides, assurez-vous que le module complémentaire [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)ou le [déploiement respecte](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) la règle d'affinité suivante pour empêcher le déploiement sur des nœuds hybrides. Ajoutez la règle d’affinité suivante si elle n’est pas déjà présente. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` ## Considérations L’objet `remoteNetworkConfig` JSON se comporte comme suit lors d’une mise à jour : + Toute partie existante de la configuration que vous ne spécifiez pas reste inchangée. Si vous ne spécifiez ni `remoteNodeNetworks` ni `remotePodNetworks`, cette partie restera inchangée. + Si vous modifiez les `remotePodNetworks` listes `remoteNodeNetworks` ou les listes de CIDRs, vous devez spécifier la liste complète de celles CIDRs que vous souhaitez inclure dans votre configuration finale. Lorsque vous spécifiez une modification à apporter à la liste ou à la liste CIDR `remoteNodeNetworks` ou `remotePodNetworks`, EKS remplace la liste d’origine lors de la mise à jour. + Les blocs CIDR de vos nœuds et pods sur site doivent répondre aux exigences suivantes : 1. Soyez dans l'une des plages de la IPv4 RFC-1918 : 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, ou dans la plage CGNAT définie par la RFC 6598 : `100.64.0.0/10` 1. Il ne faut pas que tous les VPC CIDRs de votre cluster Amazon EKS ou le CIDR de votre service Kubernetes se chevauchent. IPv4 ## Activation de nœuds hybrides sur un cluster existant Vous pouvez activer les nœuds hybrides EKS dans un cluster existant en utilisant : + [AWS CloudFormation](#hybrid-nodes-cluster-enable-cfn) + [AWS INTERFACE DE LIGNE DE COMMANDE (CLI)](#hybrid-nodes-cluster-enable-cli) + [AWS Management Console](#hybrid-nodes-cluster-enable-console) ### Activez les nœuds hybrides EKS dans un cluster existant - AWS CloudFormation 1. Pour activer les nœuds hybrides EKS dans votre cluster, ajoutez le `RemoteNodeNetwork` et (facultatif) `RemotePodNetwork` à votre CloudFormation modèle et mettez à jour la pile. Notez que `RemoteNodeNetwork` est une liste comportant au maximum un élément `Cidrs` et que `Cidrs` est une liste de plusieurs plages CIDR IP. ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [RemoteNodeCIDR] RemotePodNetworks: - Cidrs: [RemotePodCIDR] ``` 1. Passez au [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ### Activer les nœuds hybrides EKS dans un cluster existant - AWS CLI 1. Exécutez la commande suivante pour activer `RemoteNetworkConfig` pour les nœuds hybrides EKS pour votre cluster EKS. Avant d’exécuter la commande, remplacez ce qui suit par vos paramètres. Pour obtenir la liste complète des paramètres, consultez le [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)manuel *Amazon EKS API Reference*. 1. `CLUSTER_NAME` : nom du cluster EKS à mettre à jour. 1. `AWS_REGION`: AWS région dans laquelle le cluster EKS est exécuté. 1. `REMOTE_NODE_CIDRS` : le CIDR du nœud sur site pour vos nœuds hybrides. 1. `REMOTE_POD_CIDRS` (facultatif) : le CIDR du pod sur site pour les charges de travail exécutées sur des nœuds hybrides. ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}' ``` 1. La mise à jour du cluster prend plusieurs minutes. Vous pouvez vérifier le statut de votre cluster avec la commande suivante. `CLUSTER_NAME`Remplacez-le par le nom du cluster que vous modifiez et `AWS_REGION` par la AWS région dans laquelle le cluster est exécuté. Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`. ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` 1. Passez au [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ### Activez les nœuds hybrides EKS dans un cluster existant - AWS Management Console 1. Ouvrez la console Amazon EKS sur la console [Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom du cluster pour afficher les informations le concernant. 1. Sélectionnez l’onglet **Réseau**, puis **Gestion**. 1. Dans le menu déroulant, sélectionnez **Réseaux distants**. 1. **Choisissez Configurer les réseaux distants pour activer les nœuds hybrides** et spécifiez votre nœud local et votre pod CIDRs pour les nœuds hybrides. 1. Choisissez **Save changes** (Enregistrer les modifications) pour terminer. Attendez que le statut du cluster redevienne **Actif**. 1. Passez au [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ## Mettre à jour la configuration des nœuds hybrides dans un cluster existant Vous pouvez modifier `remoteNetworkConfig` dans un cluster hybride existant à l’aide de l’une des méthodes suivantes : + [AWS CloudFormation](#hybrid-nodes-cluster-update-cfn) + [AWS INTERFACE DE LIGNE DE COMMANDE (CLI)](#hybrid-nodes-cluster-update-cli) + [AWS Management Console](#hybrid-nodes-cluster-update-console) ### Mettre à jour la configuration hybride dans un cluster existant - AWS CloudFormation 1. Mettez à jour votre CloudFormation modèle avec les nouvelles valeurs CIDR du réseau. ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [NEW_REMOTE_NODE_CIDRS] RemotePodNetworks: - Cidrs: [NEW_REMOTE_POD_CIDRS] ``` **Note** Lors de la mise à jour `RemoteNodeNetworks` des listes `RemotePodNetworks` CIDR, incluez tout CIDRs (nouveau et existant). EKS remplace la liste complète lors des mises à jour. En omettant ces champs dans la demande de mise à jour, leurs configurations existantes sont conservées. 1. Mettez à jour votre CloudFormation pile avec le modèle modifié et attendez que la mise à jour de la pile soit terminée. ### Mettre à jour la configuration hybride dans un cluster existant - AWS CLI 1. Pour modifier le réseau distant CIDRs, exécutez la commande suivante. Remplacez les valeurs par vos paramètres : ``` aws eks update-cluster-config --name CLUSTER_NAME --region AWS_REGION --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["NEW_REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["NEW_REMOTE_POD_CIDRS"]}]}' ``` **Note** Lors de la mise à jour `remoteNodeNetworks` des listes `remotePodNetworks` CIDR, incluez tout CIDRs (nouveau et existant). EKS remplace la liste complète lors des mises à jour. En omettant ces champs dans la demande de mise à jour, leurs configurations existantes sont conservées. 1. Attendez que le statut du cluster revienne à ACTIF avant de continuer. ### Mettre à jour la configuration hybride dans un cluster existant - AWS Management Console 1. Ouvrez la console Amazon EKS sur la console [Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom du cluster pour afficher les informations le concernant. 1. Sélectionnez l’onglet **Réseau**, puis **Gestion**. 1. Dans le menu déroulant, sélectionnez **Réseaux distants**. 1. Mettez à jour le `Remote node networks` ci-dessous et CIDRs `Remote pod networks - Optional` selon les besoins. 1. Choisissez **Enregistrer les modifications** et attendez que le statut du cluster redevienne **actif**. ## Désactiver les nœuds hybrides dans un cluster existant Vous pouvez désactiver les nœuds hybrides EKS dans un cluster existant en utilisant : + [AWS CloudFormation](#hybrid-nodes-cluster-disable-cfn) + [AWS INTERFACE DE LIGNE DE COMMANDE (CLI)](#hybrid-nodes-cluster-disable-cli) + [AWS Management Console](#hybrid-nodes-cluster-disable-console) ### Désactiver les nœuds hybrides EKS dans un cluster existant - AWS CloudFormation 1. Pour désactiver les nœuds hybrides EKS dans votre cluster, définissez `RemoteNodeNetworks` et videz `RemotePodNetworks` les baies dans votre CloudFormation modèle et mettez à jour la pile. ``` RemoteNetworkConfig: RemoteNodeNetworks: [] RemotePodNetworks: [] ``` ### Désactiver les nœuds hybrides EKS dans un cluster existant - AWS CLI 1. Exécutez la commande suivante pour supprimer `RemoteNetworkConfig` de votre cluster EKS. Avant d’exécuter la commande, remplacez ce qui suit par vos paramètres. Pour obtenir la liste complète des paramètres, consultez le [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)manuel *Amazon EKS API Reference*. 1. `CLUSTER_NAME` : nom du cluster EKS à mettre à jour. 1. `AWS_REGION`: AWS région dans laquelle le cluster EKS est exécuté. ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[],"remotePodNetworks":[]}' ``` 1. La mise à jour du cluster prend plusieurs minutes. Vous pouvez vérifier le statut de votre cluster avec la commande suivante. `CLUSTER_NAME`Remplacez-le par le nom du cluster que vous modifiez et `AWS_REGION` par la AWS région dans laquelle le cluster est exécuté. Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`. ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` ### Désactiver les nœuds hybrides EKS dans un cluster existant - AWS Management Console 1. Ouvrez la console Amazon EKS sur la console [Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom du cluster pour afficher les informations le concernant. 1. Sélectionnez l’onglet **Réseau**, puis **Gestion**. 1. Dans le menu déroulant, sélectionnez **Réseaux distants**. 1. Choisissez **Configurer les réseaux distants pour activer les nœuds hybrides** et supprimez tous les éléments situés CIDRs sous `Remote node networks` et`Remote pod networks - Optional`. 1. Choisissez **Save changes** (Enregistrer les modifications) pour terminer. Attendez que le statut du cluster redevienne **Actif**. # Préparation de l’accès au cluster pour les nœuds hybrides Avant de connecter des nœuds hybrides à votre cluster Amazon EKS, vous devez activer votre rôle IAM pour les nœuds hybrides avec les autorisations Kubernetes afin de rejoindre le cluster. Pour plus d’informations sur la création du rôle IAM de nœuds hybrides, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). Amazon EKS propose deux méthodes pour associer les principaux IAM au contrôle d'accès basé sur les rôles (RBAC) de Kubernetes, aux entrées d'accès Amazon EKS et au. `aws-auth` ConfigMap Pour plus d’informations sur la gestion des accès Amazon EKS, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md). Suivez les procédures ci-dessous pour associer votre rôle IAM des nœuds hybrides aux autorisations Kubernetes. Pour utiliser les entrées d’accès Amazon EKS, votre cluster doit avoir été créé avec les modes d’authentification `API` ou `API_AND_CONFIG_MAP`. Pour utiliser le `aws-auth` ConfigMap, votre cluster doit avoir été créé avec le mode `API_AND_CONFIG_MAP` d'authentification. Le mode d’authentification `CONFIG_MAP`-uniquement n’est pas pris en charge pour les clusters Amazon EKS compatibles avec les nœuds hybrides. ## Utilisation des entrées d’accès Amazon EKS pour le rôle IAM des nœuds hybrides Il existe un type d’entrée d’accès Amazon EKS pour les nœuds hybrides nommé HYBRID\$1LINUX qui peut être utilisé avec un rôle IAM. Avec ce type d'entrée d'accès, le nom d'utilisateur est automatiquement défini sur system:node : \$1\$1SessionName\$1\$1. Pour plus d’informations sur la création d’entrées d’accès, voir [Créer des entrées d’accès](creating-access-entries.md). ### AWS CLI 1. La dernière version de la AWS CLI doit être installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. 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 CLI. AWS Pour installer la dernière version, consultez la section Installation et configuration rapide avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande. 1. Créez votre entrée d’accès à l’aide de la commande suivante. Remplacez CLUSTER\$1NAME par le nom de votre cluster et HYBRID\$1NODES\$1ROLE\$1ARN par l’ARN du rôle que vous avez créé dans les étapes précédentes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). ``` aws eks create-access-entry --cluster-name CLUSTER_NAME \ --principal-arn HYBRID_NODES_ROLE_ARN \ --type HYBRID_LINUX ``` ### AWS Management Console 1. Ouvrez la console Amazon EKS à l’adresse [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom de votre cluster compatible avec les nœuds hybrides. 1. Choisissez l’onglet **Access**. 1. Choisissez **Créer une entrée d'accès**. 1. Pour le **principal IAM**, sélectionnez le rôle IAM des nœuds hybrides que vous avez créé dans les étapes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. Pour **Type**, sélectionnez **Linux hybride**. 1. (Facultatif) Pour **Balises**, attribuez des étiquettes à l'entrée d'accès. Par exemple, pour faciliter la recherche de toutes les ressources portant la même balise. 1. Choisissez **Passer à la révision et à la création**. Vous ne pouvez pas ajouter de stratégies à l’entrée d’accès Linux hybride ni modifier sa portée d’accès. 1. Vérifiez la configuration de votre entrée d'accès. Si quelque chose semble incorrect, choisissez **Précédent** pour revenir en arrière et corriger l'erreur. Si la configuration est correcte, choisissez **Créer**. ## Utilisation d'aws-auth ConfigMap pour le rôle IAM des nœuds hybrides Dans les étapes suivantes, vous allez créer ou mettre à jour le `aws-auth` ConfigMap avec l'ARN du rôle IAM des nœuds hybrides que vous avez créé dans les étapes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md) lesquelles. 1. Vérifiez si vous en avez déjà un `aws-auth` ConfigMap pour votre cluster. Notez que si vous utilisez un fichier `kubeconfig` spécifique, utilisez le drapeau `--kubeconfig`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Si un s'affiche `aws-auth` ConfigMap, 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. Remplacez `HYBRID_NODES_ROLE_ARN` par l’ARN de votre rôle IAM des nœuds hybrides. Remarque : `{{SessionName}}` le format de modèle à enregistrer dans le ConfigMap. Ne le remplacez pas par d’autres valeurs. ``` data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} ``` 1. Enregistrez le fichier et quittez votre éditeur de texte. 1. S'il n'en existe pas `aws-auth` ConfigMap pour votre cluster, créez-le à l'aide de la commande suivante. Remplacez `HYBRID_NODES_ROLE_ARN` par l’ARN de votre rôle IAM des nœuds hybrides. Notez qu'il `{{SessionName}}` s'agit du format de modèle correct à enregistrer dans le ConfigMap. Ne le remplacez pas par d’autres valeurs. ``` kubectl apply -f=/dev/stdin <<-EOF apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} EOF ``` # Exécution de charges de travail sur site sur des nœuds hybrides Dans un cluster EKS avec des nœuds hybrides activés, vous pouvez exécuter des applications sur site et en périphérie sur votre propre infrastructure avec les mêmes clusters, fonctionnalités et outils Amazon EKS que ceux que vous utilisez dans le cloud AWS. Les sections suivantes contiennent des instructions détaillées pour l’utilisation des nœuds hybrides. **Topics** + [Connecter les nœuds hybrides](hybrid-nodes-join.md) + [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md) + [Mettre à niveau les nœuds hybrides](hybrid-nodes-upgrade.md) + [Nœuds hybrides de patch](hybrid-nodes-security.md) + [Supprimer des nœuds hybrides](hybrid-nodes-remove.md) # Connecter les nœuds hybrides **Note** Les étapes suivantes s’appliquent aux nœuds hybrides exécutant des systèmes d’exploitation compatibles, à l’exception de Bottlerocket. Pour connaître les étapes à suivre pour connecter un nœud hybride qui exécute Bottlerocket, consultez [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md). Cette rubrique décrit comment connecter des nœuds hybrides à un cluster Amazon EKS. Une fois que vos nœuds hybrides ont rejoint le cluster, ils apparaissent avec le statut Not Ready (Non prêt) dans la console Amazon EKS et dans les outils compatibles avec Kubernetes, tels que kubectl. Une fois les étapes décrites sur cette page terminées, passez à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) pour préparer vos nœuds hybrides à exécuter des applications. ## Prérequis Avant de connecter des nœuds hybrides à votre cluster Amazon EKS, assurez-vous d’avoir suivi toutes les étapes préalables. + Vous disposez d’une connectivité réseau entre votre environnement sur site et la région AWS hébergeant votre cluster Amazon EKS. Pour plus d’informations, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Vous disposez d’un système d’exploitation compatible pour les nœuds hybrides installés sur vos hôtes sur site. Pour plus d’informations, consultez [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md). + Vous avez créé votre rôle IAM des nœuds hybrides et configuré votre fournisseur d’informations d’identification sur site (activations hybrides AWS Systems Manager ou Rôles Anywhere IAM AWS). Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). + Vous avez créé votre cluster Amazon EKS compatible avec les nœuds hybrides. Pour plus d’informations, consultez [Créer un cluster Amazon EKS avec des nœuds hybrides](hybrid-nodes-cluster-create.md). + Vous avez associé votre rôle IAM des nœuds hybrides aux autorisations RBAC de Kubernetes. Pour plus d’informations, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ## Étape 1 : installer l’interface CLI des nœuds hybrides (`nodeadm`) sur chaque hôte sur site Si vous incluez l’interface CLI des nœuds hybrides Amazon EKS (`nodeadm`) dans vos images de système d’exploitation pré-construites, vous pouvez ignorer cette étape. Pour plus d’informations sur la version hybride des nœuds de `nodeadm`, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). La version hybride des nœuds de `nodeadm` est hébergée dans Amazon S3, avec Amazon CloudFront comme interface. Pour installer `nodeadm` sur chaque hôte sur site, vous pouvez exécuter la commande suivante à partir de vos hôtes sur site. **Pour les hôtes x86\$164 :** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Pour les hôtes ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Ajoutez les permissions d’exécution au fichier binaire téléchargé sur chaque hôte. ``` chmod +x nodeadm ``` ## Étape 2 : installer les dépendances des nœuds hybrides avec `nodeadm` Si vous installez les dépendances des nœuds hybrides dans des images de système d’exploitation précompilées, vous pouvez ignorer cette étape. La commande `nodeadm install` peut être utilisée pour installer toutes les dépendances requises pour les nœuds hybrides. Les dépendances des nœuds hybrides incluent containerd, kubelet, kubectl et les composants AWS SSM ou Rôles Anywhere IAM AWS. Pour plus d’informations sur les composants et les emplacements des fichiers installés par `nodeadm install`, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Pour plus d’informations sur les domaines qui doivent être autorisés dans votre pare-feu local pour le processus `nodeadm install`, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). Exécutez la commande ci-dessous pour installer les dépendances des nœuds hybrides sur votre hôte local. La commande ci-dessous doit être exécutée par un utilisateur disposant d’un accès sudo/root sur votre hôte. **Important** Les nœuds hybrides CLI (`nodeadm`) doivent être exécutés avec un utilisateur disposant d’un accès sudo/root sur votre hôte. + Remplacez `K8S_VERSION` par la version mineure Kubernetes de votre cluster Amazon EKS, par exemple `1.31`. Consultez les [versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) pour obtenir la liste des versions Kubernetes prises en charge. + Remplacez `CREDS_PROVIDER` par le fournisseur d’informations d’identification local que vous utilisez. Les valeurs valides sont `ssm` pour AWS SSM et `iam-ra` pour Rôles Anywhere IAM AWS. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Étape 3 : connecter les nœuds hybrides à votre cluster Avant de connecter vos nœuds hybrides à votre cluster, assurez-vous d’avoir autorisé l’accès requis dans votre pare-feu local et dans le groupe de sécurité de votre cluster pour la communication entre le plan de contrôle Amazon EKS et les nœuds hybrides. La plupart des problèmes rencontrés à cette étape sont liés à la configuration du pare-feu, à la configuration du groupe de sécurité ou à la configuration du rôle IAM des nœuds hybrides. **Important** Les nœuds hybrides CLI (`nodeadm`) doivent être exécutés avec un utilisateur disposant d’un accès sudo/root sur votre hôte. 1. Créez un fichier `nodeConfig.yaml` sur chaque hôte avec les valeurs pour votre déploiement. Pour une description complète des paramètres de configuration disponibles, voir [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Si votre rôle IAM des nœuds hybrides ne dispose pas des autorisations nécessaires pour l’action `eks:DescribeCluster`, vous devez transmettre votre point de terminaison de l’API Kubernetes, votre offre groupée CA et votre CIDR IPv4 du service Kubernetes dans la section cluster de votre `nodeConfig.yaml`. 1. Utilisez l’exemple `nodeConfig.yaml` ci-dessous si vous utilisez des activations hybrides SSM AWS pour votre fournisseur d’informations d’identification sur site. 1. Remplacez `CLUSTER_NAME` par le nom de votre cluster. 1. Remplacez `AWS_REGION` par la région AWS hébergeant votre cluster. Par exemple, `us-west-2`. 1. Remplacez `ACTIVATION_CODE` par le code d’activation que vous avez reçu lors de la création de votre activation hybride SSM AWS. Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. Remplacez `ACTIVATION_ID` par l’ID d’activation que vous avez reçu lors de la création de votre activation hybride SSM AWS. Vous pouvez récupérer ces informations à partir de la console AWS Systems Manager ou à partir de la commande AWS CLI `aws ssm describe-activations`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Utilisez l’exemple `nodeConfig.yaml` ci-dessous si vous utilisez Rôles Anywhere IAM AWS pour votre fournisseur d’informations d’identification sur site. 1. Remplacez `CLUSTER_NAME` par le nom de votre cluster. 1. Remplacez `AWS_REGION` par la région AWS hébergeant votre cluster. Par exemple, `us-west-2`. 1. Remplacez `NODE_NAME` par le nom de votre nœud. Le nom du nœud doit correspondre au nom commun (CN) du certificat sur l’hôte si vous avez configuré la stratégie de confiance de votre rôle IAM des nœuds hybrides avec la condition de ressource `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. Le `nodeName` que vous utilisez ne doit pas dépasser 64 caractères. 1. Remplacez `TRUST_ANCHOR_ARN` par l’ARN de l’ancre d’approbation que vous avez configurée dans les étapes de la section Préparer les informations d’identification pour les nœuds hybrides. 1. Remplacez `PROFILE_ARN` par l’ARN de l’ancre d’approbation que vous avez configurée dans les étapes pour [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). 1. Remplacez `ROLE_ARN` par l’ARN de votre rôle IAM des nœuds hybrides. 1. Remplacez `CERTIFICATE_PATH` par le chemin d’accès sur le disque vers votre certificat de nœud. Si vous ne le précisez pas, la valeur par défaut est `/etc/iam/pki/server.pem`. 1. Remplacez `KEY_PATH` par le chemin d’accès sur le disque vers la clé privée de votre certificat. Si vous ne le précisez pas, la valeur par défaut est `/etc/iam/pki/server.key`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. Exécutez la commande `nodeadm init` avec votre `nodeConfig.yaml` pour connecter vos nœuds hybrides à votre cluster Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Si la commande ci-dessus s’exécute correctement, votre nœud hybride a rejoint votre cluster Amazon EKS. Vous pouvez vérifier cela dans la console Amazon EKS en accédant à l’onglet Calcul de votre cluster ([assurez-vous que le principal IAM dispose des autorisations nécessaires pour afficher](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) ou avec `kubectl get nodes`. **Important** Vos nœuds auront le statut `Not Ready`, ce qui est normal et dû à l’absence d’un CNI fonctionnant sur vos nœuds hybrides. Si vos nœuds ne se sont pas joints au cluster, consultez [Dépannage des nœuds hybrides](hybrid-nodes-troubleshooting.md). ## Étape 4 : configurer un CNI pour les nœuds hybrides Pour que vos nœuds hybrides soient prêts à exécuter des applications, poursuivez avec les étapes décrites à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). # Connectez des nœuds hybrides avec Bottlerocket Cette rubrique décrit comment connecter des nœuds hybrides exécutant Bottlerocket à un cluster Amazon EKS. [Bottlerocket](https://aws.amazon.com/bottlerocket/) est une distribution Linux open source sponsorisée et soutenue par. AWS Bottlerocket est spécialement conçu pour héberger des charges de travail conteneurisées. Avec Bottlerocket, vous pouvez améliorer la disponibilité des déploiements conteneurisés et réduire les coûts opérationnels en automatisant les mises à jour de votre infrastructure de conteneurs. Bottlerocket ne comprend que les logiciels essentiels à l’exécution des conteneurs, ce qui améliore l’utilisation des ressources, réduit les menaces de sécurité et diminue les frais généraux liés à la gestion. Seules les VMware variantes de la version v1.37.0 et supérieures de Bottlerocket sont prises en charge avec les nœuds hybrides EKS. VMware des variantes de Bottlerocket sont disponibles pour les versions v1.28 et supérieures de Kubernetes. Les images du système d'exploitation de ces variantes incluent le kubelet, le containerd aws-iam-authenticator et d'autres logiciels requis pour les nœuds hybrides EKS. Vous pouvez configurer ces composants à l’aide d’un fichier de [paramètres](https://github.com/bottlerocket-os/bottlerocket#settings) Bottlerocket qui comprend des données utilisateur encodées en base64 pour les conteneurs de démarrage et d’administration Bottlerocket. La configuration de ces paramètres permet à Bottlerocket d’utiliser votre fournisseur d’informations d’identification de nœuds hybrides pour authentifier les nœuds hybrides sur votre cluster. Une fois que vos nœuds hybrides ont rejoint le cluster, leur statut `Not Ready` s’affiche dans la console Amazon EKS et dans les outils compatibles avec Kubernetes, tels que `kubectl`. Une fois les étapes décrites sur cette page terminées, passez à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) pour préparer vos nœuds hybrides à exécuter des applications. ## Conditions préalables Avant de connecter des nœuds hybrides à votre cluster Amazon EKS, assurez-vous d’avoir suivi toutes les étapes préalables. + Vous disposez d'une connectivité réseau entre votre environnement sur site et la AWS région hébergeant votre cluster Amazon EKS. Pour plus d’informations, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Vous avez créé votre rôle Hybrid Nodes IAM et configuré votre fournisseur d'informations d'identification sur site (activations hybrides de AWS Systems Manager ou AWS IAM Roles Anywhere). Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). + Vous avez créé votre cluster Amazon EKS compatible avec les nœuds hybrides. Pour plus d’informations, consultez [Créer un cluster Amazon EKS avec des nœuds hybrides](hybrid-nodes-cluster-create.md). + Vous avez associé votre rôle IAM des nœuds hybrides aux autorisations RBAC de Kubernetes. Pour plus d’informations, consultez [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ## Étape 1 : créer le fichier TOML des paramètres Bottlerocket Pour configurer Bottlerocket pour les nœuds hybrides, vous devez créer un fichier `settings.toml` contenant la configuration nécessaire. Le contenu du fichier TOML varie en fonction du fournisseur d’informations d’identification que vous utilisez (SSM ou Rôles Anywhere IAM). Ce fichier sera transmis en tant que données utilisateur lors de la mise à disposition de l’instance Bottlerocket. **Note** Les fichiers TOML fournis ci-dessous ne représentent que les paramètres minimaux requis pour initialiser une VMWare machine Bottlerocket en tant que nœud sur un cluster EKS. Bottlerocket fournit une large gamme de paramètres pour répondre à différents cas d'utilisation. Pour d'autres options de configuration au-delà de l'initialisation du nœud hybride, veuillez consulter la [documentation de Bottlerocket](https://bottlerocket.dev/en) pour obtenir la liste complète de tous les paramètres documentés pour la version de Bottlerocket que vous utilisez (par exemple, [voici](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) tous les paramètres disponibles pour Bottlerocket 1.51.x). ### SSM Si vous utilisez AWS Systems Manager comme fournisseur d'informations d'identification, créez un `settings.toml` fichier avec le contenu suivant : ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` Remplacez les espaces réservés par les valeurs suivantes : + `` : le nom de votre cluster Amazon EKS. + `` : point de terminaison du serveur d’API de votre cluster. + `` : Ensemble CA codé en base64 de votre cluster. + ``: La AWS région hébergeant votre cluster, par exemple « us-east-1 ». + `` : le nom d’hôte de l’instance Bottlerocket, qui sera également configuré comme nom de nœud. Il peut s’agir de n’importe quelle valeur unique de votre choix, mais elle doit respecter les [conventions de nommage des objets Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). De plus, le nom d’hôte que vous utilisez ne peut pas dépasser 64 caractères. REMARQUE : lorsque vous utilisez le fournisseur SSM, ce nom d’hôte et ce nom de nœud seront remplacés par l’ID de l’instance gérée (par exemple, ID `mi-*`) une fois que l’instance aura été enregistrée auprès de SSM. + `` : Contenu codé en base64 de la configuration du conteneur d’administration Bottlerocket. L’activation du conteneur d’administration vous permet de vous connecter à votre instance Bottlerocket avec SSH pour explorer le système et le déboguer. Bien que ce paramètre ne soit pas obligatoire, nous vous recommandons de l’activer afin de faciliter le dépannage. Pour plus d’informations sur l’authentification avec le conteneur d’administration, consultez la [documentation relative au conteneur d’administration Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Le conteneur d’administration accepte les entrées utilisateur et clé SSH au format JSON, par exemple : ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + `` : Contenu encodé en base64 de la configuration du conteneur d’amorçage Bottlerocket. Pour plus d’informations sur sa configuration, consultez la [documentation relative au conteneur Bottlerocket bootstrap](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Le conteneur bootstrap est chargé d'enregistrer l'instance en tant qu'instance gérée par AWS SSM et de la joindre en tant que nœud Kubernetes sur votre cluster Amazon EKS. Les données utilisateur transmises au conteneur Bootstrap prennent la forme d’une invocation de commande qui accepte en entrée le code d’activation hybride SSM et l’ID que vous avez créés précédemment : ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### Rôles Anywhere IAM Si vous utilisez AWS IAM Roles Anywhere comme fournisseur d'informations d'identification, créez un `settings.toml` fichier avec le contenu suivant : ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` Remplacez les espaces réservés par les valeurs suivantes : + `` : le nom de votre cluster Amazon EKS. + `` : point de terminaison du serveur d’API de votre cluster. + `` : Ensemble CA codé en base64 de votre cluster. + ``: La AWS région hébergeant votre cluster, par exemple « us-east-1 » + `` : le nom d’hôte de l’instance Bottlerocket, qui sera également configuré comme nom de nœud. Il peut s’agir de n’importe quelle valeur unique de votre choix, mais elle doit respecter les [conventions de nommage des objets Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). De plus, le nom d’hôte que vous utilisez ne peut pas dépasser 64 caractères. REMARQUE : lorsque vous utilisez le fournisseur IAM-RA, le nom du nœud doit correspondre au nom commun (CN) du certificat sur l’hôte si vous avez configuré la stratégie de confiance de votre rôle IAM des nœuds hybrides avec la condition de ressource `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + ``: le contenu codé en base64 de votre AWS fichier de configuration. Le contenu du fichier doit être le suivant : ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + `` : Contenu codé en base64 de la configuration du conteneur d’administration Bottlerocket. L’activation du conteneur d’administration vous permet de vous connecter à votre instance Bottlerocket avec SSH pour explorer le système et le déboguer. Bien que ce paramètre ne soit pas obligatoire, nous vous recommandons de l’activer afin de faciliter le dépannage. Pour plus d’informations sur l’authentification avec le conteneur d’administration, consultez la [documentation relative au conteneur d’administration Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). Le conteneur d’administration accepte les entrées utilisateur et clé SSH au format JSON, par exemple : ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + `` : Contenu encodé en base64 de la configuration du conteneur d’amorçage Bottlerocket. Pour plus d’informations sur sa configuration, consultez la [documentation relative au conteneur Bottlerocket bootstrap](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container). Le conteneur Bootstrap est chargé de créer les fichiers de certificat hôte et de clé privée de certificat Rôles Anywhere IAM sur l’instance. Ceux-ci seront ensuite utilisés par le `aws_signing_helper` pour obtenir des informations d’identification temporaires afin de s’authentifier auprès de votre cluster Amazon EKS. Les données utilisateur transmises au conteneur bootstrap prennent la forme d’une invocation de commande qui accepte en entrée le contenu du certificat et de la clé privée que vous avez créés précédemment : ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Étape 2 : fournir les données utilisateur à la machine virtuelle Bottlerocket vSphere Une fois le fichier TOML créé, transmettez-le en tant que données utilisateur lors de la création de la machine virtuelle vSphere. N’oubliez pas que les données utilisateur doivent être configurées avant la première mise sous tension de la machine virtuelle. Vous devrez donc le fournir lors de la création de l’instance. Si vous souhaitez créer la VM à l’avance, celle-ci devra être dans un état « poweredOff » jusqu’à ce que vous configuriez les données utilisateur correspondantes. Par exemple, si vous utilisez l’interface CLI `govc` : ### Création d’une machine virtuelle pour la première fois ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### Mise à jour des données utilisateur pour une machine virtuelle existante ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` Dans les sections ci-dessus, l’option `-e guestinfo.userdata.encoding="base64"` spécifie que les données utilisateur sont encodées en base64. Cette option `-e guestinfo.userdata` transmet le contenu du fichier `settings.toml` encodé en base64 sous forme de données utilisateur à l’instance Bottlerocket. Remplacez les espaces réservés par vos valeurs spécifiques, telles que le modèle OVA Bottlerocket et les détails réseau. ## Étape 3 : vérifier la connexion du nœud hybride Une fois l’instance Bottlerocket démarrée, elle tentera de rejoindre votre cluster Amazon EKS. Vous pouvez vérifier la connexion dans la console Amazon EKS en accédant à l’onglet Calcul de votre cluster ou en exécutant la commande suivante : ``` kubectl get nodes ``` **Important** Vos nœuds auront le statut `Not Ready`, ce qui est normal et dû à l’absence d’un CNI fonctionnant sur vos nœuds hybrides. Si vos nœuds ne se sont pas joints au cluster, consultez [Dépannage des nœuds hybrides](hybrid-nodes-troubleshooting.md). ## Étape 4 : configurer un CNI pour les nœuds hybrides Pour que vos nœuds hybrides soient prêts à exécuter des applications, poursuivez avec les étapes décrites à la section [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). # Mettre à niveau les nœuds hybrides pour votre cluster Les instructions relatives à la mise à niveau des nœuds hybrides sont similaires à celles des nœuds Amazon EKS autogérés qui s’exécutent dans Amazon EC2. Nous vous recommandons de créer de nouveaux nœuds hybrides sur votre version Kubernetes cible, de migrer en douceur vos applications existantes vers les nœuds hybrides de la nouvelle version Kubernetes, puis de supprimer les nœuds hybrides de l’ancienne version Kubernetes de votre cluster. Avant de lancer une mise à niveau, veillez à consulter les [meilleures pratiques Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) en matière de mise à niveau. Les nœuds hybrides Amazon EKS prennent en charge la [même version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que les clusters Amazon EKS avec nœuds cloud, y compris la prise en charge standard et étendue. Les nœuds hybrides Amazon EKS suivent la même [politique de distorsion des versions](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) pour les nœuds que pour Kubernetes en amont. Les nœuds hybrides Amazon EKS ne peuvent pas être d’une version plus récente que le plan de contrôle Amazon EKS, et les nœuds hybrides peuvent être jusqu’à trois versions mineures Kubernetes plus anciennes que la version mineure du plan de contrôle Amazon EKS. Si vous ne disposez pas de capacité suffisante pour créer de nouveaux nœuds hybrides sur votre version Kubernetes cible dans le cadre d’une stratégie de migration par basculement, vous pouvez également utiliser l’interface CLI nœuds hybrides Amazon EKS (`nodeadm`) pour mettre à niveau la version Kubernetes de vos nœuds hybrides sur place. **Important** Si vous mettez à niveau vos nœuds hybrides sur place avec `nodeadm`, il y a une durée d’indisponibilité pour le nœud pendant le processus où l’ancienne version des composants Kubernetes est arrêtée et où les composants de la nouvelle version Kubernetes sont installés et démarrés. ## Prérequis Avant de procéder à la mise à niveau, assurez-vous d’avoir rempli les conditions préalables suivantes. + La version Kubernetes cible pour la mise à niveau de vos nœuds hybrides doit être égale ou inférieure à la version du plan de contrôle Amazon EKS. + Si vous suivez une stratégie de migration par basculement, les nouveaux nœuds hybrides que vous installez sur votre version Kubernetes cible doivent répondre aux exigences [Configuration préalable requise pour les nœuds hybrides](hybrid-nodes-prereqs.md). Cela inclut le fait d’avoir des adresses IP dans le CIDR du réseau de nœuds distants que vous avez transmis lors de la création du cluster Amazon EKS. + Pour les migrations par basculement et les mises à niveau sur site, les nœuds hybrides doivent avoir accès aux [domaines requis](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) pour extraire les nouvelles versions des dépendances des nœuds hybrides. + Vous devez avoir installé kubectl sur votre machine locale ou l’instance que vous utilisez pour interagir avec votre point de terminaison API Amazon EKS Kubernetes. + La version de votre CNI doit prendre en charge la version de Kubernetes vers laquelle vous effectuez la mise à niveau. Si ce n’est pas le cas, mettez à niveau votre version CNI avant de mettre à niveau vos nœuds hybrides. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ## Mises à niveau liées à la migration par transition (bleu-vert) Les *mises à niveau par migration cutover* désignent le processus consistant à créer de nouveaux nœuds hybrides sur de nouveaux hôtes avec votre version Kubernetes cible, à migrer en douceur vos applications existantes vers les nouveaux nœuds hybrides sur votre version Kubernetes cible, et à supprimer les nœuds hybrides sur l’ancienne version Kubernetes de votre cluster. Cette stratégie est également appelée migration bleu-vert. 1. Connectez vos nouveaux hôtes en tant que nœuds hybrides en suivant les étapes [Connecter les nœuds hybrides](hybrid-nodes-join.md). Lorsque vous exécutez la commande `nodeadm install`, utilisez votre version cible de Kubernetes. 1. Activez la communication entre les nouveaux nœuds hybrides sur la version Kubernetes cible et vos nœuds hybrides sur l’ancienne version Kubernetes. Cette configuration permet aux pods de communiquer entre eux pendant que vous migrez votre charge de travail vers les nœuds hybrides sur la version Kubernetes cible. 1. Vérifiez que vos nœuds hybrides sur votre version Kubernetes cible ont bien rejoint votre cluster et ont le statut Ready. 1. Utilisez la commande suivante pour marquer chacun des nœuds que vous souhaitez supprimer comme non planifiable. Cela permet d’éviter que de nouveaux pods ne soient planifiés ou replanifiés sur les nœuds que vous remplacez. Pour plus d’informations, consultez [le cordon kubelet](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom des nœuds hybrides de l’ancienne version de Kubernetes. ``` kubectl cordon NODE_NAME ``` Vous pouvez identifier et isoler tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. Si votre déploiement actuel exécute moins de deux réplicas CoreDNS sur vos nœuds hybrides, augmentez horizontalement la capacité du déploiement à au moins deux réplicas. Nous vous recommandons d’exécuter au moins deux réplicas CoreDNS sur des nœuds hybrides afin d’assurer la résilience pendant les opérations normales. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Videz chacun des nœuds hybrides de l’ancienne version de Kubernetes que vous souhaitez supprimer de votre cluster à l’aide de la commande suivante. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom des nœuds hybrides de l’ancienne version de Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Vous pouvez identifier et vider tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. Vous pouvez utiliser `nodeadm` pour arrêter et supprimer les artefacts des nœuds hybrides de l’hôte. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. Pour plus d’informations, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Une fois les artefacts des nœuds hybrides arrêtés et désinstallés, supprimez la ressource du nœud de votre cluster. ``` kubectl delete node node-name ``` Vous pouvez identifier et supprimer tous les nœuds d’une version particulière de Kubernetes (dans ce cas, `1.28`) à l’aide de l’extrait de code suivant. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. Selon votre choix de CNI, il se peut que des artefacts subsistent sur vos nœuds hybrides après avoir exécuté les étapes ci-dessus. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ## Mises à niveau sur place Le processus de mise à niveau sur place consiste à utiliser `nodeadm upgrade` pour mettre à niveau la version Kubernetes pour les nœuds hybrides sans utiliser de nouveaux hôtes physiques ou virtuels ni de stratégie de migration par basculement. Le processus `nodeadm upgrade` arrête les anciens composants Kubernetes existants qui s’exécutent sur le nœud hybride, désinstalle les anciens composants Kubernetes existants, installe les nouveaux composants Kubernetes cibles et démarre les nouveaux composants Kubernetes cibles. Il est fortement recommandé de mettre à niveau un nœud à la fois afin de minimiser l’impact sur les applications exécutées sur les nœuds hybrides. La durée de ce processus dépend de la bande passante et de la latence de votre réseau. 1. Utilisez la commande suivante pour marquer le nœud que vous mettez à niveau comme non planifiable. Cela permet d’éviter que de nouveaux pods ne soient planifiés ou replanifiés sur le nœud que vous mettez à niveau. Pour plus d’informations, consultez [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) dans la documentation Kubernetes. Remplacer `NODE_NAME` par le nom du nœud hybride que vous mettez à niveau ``` kubectl cordon NODE_NAME ``` 1. Videz le nœud que vous mettez à niveau à l’aide de la commande suivante. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Remplacez `NODE_NAME` par le nom du nœud hybride que vous mettez à niveau. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Exécutez `nodeadm upgrade` sur le nœud hybride que vous mettez à niveau. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Le nom du nœud est conservé lors de la mise à niveau pour les fournisseurs d’informations d’identification AWS SSM et Rôles Anywhere IAM AWS. Vous ne pouvez pas changer de fournisseur d’informations d’identification pendant le processus de mise à niveau. Consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md) pour les valeurs de configuration de `nodeConfig.yaml`. Remplacez `K8S_VERSION` par la version cible de Kubernetes vers laquelle vous effectuez la mise à niveau. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Pour autoriser la planification des pods sur le nœud après la mise à niveau, tapez ce qui suit. Remplacez `NODE_NAME` par le nom du nœud. ``` kubectl uncordon NODE_NAME ``` 1. Vérifiez le statut de vos nœuds hybrides et attendez que vos nœuds s’arrêtent et redémarrent sur la nouvelle version de Kubernetes avec le statut Ready. ``` kubectl get nodes -o wide -w ``` # Mises à jour de sécurité pour les nœuds hybrides Cette rubrique décrit la procédure à suivre pour appliquer des correctifs de sécurité à des packages et dépendances spécifiques s’exécutant sur vos nœuds hybrides. Nous vous recommandons de mettre régulièrement à jour vos nœuds hybrides afin de recevoir les CVE et les correctifs de sécurité. Pour connaître les étapes à suivre pour mettre à niveau la version de Kubernetes, consultez [Mettre à niveau les nœuds hybrides pour votre cluster](hybrid-nodes-upgrade.md). Un exemple de logiciel pouvant nécessiter un correctif de sécurité est `containerd`. ## `Containerd` `containerd` est l’exécution de conteneur Kubernetes standard et la dépendance principale pour les nœuds hybrides EKS, utilisée pour gérer le cycle de vie des conteneurs, y compris le téléchargement d’images et la gestion de l’exécution des conteneurs. Sur un nœud hybride, vous pouvez installer `containerd` via l’interface [CLI nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) ou manuellement. En fonction du système d’exploitation de votre nœud, `nodeadm` installera `containerd` à partir du paquet distribué par le système d’exploitation ou du paquet Docker. Lorsqu’un CVE dans `containerd` a été publié, vous disposez des options suivantes pour passer à la version corrigée de `containerd` sur vos nœuds hybrides. ## Étape 1 : vérifier si le correctif a été publié dans les gestionnaires de paquets Vous pouvez vérifier si le correctif CVE `containerd` a été publié pour chaque gestionnaire de paquets OS en consultant les bulletins de sécurité correspondants : + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Si vous utilisez le dépôt Docker comme source de `containerd`, vous pouvez consulter les [annonces de sécurité Docker](https://docs.docker.com/security/security-announcements/) pour vérifier la disponibilité de la version corrigée dans le dépôt Docker. ## Étape 2 : choisir la méthode d’installation du correctif Il existe trois méthodes pour corriger et installer les mises à niveau de sécurité sur place sur les nœuds. La méthode que vous pouvez utiliser dépend de la disponibilité du correctif dans le gestionnaire de paquets du système d’exploitation : 1. Installez les correctifs avec `nodeadm upgrade` qui sont publiés dans les gestionnaires de paquets, voir [Étape 2a](#hybrid-nodes-security-nodeadm). 1. Installez les correctifs directement à l’aide des gestionnaires de paquets, voir [Étape 2b](#hybrid-nodes-security-package). 1. Installez des correctifs personnalisés qui ne sont pas publiés dans les gestionnaires de paquets. Veuillez noter qu’il existe des considérations particulières pour les correctifs personnalisés pour `containerd`, [Étape 2c](#hybrid-nodes-security-manual). ## Étape 2a : application d’un correctif avec `nodeadm upgrade` Après avoir vérifié que le correctif CVE `containerd` a été publié dans les référentiels OS ou Docker (Apt ou RPM), vous pouvez utiliser la commande `nodeadm upgrade` pour passer à la dernière version de `containerd`. Comme il ne s’agit pas d’une mise à niveau de la version Kubernetes, vous devez indiquer votre version Kubernetes actuelle dans la commande de mise à niveau `nodeadm`. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Étape 2b : application de correctifs à l’aide des gestionnaires de paquets du système d’exploitation Vous pouvez également effectuer la mise à jour via le gestionnaire de paquets correspondant et l’utiliser pour mettre à niveau le paquet `containerd` comme suit. **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## Étape 2c : correctif CVE `Containerd` non publié dans les gestionnaires de paquets Si la version corrigée `containerd` n’est disponible que par d’autres moyens que le gestionnaire de paquets, par exemple dans les versions GitHub, vous pouvez installer `containerd` à partir du site officiel GitHub. 1. Si la machine a déjà rejoint le cluster en tant que nœud hybride, vous devez alors exécuter la commande `nodeadm uninstall`. 1. Installez les binaires officiels `containerd`. Vous pouvez suivre les [étapes d’installation officielles](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) sur GitHub. 1. Exécutez la commande `nodeadm install` avec l’argument `--containerd-source` défini sur `none`, ce qui ignorera l’installation `containerd` via `nodeadm`. Vous pouvez utiliser la valeur de `none` dans la source `containerd` pour tout système d’exploitation exécuté par le nœud. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Supprimer les nœuds hybrides Cette rubrique décrit comment supprimer les nœuds hybrides de votre cluster Amazon EKS. [Vous devez supprimer vos nœuds hybrides avec l’outil compatible Kubernetes de votre choix, tel que kubectl.](https://kubernetes.io/docs/reference/kubectl/) Les frais liés aux nœuds hybrides cessent lorsque l’objet nœud est supprimé du cluster Amazon EKS. Pour plus d’informations sur la tarification des nœuds hybrides, consultez la section [Tarification d’Amazon EKS](https://aws.amazon.com/eks/pricing/). **Important** La suppression de nœuds perturbe les charges de travail exécutées sur le nœud. Avant de supprimer des nœuds hybrides, nous vous recommandons de vider d’abord le nœud afin de déplacer les pods vers un autre nœud actif. Pour plus d’informations sur la mise hors tension des nœuds, consultez la section [Mettre hors tension un nœud](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en toute sécurité dans la documentation Kubernetes. Exécutez les étapes kubectl ci-dessous à partir de votre machine locale ou de l’instance que vous utilisez pour interagir avec le point de terminaison API Kubernetes du cluster Amazon EKS. Si vous utilisez un fichier spécifique `kubeconfig`, utilisez l’indicateur `--kubeconfig`. ## Étape 1 : répertorier vos nœuds ``` kubectl get nodes ``` ## Étape 2 : vider votre nœud Pour plus d’informations sur cette commande `kubectl drain`, consultez la section [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) dans la documentation Kubernetes. ``` kubectl drain --ignore-daemonsets ``` ## Étape 3 : arrêter et désinstaller les artefacts des nœuds hybrides Vous pouvez utiliser la CLI des nœuds hybrides Amazon EKS (`nodeadm`) pour arrêter et supprimer les artefacts des nœuds hybrides de l’hôte. Vous devez exécuter `nodeadm` avec un utilisateur disposant des privilèges root/sudo. Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. Si vous utilisez Systems Manager (SSM) AWS comme fournisseur d’informations d’identification, la commande `nodeadm uninstall` désenregistre l’hôte en tant qu’instance AWS gérée par SSM. Pour de plus amples informations, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Étape 4 : supprimer votre nœud du cluster Une fois les artefacts des nœuds hybrides arrêtés et désinstallés, supprimez la ressource du nœud de votre cluster. ``` kubectl delete node ``` ## Étape 5 : vérifier s’il reste des artefacts Selon votre choix de CNI, il se peut que des artefacts subsistent sur vos nœuds hybrides après avoir exécuté les étapes ci-dessus. Pour plus d'informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). # Configuration de la mise en réseau des applications, des modules complémentaires et des webhooks pour les nœuds hybrides Après avoir créé un cluster EKS pour les nœuds hybrides, configurez des fonctionnalités supplémentaires pour la mise en réseau des applications (CNI, BGP, Ingress, équilibrage de charge, politiques réseau), les modules complémentaires, les webhooks et les paramètres de proxy. Pour obtenir la liste complète des modules complémentaires EKS et communautaires compatibles avec les nœuds hybrides, consultez [Configurer les modules complémentaires pour les nœuds hybrides](hybrid-nodes-add-ons.md). **Informations sur les clusters EKS** EKS inclut des vérifications permettant de détecter les erreurs de configuration dans vos nœuds hybrides qui pourraient nuire au bon fonctionnement de votre cluster ou de vos charges de travail. Pour plus d’informations sur les informations relatives aux clusters, consultez [Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters](cluster-insights.md). La liste suivante répertorie les fonctionnalités courantes et les modules complémentaires que vous pouvez utiliser avec les nœuds hybrides : + **Interface réseau de conteneur (CNI)** : AWS prend en charge [Cilium](https://docs.cilium.io/en/stable/index.html) en tant que CNI pour les nœuds hybrides. Pour de plus amples informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). Notez que le CNI VPC AWS ne peut pas être utilisé avec des nœuds hybrides. + **CoreDNS et `kube-proxy` ** : CoreDNS et `kube-proxy` sont installés automatiquement lorsque des nœuds hybrides rejoignent le cluster EKS. Ces modules complémentaires peuvent être gérés en tant que modules complémentaires EKS après la création du cluster. + **Ingress et équilibrage de charge** : vous pouvez utiliser l’AWS Load Balancer Controller et le Application Load Balancer (ALB) ou Network Load Balancer (NLB) avec le type de cible `ip` pour les charges de travail s’exécutant sur des nœuds hybrides. AWS prend en charge les fonctionnalités intégrées d’Ingress, de passerelle et d’équilibrage de charge Kubernetes Service de Cilium pour les charges de travail s’exécutant sur des nœuds hybrides. Pour plus d’informations, consultez [Configurer Kubernetes Ingress pour les nœuds hybrides](hybrid-nodes-ingress.md) et [Configurer les services de type LoadBalancer pour les nœuds hybrides](hybrid-nodes-load-balancing.md). + **Métriques** : vous pouvez utiliser les scrapers sans agent du service géré Amazon pour Prometheus (AMP), AWS Distro for Open Telemetry (ADOT) et l’agent d’observabilité Amazon CloudWatch avec des nœuds hybrides. Pour utiliser les scrapers AMP sans agent pour les métriques de pod sur les nœuds hybrides, vos pods doivent être accessibles depuis le VPC que vous utilisez pour le cluster EKS. + **Journaux** : Vous pouvez activer la journalisation du plan de contrôle EKS pour les clusters compatibles avec les nœuds hybrides. Vous pouvez utiliser le module complémentaire EKS ADOT et le module complémentaire EKS de l’agent d’observabilité Amazon CloudWatch pour la journalisation hybride des nœuds et des pods. + **Identités de pod et IRSA** : Vous pouvez utiliser les identités de pod EKS et les rôles IAM pour les comptes de service (IRSA) avec des applications s’exécutant sur des nœuds hybrides afin de permettre un accès granulaire à vos pods s’exécutant sur des nœuds hybrides avec d’autres services AWS. + **Webhooks** : si vous utilisez des webhooks, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md) pour obtenir les considérations et les étapes à suivre pour exécuter éventuellement des webhooks sur des nœuds cloud si vous ne pouvez pas rendre vos réseaux de pods sur site routables. + **Proxy** : si vous utilisez un serveur proxy dans votre environnement sur site pour le trafic sortant de votre centre de données ou de votre environnement périphérique, vous pouvez configurer vos nœuds hybrides et votre cluster pour utiliser votre serveur proxy. Pour de plus amples informations, consultez [Configurer le proxy pour les nœuds hybrides](hybrid-nodes-proxy.md). **Topics** + [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) + [Configurer les modules complémentaires pour les nœuds hybrides](hybrid-nodes-add-ons.md) + [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md) + [Configurer le proxy pour les nœuds hybrides](hybrid-nodes-proxy.md) + [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md) + [Configurer Kubernetes Ingress pour les nœuds hybrides](hybrid-nodes-ingress.md) + [Configurer les services de type LoadBalancer pour les nœuds hybrides](hybrid-nodes-load-balancing.md) + [Configurer les politiques réseau Kubernetes pour les nœuds hybrides](hybrid-nodes-network-policies.md) # Configurer CNI pour les nœuds hybrides Cilium est l'interface réseau de conteneurs (CNI) prise en AWS charge par les nœuds hybrides Amazon EKS. Vous devez installer un CNI pour que les nœuds hybrides soient prêts à prendre en charge les charges de travail. Les nœuds hybrides apparaissent avec le statut `Not Ready` jusqu’à ce qu’un CNI soit en cours d’exécution. Vous pouvez gérer le CNI à l’aide des outils de votre choix, tels que Helm. Les instructions fournies sur cette page concernent la gestion du cycle de vie de Cilium (installation, mise à niveau, suppression). Consultez [Présentation de Cilium Ingress et Cilium Gateway](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium), [Type de service LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer), et [Configurer les politiques réseau Kubernetes pour les nœuds hybrides](hybrid-nodes-network-policies.md) pour savoir comment configurer Cilium pour l’ingress, l’équilibrage de charge et les politiques réseau. Cilium n'est pas pris en charge AWS lorsqu'il est exécuté sur des nœuds dans AWS le cloud. Le CNI VPC Amazon n’est pas compatible avec les nœuds hybrides et le CNI VPC est configuré avec une anti-affinité pour l’étiquette `eks.amazonaws.com/compute-type: hybrid`. La documentation Calico qui figurait auparavant sur cette page a été déplacée vers le [référentiel d’exemples hybrides EKS](https://github.com/aws-samples/eks-hybrid-examples). ## Compatibilité des versions Les versions Cilium `v1.17.x` et B `v1.18.x` sont prises en charge pour les nœuds hybrides EKS pour chaque version de Kubernetes prise en charge dans Amazon EKS. **Note** Configuration requise pour le **noyau Cilium v1.18.3 : En raison de l'exigence** du noyau (noyau Linux >= 5.10), Cilium v1.18.3 n'est pas pris en charge sur : + Ubuntu 20.04 + Red Hat Enterprise Linux (RHEL) 8 Pour la configuration système requise, consultez la section Configuration requise pour [Cilium.](https://docs.cilium.io/en/stable/operations/system_requirements/) Consultez la [prise en charge des versions Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) pour connaître les versions Kubernetes prises en charge par Amazon EKS. Les nœuds hybrides EKS prennent en charge la même version de Kubernetes que les clusters Amazon EKS avec nœuds cloud. ## Fonctionnalités prises en charge AWS gère des versions de Cilium pour les nœuds hybrides EKS basées sur le projet open source [Cilium](https://github.com/cilium/cilium). Pour bénéficier de l'assistance de AWS Cilium, vous devez utiliser les versions de Cilium AWS maintenues et les versions de Cilium prises en charge. AWS fournit un support technique pour les configurations par défaut des fonctionnalités suivantes de Cilium à utiliser avec les nœuds hybrides EKS. Si vous envisagez d'utiliser des fonctionnalités hors du champ d' AWS assistance, il est recommandé d'obtenir un support commercial alternatif pour Cilium ou de disposer de l'expertise interne nécessaire pour résoudre les problèmes et apporter des correctifs au projet Cilium. | Fonction Cilium | Soutenu par AWS | | --- | --- | | Conformité au réseau Kubernetes | Oui | | Connectivité au cluster principal | Oui | | Famille d'IP | IPv4 | | La gestion du cycle de vie | Helm | | Mode réseau | Encapsulation VXLAN | | Gestion des adresses IP (IPAM) | Champ d’application du cluster Cilium IPAM | | Stratégie de réseau | Stratégie réseau Kubernetes | | Protocole de passerelle frontière (BGP) | Plan de contrôle Cilium BGP | | Entrée Kubernetes | Cilium Ingress, Cilium Gateway | | Allocation d' LoadBalancer adresses IP de service | Équilibreur de charge Cilium IPAM | | Publicité d'adresse LoadBalancer IP du service | Plan de contrôle Cilium BGP | | remplacement de kube-proxy | Oui | ## Considérations relatives à Cilium + **Référentiel Helm** [: AWS héberge le graphique Cilium Helm dans le Amazon Elastic Container Registry Public (Amazon ECR Public) sur Amazon EKS Cilium/Cilium.](https://gallery.ecr.aws/eks/cilium/cilium) Les versions disponibles incluent : + Cilium v1.17.9 : `oci://public.ecr.aws/eks/cilium/cilium:1.17.9-0` + Cilium v1.18.3 : `oci://public.ecr.aws/eks/cilium/cilium:1.18.3-0` Les commandes de cette rubrique utilisent ce référentiel. Notez que certaines commandes `helm repo` ne sont pas valides pour les référentiels Helm dans Amazon ECR Public. Vous ne pouvez donc pas faire référence à ce référentiel à partir d’un nom de référentiel Helm local. Au lieu de cela, utilisez l’URI complet dans la plupart des commandes. + Par défaut, Cilium est configuré pour fonctionner en mode overlay/tunnel avec VXLAN comme [méthode d’encapsulation](https://docs.cilium.io/en/stable/network/concepts/routing/#encapsulation). Ce mode présente le moins d’exigences sur le réseau physique sous-jacent. + Par défaut, Cilium [masque](https://docs.cilium.io/en/stable/network/concepts/masquerading/) l’adresse IP source de tout le trafic du pod quittant le cluster au profit de l’adresse IP du nœud. Si vous désactivez le masquage, votre pod CIDRs doit être routable sur votre réseau local. + Si vous exécutez des webhooks sur des nœuds hybrides, votre pod CIDRs doit être routable sur votre réseau local. Si votre pod CIDRs n'est pas routable sur votre réseau local, il est recommandé d'exécuter des webhooks sur les nœuds cloud du même cluster. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md) et [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + AWS recommande d'utiliser la fonctionnalité BGP intégrée de Cilium pour rendre votre pod CIDRs routable sur votre réseau local. Pour plus d’informations sur la configuration de Cilium BGP avec des nœuds hybrides, consultez [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md). + La gestion des adresses IP (IPAM) par défaut dans Cilium s'appelle [Cluster Scope](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/), où l'opérateur Cilium alloue des adresses IP à chaque nœud en fonction du pod configuré par l'utilisateur. CIDRs ## Installer Cilium sur les nœuds hybrides ### Procédure 1. Créez un fichier YAML nommé `cilium-values.yaml`. L’exemple suivant configure Cilium pour qu’il s’exécute uniquement sur des nœuds hybrides en définissant l’affinité pour l’étiquette `eks.amazonaws.com/compute-type: hybrid` de l’agent et de l’opérateur Cilium. + Configurez `clusterPoolIpv4PodCIDRList` avec le même pod CIDRs que celui que vous avez configuré pour les *réseaux de pods distants* de votre cluster EKS. Par exemple, `10.100.0.0/24`. L’opérateur Cilium attribue des tranches d’adresses IP à partir de l’espace IP `clusterPoolIpv4PodCIDRList` configuré. Votre CIDR de pod ne doit pas chevaucher votre CIDR de nœud sur site, votre CIDR VPC ou votre CIDR de service Kubernetes. + Configurez `clusterPoolIpv4MaskSize` en fonction du nombre de pods requis par nœud. Par exemple, `25` pour une taille de segment /25 de 128 pods par nœud. + Ne modifiez pas `clusterPoolIpv4PodCIDRList` ou `clusterPoolIpv4MaskSize` après avoir déployé Cilium sur votre cluster, consultez la section [Extension du pool de clusters](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) pour plus d’informations. + Si vous exécutez Cilium en mode de remplacement de kube-proxy, définissez `kubeProxyReplacement: "true"` dans vos valeurs Helm et assurez-vous qu’aucun déploiement kube-proxy n’est en cours d’exécution sur les mêmes nœuds que Cilium. + L’exemple ci-dessous désactive le proxy Envoy Layer 7 (L7) utilisé par Cilium pour les politiques réseau L7 et l’entrée. Pour plus d’informations, consultez [Configurer les politiques réseau Kubernetes pour les nœuds hybrides](hybrid-nodes-network-policies.md) et [Présentation de Cilium Ingress et Cilium Gateway](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium). + L’exemple ci-dessous configure `loadBalancer.serviceTopology` : `true` pour que la distribution du trafic de service fonctionne correctement si vous la configurez pour vos services. Pour de plus amples informations, veuillez consulter [Configuration de la distribution du trafic de service](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution). + Pour obtenir la liste complète des valeurs Helm pour Cilium, consultez la [référence Helm](https://docs.cilium.io/en/stable/helm-reference/) dans la documentation Cilium. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ipam: mode: cluster-pool operator: clusterPoolIPv4MaskSize: 25 clusterPoolIPv4PodCIDRList: - POD_CIDR loadBalancer: serviceTopology: true operator: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid unmanagedPodWatcher: restart: false loadBalancer: serviceTopology: true envoy: enabled: false kubeProxyReplacement: "false" ``` 1. Installez Cilium sur votre cluster. + `CILIUM_VERSION`Remplacez-le par une version Cilium (par exemple `1.17.9-0` ou`1.18.3-0`). Il est recommandé d’utiliser la dernière version du correctif pour la version mineure de Cilium. + Assurez-vous que vos nœuds répondent aux exigences du noyau pour la version que vous choisissez. Cilium v1.18.3 nécessite un noyau Linux >= 5.10. + Si vous utilisez un fichier kubeconfig spécifique, utilisez le drapeau `--kubeconfig` avec la commande d’installation Helm. ``` helm install cilium oci://public.ecr.aws/eks/cilium/cilium \ --version CILIUM_VERSION \ --namespace kube-system \ --values cilium-values.yaml ``` 1. Vérifiez que l’installation de Cilium s’est bien déroulée à l’aide des commandes suivantes. Vous devriez voir le déploiement `cilium-operator` et l’exécution `cilium-agent` sur chacun de vos nœuds hybrides. De plus, vos nœuds hybrides devraient désormais avoir un statut `Ready`. Pour plus d'informations sur la façon de configurer Cilium BGP pour promouvoir votre pod sur votre réseau local, passez CIDRs à. [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md) ``` kubectl get pods -n kube-system ``` ``` NAME READY STATUS RESTARTS AGE cilium-jjjn8 1/1 Running 0 11m cilium-operator-d4f4d7fcb-sc5xn 1/1 Running 0 11m ``` ``` kubectl get nodes ``` ``` NAME STATUS ROLES AGE VERSION mi-04a2cf999b7112233 Ready 19m v1.31.0-eks-a737599 ``` ## Mettre à niveau Cilium sur les nœuds hybrides Avant de mettre à niveau votre déploiement Cilium, consultez attentivement la [documentation relative à la mise à niveau de Cilium](https://docs.cilium.io/en/v1.17/operations/upgrade/) et les notes de mise à niveau afin de comprendre les modifications apportées à la version Cilium cible. 1. Assurez-vous d’avoir installé l’interface `helm` CLI dans votre environnement de ligne de commande. Consultez la [documentation Helm](https://helm.sh/docs/intro/quickstart/) pour obtenir les instructions d’installation. 1. Exécutez le contrôle de mise à niveau de Cilium avant le vol. Remplacez `CILIUM_VERSION` par votre version cible de Cilium. Nous vous recommandons d’utiliser la dernière version du correctif pour votre version mineure de Cilium. Vous trouverez la dernière version du correctif pour une version mineure donnée de Cilium dans la [section Versions stables](https://github.com/cilium/cilium#stable-releases) de la documentation Cilium. ``` helm install cilium-preflight oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace=kube-system \ --set preflight.enabled=true \ --set agent=false \ --set operator.enabled=false ``` 1. Après avoir appliqué le `cilium-preflight.yaml`, assurez-vous que le nombre de pods `READY` correspond au nombre de pods Cilium en cours d’exécution. ``` kubectl get ds -n kube-system | sed -n '1p;/cilium/p' ``` ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE cilium 2 2 2 2 2 1h20m cilium-pre-flight-check 2 2 2 2 2 7m15s ``` 1. Une fois que le nombre de pods READY est égal, assurez-vous que le déploiement préalable de Cilium est également marqué comme READY 1/1. Si le message READY 0/1 s’affiche, consultez la section [Validation CNP](https://docs.cilium.io/en/v1.17/operations/upgrade/#cnp-validation) et résolvez les problèmes liés au déploiement avant de poursuivre la mise à niveau. ``` kubectl get deployment -n kube-system cilium-pre-flight-check -w ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE cilium-pre-flight-check 1/1 1 0 12s ``` 1. Supprimer le pré-vol ``` helm uninstall cilium-preflight --namespace kube-system ``` 1. Avant d’exécuter la commande `helm upgrade`, conservez les valeurs de votre déploiement dans un `existing-cilium-values.yaml` ou utilisez les options de ligne de commande `--set` pour vos paramètres lorsque vous exécutez la commande de mise à niveau. L'opération de mise à niveau remplace le Cilium ConfigMap. Il est donc essentiel que vos valeurs de configuration soient transmises lors de la mise à niveau. ``` helm get values cilium --namespace kube-system -o yaml > existing-cilium-values.yaml ``` 1. Pendant le fonctionnement normal du cluster, tous les composants Cilium doivent exécuter la même version. Les étapes suivantes décrivent comment mettre à niveau tous les composants d’une version stable vers une version stable ultérieure. Lors de la mise à niveau d’une version mineure vers une autre version mineure, il est recommandé de commencer par mettre à niveau vers la dernière version corrective de la version mineure existante de Cilium. Pour minimiser les perturbations, définissez l’option `upgradeCompatibility` sur la version initiale de Cilium que vous avez installée dans ce cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace kube-system \ --set upgradeCompatibility=1.X \ -f existing-cilium-values.yaml ``` 1. (Facultatif) Si vous devez annuler votre mise à niveau en raison de problèmes, exécutez les commandes suivantes. ``` helm history cilium --namespace kube-system helm rollback cilium [REVISION] --namespace kube-system ``` ## Supprimer Cilium des nœuds hybrides 1. Exécutez la commande suivante pour désinstaller tous les composants Cilium de votre cluster. Remarque : la désinstallation du CNI peut avoir un impact sur l’état des nœuds et des pods et ne doit pas être effectuée sur les clusters de production. ``` helm uninstall cilium --namespace kube-system ``` Les interfaces et les routes configurées par Cilium ne sont pas supprimées par défaut lorsque le CNI est supprimé du cluster. Consultez le [GitHub problème](https://github.com/cilium/cilium/issues/34289) pour plus d'informations. 1. Pour nettoyer les fichiers de configuration et les ressources sur disque, si vous utilisez les répertoires de configuration standard, vous pouvez supprimer les fichiers comme indiqué par le [`cni-uninstall.sh`script](https://github.com/cilium/cilium/blob/main/plugins/cilium-cni/cni-uninstall.sh) dans le référentiel Cilium sur. GitHub 1. Pour supprimer les définitions de ressources personnalisées Cilium (CRDs) de votre cluster, vous pouvez exécuter les commandes suivantes. ``` kubectl get crds -oname | grep "cilium" | xargs kubectl delete ``` # Configurer les modules complémentaires pour les nœuds hybrides Cette page décrit les considérations relatives à l'exécution de AWS modules complémentaires et de modules complémentaires communautaires sur les nœuds hybrides Amazon EKS. Pour en savoir plus sur les modules complémentaires Amazon EKS et les processus de création, de mise à niveau et de suppression de modules complémentaires de votre cluster, consultez [Modules complémentaires Amazon EKS](eks-add-ons.md). Sauf indication contraire sur cette page, les processus de création, de mise à niveau et de suppression des modules complémentaires Amazon EKS sont les mêmes pour les clusters Amazon EKS dotés de nœuds hybrides que pour les clusters Amazon EKS dotés de nœuds exécutés dans AWS le cloud. Seuls les modules complémentaires inclus dans cette page ont été validés pour leur compatibilité avec les nœuds hybrides Amazon EKS. Les AWS modules complémentaires suivants sont compatibles avec les nœuds hybrides Amazon EKS. | AWS module complémentaire | Versions complémentaires compatibles | | --- | --- | | kube-proxy | v1.25.14-eksbuild.2 et versions ultérieures | | CoreDNS | v1.9.3-eksbuild.7 et versions ultérieures | | AWS Distribution pour OpenTelemetry (ADOT) | v0.102.1-eksbuild.2 et versions ultérieures | | CloudWatch Agent d'observabilité | v2.2.1-eksbuild.1 et versions ultérieures | | Agent d'identité du pod EKS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/hybrid-nodes-add-ons.html) | | Agent de surveillance des nœuds | v1.2.0-eksbuild.1 et versions ultérieures | | Contrôleur d'instantané CSI | v8.1.0-eksbuild.1 et ultérieures | | AWS Connecteur CA privé pour Kubernetes | v1.6.0-eksbuild.1 et ultérieures | | pilote Amazon FSx CSI | v1.7.0-eksbuild.1 et versions ultérieures | | AWS Fournisseur de pilotes CSI Secrets Store | v2.1.1-eksbuild.1 et versions ultérieures | Les modules complémentaires communautaires suivants sont compatibles avec les nœuds hybrides Amazon EKS. Pour en savoir plus sur les modules complémentaires communautaires, consultez [Extensions communautaires](community-addons.md). | Module complémentaire communautaire | Versions complémentaires compatibles | | --- | --- | | Serveur de métriques Kubernetes | v0.7.2-eksbuild.1 et versions ultérieures | | cert-manager | v1.17.2-eksbuild.1 et versions ultérieures | | Exportateur de nœuds Prometheus | v1.9.1-eksbuild.2 et versions ultérieures | | kube-state-metrics | v2.15.0-eksbuild.4 et versions ultérieures | | DNS externe | v0.19.0-eksbuild.1 et versions ultérieures | Outre les modules complémentaires Amazon EKS présentés dans les tableaux ci-dessus, le [collecteur du service géré Amazon pour Prometheus](prometheus.md) et le [contrôleur d’équilibreur de charge AWS](aws-load-balancer-controller.md) pour [l’entrée d’applications](alb-ingress.md) (HTTP) et [l’équilibrage de charge](network-load-balancing.md) (TCP/UDP) sont compatibles avec les nœuds hybrides. Il existe des AWS modules complémentaires et des modules complémentaires communautaires qui ne sont pas compatibles avec les nœuds hybrides Amazon EKS. Les dernières versions de ces modules complémentaires disposent d’une règle anti-affinité pour l’étiquette `eks.amazonaws.com/compute-type: hybrid` par défaut appliquée aux nœuds hybrides. Cela les empêche de s’exécuter sur des nœuds hybrides lorsqu’ils sont déployés dans vos clusters. Si vous avez des clusters comportant à la fois des nœuds hybrides et des nœuds exécutés dans AWS le cloud, vous pouvez déployer ces modules complémentaires dans votre cluster sur des nœuds exécutés dans AWS le cloud. L'Amazon VPC CNI n'est pas compatible avec les nœuds hybrides, et Cilium et Calico sont pris en charge en tant qu'interfaces réseau de conteneurs () CNIs pour les nœuds hybrides Amazon EKS. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ## AWS modules complémentaires Les sections suivantes décrivent les différences entre l'exécution de AWS modules complémentaires compatibles sur des nœuds hybrides par rapport aux autres types de calcul Amazon EKS. ## kube-proxy et CoreDNS EKS installe kube-proxy et CoreDNS en tant que modules complémentaires autogérés par défaut lorsque vous créez un cluster EKS avec l'API AWS et, notamment, à partir de la CLI. AWS SDKs AWS Vous pouvez remplacer ces modules complémentaires par les modules complémentaires Amazon EKS après la création du cluster. Consultez la documentation EKS pour plus de détails sur [Gérer `kube-proxy` dans les Clusters Amazon EKS](managing-kube-proxy.md) et [Gérer CoreDNS pour DNS dans les clusters Amazon EKS](managing-coredns.md). Si vous utilisez un cluster en mode mixte avec à la fois des nœuds hybrides et des nœuds dans le AWS cloud, il est AWS recommandé d'avoir au moins une réplique CoreDNS sur les nœuds hybrides et au moins une réplique CoreDNS sur vos nœuds dans le cloud. AWS Consultez [Configuration des réplicas de CoreDNS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-coredns) pour les étapes de configuration. ## CloudWatch Agent d'observabilité L'opérateur de l'agent CloudWatch Observability utilise des [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Si vous exécutez l’opérateur sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides car [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) dépend de la disponibilité du service IMDS ([Instance Metadata Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)) pour les métriques au niveau des nœuds. Les métriques au niveau des clusters, des charges de travail, des pods et des conteneurs sont disponibles pour les nœuds hybrides. Après avoir installé le module complémentaire en suivant les étapes décrites dans [Installer l' CloudWatch agent avec Amazon CloudWatch Observability, le](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) manifeste du module complémentaire doit être mis à jour pour que l'agent puisse s'exécuter correctement sur des nœuds hybrides. Modifiez la ressource `amazoncloudwatchagents` sur le cluster pour ajouter la variable d’environnement `RUN_WITH_IRSA` comme indiqué ci-dessous. ``` kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent ``` ``` apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ... ``` ## Collecteur géré Amazon Managed Prometheus pour nœuds hybrides Un collecteur géré par le service géré Amazon pour Prometheus (AMP) consiste en un scraper qui détecte et collecte des métriques à partir des ressources d’un cluster Amazon EKS. AMP gère le scraper pour vous, vous évitant ainsi d’avoir à gérer vous-même les instances, les agents ou les scrapers. Vous pouvez utiliser les collecteurs gérés AMP sans aucune configuration supplémentaire spécifique aux nœuds hybrides. Cependant, les points de terminaison métriques de vos applications sur les nœuds hybrides doivent être accessibles depuis le VPC, y compris les itinéraires entre le VPC et le CIDRs réseau de pods distants et les ports ouverts dans votre pare-feu sur site. De plus, votre cluster doit disposer d’un [accès privé au point de terminaison du cluster](cluster-endpoint.md). Suivez les étapes décrites dans la section [Utilisation d'un collecteur AWS géré](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html) dans le guide de l'utilisateur d'Amazon Managed Service for Prometheus. ## AWS Distribution pour OpenTelemetry (ADOT) Vous pouvez utiliser le module complémentaire AWS Distro for OpenTelemetry (ADOT) pour collecter des métriques, des journaux et des données de suivi à partir de vos applications exécutées sur des nœuds hybrides. ADOT utilise des [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) d’admission pour modifier et valider les demandes de ressources personnalisées du collecteur. Si vous exécutez l’opérateur ADOT sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). Suivez les étapes décrites dans [Getting Started with AWS Distro pour OpenTelemetry utiliser les modules complémentaires EKS](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) dans la * AWS distribution pour OpenTelemetry* obtenir de la documentation. ## AWS Contrôleur Load Balancer Vous pouvez utiliser le [AWS Load Balancer Controller](aws-load-balancer-controller.md) et l'Application Load Balancer (ALB) ou le Network Load Balancer (NLB) avec le `ip` type de cible pour les charges de travail sur les nœuds hybrides. Les cibles IP utilisées avec l'ALB ou le NLB doivent être routables depuis. AWS[Le contrôleur AWS Load Balancer utilise également des webhooks.](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) Si vous exécutez l'opérateur AWS Load Balancer Controller sur des nœuds hybrides, le CIDR de votre pod local doit être routable sur votre réseau local et vous devez configurer votre cluster EKS avec votre réseau de pods distants. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). Pour installer le AWS Load Balancer Controller, suivez les étapes indiquées dans ou. [AWS Application Load Balancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-alb) [AWS Network Load Balancer](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-nlb) Pour l’entrée avec ALB, vous devez spécifier les annotations ci-dessous. Pour plus d’informations, consultez [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md). ``` alb.ingress.kubernetes.io/target-type: ip ``` Pour l’équilibrage de charge avec NLB, vous devez spécifier les annotations ci-dessous. Pour plus d’informations, consultez [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md). ``` service.beta.kubernetes.io/aws-load-balancer-type: "external" service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip" ``` ## Agent d'identité du pod EKS **Note** Pour déployer correctement le module complémentaire EKS Pod Identity Agent sur des nœuds hybrides exécutant Bottlerocket, assurez-vous que votre version de Bottlerocket est au moins v1.39.0. Pod Identity Agent n’est pas pris en charge sur les versions antérieures de Bottlerocket dans les environnements à nœuds hybrides. L'agent d'identité Amazon EKS Pod d'origine DaemonSet s'appuie sur la disponibilité d'EC2 IMDS sur le nœud pour obtenir les informations d'identification requises AWS . Comme l'IMDS n'est pas disponible sur les nœuds hybrides, à partir de la version 1.3.3-eksbuild.1, le module complémentaire Pod Identity Agent déploie éventuellement un module qui monte les informations d'identification requises. DaemonSet Les nœuds hybrides exécutant Bottlerocket nécessitent une méthode différente pour monter les informations d'identification, et à partir de la version 1.3.7-eksbuild.2, le module complémentaire Pod Identity Agent déploie éventuellement une méthode qui cible spécifiquement les nœuds hybrides Bottlerocket. DaemonSet Les sections suivantes décrivent le processus d'activation de l'option DaemonSets. ### Ubuntu/RHEL/AL2023 1. Pour utiliser l'agent Pod Identity sur Ubuntu/RHEL/Al 2023 nœuds hybrides, `enableCredentialsFile: true` configurez-le dans la section hybride de la `nodeadm` configuration comme indiqué ci-dessous : ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: hybrid: enableCredentialsFile: true # <-- Add this ``` Cela permettra à `nodeadm` de créer un fichier d’informations d’identification à configurer sur le nœud sous `/eks-hybrid/.aws/credentials`, qui sera utilisé par les pods `eks-pod-identity-agent`. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement. 1. Après avoir mis à jour la configuration `nodeadm` sur *chaque* nœud, exécutez la commande `nodeadm init` suivante avec votre `nodeConfig.yaml` pour joindre vos nœuds hybrides à votre cluster Amazon EKS. Si vos nœuds ont déjà rejoint le cluster, exécutez à nouveau la commande `nodeadm init`. ``` nodeadm init -c file://nodeConfig.yaml ``` 1. Installation `eks-pod-identity-agent` avec prise en charge des nœuds hybrides activée, à l'aide de la AWS CLI ou AWS Management Console. 1. AWS CLI : depuis la machine que vous utilisez pour administrer le cluster, exécutez la commande suivante pour effectuer l'installation en `eks-pod-identity-agent` activant la prise en charge des nœuds hybrides. Remplacez `my-cluster` par le nom de votre cluster. ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid":{"create": true}}}' ``` 1. AWS Management Console: Si vous installez le module complémentaire Pod Identity Agent via la AWS console, ajoutez ce qui suit à la configuration facultative pour déployer DaemonSet celui qui cible les nœuds hybrides. ``` {"daemonsets":{"hybrid":{"create": true}}} ``` ### Flacon Rocket 1. Pour utiliser l’agent Pod Identity sur les nœuds hybrides Bottlerocket, ajoutez l’indicateur `--enable-credentials-file=true` à la commande utilisée pour les données utilisateur du conteneur de démarrage Bottlerocket, comme décrit dans [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md). 1. Si vous utilisez le fournisseur d’informations d’identification SSM, votre commande devrait ressembler à ceci : ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= --enable-credentials-file=true ``` 1. Si vous utilisez le fournisseur d’informations d’identification Rôles Anywhere IAM, votre commande devrait ressembler à ceci : ``` eks-hybrid-iam-ra-setup --certificate= --key= --enable-credentials-file=true ``` Cela configurera le script bootstrap pour créer un fichier d’informations d’identification sur le nœud sous `/var/eks-hybrid/.aws/credentials`, qui sera utilisé par les pods `eks-pod-identity-agent`. Ce fichier d'informations d'identification contiendra des AWS informations d'identification temporaires qui seront actualisées périodiquement. 1. Installation `eks-pod-identity-agent` avec prise en charge des nœuds hybrides Bottlerocket activée, à l'aide de la CLI AWS ou. AWS Management Console 1. AWS CLI : depuis la machine que vous utilisez pour administrer le cluster, exécutez la commande suivante pour effectuer l'installation en activant la prise en charge `eks-pod-identity-agent` des nœuds hybrides Bottlerocket. Remplacez `my-cluster` par le nom de votre cluster. ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid-bottlerocket":{"create": true}}}' ``` 1. AWS Management Console: Si vous installez le module complémentaire Pod Identity Agent via la AWS console, ajoutez ce qui suit à la configuration facultative pour déployer le module DaemonSet qui cible les nœuds hybrides Bottlerocket. ``` {"daemonsets":{"hybrid-bottlerocket":{"create": true}}} ``` ## Contrôleur d'instantané CSI À partir de la version`v8.1.0-eksbuild.2`, le [module complémentaire CSI Snapshot Controller](csi-snapshot-controller.md) applique une règle d'anti-affinité souple pour les nœuds hybrides, préférant que le contrôleur `deployment` s'exécute sur EC2 dans la même région AWS que le plan de contrôle Amazon EKS. La colocation `deployment` dans la même AWS région que le plan de contrôle Amazon EKS améliore la latence. ## Modules complémentaires communautaires Les sections suivantes décrivent les différences entre l’exécution d’extensions communautaires compatibles sur des nœuds hybrides et d’autres types de calcul Amazon EKS. ## Serveur de métriques Kubernetes Le plan de contrôle doit atteindre l’adresse IP du pod du serveur de métriques (ou l’adresse IP du nœud si hostNetwork est activé). Par conséquent, à moins que vous n’exécutiez Metrics Server en mode hostNetwork, vous devez configurer un réseau de pods distant lors de la création de votre cluster Amazon EKS, et vous devez rendre vos adresses IP de pods routables. La mise en œuvre du protocole de passerelle frontière (BGP) avec le CNI est une méthode courante pour rendre les adresses IP de vos pods routables. ## cert-manager `cert-manager` utilise des [webhooks.](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) Si vous utilisez `cert-manager` sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site et vous devez configurer votre cluster EKS avec votre réseau de pods distant. Pour plus d’informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). # Configurer les webhooks pour les nœuds hybrides Cette page détaille les considérations relatives à l’exécution de webhooks avec des nœuds hybrides. Les webhooks sont utilisés dans les applications Kubernetes et les projets open source, tels que l’AWS Load Balancer Controller et l’agent d’observabilité CloudWatch, pour exécuter des fonctions de mutation et de validation lors de l’exécution. **Réseaux de pods routables** Si vous pouvez rendre votre pod CIDR sur site routable sur votre réseau sur site, vous pouvez exécuter des webhooks sur des nœuds hybrides. Il existe plusieurs techniques que vous pouvez utiliser pour rendre votre pod CIDR sur site routable sur votre réseau sur site, notamment le protocole de passerelle frontière (BGP), les routes statiques ou d’autres solutions de routage personnalisées. BGP est la solution recommandée, car elle est plus évolutive et plus facile à gérer que les autres solutions qui nécessitent une configuration personnalisée ou manuelle des routes. AWS prend en charge les capacités BGP de Cilium et Calico pour la publicité des CIDR de pod. Pour plus d’informations, consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md) et [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs). **Réseaux de pods non routables** Si vous *ne pouvez pas* rendre votre pod CIDR sur site routable sur votre réseau sur site et que vous devez exécuter des webhooks, nous vous recommandons d’exécuter tous les webhooks sur des nœuds cloud dans le même cluster EKS que vos nœuds hybrides. ## Considérations relatives aux clusters en mode mixte Les *clusters en mode mixte* sont définis comme des clusters EKS qui comportent à la fois des nœuds hybrides et des nœuds fonctionnant dans le cloud AWS. Lorsque vous exécutez un cluster en mode mixte, tenez compte des recommandations suivantes : + Exécutez le VPC CNI sur des nœuds dans le cloud AWS et Cilium ou Calico sur des nœuds hybrides. Cilium et Calico ne sont pas pris en charge par AWS lorsqu’ils sont exécutés sur des nœuds dans le Cloud AWS. + Configurez les webhooks pour qu’ils s’exécutent sur des nœuds dans le cloud AWS. Consultez [Configuration des webhooks pour les modules complémentaires](#hybrid-nodes-webhooks-add-ons) pour découvrir comment configurer les webhooks avec AWS et les modules complémentaires communautaires. + Si vos applications nécessitent que les pods exécutés sur des nœuds dans le cloud AWS communiquent directement avec les pods exécutés sur des nœuds hybrides (« communication est-ouest ») et que vous utilisez le VPC CNI sur les nœuds dans le cloud AWS, et Cilium ou Calico sur les nœuds hybrides, alors votre CIDR de pod sur site doit être routable sur votre réseau sur site. + Exécutez au moins un réplica de CoreDNS sur les nœuds dans le cloud AWS et au moins un réplica de CoreDNS sur les nœuds hybrides. + Configurez la distribution du trafic de service afin que celui-ci reste localisé dans la zone d’où il provient. Pour plus d’informations sur la distribution du trafic de service, voir [Configuration de la distribution du trafic de service](#hybrid-nodes-mixed-service-traffic-distribution). + Si vous utilisez des Application Load Balancers (ALB) ou des Network Load Balancers (NLB) AWS pour le trafic de charge de travail s’exécutant sur des nœuds hybrides, les cibles IP utilisées avec l’ALB ou le NLB doivent être routables à partir d’AWS. + Le module complémentaire Metrics Server nécessite une connectivité entre le plan de contrôle EKS et l’adresse IP du pod Metrics Server. Si vous exécutez le module complémentaire Metrics Server sur des nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site. + Pour collecter des métriques pour les nœuds hybrides à l’aide des collecteurs gérés par le service géré Amazon pour Prometheus (AMP), votre CIDR de pod sur site doit être routable sur votre réseau sur site. Vous pouvez également utiliser le collecteur géré AMP pour les métriques et les ressources du plan de contrôle EKS s’exécutant dans le cloud AWS, ainsi que le module complémentaire AWS Distro for OpenTelemetry (ADOT) pour collecter les métriques des nœuds hybrides. ## Configuration de clusters en mode mixte Pour afficher les webhooks de mutation et de validation exécutés sur votre cluster, vous pouvez consulter le type de ressource **Extensions** dans le panneau **Ressources** de la console EKS de votre cluster, ou utiliser les commandes suivantes. EKS rapporte également les métriques webhook dans le tableau de bord d’observabilité du cluster. Pour plus d’informations, consultez [Surveillez votre cluster à l’aide du tableau de bord d’observabilité](observability-dashboard.md). ``` kubectl get mutatingwebhookconfigurations ``` ``` kubectl get validatingwebhookconfigurations ``` ### Configuration de la distribution du trafic de service Lorsque vous utilisez des clusters en mode mixte, nous vous recommandons d’utiliser la [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) afin de maintenir le trafic de service local dans la zone d’où il provient. La distribution du trafic des services (disponible pour les versions 1.31 et ultérieures de Kubernetes dans EKS) est la solution recommandée par rapport au [routage topologique](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), car elle est plus prévisible. Avec la distribution du trafic de service, les terminaux sains de la zone recevront tout le trafic destiné à cette zone. Avec le routage topologique, chaque service doit remplir plusieurs conditions dans cette zone pour appliquer le routage personnalisé, sinon il achemine le trafic de manière uniforme vers tous les points de terminaison. Si vous utilisez Cilium comme CNI, vous devez exécuter le CNI avec le paramètre `enable-service-topology` défini sur `true` pour activer la distribution du trafic de service. Vous pouvez transmettre cette configuration avec l’indicateur d’installation Helm `--set loadBalancer.serviceTopology=true` ou mettre à jour une installation existante à l’aide de la commande CLI Cilium `cilium config set enable-service-topology true`. L’agent Cilium exécuté sur chaque nœud doit être redémarré après la mise à jour de la configuration d’une installation existante. La section suivante présente un exemple de configuration de la distribution du trafic de service pour le service CoreDNS. Nous vous recommandons d’activer cette option pour tous les services de votre cluster afin d’éviter tout trafic inter-environnements indésirable. ### Configuration des réplicas de CoreDNS Si vous utilisez un cluster en mode mixte avec à la fois des nœuds hybrides et des nœuds dans le cloud AWS, nous vous recommandons d’avoir au moins un réplica CoreDNS sur les nœuds hybrides et au moins un réplica CoreDNS sur vos nœuds dans le cloud AWS. Pour éviter les problèmes de latence et de réseau dans une configuration de cluster en mode mixte, vous pouvez configurer le service CoreDNS pour qu’il privilégie le réplica CoreDNS le plus proche avec la [distribution du trafic de service](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution). La *distribution du trafic de service* (disponible pour les versions 1.31 et ultérieures de Kubernetes dans EKS) est la solution recommandée par rapport au [routage topologique](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), car elle est plus prévisible. Dans la distribution du trafic en service, les points de terminaison sains de la zone recevront tout le trafic destiné à cette zone. Dans le routage sensible à la topologie, chaque service doit remplir plusieurs conditions dans cette zone pour appliquer le routage personnalisé, sinon il achemine le trafic de manière uniforme vers tous les points de terminaison. Les étapes suivantes permettent de configurer la distribution du trafic de service. Si vous utilisez Cilium comme CNI, vous devez exécuter le CNI avec le paramètre `enable-service-topology` défini sur `true` pour activer la distribution du trafic de service. Vous pouvez transmettre cette configuration avec l’indicateur d’installation Helm `--set loadBalancer.serviceTopology=true` ou mettre à jour une installation existante à l’aide de la commande CLI Cilium `cilium config set enable-service-topology true`. L’agent Cilium exécuté sur chaque nœud doit être redémarré après la mise à jour de la configuration d’une installation existante. 1. Ajoutez une étiquette de zone topologique pour chacun de vos nœuds hybrides, par exemple `topology.kubernetes.io/zone: onprem`. Vous pouvez également définir l’étiquette au niveau de la phase `nodeadm init` en spécifiant l’étiquette dans votre configuration `nodeadm`, voir [Configuration du nœud pour personnaliser kubelet (facultatif)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet). Remarque : Les nœuds exécutés dans le cloud AWS se voient automatiquement attribuer une étiquette de zone topologique correspondant à la zone de disponibilité (AZ) du nœud. ``` kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone ``` 1. Ajoutez `podAntiAffinity` au déploiement CoreDNS avec la clé de zone de topologie. Vous pouvez également configurer le déploiement de CoreDNS lors de l’installation à l’aide des modules complémentaires EKS. ``` kubectl edit deployment coredns -n kube-system ``` ``` spec: template: spec: affinity: ... podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname weight: 100 - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: topology.kubernetes.io/zone weight: 50 ... ``` 1. Ajoutez le paramètre `trafficDistribution: PreferClose` à la configuration du service `kube-dns` pour activer la distribution du trafic du service. ``` kubectl patch svc kube-dns -n kube-system --type=merge -p '{ "spec": { "trafficDistribution": "PreferClose" } }' ``` 1. Vous pouvez confirmer que la distribution du trafic de service est activée en consultant les tranches de point de terminaison du service `kube-dns`. Vos tranches de point de terminaison doivent afficher les étiquettes `hints` de votre zone topologique, ce qui confirme que la distribution du trafic de service est activée. Si vous ne voyez pas l’adresse de chaque point de terminaison `hints`, cela signifie que la distribution du trafic de service n’est pas activée. ``` kubectl get endpointslice -A | grep "kube-dns" ``` ``` kubectl get endpointslice [.replaceable]`kube-dns-` -n kube-system -o yaml ``` ``` addressType: IPv4 apiVersion: discovery.k8s.io/v1 endpoints: - addresses: - hints: forZones: - name: onprem nodeName: zone: onprem - addresses: - hints: forZones: - name: us-west-2a nodeName: zone: us-west-2a ``` ### Configuration des webhooks pour les modules complémentaires Les modules complémentaires suivants utilisent des webhooks et sont compatibles avec les nœuds hybrides. + Contrôleur de l'équilibreur de charge AWS + Agent d’observabilité CloudWatch + AWS Distro for OpenTelemetry (ADOT) + `cert-manager` Consultez les sections suivantes pour configurer les webhooks utilisés par ces modules complémentaires afin qu’ils s’exécutent sur les nœuds dans Cloud AWS. #### Contrôleur de l'équilibreur de charge AWS Pour utiliser l’AWS Load Balancer Controller dans une configuration de cluster en mode mixte, vous devez exécuter le contrôleur sur les nœuds dans le Cloud AWS. Pour ce faire, ajoutez les éléments suivants à votre configuration des valeurs Helm ou spécifiez les valeurs à l’aide de la configuration du module complémentaire EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### Agent d’observabilité CloudWatch Le module complémentaire Agent d’observabilité CloudWatch dispose d’un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l’opérateur sur des nœuds du AWS cloud dans une configuration de cluster en mode mixte, modifiez la configuration de l’opérateur Agent d’observabilité CloudWatch. Vous ne pouvez pas configurer l’affinité des opérateurs lors de l’installation avec les modules complémentaires Helm et EKS (voir le [problème \$12431 de containers-roadmap](https://github.com/aws/containers-roadmap/issues/2431)). ``` kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager ``` ``` spec: ... template: ... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### AWS Distro for OpenTelemetry (ADOT) Le module complémentaire AWS Distro pour OpenTelemetry (ADOT) dispose d’un opérateur Kubernetes qui utilise des webhooks. Pour exécuter l’opérateur sur les nœuds dans le cloud AWS dans une configuration de cluster en mode mixte, ajoutez les éléments suivants à votre configuration de valeurs Helm ou spécifiez les valeurs à l’aide de la configuration du module complémentaire EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` Si votre CIDR de pod n’est pas routable sur votre réseau sur site, le collecteur ADOT doit alors s’exécuter sur des nœuds hybrides afin de récupérer les métriques de vos nœuds hybrides et des charges de travail qui s’y exécutent. Pour ce faire, modifiez la définition de ressource personnalisée (CRD). ``` kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics ``` ``` spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` Vous pouvez configurer le collecteur ADOT pour qu’il ne récupère que les métriques des nœuds hybrides et des ressources s’exécutant sur des nœuds hybrides en ajoutant les éléments `relabel_configs` suivants à chaque `scrape_configs` dans la configuration CRD du collecteur ADOT. ``` relabel_configs: - action: keep regex: hybrid source_labels: - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type ``` Le module complémentaire ADOT doit installer `cert-manager` pour pouvoir utiliser les certificats TLS utilisés par le webhook de l’opérateur ADOT. `cert-manager` exécute également des webhooks et vous pouvez le configurer pour qu’il s’exécute sur des nœuds dans le cloud AWS à l’aide de la configuration Helm suivante. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### `cert-manager` Le module complémentaire exécute des webhooks `cert-manager` et vous pouvez le configurer pour qu’il s’exécute sur des nœuds dans le cloud AWS à l’aide de la configuration Helm suivante. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` # Configurer le proxy pour les nœuds hybrides Si vous utilisez un serveur proxy dans votre environnement sur site pour le trafic sortant de votre centre de données ou de votre environnement périphérique, vous devez configurer séparément vos nœuds et votre cluster pour utiliser votre serveur proxy. Cluster Sur votre cluster, vous devez configurer `kube-proxy` pour utiliser votre serveur proxy. Vous devez effectuer la configuration de `kube-proxy` après avoir créé votre cluster Amazon EKS. Nœuds Sur vos nœuds, vous devez configurer le système d’exploitation, `containerd`, `kubelet`, et l’agent Amazon SSM pour utiliser votre serveur proxy. Vous pouvez effectuer ces modifications pendant le processus de création des images de votre système d’exploitation ou avant d’exécuter `nodeadm init` sur chaque nœud hybride. ## Configuration au niveau du nœud Vous devez appliquer les configurations suivantes soit dans vos images de système d’exploitation, soit avant l’exécution de `nodeadm init` sur chaque nœud hybride. ### Configuration du proxy `containerd` `containerd` est l’environnement d’exécution de gestion de conteneurs par défaut pour Kubernetes. Si vous utilisez un proxy pour accéder à Internet, vous devez configurer `containerd` afin qu’il puisse extraire les images de conteneur requises par Kubernetes et Amazon EKS. Créez un fichier sur chaque nœud hybride appelé `http-proxy.conf` dans le répertoire `/etc/systemd/system/containerd.service.d` avec le contenu suivant. Remplacez `proxy-domain` et `port` par les valeurs correspondant à votre environnement. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### `containerd` configuration à partir des données utilisateur Le répertoire `containerd.service.d` devra être créé pour ce fichier. Vous devrez recharger systemd pour récupérer le fichier de configuration sans redémarrer. Dans AL2023, le service sera probablement déjà en cours d’exécution lorsque votre script s’exécutera, vous devrez donc également le redémarrer. ``` mkdir -p /etc/systemd/system/containerd.service.d echo '[Service]' > /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf systemctl daemon-reload systemctl restart containerd ``` ### Configuration du proxy `kubelet` `kubelet` est l’agent de nœud Kubernetes qui s’exécute sur chaque nœud Kubernetes et qui est chargé de gérer le nœud et les pods qui s’y exécutent. Si vous utilisez un proxy dans votre environnement sur site, vous devez configurer le `kubelet` afin qu’il puisse communiquer avec les points de terminaison publics ou privés de votre cluster Amazon EKS. Créez un fichier sur chaque nœud hybride appelé `http-proxy.conf` dans le répertoire `/etc/systemd/system/kubelet.service.d/` avec le contenu suivant. Remplacez `proxy-domain` et `port` par les valeurs correspondant à votre environnement. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### Configuration `kubelet` à partir des données utilisateur Le répertoire `kubelet.service.d` doit être créé pour ce fichier. Vous devrez recharger systemd pour récupérer le fichier de configuration sans redémarrer. Dans AL2023, le service sera probablement déjà en cours d’exécution lorsque votre script s’exécutera, vous devrez donc également le redémarrer. ``` mkdir -p /etc/systemd/system/kubelet.service.d echo '[Service]' > /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf systemctl daemon-reload systemctl restart kubelet ``` ### Configuration du proxy `ssm` `ssm` est l’un des fournisseurs d’informations d’identification pouvant être utilisés pour initialiser un nœud hybride. `ssm` est chargé de l’authentification avec AWS et de la génération d’informations d’identification temporaires utilisées par `kubelet`. Si vous utilisez un proxy dans votre environnement sur site et que vous utilisez `ssm` comme fournisseur d’informations d’identification sur le nœud, vous devez le configurer le `ssm` afin qu’il puisse communiquer avec les points de terminaison du service Amazon SSM. Créez un fichier sur chaque nœud hybride appelé `http-proxy.conf` dans le chemin ci-dessous en fonction du système d’exploitation + Ubuntu – `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d/http-proxy.conf` + Amazon Linux 2023 et Red Hat Enterprise Linux – `/etc/systemd/system/amazon-ssm-agent.service.d/http-proxy.conf` Remplissez le fichier avec le contenu suivant. Remplacez `proxy-domain` et `port` par les valeurs correspondant à votre environnement. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### Configuration à partir des données utilisateur `ssm` Le répertoire des fichiers de service systemd `ssm` doit être créé pour ce fichier. Le chemin d’accès au répertoire dépend du système d’exploitation utilisé sur le nœud. + Ubuntu – `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d` + Amazon Linux 2023 et Red Hat Enterprise Linux – `/etc/systemd/system/amazon-ssm-agent.service.d` Remplacer le nom du service systemd dans la commande de redémarrage ci-dessous en fonction du système d’exploitation utilisé sur le nœud + Ubuntu – `snap.amazon-ssm-agent.amazon-ssm-agent` + Amazon Linux 2023 et Red Hat Enterprise Linux – `amazon-ssm-agent` ``` mkdir -p systemd-service-file-directory echo '[Service]' > [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTP_PROXY=http://[.replaceable]#proxy-domain:port"' >> systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://[.replaceable]#proxy-domain:port"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf systemctl daemon-reload systemctl restart [.replaceable]#systemd-service-name ``` ### Configuration du proxy du système d’exploitation Si vous utilisez un proxy pour accéder à Internet, vous devez configurer votre système d’exploitation afin de pouvoir extraire les dépendances des nœuds hybrides à partir du gestionnaire de paquets de votre système d’exploitation. **Ubuntu** 1. Configurez `snap` pour utiliser votre proxy à l’aide des commandes suivantes : ``` sudo snap set system proxy.https=http://proxy-domain:port sudo snap set system proxy.http=http://proxy-domain:port ``` 1. Pour activer le proxy pour `apt`, créez un fichier nommé `apt.conf` dans le répertoire `/etc/apt/`. Remplacez proxy-domain et port par les valeurs correspondant à votre environnement. ``` Acquire::http::Proxy "http://proxy-domain:port"; Acquire::https::Proxy "http://proxy-domain:port"; ``` **Amazon Linux 2023** 1. Configurez `dnf` pour utiliser votre proxy. Créez un fichier `/etc/dnf/dnf.conf` contenant le domaine proxy et les valeurs de port de votre environnement. ``` proxy=http://proxy-domain:port ``` **Utilisation de Red Hat Enterprise Linux** 1. Configurez `yum` pour utiliser votre proxy. Créez un fichier `/etc/yum.conf` contenant le domaine proxy et les valeurs de port de votre environnement. ``` proxy=http://proxy-domain:port ``` ### Configuration du proxy de Rôles Anywhere IAM Le service de fournisseur d’informations d’identification Rôles Anywhere IAM est chargé d’actualiser les informations d’identification lors de l’utilisation de Rôles Anywhere IAM avec l’indicateur `enableCredentialsFile` (voir [Agent d'identité du pod EKS](hybrid-nodes-add-ons.md#hybrid-nodes-add-ons-pod-id)). Si vous utilisez un proxy dans votre environnement sur site, vous devez configurer le service afin qu’il puisse communiquer avec les points de terminaison Rôles Anywhere IAM. Créez un fichier nommé `http-proxy.conf` dans le répertoire `/etc/systemd/system/aws_signing_helper_update.service.d/` avec le contenu suivant. Remplacez `proxy-domain` et `port` par les valeurs correspondant à votre environnement. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` ## Configuration à l’échelle du cluster Les configurations de cette section doivent être appliquées après avoir créé votre cluster Amazon EKS et avant d’exécuter `nodeadm init` sur chaque nœud hybride. ### Configuration du proxy kube-proxy Amazon EKS installe automatiquement `kube-proxy` sur chaque nœud hybride en tant que DaemonSet lorsque vos nœuds hybrides rejoignent le cluster. `kube-proxy` permet le routage entre les services pris en charge par les pods sur les clusters Amazon EKS. Pour configurer chaque hôte, `kube-proxy` demande une résolution DNS pour le point de terminaison de votre cluster Amazon EKS. 1. Modifiez le DaemonSet `kube-proxy` à l’aide de la commande suivante ``` kubectl -n kube-system edit ds kube-proxy ``` Cela ouvrira la définition du DaemonSet `kube-proxy` dans l’éditeur que vous avez configuré. 1. Ajoutez les variables d’environnement pour `HTTP_PROXY` et `HTTPS_PROXY`. Notez que la variable d’environnement `NODE_NAME` doit déjà exister dans votre configuration. Remplacez `proxy-domain` et `port` par les valeurs correspondant à votre environnement. ``` containers: - command: - kube-proxy - --v=2 - --config=/var/lib/kube-proxy-config/config - --hostname-override=$(NODE_NAME) env: - name: HTTP_PROXY value: http://proxy-domain:port - name: HTTPS_PROXY value: http://proxy-domain:port - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName ``` # Configurer Cilium BGP pour les nœuds hybrides Cette rubrique décrit comment configurer le protocole de passerelle frontière (BGP) de Cilium pour les nœuds hybrides Amazon EKS. La fonctionnalité BGP de Cilium s’appelle le [plan de contrôle Cilium BGP](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane/) et peut être utilisée pour diffuser les adresses des pods et des services vers votre réseau sur site. Pour connaître les autres méthodes permettant de rendre les CIDR pod routables sur votre réseau local, consultez [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs). ## Configurer Cilium BGP ### Prérequis + Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ### Procédure 1. Pour utiliser BGP avec Cilium afin de publier les adresses des pods ou des services sur votre réseau local, Cilium doit être installé avec `bgpControlPlane.enabled: true`. Si vous activez BGP pour un déploiement Cilium existant, vous devez redémarrer l’opérateur Cilium pour appliquer la configuration BGP si BGP n’était pas activé auparavant. Vous pouvez définir `operator.rollOutPods` sur `true` dans vos valeurs Helm pour redémarrer l’opérateur Cilium dans le cadre du processus d’installation/mise à niveau Helm. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --set bgpControlPlane.enabled=true ``` 1. Vérifiez que l’opérateur Cilium et les agents ont été redémarrés et fonctionnent correctement. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` 1. Créez un fichier nommé `cilium-bgp-cluster.yaml` avec une définition `CiliumBGPClusterConfig`. Vous devrez peut-être obtenir les informations suivantes auprès de votre administrateur réseau. + Configurez `localASN` avec l’ASN pour les nœuds exécutant Cilium. + Configurez `peerASN` avec l’ASN pour votre routeur local. + Configurez le `peerAddress` du routeur local avec lequel chaque nœud exécutant Cilium sera appairé. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPClusterConfig metadata: name: cilium-bgp spec: nodeSelector: matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid bgpInstances: - name: "rack0" localASN: NODES_ASN peers: - name: "onprem-router" peerASN: ONPREM_ROUTER_ASN peerAddress: ONPREM_ROUTER_IP peerConfigRef: name: "cilium-peer" ``` 1. Appliquer la configuration du cluster Cilium BGP à votre cluster. ``` kubectl apply -f cilium-bgp-cluster.yaml ``` 1. Créez un fichier nommé `cilium-bgp-peer.yaml` d’après la ressource `CiliumBGPPeerConfig` qui définit une configuration de pair BGP. Plusieurs pairs peuvent partager la même configuration et fournir une référence à la ressource `CiliumBGPPeerConfig` commune. Consultez la [configuration BGP Peer](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-v2/#bgp-peer-configuration) dans la documentation Cilium pour obtenir la liste complète des options de configuration. Les valeurs des paramètres Cilium peer suivants doivent correspondre à celles du routeur local avec lequel vous établissez une connexion peer-to-peer. + Configurez `holdTimeSeconds`, qui détermine la durée pendant laquelle un pair BGP attend un message de maintien ou de mise à jour avant de déclarer la session comme interrompue. La durée par défaut est de 90 secondes. + Configurez `keepAliveTimeSeconds`, ce qui détermine si un pair BGP est toujours accessible et si la session BGP est active. Le durée par défaut est 30 secondes. + Configurez `restartTimeSeconds`, le délai pendant lequel le plan de contrôle BGP de Cilium doit rétablir la session BGP après un redémarrage. La durée par défaut est de 120 secondes. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPPeerConfig metadata: name: cilium-peer spec: timers: holdTimeSeconds: 90 keepAliveTimeSeconds: 30 gracefulRestart: enabled: true restartTimeSeconds: 120 families: - afi: ipv4 safi: unicast advertisements: matchLabels: advertise: "bgp" ``` 1. Appliquez la configuration de pair Cilium BGP à votre cluster. ``` kubectl apply -f cilium-bgp-peer.yaml ``` 1. Créez un fichier nommé `cilium-bgp-advertisement-pods.yaml` avec une ressource `CiliumBGPAdvertisement` pour annoncer les CIDR du pod à votre réseau sur site. + Cette ressource `CiliumBGPAdvertisement` sert à définir les types de publicités et les attributs qui leur sont associés. L’exemple ci-dessous configure Cilium pour qu’il n’annonce que les CIDR des pods. Consultez les exemples dans [Type de service LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer) et [Équilibrage de charge dans le cluster Cilium](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-cilium) pour plus d’informations sur la configuration de Cilium afin d’annoncer les adresses de service. + Chaque nœud hybride exécutant l’agent Cilium est apparié avec le routeur en amont compatible BGP. Chaque nœud annonce la plage CIDR du pod dont il est propriétaire lorsque le `advertisementType` de Cilium est configuré sur `PodCIDR` comme dans l’exemple ci-dessous. Pour plus d’informations, consultez la [configuration des annonces BGP](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane-v2/#bgp-advertisements) dans la documentation Cilium. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-pods labels: advertise: bgp spec: advertisements: - advertisementType: "PodCIDR" ``` 1. Appliquez la configuration Cilium BGP Advertisement à votre cluster. ``` kubectl apply -f cilium-bgp-advertisement-pods.yaml ``` 1. Vous pouvez vérifier que le peering BGP fonctionne avec l’interface [CLI Cilium](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) à l’aide de la commande `cilium bgp peers`. Vous devriez voir les valeurs correctes dans la sortie pour votre environnement et l’état de session cen tant que `established`. Pour plus d’informations sur le dépannage, consultez le [guide de dépannage et d’utilisation](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane/#troubleshooting-and-operation-guide) dans la documentation Cilium. Dans les exemples ci-dessous, cinq nœuds hybrides exécutent l’agent Cilium et chaque nœud annonce la plage CIDR Pod qu’il possède. ``` cilium bgp peers ``` ``` Node Local AS Peer AS Peer Address Session State Uptime Family Received Advertised mi-026d6a261e355fba7 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 mi-082f73826a163626e NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-09183e8a3d755abf6 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m47s ipv4/unicast 1 2 mi-0d78d815980ed202d NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-0daa253999fe92daa NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 ``` ``` cilium bgp routes ``` ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN 10.86.2.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN 10.86.2.192/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN 10.86.2.64/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN 10.86.2.128/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN 10.86.3.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] ``` # Configurer Kubernetes Ingress pour les nœuds hybrides Cette rubrique décrit comment configurer Kubernetes Ingress pour les charges de travail exécutées sur des nœuds hybrides Amazon EKS. [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) expose les routes HTTP et HTTPS depuis l’extérieur du cluster vers les services au sein du cluster. Pour utiliser les ressources Ingress, un contrôleur Kubernetes Ingress est nécessaire pour configurer l’infrastructure réseau et les composants qui gèrent le trafic réseau. AWS prend en charge AWS Application Load Balancer (ALB) et Cilium pour Kubernetes Ingress pour les charges de travail exécutées sur des nœuds hybrides EKS. La décision d’utiliser ALB ou Cilium pour Ingress dépend de la source du trafic applicatif. Si le trafic applicatif provient d’une région AWS, AWS recommande d’utiliser AWS ALB et l’AWS Load Balancer Controller. Si le trafic applicatif provient de l’environnement local sur site ou périphérique, AWS recommande d’utiliser les fonctionnalités Ingress intégrées à Cilium, qui peuvent être utilisées avec ou sans infrastructure d’équilibrage de charge dans votre environnement. ![\[Nœuds hybrides EKS Ingress\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-ingress.png) ## AWS Application Load Balancer Vous pouvez utiliser l’[AWS Load Balancer Controller](aws-load-balancer-controller.md) et l’Application Load Balancer (ALB) avec le type de cible `ip` pour les charges de travail s’exécutant sur des nœuds hybrides. Lorsque vous utilisez le type de cible `ip`, ALB transfère le trafic directement vers les pods, en contournant le chemin réseau de la couche Service. Pour qu’ALB atteigne les cibles IP des pods sur les nœuds hybrides, votre CIDR de pod sur site doit être routable sur votre réseau sur site. De plus, l’AWS Load Balancer Controller utilise des webhooks et nécessite une communication directe depuis le plan de contrôle EKS. Pour de plus amples informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). ### Considérations + Voir [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) et [Installez le contrôleur AWS Load Balancer avec Helm](lbc-helm.md) pour plus d’informations sur AWS Application Load Balancer et AWS Load Balancer Controller. + Consultez la section [Meilleures pratiques pour l’équilibrage de charge](https://docs.aws.amazon.com/eks/latest/best-practices/load-balacing.html) pour savoir comment choisir entre AWSApplication Load Balancer et AWS Network Load Balancer. + Consultez les annotations sur l’[AWS Load Balancer Controller Ingress](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) pour obtenir la liste des annotations pouvant être configurées pour les ressources d’entrée avec AWS Application Load Balancer. ### Prérequis + Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). + Le plan de contrôle Cilium BGP a été activé en suivant les instructions fournies dans [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md). Si vous ne souhaitez pas utiliser BGP, vous devez utiliser une autre méthode pour rendre vos CIDR de pods sur site routables sur votre réseau sur site. Si vous ne rendez pas vos CIDR de pods sur site routables, ALB ne pourra pas enregistrer ni contacter vos cibles IP de pods. + Helm installé dans votre environnement de ligne de commande, consultez les instructions de configuration de Helm pour plus d’informations.[Déployez des applications avec Helm sur Amazon EKS](helm.md) + eksctl installé dans votre environnement de ligne de commande, consultez les [instructions d’installation d’eksctl](install-kubectl.md#eksctl-install-update) pour plus d’informations. ### Procédure 1. Téléchargez une politique IAM pour le contrôleur de l'équilibreur de charge AWS qui lui permet d'effectuer des appels aux API AWS en votre nom. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. Créez une politique IAM à l'aide de la politique téléchargée à l'étape précédente. ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. Remplacez la valeur du nom du cluster (`CLUSTER_NAME`), de AWS la région (`AWS_REGION`) et de l’ID de AWS compte (`AWS_ACCOUNT_ID`) par vos paramètres et exécutez la commande suivante. ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. Ajoutez le référentiel des Charts de Helm eks-charts et mettez à jour votre référentiel Helm local pour vous assurer que vous disposez des graphiques les plus récents. ``` helm repo add eks https://aws.github.io/eks-charts ``` ``` helm repo update eks ``` 1. Installez le contrôleur de l'équilibreur de charge AWS. Remplacez les valeurs correspondant au nom du cluster (`CLUSTER_NAME`), à la région AWS (`AWS_REGION`), à l’ID VPC `VPC_ID`() et à la version des Charts de Helm de l’AWS Load Balancer Controller (`AWS_LBC_HELM_VERSION`) par vos paramètres, puis exécutez la commande suivante. Si vous utilisez un cluster en mode mixte avec des nœuds hybrides et des nœuds dans le cloud AWS, vous pouvez exécuter l’AWS Load Balancer Controller sur les nœuds cloud en suivant les instructions disponibles à l’adresse [Contrôleur de l'équilibreur de charge AWS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc). + Vous pouvez trouver la dernière version des Charts de Helm en exécutant `helm search repo eks/aws-load-balancer-controller --versions`. ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. Vérifiez que l’AWS Load Balancer Controller a été installé correctement. ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. Créer un exemple d’application. L’exemple ci-dessous utilise l’application microservices [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Créez un fichier nommé `my-ingress-alb.yaml` avec les contenus suivants. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: alb.ingress.kubernetes.io/load-balancer-name: "my-ingress-alb" alb.ingress.kubernetes.io/target-type: "ip" alb.ingress.kubernetes.io/scheme: "internet-facing" alb.ingress.kubernetes.io/healthcheck-path: "/details/1" spec: ingressClassName: alb rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Appliquez la configuration Ingress à votre cluster. ``` kubectl apply -f my-ingress-alb.yaml ``` 1. La configuration de l’ALB pour votre ressource Ingress peut prendre quelques minutes. Une fois l’ALB provisionné, votre ressource Ingress se verra attribuer une adresse correspondant au nom DNS du déploiement ALB. L’adresse aura le format `-..elb.amazonaws.com`. ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress alb * my-ingress-alb-..elb.amazonaws.com 80 23m ``` 1. Accédez au service à l’aide de l’adresse de l’ALB. ``` curl -s http//my-ingress-alb-..elb.amazonaws.com:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" "details": "This is the details page" } ``` ## Présentation de Cilium Ingress et Cilium Gateway Les fonctionnalités Ingress de Cilium sont intégrées à l’architecture de Cilium et peuvent être gérées à l’aide de l’API Ingress ou de l’API Gateway de Kubernetes. Si vous ne disposez pas encore de ressources Ingress, AWS recommandoe de commencer par l’API Gateway, car elle offre un moyen plus expressif et plus flexible de définir et de gérer les ressources réseau Kubernetes. [L’API Kubernetes Gateway](https://gateway-api.sigs.k8s.io/) vise à normaliser la manière dont les ressources réseau pour Ingress, l’équilibreur de charge et le maillage de services sont définies et gérées dans les clusters Kubernetes. Lorsque vous activez les fonctionnalités Ingress ou Gateway de Cilium, l’opérateur Cilium synchronise les objets Ingress / Gateway dans le cluster et les proxys Envoy sur chaque nœud traitent le trafic réseau de couche 7 (L7). Cilium ne fournit pas directement d’infrastructure Ingress / Gateway telle que des équilibreurs de charge. Si vous prévoyez d’utiliser Cilium Ingress / Gateway avec un équilibreur de charge, vous devez utiliser les outils de l’équilibreur de charge, généralement un contrôleur Ingress ou Gateway, pour déployer et gérer l’infrastructure de l’équilibreur de charge. Pour le trafic Ingress/Gateway, Cilium gère le trafic réseau central et l’application des politiques L3/L4, tandis que les proxys Envoy intégrés traitent le trafic réseau L7. Avec Cilium Ingress / Gateway, Envoy est chargé d’appliquer les règles de routage L7, les politiques et la manipulation des requêtes, la gestion avancée du trafic telle que la répartition et la mise en miroir du trafic, ainsi que la terminaison et l’origine TLS. Les proxys Envoy de Cilium sont déployés par défaut sous forme de DaemonSet (`cilium-envoy`) distinct, ce qui permet de mettre à jour, de dimensionner et de gérer séparément Envoy et l’agent Cilium. Pour plus d’informations sur le fonctionnement de [Cilium Ingress](https://docs.cilium.io/en/stable/network/servicemesh/ingress/) et [Cilium Gateway](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/), consultez les pages Cilium Ingress et Cilium Gateway dans la documentation Cilium. ## Comparaison entre Cilium Ingress et Gateway Le tableau ci-dessous résume les fonctionnalités de Cilium Ingress et Cilium Gateway dans la **version 1.17.x de Cilium**. | Fonctionnalité | Ingress | Passerelle | | --- | --- | --- | | Type de service LoadBalancer | Oui | Oui | | Type de service NodePort | Oui | N°1 | | Réseau hôte | Oui | Oui | | Équilibreur de charge partagé | Oui | Oui | | Équilibreur de charge dédié | Oui | No2 | | Stratégies réseau | Oui | Oui | | Protocoles | Couche 7 (HTTP (S), gRPC) | Couche 7 (HTTP(S), gRPC)3 | | TLS Passthrough | Oui | Oui | | Gestion du trafic | Routage du chemin et d’hôte | Routage de chemin et d’hôte, redirection et réécriture d’URL, répartition du trafic, modification d’en-tête | 1 La prise en charge de Cilium Gateway pour les services NodePort est prévue pour la [version 1.18.x de Cilium (\$127273)](https://github.com/cilium/cilium/pull/27273) 2 Prise en charge de Cilium Gateway pour les équilibreurs de charge dédiés ([\$125567](https://github.com/cilium/cilium/issues/25567)) 3 Prise en charge de Cilium Gateway pour TCP/UDP ([\$121929](https://github.com/cilium/cilium/issues/21929)) ## Installer Cilium Gateway ### Considérations + Cilium doit être configuré avec `nodePort.enabled` réglé sur `true`, comme indiqué dans les exemples ci-dessous. Si vous utilisez la fonctionnalité de remplacement kube-proxy de Cilium, vous n’avez pas besoin de définir `nodePort.enabled` sur `true`. + Cilium doit être configuré avec `envoy.enabled` réglé sur `true`, comme indiqué dans les exemples ci-dessous. + Cilium Gateway peut être déployé en mode équilibreur de charge (par défaut) ou en mode réseau hôte. + Lorsque vous utilisez Cilium Gateway en mode équilibreur de charge, l’annotation `service.beta.kubernetes.io/aws-load-balancer-type: "external"` doit être définie sur la ressource Gateway afin d’empêcher le fournisseur de cloud hérité AWS de créer un Classic Load Balancer pour le service de type LoadBalancer que Cilium crée pour la ressource Gateway. + Lorsque vous utilisez Cilium Gateway en mode réseau hôte, le service de type LoadBalancer est désactivé. Le mode réseau hôte est utile pour les environnements qui ne disposent pas d’une infrastructure d’équilibrage de charge. Pour plus d’informations, consultez [Réseau hôte](#hybrid-nodes-ingress-cilium-host-network). ### Prérequis 1. Helm installé dans votre environnement de ligne de commande, consultez les [Instructions de configuration de Helm](helm.md). 1. Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ### Procédure 1. Installez les définitions de ressources personnalisées (CRD) de l’API Kubernetes Gateway. ``` kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml ``` 1. Créez un fichier nommé `cilium-gateway-values.yaml` avec le contenu suivant. L’exemple ci-dessous configure Cilium Gateway pour utiliser le mode d’équilibrage de charge par défaut et utiliser un DaemonSet `cilium-envoy` distinct pour les proxys Envoy configurés pour s’exécuter uniquement sur des nœuds hybrides. ``` gatewayAPI: enabled: true # uncomment to use host network mode # hostNetwork: # enabled: true nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Appliquez le fichier de valeurs Helm à votre cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-gateway-values.yaml ``` 1. Vérifiez que l’opérateur Cilium, l’agent et les pods Envoy fonctionnent correctement. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Configurer la passerelle Cilium Cilium Gateway est activé sur les objets Gateway en définissant le paramètre `gatewayClassName` sur `cilium`. Le service créé par Cilium pour les ressources Gateway peut être configuré à l’aide des champs de l’objet Gateway. Les annotations couramment utilisées par les contrôleurs Gateway pour configurer l’infrastructure d’équilibrage de charge peuvent être configurées à l’aide du champ `infrastructure` de l’objet Gateway. Lorsque vous utilisez l’IPAM LoadBalancer de Cilium (voir exemple dans [Type de service LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer)), l’adresse IP à utiliser pour le service de type LoadBalancer peut être configurée dans le champ `addresses` de l’objet Gateway. Pour plus d’informations sur la configuration de la passerelle, consultez la [spécification de l’API Kubernetes Gateway](https://gateway-api.sigs.k8s.io/reference/spec/#gateway). ``` apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/... service.kuberentes.io/... addresses: - type: IPAddress value: listeners: ... ``` Cilium et la spécification Kubernetes Gateway prennent en charge les ressources GatewayClass, Gateway, HTTPRoute, GRPCRoute et ReferenceGrant. + Consultez les spécifications [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/HTTPRoute) et [GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/GRPCRoute) pour obtenir la liste des champs disponibles. + Consultez les exemples dans la section [Déployer Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy) ci-dessous et ceux dans la [documentation Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#examples) pour savoir comment utiliser et configurer ces ressources. ## Déployer Cilium Gateway 1. Créer un exemple d’application. L’exemple ci-dessous utilise l’application microservices [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Vérifiez que l’application fonctionne correctement. ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. Créez un fichier nommé `my-gateway.yaml` avec les contenus suivants. L’exemple ci-dessous utilise l’annotation `service.beta.kubernetes.io/aws-load-balancer-type: "external"` pour empêcher l’ancien fournisseur de cloud AWS de créer un Classic Load Balancer pour le service de type LoadBalancer que Cilium crée pour la ressource Gateway. ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" listeners: - protocol: HTTP port: 80 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` 1. Appliquez la ressource Gateway à votre cluster. ``` kubectl apply -f my-gateway.yaml ``` 1. Confirmez que la ressource Gateway et le service correspondant ont été créés. À ce stade, il est prévu que le champ `ADDRESS` de la ressource Gateway ne soit pas renseigné avec une adresse IP ou un nom d’hôte, et que le service de type LoadBalancer pour la ressource Gateway ne dispose pas non plus d’adresse IP ou de nom d’hôte attribué. ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium True 10s ``` ``` kubectl get svc cilium-gateway-my-gateway ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-gateway-my-gateway LoadBalancer 172.16.227.247 80:30912/TCP 24s ``` 1. Procédez à [Type de service LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) pour configurer la ressource Gateway afin d’utiliser une adresse IP attribuée par Cilium Load Balancer IPAM, et [Type de service NodePort](#hybrid-nodes-ingress-cilium-nodeport) ou [Réseau hôte](#hybrid-nodes-ingress-cilium-host-network) pour configurer la ressource Gateway afin d’utiliser les adresses NodePort ou réseau hôte. ## Installer Cilium Ingress ### Considérations + Cilium doit être configuré avec `nodePort.enabled` réglé sur `true`, comme indiqué dans les exemples ci-dessous. Si vous utilisez la fonctionnalité de remplacement kube-proxy de Cilium, vous n’avez pas besoin de définir `nodePort.enabled` sur `true`. + Cilium doit être configuré avec `envoy.enabled` réglé sur `true`, comme indiqué dans les exemples ci-dessous. + Lorsque `ingressController.loadbalancerMode` est défini sur `dedicated`, Cilium crée des services dédiés pour chaque ressource Ingress. Lorsque `ingressController.loadbalancerMode` est défini sur `shared`, Cilium crée un service partagé de type LoadBalancer pour toutes les ressources Ingress du cluster. Lorsque vous utilisez le mode équilibreur de charge `shared`, les paramètres du service partagé tels que `labels`, `annotations`, `type` et `loadBalancerIP` sont configurés dans la section `ingressController.service` des valeurs Helm. Pour plus d’informations, consultez la [référence sur les valeurs Cilium Helm](https://github.com/cilium/cilium/blob/v1.17.6/install/kubernetes/cilium/values.yaml#L887). + Avec `ingressController.default` défini sur `true`, Cilium est configuré comme contrôleur Ingress par défaut pour le cluster et créera des entrées Ingress même lorsque `ingressClassName` n’est pas spécifié sur les ressources Ingress. + Cilium Ingress peut être déployé en mode équilibreur de charge (par défaut), port de nœud ou réseau hôte. Lorsque Cilium est installé en mode réseau hôte, les modes Service de type LoadBalancer et Service de type NodePort sont désactivés. Pour plus d’informations, consultez [Réseau hôte](#hybrid-nodes-ingress-cilium-host-network). + Définissez toujours `ingressController.service.annotations` sur `service.beta.kubernetes.io/aws-load-balancer-type: "external"` dans les valeurs Helm afin d’empêcher l’ancien fournisseur de cloud AWS de créer un Classic Load Balancer pour le service par défaut `cilium-ingress` créé par les [Charts de Helm Cilium](https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/templates/cilium-ingress-service.yaml). ### Prérequis 1. Helm installé dans votre environnement de ligne de commande, consultez les [Instructions de configuration de Helm](helm.md). 1. Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). ### Procédure 1. Créez un fichier nommé `cilium-ingress-values.yaml` avec le contenu suivant. L’exemple ci-dessous configure Cilium Ingress pour utiliser le mode d’équilibrage de charge `dedicated` par défaut et utiliser un DaemonSet distinct `cilium-envoy` pour les proxys Envoy configurés pour s’exécuter uniquement sur des nœuds hybrides. ``` ingressController: enabled: true loadbalancerMode: dedicated service: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Appliquez le fichier de valeurs Helm à votre cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-ingress-values.yaml ``` 1. Vérifiez que l’opérateur Cilium, l’agent et les pods Envoy fonctionnent correctement. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Configurer Cilium Ingress Cilium Ingress est activé sur les objets Ingress en définissant le paramètre `ingressClassName` sur `cilium`. Les services créés par Cilium pour les ressources Ingress peuvent être configurés à l’aide d’annotations sur les objets Ingress lorsque vous utilisez le mode équilibreur de charge `dedicated`, et dans la configuration Cilium / Helm lorsque vous utilisez le mode équilibreur de charge `shared`. Ces annotations sont couramment utilisées par les contrôleurs Ingress pour configurer l’infrastructure de l’équilibreur de charge ou d’autres attributs du service, tels que le type de service, le mode de l’équilibreur de charge, les ports et le transfert TLS. Les annotations clés sont décrites ci-dessous. Pour obtenir la liste complète des annotations prises en charge, consultez les [annotations Cilium Ingress](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#supported-ingress-annotations) dans la documentation Cilium. | Annotation | Description | | --- | --- | | `ingress.cilium.io/loadbalancer-mode` | `dedicated` : Service dédié de type LoadBalancer pour chaque ressource Ingress (par défaut). `shared` : Service unique de type LoadBalancer pour toutes les ressources Ingress. | | `ingress.cilium.io/service-type` | `LoadBalancer` : le service sera de type LoadBalancer (par défaut) `NodePort` : Le service sera de type NodePort. | | `service.beta.kubernetes.io/aws-load-balancer-type` | `"external"` : Empêcher les anciens fournisseurs de cloud AWS de provisionner un Classic Load Balancer pour les services de type LoadBalancer. | | `lbipam.cilium.io/ips` | Liste des adresses IP à attribuer à partir de Cilium LoadBalancer IPAM | Cilium et la spécification Kubernetes Ingress prennent en charge les règles de correspondance exacte, préfixe et spécifique à l’implémentation pour les chemins d’accès Ingress. Cilium prend en charge les expressions régulières comme règle de correspondance spécifique à son implémentation. Pour plus d’informations, consultez les sections [Types et priorité des chemins d’entrée](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#ingress-path-types-and-precedence) et [Exemples de types de chemins](https://docs.cilium.io/en/stable/network/servicemesh/path-types/) dans la documentation Cilium, ainsi que les exemples présentés dans cette section [Déployer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy). Un exemple d’objet Cilium Ingress est présenté ci-dessous. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: service.beta.kuberentes.io/... service.kuberentes.io/... spec: ingressClassName: cilium rules: ... ``` ## Déployer Cilium Ingress 1. Créer un exemple d’application. L’exemple ci-dessous utilise l’application microservices [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Vérifiez que l’application fonctionne correctement. ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. Créez un fichier nommé `my-ingress.yaml` avec les contenus suivants. L’exemple ci-dessous utilise l’annotation `service.beta.kubernetes.io/aws-load-balancer-type: "external"` pour empêcher l’ancien fournisseur de cloud AWS de créer un Classic Load Balancer pour le service de type LoadBalancer que Cilium crée pour la ressource Ingress. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Appliquez la ressource Ingress à votre cluster. ``` kubectl apply -f my-ingress.yaml ``` 1. Confirmez que la ressource Ingress et le service correspondant ont été créés. À ce stade, il est prévu que le champ `ADDRESS` de la ressource Ingress ne soit pas renseigné avec une adresse IP ou un nom d’hôte, et que le service partagé ou dédié de type LoadBalancer pour la ressource Ingress ne dispose pas non plus d’adresse IP ou de nom d’hôte attribué. ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * 80 8s ``` Pour le mode équilibreur de charge `shared` ``` kubectl -n kube-system get svc cilium-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress LoadBalancer 172.16.217.48 80:32359/TCP,443:31090/TCP 10m ``` Pour le mode équilibreur de charge `dedicated` ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress LoadBalancer 172.16.193.15 80:32088/TCP,443:30332/TCP 25s ``` 1. Procédez à [Type de service LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) pour configurer la ressource Ingress afin d’utiliser une adresse IP attribuée par Cilium Load Balancer IPAM, et [Type de service NodePort](#hybrid-nodes-ingress-cilium-nodeport) ou [Réseau hôte](#hybrid-nodes-ingress-cilium-host-network) pour configurer la ressource Ingress afin d’utiliser les adresses NodePort ou du réseau hôte. ## Type de service LoadBalancer ### Infrastructure existante de l’équilibreur de charge Par défaut, pour Cilium Ingress et Cilium Gateway, Cilium crée des services Kubernetes de type LoadBalancer pour les ressources Ingress / Gateway. Les attributs du ou des services créés par Cilium peuvent être configurés via les ressources Ingress et Gateway. Lorsque vous créez des ressources Ingress ou Gateway, l’adresse IP ou les noms d’hôte exposés en externe pour Ingress ou Gateway sont attribués à partir de l’infrastructure d’équilibrage de charge, qui est généralement fournie par un contrôleur Ingress ou Gateway. De nombreux contrôleurs Ingress et Gateway utilisent des annotations pour détecter et configurer l’infrastructure d’équilibrage de charge. Les annotations pour ces contrôleurs Ingress et Gateway sont configurées sur les ressources Ingress ou Gateway, comme indiqué dans les exemples précédents ci-dessus. Consultez la documentation de votre contrôleur Ingress ou Gateway pour connaître les annotations qu’il prend en charge et consultez la [documentation Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) et la [documentation Kubernetes Gateway](https://gateway-api.sigs.k8s.io/implementations/) pour obtenir une liste des contrôleurs courants. **Important** Cilium Ingress et Gateway ne peuvent pas être utilisés avec l’AWS Load Balancer Controller et les Network Load Balancers (NLB) AWS avec les nœuds hybrides EKS. Tenter de les utiliser ensemble entraîne des cibles non enregistrées, car le NLB tente de se connecter directement aux adresses IP des pods qui prennent en charge le service de type LoadBalancer lorsque le NLB `target-type` est défini sur `ip` (condition requise pour utiliser NLB avec des charges de travail s’exécutant sur des nœuds hybrides EKS). ### Pas d’infrastructure d’équilibrage de charge Si votre environnement ne dispose pas d’une infrastructure d’équilibrage de charge et du contrôleur Ingress / Gateway correspondant, les ressources Ingress / Gateway et les services de type LoadBalancer correspondants peuvent être configurés pour utiliser les adresses IP attribuées par la [gestion des adresses IP de l’équilibreur de charge](https://docs.cilium.io/en/stable/network/lb-ipam/) de Cilium (LB IPAM). L’IPAM du LB Cilium peut être configuré avec des plages d’adresses IP connues provenant de votre environnement sur site et peut utiliser la prise en charge intégrée du protocole de passerelle frontière (BGP) de Cilium ou les annonces L2 pour diffuser les adresses IP du LoadBalancer vers votre réseau sur site. L’exemple ci-dessous montre comment configurer l’IPAM LB de Cilium avec une adresse IP à utiliser pour vos ressources Ingress / Gateway, et comment configurer le plan de contrôle BGP de Cilium pour annoncer l’adresse IP de l’équilibreur de charge au réseau sur site. La fonctionnalité LB IPAM de Cilium est activée par défaut, mais n’est pas activée tant qu’une ressource `CiliumLoadBalancerIPPool` n’est pas créée. #### Prérequis + Cilium Ingress ou Gateway installé conformément aux instructions fournies dans [Installer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install) ou [Installer Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-install). + Ressources Cilium Ingress ou Gateway avec exemple d’application déployée en suivant les instructions dans [Déployer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy) ou [Déployer Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy). + Le plan de contrôle Cilium BGP a été activé en suivant les instructions fournies dans [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md). Si vous ne souhaitez pas utiliser BGP, vous pouvez ignorer cette condition préalable, mais vous ne pourrez pas accéder à votre ressource Ingress ou Gateway tant que l’adresse IP LoadBalancer attribuée par Cilium LB IPAM ne sera pas routable sur votre réseau sur site. #### Procédure 1. Vous pouvez éventuellement modifier la ressource Ingress ou Gateway afin de demander une adresse IP spécifique à utiliser pour le service de type LoadBalancer. Si vous ne demandez pas d’adresse IP spécifique, Cilium attribuera une adresse IP à partir de la plage d’adresses IP configurée dans la ressource `CiliumLoadBalancerIPPool` à l’étape suivante. Dans les commandes ci-dessous, remplacez `LB_IP_ADDRESS` par l’adresse IP pour demander le service de type LoadBalancer. **Passerelle** ``` kubectl patch gateway -n default my-gateway --type=merge -p '{ "spec": { "addresses": [{"type": "IPAddress", "value": "LB_IP_ADDRESS"}] } }' ``` **Ingress** ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"lbipam.cilium.io/ips": "LB_IP_ADDRESS"}} }' ``` 1. Créez un fichier nommé `cilium-lbip-pool-ingress.yaml` avec une ressource `CiliumLoadBalancerIPPool` pour configurer la plage d’adresses IP de l’équilibreur de charge pour vos ressources Ingress / Gateway. + Si vous utilisez Cilium Ingress, Cilium applique automatiquement le label `cilium.io/ingress: "true"` aux services qu’il crée pour les ressources Ingress. Vous pouvez utiliser cette étiquette dans le champ `serviceSelector` de la définition de la ressource `CiliumLoadBalancerIPPool` pour sélectionner les services éligibles à LB IPAM. + Si vous utilisez Cilium Gateway, vous pouvez utiliser l’étiquette `gateway.networking.k8s.io/gateway-name` dans les champs `serviceSelector` de la définition de ressource `CiliumLoadBalancerIPPool` pour sélectionner les ressources Gateway éligibles pour LB IPAM. + Remplacez `LB_IP_CIDR` par la plage d’adresses IP à utiliser pour les adresses IP de l’équilibreur de charge. Pour sélectionner une seule adresse IP, utilisez un CIDR `/32`. Pour plus d’informations, consultez la section [Gestion des adresses IP LoadBalancer](https://docs.cilium.io/en/stable/network/lb-ipam/) dans la documentation Cilium. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: bookinfo-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. Appliquez la ressource `CiliumLoadBalancerIPPool` à votre cluster. ``` kubectl apply -f cilium-lbip-pool-ingress.yaml ``` 1. Confirmez qu’une adresse IP a été attribuée par Cilium LB IPAM pour la ressource Ingress / Gateway. **Passerelle** ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium LB_IP_ADDRESS True 6m41s ``` **Ingress** ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * LB_IP_ADDRESS 80 10m ``` 1. Créez un fichier nommé `cilium-bgp-advertisement-ingress.yaml` avec une ressource `CiliumBGPAdvertisement` pour annoncer l’adresse IP du LoadBalancer pour les ressources Ingress / Gateway. Si vous n’utilisez pas Cilium BGP, vous pouvez ignorer cette étape. L’adresse IP du LoadBalancer utilisée pour votre ressource Ingress / Gateway doit être routable sur votre réseau local afin que vous puissiez interroger le service à l’étape suivante. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-lb-ip labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. Appliquez la ressource `CiliumBGPAdvertisement` à votre cluster. ``` kubectl apply -f cilium-bgp-advertisement-ingress.yaml ``` 1. Accédez au service à l’aide de l’adresse IP attribuée par Cilium LB IPAM. ``` curl -s http://LB_IP_ADDRESS:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## Type de service NodePort Si votre environnement ne dispose pas d’une infrastructure d’équilibrage de charge et d’un contrôleur Ingress correspondant, ou si vous gérez vous-même votre infrastructure d’équilibrage de charge ou utilisez un équilibrage de charge basée sur DNS, vous pouvez configurer Cilium Ingress pour créer des services de type NodePort pour les ressources Ingress. Lorsque vous utilisez NodePort avec Cilium Ingress, le service de type NodePort est exposé sur un port de chaque nœud dans la plage de ports 30000-32767. Dans ce mode, lorsque le trafic atteint un nœud quelconque du cluster sur le NodePort, il est ensuite transféré vers un pod qui prend en charge le service, lequel peut se trouver sur le même nœud ou sur un nœud différent. **Note** La prise en charge de Cilium Gateway pour les services NodePort est prévue pour la version 1.18.x de Cilium ([\$127273](https://github.com/cilium/cilium/pull/27273)) ### Prérequis + Cilium Ingress installé en suivant les instructions fournies dans [Installer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install). + Ressources Cilium Ingress avec exemple d’application déployée en suivant les instructions dans [Déployer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy). ### Procédure 1. Modifiez la ressource Ingress `my-ingress` existante pour la faire passer du type de service LoadBalancer à NodePort. ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"ingress.cilium.io/service-type": "NodePort"}} }' ``` Si vous n’avez pas créé la ressource Ingress, vous pouvez la créer en appliquant la définition Ingress suivante à votre cluster. Remarque : la définition d’Ingress ci-dessous utilise l’application exemple Istio Bookinfo décrite dans [Déployer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy). ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" "ingress.cilium.io/service-type": "NodePort" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Confirmez que le service pour la ressource Ingress a été mis à jour pour utiliser le type de service NodePort. Notez le port pour le protocole HTTP dans la sortie. Dans l’exemple ci-dessous, ce port HTTP est `32353`, qui sera utilisé dans une étape ultérieure pour interroger le service. L’avantage d’utiliser Cilium Ingress avec un service de type NodePort est que vous pouvez appliquer un routage basé sur le chemin et l’hôte, ainsi que des politiques réseau pour le trafic Ingress, ce qui n’est pas possible avec un service standard de type NodePort sans Ingress. ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress NodePort 172.16.47.153 80:32353/TCP,443:30253/TCP 27m ``` 1. Obtenez les adresses IP des nœuds de votre cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Accédez au service de type NodePort à l’aide des adresses IP de vos nœuds et du NodePort capturé ci-dessus. Dans l’exemple ci-dessous, l’adresse IP du nœud utilisée est `10.80.146.32` et le NodePort est `32353`. Remplacez-les par les valeurs correspondant à votre environnement. ``` curl -s http://10.80.146.32:32353/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## Réseau hôte Comme pour le service de type NodePort, si vous ne disposez pas d’une infrastructure d’équilibrage de charge et d’un contrôleur Ingress ou Gateway, ou si vous gérez vous-même votre équilibrage de charge à l’aide d’un équilibreur de charge externe, vous pouvez configurer Cilium Ingress et Cilium Gateway pour exposer les ressources Ingress et Gateway directement sur le réseau hôte. Lorsque le mode réseau hôte est activé pour une ressource Ingress ou Gateway, les modes Service de type LoadBalancer et NodePort sont automatiquement désactivés. Le mode réseau hôte est mutuellement exclusif avec ces modes alternatifs pour chaque ressource Ingress ou Gateway. Par rapport au service de type NodePort, le mode réseau hôte offre une flexibilité supplémentaire pour la plage de ports pouvant être utilisés (il n’est pas limité à la plage NodePort 30000-32767) et vous pouvez configurer un sous-ensemble de nœuds où les proxys Envoy s’exécutent sur le réseau hôte. ### Prérequis + Cilium Ingress ou Gateway installé conformément aux instructions fournies dans [Installer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install) ou [Installer Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-install). ### Procédure #### Passerelle 1. Créez un fichier nommé `cilium-gateway-host-network.yaml` avec le contenu suivant. ``` gatewayAPI: enabled: true hostNetwork: enabled: true # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: gateway ``` 1. Appliquez la configuration du réseau hôte Cilium Gateway à votre cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-gateway-host-network.yaml ``` Si vous n’avez pas créé la ressource Gateway, vous pouvez la créer en appliquant la définition Gateway suivante à votre cluster. La définition Gateway ci-dessous utilise l’application exemple Istio Bookinfo décrite dans [Déployer Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy). Dans l’exemple ci-dessous, la ressource Gateway est configurée pour utiliser le port `8111` pour l’écouteur HTTP, qui est le port d’écouteur partagé pour les proxys Envoy s’exécutant sur le réseau hôte. Si vous utilisez un port privilégié (inférieur à 1023) pour la ressource Gateway, consultez la [documentation Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#bind-to-privileged-port) pour obtenir des instructions. ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium listeners: - protocol: HTTP port: 8111 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` Vous pouvez observer la configuration Cilium Envoy appliquée à l’aide de la commande suivante. ``` kubectl get cec cilium-gateway-my-gateway -o yaml ``` Vous pouvez obtenir le port d’écouteur Envoy pour le service `cilium-gateway-my-gateway` à l’aide de la commande suivante. Dans cet exemple, le port d’écouteur partagé est `8111`. ``` kubectl get cec cilium-gateway-my-gateway -o jsonpath={.spec.services[0].ports[0]} ``` 1. Obtenez les adresses IP des nœuds de votre cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Accédez au service à l’aide des adresses IP de vos nœuds et du port d’écouteur de la ressource `cilium-gateway-my-gateway`. Dans l’exemple ci-dessous, l’adresse IP du nœud utilisée est `10.80.146.32` et le port d’écouteur est `8111`. Remplacez-les par les valeurs correspondant à votre environnement. ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` #### Ingress En raison d’un problème en amont avec Cilium ([\$134028](https://github.com/cilium/cilium/issues/34028)), Cilium Ingress en mode réseau hôte nécessite l’utilisation de `loadbalancerMode: shared`, qui crée un seul service de type ClusterIP pour toutes les ressources Ingress du cluster. Si vous utilisez un port privilégié (inférieur à 1023) pour la ressource Ingress, consultez la [documentation Cilium](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#bind-to-privileged-port) pour obtenir des instructions. 1. Créez un fichier nommé `cilium-ingress-host-network.yaml` avec le contenu suivant. ``` ingressController: enabled: true loadbalancerMode: shared # This is a workaround for the upstream Cilium issue service: externalTrafficPolicy: null type: ClusterIP hostNetwork: enabled: true # ensure the port does not conflict with other services on the node sharedListenerPort: 8111 # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: ingress ``` 1. Appliquez la configuration Cilium Ingress du réseau hôte à votre cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-ingress-host-network.yaml ``` Si vous n’avez pas créé la ressource Ingress, vous pouvez la créer en appliquant la définition Ingress suivante à votre cluster. La définition d’Ingress ci-dessous utilise l’application exemple Istio Bookinfo décrite dans [Déployer Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy). ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` Vous pouvez observer la configuration Cilium Envoy appliquée à l’aide de la commande suivante. ``` kubectl get cec -n kube-system cilium-ingress -o yaml ``` Vous pouvez obtenir le port d’écouteur Envoy pour le service `cilium-ingress` à l’aide de la commande suivante. Dans cet exemple, le port d’écouteur partagé est `8111`. ``` kubectl get cec -n kube-system cilium-ingress -o jsonpath={.spec.services[0].ports[0]} ``` 1. Obtenez les adresses IP des nœuds de votre cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Accédez au service à l’aide des adresses IP de vos nœuds et de `sharedListenerPort` pour la ressource `cilium-ingress`. Dans l’exemple ci-dessous, l’adresse IP du nœud utilisée est `10.80.146.32` et le port d’écouteur est `8111`. Remplacez-les par les valeurs correspondant à votre environnement. ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` # Configurer les services de type LoadBalancer pour les nœuds hybrides Cette rubrique décrit comment configurer l’équilibrage de charge de couche 4 (L4) pour les applications s’exécutant sur des nœuds hybrides Amazon EKS. Les services Kubernetes de type LoadBalancer sont utilisés pour exposer les applications Kubernetes à l’extérieur du cluster. Les services de type LoadBalancer sont couramment utilisés avec une infrastructure d’équilibrage de charge physique dans le cloud ou dans un environnement sur site pour traiter le trafic de la charge de travail. Cette infrastructure d’équilibrage de charge est généralement fournie avec un contrôleur spécifique à l’environnement. AWS prend en charge Network Load Balancer (NLB) AWS et Cilium pour les services de type LoadBalancer s’exécutant sur des nœuds hybrides EKS. La décision d’utiliser NLB ou Cilium dépend de la source du trafic applicatif. Si le trafic applicatif provient d’une région AWS, AWS recommande d’utiliser AWS NLB ainsi que l’AWS Load Balancer Controller. Si le trafic applicatif provient de l’environnement local sur site ou périphérique, AWS recommande d’utiliser les capacités de répartition de charge intégrées à Cilium, qui peuvent être utilisées avec ou sans infrastructure d’équilibrage de charge dans votre environnement. Pour l’équilibrage de charge du trafic des applications de couche 7 (L7), voir [Configurer Kubernetes Ingress pour les nœuds hybrides](hybrid-nodes-ingress.md). Pour obtenir des informations générales sur l’équilibrage de charge avec EKS, consultez la section [Meilleures pratiques pour l’équilibrage de charge](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html). ## AWS Network Load Balancer Vous pouvez utiliser l’[AWS Load Balancer Controller](aws-load-balancer-controller.md) et NLB avec le type de cible `ip` pour les charges de travail s’exécutant sur des nœuds hybrides. Lorsque vous utilisez le type de cible `ip`, NLB transfère le trafic directement vers les pods, en contournant le chemin réseau de la couche Service. Pour que NLB atteigne les cibles IP des pods sur les nœuds hybrides, vos CIDR de pods sur site doivent être routables sur votre réseau sur site. De plus, l’AWS Load Balancer Controller utilise des webhooks et nécessite une communication directe depuis le plan de contrôle EKS. Pour de plus amples informations, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). + Consultez [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md) pour connaître les exigences de configuration du sous-réseau, et [Installez le contrôleur AWS Load Balancer avec Helm](lbc-helm.md) et les [Bonnes pratiques en matière d’équilibrage de charge](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html) pour obtenir des informations supplémentaires sur le Network Load Balancer AWS et l’AWS Load Balancer Controller. + Consultez les [configurations NLB de l’AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/nlb/) pour connaître les configurations pouvant être appliquées aux services de type `LoadBalancer` avec le Network Load Balancer AWS. ### Prérequis + Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). + Le plan de contrôle Cilium BGP a été activé en suivant les instructions fournies dans [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md). Si vous ne souhaitez pas utiliser BGP, vous devez utiliser une autre méthode pour rendre vos CIDR de pods sur site routables sur votre réseau sur site. Pour plus d’informations, consultez [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs). + Helm installé dans votre environnement de ligne de commande, consultez les [Instructions de configuration de Helm](helm.md). + eksctl installé dans votre environnement de ligne de commande, consultez les instructions de [configuration d’eksctl](install-kubectl.md#eksctl-install-update). ### Procédure 1. Téléchargez une politique IAM pour le contrôleur de l'équilibreur de charge AWS qui lui permet d'effectuer des appels aux API AWS en votre nom. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. Créez une politique IAM à l'aide de la politique téléchargée à l'étape précédente. ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. Remplacez les valeurs pour le nom du cluster (`CLUSTER_NAME`), la région AWS (`AWS_REGION`) et l’ID du compte AWS (`AWS_ACCOUNT_ID`) par vos paramètres, puis exécutez la commande suivante. ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. Ajoutez le référentiel des Charts de Helm eks-charts. AWS maintient ce référentiel sur GitHub. ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. Mettez à jour votre référentiel Helm local pour vous assurer que vous disposez des graphiques les plus récents. ``` helm repo update eks ``` 1. Installez le contrôleur de l'équilibreur de charge AWS. Remplacez les valeurs pour le nom du cluster (`CLUSTER_NAME`), la région AWS (`AWS_REGION`), l’ID VPC (`VPC_ID`) et la version des Charts de Helm de l’AWS Load Balancer Controller (`AWS_LBC_HELM_VERSION`) par vos paramètres. Vous pouvez trouver la dernière version des Charts de Helm en exécutant `helm search repo eks/aws-load-balancer-controller --versions`. Si vous utilisez un cluster en mode mixte avec des nœuds hybrides et des nœuds dans le cloud AWS, vous pouvez exécuter l’AWS Load Balancer Controller sur les nœuds cloud en suivant les instructions disponibles à l’adresse [Contrôleur de l'équilibreur de charge AWS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc). ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. Vérifiez que l’AWS Load Balancer Controller a été installé correctement. ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. Définissez un exemple d’application dans un fichier nommé `tcp-sample-app.yaml`. L’exemple ci-dessous utilise un déploiement NGINX simple avec un port TCP. ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. Appliquez le déploiement à votre cluster. ``` kubectl apply -f tcp-sample-app.yaml ``` 1. Définissez un service de type LoadBalancer pour le déploiement dans un fichier nommé `tcp-sample-service.yaml`. ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. Appliquez la configuration du service à votre cluster. ``` kubectl apply -f tcp-sample-service.yaml ``` 1. La configuration du NLB pour le service peut prendre quelques minutes. Une fois le NLB provisionné, le service se verra attribuer une adresse correspondant au nom DNS du déploiement NLB. ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.115.212 k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com 80:30396/TCP 8s ``` 1. Accédez au service à l’aide de l’adresse du NLB. ``` curl k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com ``` Un exemple de résultat est présenté ci-dessous. ``` Welcome to nginx! [...] ``` 1. Nettoyez les ressources que vous avez créées. ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml ``` ## Équilibrage de charge dans le cluster Cilium Cilium peut être utilisé comme équilibreur de charge intra-cluster pour les charges de travail exécutées sur des nœuds hybrides EKS, ce qui peut s’avérer utile pour les environnements qui ne disposent pas d’infrastructure d’équilibrage de charge. Les capacités d’équilibrage de charge de Cilium reposent sur une combinaison de fonctionnalités Cilium, notamment le remplacement de kube-proxy, la gestion des adresses IP de l’équilibreur de charge (IPAM) et le plan de contrôle BGP. Les responsabilités de ces fonctionnalités sont détaillées ci-dessous : + **Remplacement de Cilium kube-proxy** : gère le routage du trafic des services vers les pods dorsaux. + **Cilium Load Balancer IPAM** : gère les adresses IP pouvant être attribuées aux services de type `LoadBalancer`. + **Plan de contrôle Cilium BGP** : annonce les adresses IP attribuées par le Load Balancer IPAM au réseau local. Si vous n’utilisez pas le remplacement kube-proxy de Cilium, vous pouvez toujours utiliser Cilium Load Balancer IPAM et BGP Control Plane pour allouer et attribuer des adresses IP aux services de type LoadBalancer. Si vous n’utilisez pas le remplacement kube-proxy de Cilium, l’équilibrage de charge pour les services vers les pods dorsaux est géré par kube-proxy et les règles iptables par défaut dans EKS. ### Prérequis + Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md), avec ou sans remplacement de kube-proxy activé. Le remplacement de kube-proxy par Cilium nécessite l’exécution d’un système d’exploitation avec un noyau Linux au moins aussi récent que v4.19.57, v5.1.16 ou v5.2.0. Toutes les versions récentes des systèmes d’exploitation pris en charge pour une utilisation avec des nœuds hybrides répondent à ces critères, à l’exception de Red Hat Enterprise Linux (RHEL) 8.x. + Le plan de contrôle Cilium BGP a été activé en suivant les instructions fournies dans [Configurer Cilium BGP pour les nœuds hybrides](hybrid-nodes-cilium-bgp.md). Si vous ne souhaitez pas utiliser BGP, vous devez utiliser une autre méthode pour rendre vos CIDR de pods sur site routables sur votre réseau sur site. Pour plus d’informations, consultez [CIDR de pods distants routables](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs). + Helm installé dans votre environnement de ligne de commande, consultez les [Instructions de configuration de Helm](helm.md). ### Procédure 1. Créez un fichier nommé `cilium-lbip-pool-loadbalancer.yaml` avec une ressource `CiliumLoadBalancerIPPool` pour configurer la plage d’adresses IP du Load Balancer pour vos services de type LoadBalancer. + Remplacez `LB_IP_CIDR` par la plage d’adresses IP à utiliser pour les adresses IP de l’équilibreur de charge. Pour sélectionner une seule adresse IP, utilisez un CIDR `/32`. Pour plus d’informations, consultez la section [Gestion des adresses IP LoadBalancer](https://docs.cilium.io/en/stable/network/lb-ipam/) dans la documentation Cilium. + Le champ `serviceSelector` est configuré pour correspondre au nom du service que vous créerez à l’étape suivante. Avec cette configuration, les adresses IP de ce pool ne seront attribuées qu’aux services portant le nom `tcp-sample-service`. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: tcp-service-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. Appliquez la ressource `CiliumLoadBalancerIPPool` à votre cluster. ``` kubectl apply -f cilium-lbip-pool-loadbalancer.yaml ``` 1. Vérifiez qu’au moins une adresse IP est disponible dans le pool. ``` kubectl get ciliumloadbalancerippools.cilium.io ``` ``` NAME DISABLED CONFLICTING IPS AVAILABLE AGE tcp-service-pool false False 1 24m ``` 1. Créez un fichier nommé `cilium-bgp-advertisement-loadbalancer.yaml` avec une ressource `CiliumBGPAdvertisement` pour annoncer l’adresse IP de l’équilibreur de charge pour le service que vous allez créer à l’étape suivante. Si vous n’utilisez pas Cilium BGP, vous pouvez ignorer cette étape. L’adresse IP de l’équilibreur de charge utilisée pour votre service doit être routable sur votre réseau sur site afin que vous puissiez interroger le service lors de la dernière étape. + Le champ `advertisementType` est défini sur `Service` et `service.addresses` est défini sur `LoadBalancerIP` pour annoncer uniquement le `LoadBalancerIP` pour les services de type `LoadBalancer`. + Le champ `selector` est configuré pour correspondre au nom du service que vous créerez à l’étape suivante. Avec cette configuration, seul `LoadBalancerIP` pour les services portant le nom `tcp-sample-service` seront annoncés. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-tcp-service labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. Appliquez la ressource `CiliumBGPAdvertisement` à votre cluster. Si vous n’utilisez pas Cilium BGP, vous pouvez ignorer cette étape. ``` kubectl apply -f cilium-bgp-advertisement-loadbalancer.yaml ``` 1. Définissez un exemple d’application dans un fichier nommé `tcp-sample-app.yaml`. L’exemple ci-dessous utilise un déploiement NGINX simple avec un port TCP. ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. Appliquez le déploiement à votre cluster. ``` kubectl apply -f tcp-sample-app.yaml ``` 1. Définissez un service de type LoadBalancer pour le déploiement dans un fichier nommé `tcp-sample-service.yaml`. + Vous pouvez demander une adresse IP spécifique à partir du pool d’adresses IP de l’équilibreur de charge à l’aide de l’annotation `lbipam.cilium.io/ips` sur l’objet Service. Vous pouvez supprimer cette annotation si vous ne souhaitez pas demander une adresse IP spécifique pour le Service. + Le champ spec `loadBalancerClass` est obligatoire afin d’empêcher l’ancien fournisseur de cloud AWS de créer un Classic Load Balancer pour le service. Dans l’exemple ci-dessous, cela est configuré sur `io.cilium/bgp-control-plane` pour utiliser le plan de contrôle BGP de Cilium comme classe d’équilibrage de charge. Ce champ peut également être configuré sur `io.cilium/l2-announcer` pour utiliser la [fonctionnalité L2 Announcements](https://docs.cilium.io/en/latest/network/l2-announcements/) de Cilium (actuellement en version bêta et non officiellement prise en charge par AWS). ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: lbipam.cilium.io/ips: "LB_IP_ADDRESS" spec: loadBalancerClass: io.cilium/bgp-control-plane ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. Appliquez le service à votre cluster. Le service sera créé avec une adresse IP externe que vous pourrez utiliser pour accéder à l’application. ``` kubectl apply -f tcp-sample-service.yaml ``` 1. Vérifiez que le service a été créé avec succès et qu’une adresse IP lui a été attribuée à partir du `CiliumLoadBalancerIPPool` créé à l’étape précédente. ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.117.76 LB_IP_ADDRESS 80:31129/TCP 14m ``` 1. Si vous utilisez Cilium en mode de remplacement de kube-proxy, vous pouvez vérifier que Cilium gère l’équilibrage de charge pour le service en exécutant la commande suivante. Dans la sortie ci-dessous, les adresses `10.86.2.x` sont les adresses IP des pods dorsaux du service. ``` kubectl -n kube-system exec ds/cilium -- cilium-dbg service list ``` ``` ID Frontend Service Type Backend ... 41 LB_IP_ADDRESS:80/TCP LoadBalancer 1 => 10.86.2.76:80/TCP (active) 2 => 10.86.2.130:80/TCP (active) 3 => 10.86.2.141:80/TCP (active) ``` 1. Confirmez que Cilium annonce l’adresse IP au réseau local via BGP. Dans l’exemple ci-dessous, il existe cinq nœuds hybrides, chacun annonçant le `LB_IP_ADDRESS` pour le service `tcp-sample-service` au réseau local. ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] ``` 1. Accédez au service à l’aide de l’adresse IP de l’équilibreur de charge attribué. ``` curl LB_IP_ADDRESS ``` Un exemple de résultat est présenté ci-dessous. ``` Welcome to nginx! [...] ``` 1. Nettoyez les ressources que vous avez créées. ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml kubectl delete -f cilium-lb-ip-pool.yaml kubectl delete -f cilium-bgp-advertisement.yaml ``` # Configurer les politiques réseau Kubernetes pour les nœuds hybrides AWS prend en charge les politiques réseau Kubernetes (couche 3 / couche 4) pour le trafic entrant et sortant des pods lors de l’utilisation de Cilium comme CNI avec les nœuds hybrides EKS. Si vous exécutez des clusters EKS avec des nœuds dans le cloud AWS, AWS prend en charge [Amazon VPC CNI pour les politiques réseau Kubernetes](cni-network-policy.md). Cette rubrique explique comment configurer Cilium et les politiques réseau Kubernetes avec les nœuds hybrides EKS. Pour plus d’informations sur les politiques réseau Kubernetes, consultez la section [Politiques réseau Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dans la documentation Kubernetes. ## Configurer des stratégies réseau ### Considérations + AWS prend en charge les politiques réseau Kubernetes en amont et les spécifications pour les pods ingress et egress. AWS ne prend actuellement pas en charge ni `CiliumNetworkPolicy` ni `CiliumClusterwideNetworkPolicy`. + La valeur Helm `policyEnforcementMode` peut être utilisée pour contrôler le comportement par défaut de l’application des politiques Cilium. Le comportement par défaut autorise tout le trafic sortant et entrant. Lorsqu’un point de terminaison est sélectionné par une stratégie réseau, il passe à un état de refus par défaut, dans lequel seul le trafic explicitement autorisé est autorisé. Consultez la documentation Cilium pour plus d’informations sur le [mode de politique par défaut](https://docs.cilium.io/en/stable/security/policy/intro/#policy-mode-default) et les [modes d’application des politiques](https://docs.cilium.io/en/stable/security/policy/intro/#policy-enforcement-modes). + Si vous modifiez `policyEnforcementMode` pour une installation Cilium existante, vous devez redémarrer le DaemonSet de l’agent Cilium pour appliquer le nouveau mode d’application des politiques. + Utilisez `namespaceSelector` et `podSelector` pour autoriser ou refuser le trafic vers/depuis les espaces de noms et les pods avec des étiquettes correspondantes. Le `namespaceSelector` et `podSelector` peut être utilisé avec `matchLabels` ou `matchExpressions` pour choisir des espaces de noms et des pods en fonction de leurs étiquettes. + Utilisez `ingress.ports` et `egress.ports` pour autoriser ou refuser le trafic vers/depuis les ports ainsi que les protocoles. + Le champ `ipBlock` ne peut pas être utilisé pour autoriser ou refuser de façon sélective le trafic vers/depuis les adresses IP des pods ([\$19209](https://github.com/cilium/cilium/issues/9209)). Utiliser des sélecteurs `ipBlock` pour les adresses IP des nœuds est une fonctionnalité bêta de Cilium qui n’est pas prise en charge par AWS. + Consultez la ressource [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) dans la documentation Kubernetes pour obtenir des informations sur les champs disponibles pour les politiques réseau Kubernetes. ### Prérequis + Cilium installé en suivant les instructions dans [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). + Helm installé dans votre environnement de ligne de commande, consultez les [Instructions de configuration de Helm](helm.md). ### Procédure La procédure suivante configure les stratégies réseau pour un exemple d’application de microservices afin que les composants ne puissent communiquer qu’avec les autres composants nécessaires au fonctionnement de l’application. La procédure utilise l’application microservices [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). L’application Bookinfo se compose de quatre microservices distincts ayant les relations suivantes : + **pageproduit.** Le microservice de la page produit appelle les microservices de détails et d’avis pour remplir la page. + **détails**. Le microservice details contient des informations sur les livres. + **reviews**. Le microservice « critiques » contient des critiques de livres. Il fait également appel au microservice de notation. + **évaluations**. Le microservice « évaluations » contient des informations sur le classement des livres qui accompagnent les critiques littéraires. 1. Créer l’application exemple. ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Vérifiez que l’application fonctionne correctement et notez l’adresse IP du pod pour le microservice pageproduit. Vous utiliserez cette adresse IP du pod pour interroger chaque microservice dans les étapes suivantes. ``` kubectl get pods -o wide ``` ``` NAME READY STATUS RESTARTS AGE IP NODE details-v1-766844796b-9wff2 1/1 Running 0 7s 10.86.3.7 mi-0daa253999fe92daa productpage-v1-54bb874995-lwfgg 1/1 Running 0 7s 10.86.2.193 mi-082f73826a163626e ratings-v1-5dc79b6bcd-59njm 1/1 Running 0 7s 10.86.2.232 mi-082f73826a163626e reviews-v1-598b896c9d-p2289 1/1 Running 0 7s 10.86.2.47 mi-026d6a261e355fba7 reviews-v2-556d6457d-djktc 1/1 Running 0 7s 10.86.3.58 mi-0daa253999fe92daa reviews-v3-564544b4d6-g8hh4 1/1 Running 0 7s 10.86.2.69 mi-09183e8a3d755abf6 ``` 1. Créez un pod qui sera utilisé tout au long du processus pour tester les politiques réseau. Notez que le pod est créé dans l’espace de noms `default` avec le label `access: true`. ``` kubectl run curl-pod --image=curlimages/curl -i --tty --labels=access=true --namespace=default --overrides='{"spec": { "nodeSelector": {"eks.amazonaws.com/compute-type": "hybrid"}}}' -- /bin/sh ``` 1. Testez l’accès au microservice de la page produit. Dans l’exemple ci-dessous, nous utilisons l’adresse IP du pod productpage (`10.86.2.193`) pour interroger le microservice. Remplacez ceci par l’adresse IP du pod productpage dans votre environnement. ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" ``` ``` Simple Bookstore App ``` 1. Vous pouvez quitter le pod test curl en tapant `exit` et vous pouvez vous reconnecter au pod en exécutant la commande suivante. ``` kubectl attach curl-pod -c curl-pod -i -t ``` 1. Pour démontrer les effets des stratégies réseau dans les étapes suivantes, nous créons d’abord une stratégie réseau qui refuse tout trafic pour les microservices BookInfo. Créez un fichier nommé `network-policy-deny-bookinfo.yaml` qui définit la stratégie réseau de refus. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-bookinfo namespace: default spec: podSelector: matchExpressions: - key: app operator: In values: ["productpage", "details", "reviews", "ratings"] policyTypes: - Ingress - Egress ``` 1. Appliquez la stratégie réseau de refus à votre cluster. ``` kubectl apply -f network-policy-default-deny-bookinfo.yaml ``` 1. Testez l’accès à l’application BookInfo. Dans l’exemple ci-dessous, nous utilisons l’adresse IP du pod productpage (`10.86.2.193`) pour interroger le microservice. Remplacez ceci par l’adresse IP du pod productpage dans votre environnement. ``` curl http://10.86.2.193:9080/productpage --max-time 10 ``` ``` curl: (28) Connection timed out after 10001 milliseconds ``` 1. Créez un fichier nommé `network-policy-productpage.yaml` qui définit la politique réseau de la page produit. La politique prévoit les règles suivantes : + autorise le trafic entrant provenant des pods portant le label `access: true` (le pod curl créé à l’étape précédente) + autorise le trafic TCP sortant sur le port `9080` pour les microservices détaillant les informations, les avis et les évaluations + autorise le trafic TCP/UDP sortant sur le port `53` pour CoreDNS qui s’exécute dans l’espace de noms `kube-system` ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: productpage-policy namespace: default spec: podSelector: matchLabels: app: productpage policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: access: "true" egress: - to: - podSelector: matchExpressions: - key: app operator: In values: ["details", "reviews", "ratings"] ports: - port: 9080 protocol: TCP - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. Appliquez la stratégie réseau de la page produit à votre cluster. ``` kubectl apply -f network-policy-productpage.yaml ``` 1. Connectez-vous au pod curl et testez l’accès à l’application Bookinfo. L’accès au microservice de la page produit est désormais autorisé, mais les autres microservices sont toujours refusés, car ils sont toujours soumis à la politique réseau de refus. Dans les exemples ci-dessous, nous utilisons l’adresse IP du pod productpage (`10.86.2.193`) pour interroger le microservice. Remplacez ceci par l’adresse IP du pod productpage dans votre environnement. ``` kubectl attach curl-pod -c curl-pod -i -t ``` ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" Simple Bookstore App ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1 {"error": "Sorry, product details are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews {"error": "Sorry, product reviews are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings {"error": "Sorry, product ratings are currently unavailable for this book."} ``` 1. Créez un fichier nommé `network-policy-details.yaml` qui définit les détails de la stratégie réseau. La politique autorise uniquement le trafic entrant provenant du microservice productpage. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: details-policy namespace: default spec: podSelector: matchLabels: app: details policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: productpage ``` 1. Créez un fichier nommé `network-policy-reviews.yaml` qui définit la politique réseau des avis. La politique autorise uniquement le trafic entrant provenant du microservice productpage et uniquement le trafic sortant vers le microservice ratings et CoreDNS. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: reviews-policy namespace: default spec: podSelector: matchLabels: app: reviews policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: productpage egress: - to: - podSelector: matchLabels: app: ratings - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. Créez un fichier nommé `network-policy-ratings.yaml` qui définit la politique du réseau de notation. La politique autorise uniquement le trafic entrant provenant des microservices de la page produit et des avis. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ratings-policy namespace: default spec: podSelector: matchLabels: app: ratings policyTypes: - Ingress ingress: - from: - podSelector: matchExpressions: - key: app operator: In values: ["productpage", "reviews"] ``` 1. Appliquez les politiques réseau relatives aux détails, aux avis et aux évaluations à votre cluster. ``` kubectl apply -f network-policy-details.yaml kubectl apply -f network-policy-reviews.yaml kubectl apply -f network-policy-ratings.yaml ``` 1. Connectez-vous au pod curl et testez l’accès à l’application Bookinfo. Dans les exemples ci-dessous, nous utilisons l’adresse IP du pod productpage (`10.86.2.193`) pour interroger le microservice. Remplacez ceci par l’adresse IP du pod productpage dans votre environnement. ``` kubectl attach curl-pod -c curl-pod -i -t ``` Testez les détails du microservice. ``` curl -s http://10.86.2.193:9080/api/v1/products/1 ``` ``` {"id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890"} ``` Testez le microservice des évaluations. ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews ``` ``` {"id": "1", "podname": "reviews-v1-598b896c9d-p2289", "clustername": "null", "reviews": [{"reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"}, {"reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]} ``` Testez le microservice de notation. ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings ``` ``` {"id": 1, "ratings": {"Reviewer1": 5, "Reviewer2": 4}} ``` 1. Nettoyez les ressources que vous avez créées au cours de cette procédure. ``` kubectl delete -f network-policy-deny-bookinfo.yaml kubectl delete -f network-policy-productpage.yaml kubectl delete -f network-policy-details.yaml kubectl delete -f network-policy-reviews.yaml kubectl delete -f network-policy-ratings.yaml kubectl delete -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml kubectl delete pod curl-pod ``` # Concepts pour les nœuds hybrides Avec les *nœuds hybrides Amazon EKS*, vous pouvez connecter des machines physiques ou virtuelles fonctionnant dans des environnements sur site ou en périphérie à des clusters Amazon EKS fonctionnant dans le cloud AWS. Cette approche présente de nombreux avantages, mais introduit également de nouveaux concepts et architectures de réseau pour ceux qui sont habitués à exploiter des clusters Kubernetes dans un environnement réseau unique. Les sections suivantes approfondissent les concepts Kubernetes et réseau pour les nœuds hybrides EKS et détaillent la manière dont le trafic circule à travers l’architecture hybride. Ces sections nécessitent que vous ayez des connaissances de base sur les réseaux Kubernetes, telles que les concepts de pods, de nœuds, de services, du plan de contrôle Kubernetes, de kubelet et de kube-proxy. Nous vous recommandons de lire ces pages dans l’ordre, en commençant par la [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md), puis la [Concepts Kubernetes pour les nœuds hybrides](hybrid-nodes-concepts-kubernetes.md), et enfin la [Flux de trafic réseau pour les nœuds hybrides](hybrid-nodes-concepts-traffic-flows.md). **Topics** + [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md) + [Concepts Kubernetes pour les nœuds hybrides](hybrid-nodes-concepts-kubernetes.md) + [Flux de trafic réseau pour les nœuds hybrides](hybrid-nodes-concepts-traffic-flows.md) # Concepts de mise en réseau pour les nœuds hybrides Cette section détaille les concepts fondamentaux du réseau et les contraintes à prendre en compte lors de la conception de la topologie réseau pour les nœuds hybrides EKS. ## Concepts de mise en réseau pour les nœuds hybrides EKS ![\[Schéma du réseau de nœuds hybrides de haut niveau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png) **Le VPC en tant que hub réseau** Tout le trafic qui traverse les limites du cloud passe par votre VPC. Cela inclut le trafic entre le plan de contrôle EKS ou les pods s'exécutant AWS vers les nœuds hybrides ou les pods exécutés sur ceux-ci. Vous pouvez considérer le VPC de votre cluster comme le hub réseau entre vos nœuds hybrides et le reste du cluster. Cette architecture vous donne un contrôle total sur le trafic et son routage, mais vous rend également responsable de la configuration correcte des routes, des groupes de sécurité et des pare-feu pour le VPC. **Plan de contrôle EKS vers le VPC** Le plan de contrôle EKS attache les **interfaces réseau élastiques (ENIs)** à votre VPC. Ils ENIs gèrent le trafic à destination et en provenance du serveur API EKS. Vous contrôlez le placement du plan de contrôle EKS ENIs lorsque vous configurez votre cluster, car EKS s'attache ENIs aux sous-réseaux que vous transmettez lors de la création du cluster. EKS associe les groupes de sécurité aux groupes ENIs qu'EKS attache à vos sous-réseaux. Ces groupes de sécurité autorisent le trafic à destination et en provenance du plan de contrôle EKS via le ENIs. Ceci est important pour les nœuds hybrides EKS, car vous devez autoriser le trafic provenant des nœuds hybrides et des pods qui s'y exécutent vers le plan de contrôle EKS ENIs. **Réseau de nœuds distants** Les réseaux de nœuds distants, en particulier le nœud distant CIDRs, sont les plages de nœuds IPs attribuées aux machines que vous utilisez en tant que nœuds hybrides. Lorsque vous provisionnez des nœuds hybrides, ceux-ci résident dans votre centre de données sur site ou à la périphérie, qui est un domaine réseau différent du plan de contrôle EKS et du VPC. Chaque nœud hybride possède une ou plusieurs adresses IP provenant d’un CIDR de nœud distant distinct des sous-réseaux de votre VPC. Vous configurez le cluster EKS avec ces nœuds distants CIDRs afin qu'EKS sache qu'il doit acheminer tout le trafic destiné aux nœuds hybrides IPs via le VPC de votre cluster, comme les demandes adressées à l'API kubelet. Les connexions à l'`kubelet`API sont utilisées dans les `kubectl port-forward` commandes `kubectl attach` `kubectl cp``kubectl exec`,`kubectl logs`,, et. **Réseaux de pods distants** Les réseaux de pods distants sont les plages IPs attribuées aux pods exécutés sur les nœuds hybrides. En général, vous configurez votre CNI avec ces plages et la fonctionnalité de gestion des adresses IP (IPAM) du CNI se charge d’attribuer une tranche de ces plages à chaque nœud hybride. Lorsque vous créez un pod, le CNI attribue une adresse IP au pod à partir de la tranche allouée au nœud où le pod a été planifié. Vous configurez le cluster EKS avec ces pods distants CIDRs afin que le plan de contrôle EKS sache qu'il doit acheminer tout le trafic destiné aux pods exécutés sur les nœuds hybrides via le VPC de votre cluster, par exemple pour les communications avec les webhooks. ![\[Réseaux de pods distants\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png) **Sur site, sur le VPC** Le réseau local que vous utilisez pour les nœuds hybrides doit être acheminé vers le VPC que vous utilisez pour votre cluster EKS. Plusieurs [options de connectivité Network-to-Amazon VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) sont disponibles pour connecter votre réseau local à un VPC. Vous pouvez également utiliser votre propre solution VPN. Il est important de configurer correctement le routage côté AWS cloud dans le VPC et dans votre réseau sur site, afin que les deux réseaux acheminent le trafic approprié via la connexion des deux réseaux. Dans le VPC, tout le trafic à destination du nœud distant et des réseaux de pods distants doit transiter par la connexion à votre réseau local (appelée « passerelle »). Si certains de vos sous-réseaux ont des tables de routage différentes, vous devez configurer chaque table de routage avec les routes pour vos nœuds hybrides et les pods qui s’exécutent sur ceux-ci. Cela est vrai pour les sous-réseaux auxquels le plan ENIs de contrôle EKS est attaché, ainsi que pour les sous-réseaux contenant des EC2 nœuds ou des pods devant communiquer avec des nœuds hybrides. Dans votre réseau sur site, vous devez configurer votre réseau pour autoriser le trafic à destination et en provenance du VPC de votre cluster EKS et les AWS autres services requis pour les nœuds hybrides. Le trafic pour le cluster EKS traverse la passerelle dans les deux sens. ## Contraintes du réseau **Réseau entièrement routé** La principale contrainte réside dans le fait que le plan de contrôle EKS et tous les nœuds, qu’ils soient cloud ou hybrides, doivent former un réseau **entièrement routé**. Cela signifie que tous les nœuds doivent pouvoir se joindre mutuellement au niveau de la couche trois, par adresse IP. Le plan de contrôle EKS et les nœuds cloud sont déjà accessibles les uns depuis les autres, car ils se trouvent dans un réseau plat (le VPC). Les nœuds hybrides se trouvent toutefois dans un domaine de réseau différent. C’est pourquoi vous devez configurer un routage supplémentaire dans le VPC et sur votre réseau local afin d’acheminer le trafic entre les nœuds hybrides et le reste du cluster. Si les nœuds hybrides sont accessibles les uns depuis les autres et depuis le VPC, vos nœuds hybrides peuvent se trouver dans un seul réseau plat ou dans plusieurs réseaux segmentés. **Module de télécommande routable CIDRs** Pour que le plan de contrôle EKS puisse communiquer avec les pods s’exécutant sur des nœuds hybrides (par exemple, les webhooks ou le serveur Metrics) ou pour que les pods s’exécutant sur des nœuds cloud puissent communiquer avec les pods s’exécutant sur des nœuds hybrides (communication est-ouest de la charge de travail), votre CIDR de pod distant doit être routable à partir du VPC. Cela signifie que le VPC doit être en mesure d'acheminer le trafic vers le pod CIDRs via la passerelle vers votre réseau local et que votre réseau local doit être en mesure d'acheminer le trafic d'un pod vers le bon nœud. Il est important de noter la distinction entre les exigences de routage des pods dans le VPC et sur site. Le VPC doit uniquement savoir que tout trafic destiné à un pod distant doit passer par la passerelle. Si vous ne possédez qu’un seul CIDR du pod distant, vous n’avez besoin que d’un seul itinéraire. Cette exigence s’applique à tous les sauts de votre réseau local jusqu’au routeur local situé dans le même sous-réseau que vos nœuds hybrides. C’est le seul routeur qui doit connaître la tranche CIDR du pod attribuée à chaque nœud, afin de s’assurer que le trafic destiné à un pod particulier est acheminé vers le nœud où le pod a été planifié. Vous pouvez choisir de propager ces routes pour le pod local CIDRs depuis votre routeur local vers les tables de routage VPC, mais cela n'est pas nécessaire. Si votre espace sur site CIDRs change fréquemment et que vos tables de routage VPC doivent être mises à jour pour refléter le changement d' CIDRsespace, nous vous recommandons de propager l'espace sur site CIDRs vers les tables de routage VPC, mais cela est rare. Notez que la contrainte permettant de rendre votre module local CIDRs routable est facultative. Si vous n'avez pas besoin d'exécuter des webhooks sur vos nœuds hybrides ou de laisser les pods sur les nœuds cloud communiquer avec les pods sur les nœuds hybrides, vous n'avez pas besoin de configurer le routage pour le pod CIDRs sur votre réseau local. *Pourquoi le pod sur site CIDRs doit-il être routable avec des nœuds hybrides ?* Lorsque vous utilisez EKS avec le VPC CNI pour vos nœuds de cloud, le VPC CNI est attribué directement IPs du VPC aux pods. Cela signifie qu'aucun routage spécial n'est nécessaire, car les modules cloud et le plan de contrôle EKS peuvent accéder IPs directement au pod. Lorsqu'ils sont exécutés sur site (et avec d'autres CNIs dans le cloud), les pods s'exécutent généralement sur un réseau superposé isolé et le CNI se charge de distribuer le trafic entre les pods. Cela se fait généralement par le biais de l'encapsulation : le CNI convertit le pod-to-pod trafic en node-to-node trafic, en se chargeant de l'encapsulation et du désencapsulage des deux côtés. De cette manière, aucune configuration supplémentaire n’est nécessaire sur les nœuds et les routeurs. La mise en réseau avec des nœuds hybrides est unique, car elle combine les deux topologies : le plan de contrôle EKS et les nœuds cloud (avec le VPC CNI) s’attendent à un réseau plat comprenant des nœuds et des pods, tandis que les pods s’exécutant sur des nœuds hybrides se trouvent dans un réseau superposé utilisant VXLAN pour l’encapsulation (par défaut dans Cilium). Les pods exécutés sur des nœuds hybrides peuvent atteindre le plan de contrôle EKS et les pods exécutés sur des nœuds cloud, à condition que le réseau local puisse acheminer vers le VPC. Toutefois, sans routage pour le module CIDRs sur le réseau local, tout trafic revenant vers une adresse IP d'espace local sera finalement abandonné si le réseau ne sait pas comment atteindre le réseau superposé et acheminer vers les nœuds appropriés. # Concepts Kubernetes pour les nœuds hybrides Cette page détaille les concepts clés de Kubernetes qui sous-tendent l’architecture système des nœuds hybrides EKS. ## Plan de contrôle EKS dans le VPC Les adresses IP des ENI du plan de contrôle EKS sont stockées dans l’objet `kubernetes` `Endpoints` dans l’espace de noms `default`. Lorsque EKS crée de nouveaux ENI ou supprime les anciens, EKS met à jour cet objet afin que la liste des adresses IP soit toujours à jour. Vous pouvez utiliser ces points de terminaison via le service `kubernetes`, également dans l’espace de noms `default`. Ce service, de type `ClusterIP`, se voit toujours attribuer la première adresse IP du CIDR du service du cluster. Par exemple, pour le service CIDR `172.16.0.0/16`, l’adresse IP du service sera `172.16.0.1`. En général, c’est ainsi que les pods (qu’ils fonctionnent dans le cloud ou sur des nœuds hybrides) accèdent au serveur API EKS Kubernetes. Les pods utilisent l’adresse IP du service comme adresse IP de destination, qui est traduite en adresses IP réelles de l’une des ENI du plan de contrôle EKS. La principale exception est `kube-proxy`, car elle configure la traduction. ## point de terminaison de serveur d’API E L’adresse IP du service `kubernetes` n’est pas le seul moyen d’accéder au serveur API EKS. EKS crée également un nom DNS Route53 lorsque vous créez votre cluster. Il s’agit du champ `endpoint` de votre cluster EKS lorsque vous appelez l’action API `DescribeCluster` EKS. ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` Dans un cluster d’accès aux points de terminaison publics ou d’accès aux points de terminaison publics et privés, vos nœuds hybrides résoudront ce nom DNS en une adresse IP publique par défaut, routable via Internet. Dans un cluster d’accès aux points de terminaison privés, le nom DNS est résolu en adresses IP privées des ENI du plan de contrôle EKS. Voici comment le `kubelet` et `kube-proxy` accèdent au serveur API Kubernetes. Si vous souhaitez que tout le trafic de votre cluster Kubernetes passe par le VPC, vous devez soit configurer votre cluster en mode d’accès privé, soit modifier votre serveur DNS sur site afin de résoudre le point de terminaison du cluster EKS vers les adresses IP privées des ENI du plan de contrôle EKS. ## Point de terminaison `kubelet` Le `kubelet` expose plusieurs points de terminaison REST, permettant à d’autres parties du système d’interagir avec chaque nœud et d’y recueillir des informations. Dans la plupart des clusters, la majorité du trafic vers le serveur `kubelet` provient du plan de contrôle, mais certains agents de surveillance peuvent également interagir avec lui. Grâce à cette interface, le `kubelet` gère diverses requêtes : récupération des journaux (`kubectl logs`), exécution de commandes à l’intérieur des conteneurs (`kubectl exec`) et redirection du trafic (`kubectl port-forward`). Chacune de ces requêtes interagit avec l’exécution de conteneur sous-jacent via `kubelet`, ce qui semble transparent pour les administrateurs de cluster et les développeurs. Le serveur d’API Kubernetes est le serveur d’API Kubernetes. Lorsque vous utilisez l’une des commandes `kubectl` mentionnées précédemment, `kubectl` envoie une requête API au serveur API, qui appelle ensuite l’API `kubelet` du nœud sur lequel le pod est exécuté. C’est la principale raison pour laquelle l’adresse IP du nœud doit être accessible depuis le plan de contrôle EKS et pourquoi, même si vos pods sont en cours d’exécution, vous ne pourrez pas accéder à leurs journaux ou à `exec` si la route du nœud est mal configurée. **IP des nœuds** Lorsque le plan de contrôle EKS communique avec un nœud, il utilise l’une des adresses indiquées dans l’état de l’objet `Node` (`status.addresses`). Avec les nœuds cloud EKS, il est courant que le kubelet signale l’adresse IP privée de l’instance EC2 comme une `InternalIP` lors de l’enregistrement du nœud. Cette adresse IP est ensuite validée par le Cloud Controller Manager (CCM) qui s’assure qu’elle appartient bien à l’instance EC2. De plus, le CCM ajoute généralement les adresses IP publiques (comme `ExternalIP`) et les noms DNS (`InternalDNS` et `ExternalDNS`) de l’instance au statut du nœud. Cependant, il n’existe pas de CCM pour les nœuds hybrides. Lorsque vous enregistrez un nœud hybride avec la CLI des nœuds hybrides EKS (`nodeadm`), celle-ci configure le kubelet pour qu’il signale l’adresse IP de votre machine directement dans l’état du nœud, sans passer par le CCM. ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` Si votre machine dispose de plusieurs adresses IP, le kubelet en sélectionnera une selon sa propre logique. Vous pouvez contrôler l’adresse IP sélectionnée à l’aide du drapeau `--node-ip`, que vous pouvez passer dans la configuration `nodeadm` dans `spec.kubelet.flags`. Seule l’adresse IP indiquée dans l’objet `Node` nécessite une route depuis le VPC. Vos machines peuvent avoir d’autres adresses IP qui ne sont pas accessibles depuis le cloud. ## `kube-proxy` `kube-proxy` est responsable de la mise en œuvre de l’abstraction du service au niveau de la couche réseau de chaque nœud. Il agit comme un proxy réseau et un équilibreur de charge pour le trafic destiné aux services Kubernetes. En surveillant en permanence le serveur API Kubernetes pour détecter les changements liés aux services et aux points de terminaison, `kube-proxy` met à jour de manière dynamique les règles de réseau de l’hôte sous-jacent afin de garantir que le trafic est correctement acheminé. En mode `iptables`, `kube-proxy` programme plusieurs chaînes `netfilter` pour gérer le trafic de service. Les règles forment la hiérarchie suivante : 1. **Chaîne KUBE-SERVICES** : point d’entrée pour tout le trafic de services. Il comporte des règles correspondant à chaque `ClusterIP` et port du service. 1. **Chaînes KUBE-SVC-XXX** : les chaînes spécifiques à un service disposent de règles d’équilibrage de charge pour chaque service. 1. **Chaînes KUBE-SEP-XXX** : les chaînes spécifiques aux points de terminaison contiennent les règles `DNAT` effectives. Examinons ce qui se passe pour un service `test-server` dans l’espace de noms `default` : \$1 Service ClusterIP : `172.16.31.14` \$1 Port du service : `80` \$1 Pods de sauvegarde : `10.2.0.110`, `10.2.1.39`, et `10.2.2.254` Lorsque nous inspectons les règles `iptables` (à l’aide de `iptables-save –0— grep -A10 KUBE-SERVICES`) : 1. Dans la chaîne **KUBE-SERVICES**, nous trouvons une règle correspondant au service : ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + Cette règle correspond aux paquets destinés à 172.16.31.14:80 + Le commentaire indique à quoi sert cette règle : `default/test-server cluster IP` + Les paquets correspondants passent à la chaîne `KUBE-SVC-XYZABC123456` 1. La chaîne **KUBE-SVC-XYZABC123456** dispose de règles d’équilibrage de charge basées sur la probabilité : ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + Première règle : 33,3 % de chances de passer à `KUBE-SEP-POD1XYZABC` + Deuxième règle : 50 % de chances que le trafic restant (33,3 % du total) passe à `KUBE-SEP-POD2XYZABC` + Dernière règle : tout le trafic restant (33,3 % du total) passe à `KUBE-SEP-POD3XYZABC` 1. Les chaînes **KUBE-SEP-XXX** individuelles exécutent le DNAT (Destination NAT) : ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + Ces règles DNAT réécrivent l’adresse IP et le port de destination afin de diriger le trafic vers des pods spécifiques. + Chaque règle gère environ 33,3 % du trafic, assurant ainsi un équilibrage de charge uniforme entre `10.2.0.110`, `10.2.1.39` et `10.2.2.254`. Cette structure en chaîne à plusieurs niveaux permet à `kube-proxy` de mettre en œuvre efficacement l’équilibrage de charge et la redirection des services grâce à la manipulation des paquets au niveau du noyau, sans nécessiter de processus proxy dans le chemin de données. ### Impact sur les opérations Kubernetes Une `kube-proxy` rompu sur un nœud empêche ce dernier d’acheminer correctement le trafic du service, ce qui entraîne des délais d’attente ou des échecs de connexion pour les pods qui dépendent des services du cluster. Cela peut être particulièrement perturbant lors de la première inscription d’un nœud. Le CNI doit communiquer avec le serveur API Kubernetes pour obtenir des informations, telles que le CIDR du pod du nœud, avant de pouvoir configurer le réseau des pods. Pour ce faire, il utilise l’adresse IP du service `kubernetes`. Cependant, si `kube-proxy` n’a pas pu démarrer ou n’a pas réussi à définir les règles `iptables` appropriées, les requêtes envoyées à l’adresse IP du service `kubernetes` ne sont pas traduites en adresses IP réelles des ENI du plan de contrôle EKS. En conséquence, le CNI entrera dans une boucle de crash et aucun des pods ne pourra fonctionner correctement. Nous savons que les pods utilisent l’adresse IP `kubernetes` du service pour communiquer avec le serveur API Kubernetes, mais il faut d’abord que `kube-proxy` définisse des règles `iptables` pour que cela fonctionne. Comment `kube-proxy` communique-t-il avec le serveur API ? Le `kube-proxy` doit être configuré pour utiliser les adresses IP réelles du serveur API Kubernetes ou un nom DNS qui les résout. Dans le cas d’EKS, EKS configure la valeur `kube-proxy` par défaut pour pointer vers le nom DNS Route53 créé par EKS lors de la création du cluster. Vous pouvez voir cette valeur dans le `kube-proxy` ConfigMap dans l’espace de noms `kube-system`. Le contenu de ce ConfigMap est un `kubeconfig` qui est injecté dans le pod `kube-proxy`, recherchez donc le champ `clusters–0—.cluster.server`. Cette valeur correspondra au champ `endpoint` de votre cluster EKS (lorsque vous appelez l’API `DescribeCluster` EKS). ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## CIDR de pods distants routables Cette page [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md) détaille les conditions requises pour exécuter des webhooks sur des nœuds hybrides ou pour que les pods exécutés sur des nœuds cloud communiquent avec les pods exécutés sur des nœuds hybrides. La condition essentielle est que le routeur sur site doit savoir quel nœud est responsable d’une adresse IP de pod particulière. Il existe plusieurs façons d’y parvenir, notamment le protocole de passerelle frontière (BGP), les routes statiques et le proxy ARP (Address Resolution Protocol). Ces points sont abordés dans les sections suivantes. **Protocole de passerelle frontière (BGP)** Si votre CNI le prend en charge (comme Cilium et Calico), vous pouvez utiliser le mode BGP de votre CNI pour propager les routes vers vos CIDR de pod par nœud depuis vos nœuds vers votre routeur local. Lorsque vous utilisez le mode BGP du CNI, votre CNI agit comme un routeur virtuel, de sorte que votre routeur local considère que le CIDR du pod appartient à un sous-réseau différent et que votre nœud est la passerelle vers ce sous-réseau. ![\[Routage BGP des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-bgp.png) **Routes statiques** Vous pouvez également configurer des routes statiques dans votre routeur local. Il s’agit de la méthode la plus simple pour acheminer le CIDR du pod sur site vers votre VPC, mais c’est aussi la plus sujette aux erreurs et la plus difficile à maintenir. Vous devez vous assurer que les routes sont toujours à jour avec les nœuds existants et leurs CIDR de pod attribués. Si votre nombre de nœuds est faible et que votre infrastructure est statique, cette option est viable et élimine le besoin d’une prise en charge BGP dans votre routeur. Si vous optez pour cette solution, nous vous recommandons de configurer votre CNI avec la tranche CIDR du pod que vous souhaitez attribuer à chaque nœud, plutôt que de laisser son IPAM décider. ![\[Routage statique des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **Proxy ARP (Address Resolution Protocol)** Le proxy ARP est une autre approche permettant de rendre routables les adresses IP des pods sur site, particulièrement utile lorsque vos nœuds hybrides se trouvent sur le même réseau de couche 2 que votre routeur local. Lorsque le proxy ARP est activé, un nœud répond aux requêtes ARP pour les adresses IP des pods qu’il héberge, même si ces adresses IP appartiennent à un sous-réseau différent. Lorsqu’un appareil de votre réseau local tente d’atteindre une adresse IP de pod, il envoie d’abord une requête ARP demandant « Qui possède cette adresse IP ? ». Le nœud hybride hébergeant ce pod répondra avec sa propre adresse MAC, indiquant « Je peux gérer le trafic pour cette adresse IP ». Cela crée un chemin direct entre les appareils de votre réseau local et les pods sans nécessiter de configuration du routeur. Pour que cela fonctionne, votre CNI doit prendre en charge la fonctionnalité ARP proxy. Cilium dispose d’un support intégré pour le proxy ARP que vous pouvez activer via la configuration. Le point essentiel à prendre en compte est que le CIDR du pod ne doit pas chevaucher aucun autre réseau de votre environnement, car cela pourrait entraîner des conflits de routage. Cette approche présente plusieurs avantages : \$1 Pas besoin de configurer votre routeur avec BGP ou de maintenir des routes statiques \$1 Fonctionne bien dans les environnements où vous n’avez pas le contrôle sur la configuration de votre routeur ![\[Nœuds hybrides (ARP), proxy\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## Encapsulation de pod à pod Dans les environnements sur site, les CNI utilisent généralement des protocoles d’encapsulation pour créer des réseaux superposés qui peuvent fonctionner au-dessus du réseau physique sans qu’il soit nécessaire de le reconfigurer. Cette section explique comment fonctionne cette encapsulation. Veuillez noter que certains détails peuvent varier en fonction du CNI que vous utilisez. L’encapsulation consiste à envelopper les paquets réseau du pod d’origine dans un autre paquet réseau qui peut être acheminé via le réseau physique sous-jacent. Cela permet aux pods de communiquer entre les nœuds exécutant le même CNI sans que le réseau physique ait besoin de savoir comment acheminer ces CIDR de pod. Le protocole d’encapsulation le plus couramment utilisé avec Kubernetes est le Virtual Extensible LAN (VXLAN), mais d’autres protocoles (tels que `Geneve`) sont également disponibles en fonction de votre CNI. ### Encapsulation VXLAN VXLAN encapsule les trames Ethernet de couche 2 dans des paquets UDP. Lorsqu’un pod envoie du trafic à un autre pod sur un nœud différent, le CNI effectue les opérations suivantes : 1. Le CNI intercepte les paquets provenant du Pod A. 1. Le CNI encapsule le paquet d’origine dans un en-tête VXLAN. 1. Ce paquet encapsulé est ensuite envoyé via la pile réseau standard du nœud vers le nœud de destination. 1. Le CNI sur le nœud de destination déballe le paquet et le transmet au Pod B Voici ce qui arrive à la structure du paquet lors de l’encapsulation VXLAN : Paquet original de pod à pod : ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` Après l’encapsulation VXLAN : ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` L’identifiant réseau VXLAN (VNI) permet de distinguer les différents réseaux superposés. ### Scénarios de communication de pod **Pods sur le même nœud hybride** Lorsque des pods sur le même nœud hybride communiquent, aucune encapsulation n’est généralement nécessaire. Le CNI configure des routes locales qui dirigent le trafic entre les pods via les interfaces virtuelles internes du nœud : ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` Le paquet ne quitte jamais le nœud et ne nécessite pas d’encapsulation. **Pods sur différents nœuds hybrides** La communication entre les pods sur différents nœuds hybrides nécessite une encapsulation : ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` Cela permet au trafic des pods de traverser l’infrastructure réseau physique sans que celle-ci ait besoin de comprendre le routage IP des pods. # Flux de trafic réseau pour les nœuds hybrides Cette page détaille les flux de trafic réseau pour les nœuds hybrides EKS avec des diagrammes montrant les chemins end-to-end réseau pour les différents types de trafic. Les flux de trafic suivants sont couverts : + [Nœud hybride `kubelet` vers plan de contrôle EKS](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [Plan de contrôle EKS vers nœud hybride (serveur `kubelet`)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [Plan de contrôle EKS pour les pods exécutés sur un nœud hybride (webhooks)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [Pod-to-Pod exécution sur des nœuds hybrides](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides (trafic est-ouest)](#hybrid-nodes-concepts-traffic-flows-east-west) ## Nœud hybride `kubelet` vers plan de contrôle EKS ![\[Nœud hybride kubelet vers plan de contrôle EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### Demande **1`kubelet`. Lance une demande** Lorsque `kubelet` sur un nœud hybride doit communiquer avec le plan de contrôle EKS (par exemple, pour signaler l’état du nœud ou obtenir les spécifications du pod), il utilise le `kubeconfig` fourni lors de l’enregistrement du nœud. Ce `kubeconfig` possède l’URL du point de terminaison du serveur API (le nom DNS Route53) plutôt que d’adresses IP directes. Le `kubelet` effectue une recherche DNS pour le point de terminaison (par exemple, `https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com`). Dans un cluster à accès public, cela se résout en une adresse IP publique (par exemple `54.239.118.52`) qui appartient au service EKS s’exécutant dans AWS. Le `kubelet` crée ensuite une requête HTTPS sécurisée vers ce point de terminaison. Le paquet initial ressemble à ceci : ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 52390 (random) | | | Dst: 54.239.118.52 | Dst: 443 | | +--------------------+---------------------+-----------------+ ``` **2. Routage du routeur local** Étant donné que l’adresse IP de destination est une adresse IP publique et ne fait pas partie du réseau sur site, le `kubelet` envoie ce paquet à sa passerelle par défaut (le routeur local sur site). Le routeur examine l’adresse IP de destination et détermine qu’il s’agit d’une adresse IP publique. Pour le trafic public, le routeur transfère généralement le paquet vers une passerelle Internet ou un routeur frontalier qui gère le trafic sortant vers Internet. Ceci n’apparaît pas dans le schéma et dépendra de la configuration de votre réseau sur site. Le paquet traverse votre infrastructure réseau sur site et atteint finalement le réseau de votre fournisseur d’accès Internet. **3. Livraison au plan de commande EKS** Le paquet traverse l'Internet public et les réseaux de transit jusqu'à ce qu' AWS il atteigne le réseau. AWS le réseau achemine le paquet vers le point de terminaison du service EKS dans la région appropriée. Lorsque le paquet atteint le service EKS, il est transféré vers le plan de contrôle EKS réel de votre cluster. Ce routage via l’Internet public est différent du chemin privé routé par VPC que nous verrons dans d’autres flux de trafic. La principale différence réside dans le fait que, lorsque vous utilisez le mode d’accès public, le trafic provenant des `kubelet` locales (mais pas des pods) vers le plan de contrôle EKS ne passe pas par votre VPC, mais utilise plutôt l’infrastructure Internet mondiale. ### Réponse Une fois que le plan de contrôle EKS a traité la demande `kubelet`, il renvoie une réponse : **3. Le plan de contrôle EKS envoie une réponse** Le plan de contrôle EKS crée un paquet de réponse. Ce paquet a l’adresse IP publique comme source et l’adresse IP du nœud hybride comme destination : ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 54.239.118.52 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 52390 | | +--------------------+---------------------+-----------------+ ``` **2. Routage Internet** Le paquet de réponse retourne sur Internet, en suivant le chemin de routage déterminé par les fournisseurs d’accès Internet, jusqu’à ce qu’il atteigne le routeur périphérique de votre réseau sur site. **1. Livraison locale** Votre routeur local reçoit le paquet et reconnaît que l’adresse IP de destination (`10.80.0.2`) appartient à votre réseau sur site. Il transmet le paquet via votre infrastructure réseau locale jusqu’à ce qu’il atteigne le nœud hybride cible, où `kubelet` reçoit et traite la réponse. ## Nœud hybride `kube-proxy` vers plan de contrôle EKS Si vous activez l’accès public aux points de terminaison pour le cluster, le trafic de retour utilise l’Internet public. Ce trafic provient du `kube-proxy` sur le nœud hybride vers le plan de contrôle EKS et suit le même chemin que le trafic provenant du `kubelet` vers le plan de contrôle EKS. ## Plan de contrôle EKS vers nœud hybride (serveur `kubelet`) ![\[Plan de contrôle EKS vers nœud hybride\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### Demande **1. Le serveur d’API EKS Kubernetes lance une demande** Le serveur API EKS Kubernetes extrait l’adresse IP du nœud (`10.80.0.2`) à partir de l’état de l’objet nœud. Il achemine ensuite cette demande via son ENI dans le VPC, car l’adresse IP de destination appartient au nœud distant configuré CIDR (`10.80.0.0/16`). Le paquet initial ressemble à ceci : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 67493 (random) | | | Dst: 10.80.0.2 | Dst: 10250 | | +-----------------+---------------------+-----------------+ ``` **2. Traitement réseau VPC** Le paquet quitte l’ENI et entre dans la couche réseau VPC, où il est dirigé vers la passerelle du sous-réseau pour un routage supplémentaire. **3. Recherche dans une table de routage VPC** La table de routage VPC pour le sous-réseau contenant l’ENI du plan de contrôle EKS dispose d’un itinéraire spécifique (le deuxième dans le diagramme) pour le CIDR du nœud distant. Sur la base de cette règle de routage, le paquet est dirigé vers la VPC-to-onprem passerelle. **4. Transit transfrontalier** La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. **5. Réception réseau sur site** Le paquet arrive à votre routeur local sur site qui gère le trafic pour le sous-réseau où se trouvent vos nœuds hybrides. **6. Livraison finale** Le routeur local identifie que l’adresse IP (`10.80.0.2`) de destination appartient à son réseau directement connecté et transfère le paquet directement au nœud hybride cible, où le `kubelet` reçoit et traite la requête. ### Réponse Une fois que le nœud hybride `kubelet` a traité la demande, il renvoie une réponse en suivant le même chemin en sens inverse : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 10250 | | | Dst: 10.0.0.132 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **6. `kubelet` Envoie une réponse** `kubelet`Le nœud hybride (`10.80.0.2`) crée un paquet de réponse avec l’adresse IP source d’origine comme destination. La destination n’appartenant pas au réseau local, elle est envoyée à la passerelle par défaut de l’hôte, qui est le routeur local. **5. Routage du routeur local** Le routeur détermine que l’adresse IP de destination (`10.0.0.132`) appartient à `10.0.0.0/16`, qui dispose d’une route pointant vers la passerelle connectée à AWS. **4. Retour transfrontalier** Le paquet retourne par la même connexion locale vers VPC (telle que Direct Connect ou VPN), franchissant la limite du cloud dans le sens inverse. **3. Routage VPC** Lorsque le paquet arrive dans le VPC, les tables de routage identifient que l’adresse IP de destination appartient à un CIDR VPC. Les acheminements de paquets au sein du VPC. **2. Livraison de réseaux VPC** La couche réseau VPC transmet le paquet au sous-réseau avec le plan de contrôle EKS ENI (`10.0.0.132`). **1. Réception ENI** Le paquet atteint le plan de contrôle EKS ENI connecté au serveur API Kubernetes, achevant ainsi son aller-retour. ## Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS ![\[Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### Sans CNI NAT ### Demande Les pods communiquent généralement avec le serveur API Kubernetes via le service `kubernetes`. L’adresse IP du service est la première adresse IP du service CIDR du cluster. Cette convention permet aux pods qui doivent s’exécuter avant que CoreDNS soit disponible d’accéder au serveur API, par exemple le CNI. Les demandes quittent le pod avec l’adresse IP du service comme destination. Par exemple, si le CIDR du service est `172.16.0.0/16`, l’adresse IP du service sera `172.16.0.1`. **1. Le module lance une demande** Le pod envoie une requête à l’adresse IP `kubernetes` du service ()`172.16.0.1` sur le port (443) du serveur API à partir d’un port source aléatoire. Le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. Traitement CNI** Le CNI détecte que l’adresse IP de destination n’appartient à aucun des pods CIDR qu’il gère. Comme le **NAT sortant est désactivé**, le CNI transmet le paquet à la pile réseau hôte sans le modifier. **3. Traitement du réseau de nœuds** Le paquet entre dans la pile réseau du nœud où des hooks `netfilter` déclenchent les règles `iptables` définies par kube-proxy. Plusieurs règles s’appliquent dans l’ordre suivant : 1. Le paquet atteint d’abord la chaîne `KUBE-SERVICES`, qui contient les règles correspondant à l’adresse IP du cluster et au port de chaque service. 1. La règle de correspondance passe à la chaîne `KUBE-SVC-XXX` pour le service `kubernetes` (paquets destinés à `172.16.0.1:443`), qui contient les règles d’équilibrage de charge. 1. La règle d'équilibrage de charge sélectionne aléatoirement l'une des `KUBE-SEP-XXX` chaînes pour le plan de commande ENI IPs (`10.0.0.132`or`10.0.1.23`). 1. La chaîne `KUBE-SEP-XXX` sélectionnée possède la règle réelle qui change l’adresse IP de destination de l’adresse IP du service à l’adresse IP sélectionnée. C’est ce qu’on appelle la traduction d’adresses réseau de destination (DNAT). Une fois ces règles appliquées, en supposant que l’adresse IP de l’ENI du plan de contrôle EKS sélectionné soit `10.0.0.132`, le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Le nœud transmet le paquet à sa passerelle par défaut car l’adresse IP de destination ne se trouve pas sur le réseau local. **4. Routage du routeur local** Le routeur local détermine que l’adresse IP de destination (`10.0.0.132`) appartient au CIDR VPC (`10.0.0.0/16`) et la transfère vers la passerelle connectée à AWS. **5. Transit transfrontalier** Le paquet passe par votre connexion établie (telle que Direct Connect ou VPN) à travers la limite du cloud jusqu’au VPC. **6. Livraison de réseaux VPC** La couche réseau VPC achemine le paquet vers le sous-réseau approprié où se trouve l’ENI (`10.0.0.132`) du plan de contrôle EKS. **7. Réception ENI** Le paquet atteint le plan de contrôle EKS ENI attaché au serveur d’API Kubernetes. ### Réponse Une fois que le plan de contrôle EKS a traité la demande, il renvoie une réponse au pod : **7. Le serveur API envoie une réponse** Le serveur d’API EKS Kubernetes crée un paquet de réponse avec l’adresse IP source d’origine comme destination. Le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` Comme l’adresse IP de destination appartient au pod distant CIDR (`10.85.0.0/16`) configuré, il l’envoie via son ENI dans le VPC avec le routeur du sous-réseau comme saut suivant. **6. Routage VPC** La table de routage VPC contient une entrée pour le pod distant CIDR (`10.85.0.0/16`), qui dirige ce trafic vers la passerelle. VPC-to-onprem **5. Transit transfrontalier** La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. **4. Réception réseau sur site** Le paquet arrive à votre routeur local sur site. **3. Livraison au nœud** La table du routeur contient une entrée pour `10.85.1.0/24` avec `10.80.0.2` comme prochain saut, livrant le paquet à notre nœud. **2. Traitement du réseau de nœuds** Lorsque le paquet est traité par la pile réseau du nœud, `conntrack` (une partie de `netfilter`) correspond au paquet avec la connexion initialement établie par le pod. Depuis l’application initiale du DNAT, `conntrack` inverse le DNAT en réécrivant l’adresse IP source de l’ENI du plan de contrôle EKS vers l’adresse IP `kubernetes` du service : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. Traitement CNI** Le CNI identifie que l’adresse IP de destination appartient à un pod de son réseau et achemine le paquet vers l’espace de noms réseau du pod approprié. Ce flux montre pourquoi Remote Pod CIDRs doit être correctement routable depuis le VPC jusqu'au nœud spécifique hébergeant chaque pod. Le chemin de retour complet dépend du routage correct du pod sur les réseaux cloud et IPs sur site. ### Avec CNI NAT Ce flux est très similaire à celui *sans CNI NAT*, mais avec une différence essentielle : le CNI applique le NAT source (SNAT) au paquet avant de l’envoyer à la pile réseau du nœud. Cela modifie l’adresse IP source du paquet pour la remplacer par l’adresse IP du nœud, ce qui permet au paquet d’être renvoyé vers le nœud sans nécessiter de configuration de routage supplémentaire. ### Demande **1. Le module lance une demande** Le pod envoie une requête à l’adresse IP `kubernetes` du service ()`172.16.0.1` sur le port (443) du serveur API EKS Kubernetes à partir d’un port source aléatoire. Le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. Traitement CNI** Le CNI détecte que l’adresse IP de destination n’appartient à aucun des pods CIDR qu’il gère. Comme le **NAT sortant est activé**, le CNI applique le SNAT au paquet, en remplaçant l’adresse IP source par celle du nœud avant de le transmettre à la pile réseau du nœud : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Remarque : CNI et CNI `iptables` sont présentés dans l'exemple sous forme de blocs séparés pour plus de clarté, mais dans la pratique, il est possible que certains CNIs utilisent le NAT `iptables` pour appliquer le NAT. **3. Traitement du réseau de nœuds** Ici, les `iptables` règles définies par `kube-proxy` se comportent de la même manière que dans l'exemple précédent, en équilibrant la charge du paquet sur l'un des plans de contrôle EKS ENIs. Le paquet se présente maintenant comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` Le nœud transmet le paquet à sa passerelle par défaut car l’adresse IP de destination ne se trouve pas sur le réseau local. **4. Routage du routeur local** Le routeur local détermine que l’adresse IP de destination (`10.0.0.132`) appartient au CIDR VPC (`10.0.0.0/16`) et la transfère vers la passerelle connectée à AWS. **5. Transit transfrontalier** Le paquet passe par votre connexion établie (telle que Direct Connect ou VPN) à travers la limite du cloud jusqu’au VPC. **6. Livraison de réseaux VPC** La couche réseau VPC achemine le paquet vers le sous-réseau approprié où se trouve l’ENI (`10.0.0.132`) du plan de contrôle EKS. **7. Réception ENI** Le paquet atteint le plan de contrôle EKS ENI attaché au serveur d’API Kubernetes. ### Réponse Une fois que le plan de contrôle EKS a traité la demande, il renvoie une réponse au pod : **7. Le serveur API envoie une réponse** Le serveur d’API EKS Kubernetes crée un paquet de réponse avec l’adresse IP source d’origine comme destination. Le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` Comme l’adresse IP de destination appartient au nœud distant CIDR (`10.80.0.0/16`) configuré, il l’envoie via son ENI dans le VPC avec le routeur du sous-réseau comme saut suivant. **6. Routage VPC** La table de routage VPC contient une entrée pour le nœud distant CIDR (`10.80.0.0/16`), qui dirige ce trafic vers la passerelle. VPC-to-onprem **5. Transit transfrontalier** La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. **4. Réception réseau sur site** Le paquet arrive à votre routeur local sur site. **3. Livraison au nœud** Le routeur local identifie que l’adresse IP (`10.80.0.2`) de destination appartient à son réseau directement connecté et transfère le paquet directement au nœud hybride cible. **2. Traitement du réseau de nœuds** Lorsque le paquet est traité par la pile réseau du nœud, `conntrack` (une partie de `netfilter`) correspond au paquet avec la connexion initialement établie par le pod et, comme le DNAT a été appliqué à l’origine, il inverse cette opération en réécrivant l’adresse IP source de l’ENI du plan de contrôle EKS vers l’adresse IP du service `kubernetes` : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. Traitement CNI** Le CNI identifie que ce paquet appartient à une connexion à laquelle il a précédemment appliqué le SNAT. Il inverse le SNAT, remplaçant l’adresse IP de destination par l’adresse IP du pod : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` Le CNI détecte que l’adresse IP de destination appartient à un pod de son réseau et achemine le paquet vers l’espace de noms réseau du pod approprié. Ce flux montre comment CNI Nat-ing peut simplifier la configuration en permettant le renvoi des paquets vers le nœud sans nécessiter de routage supplémentaire pour le pod. CIDRs ## Plan de contrôle EKS pour les pods exécutés sur un nœud hybride (webhooks) ![\[Plan de contrôle EKS pour les pods exécutés sur un nœud hybride\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) Ce modèle de trafic est le plus souvent observé avec les webhooks, où le plan de contrôle EKS doit initier directement des connexions vers les serveurs webhooks s’exécutant dans des pods sur des nœuds hybrides. Parmi les exemples, citons la validation et la mutation des webhooks d’admission, qui sont appelés par le serveur API pendant les processus de validation ou de mutation des ressources. ### Demande **1. Le serveur d’API EKS Kubernetes lance une demande** Lorsqu’un webhook est configuré dans le cluster et qu’une opération API pertinente le déclenche, le serveur API EKS Kubernetes doit établir une connexion directe avec le pod du serveur webhook. Le serveur API recherche d’abord l’adresse IP du pod à partir de la ressource Service ou Endpoint associée au webhook. En supposant que le pod webhook s’exécute sur un nœud hybride avec l’adresse IP `10.85.1.23`, le serveur API Kubernetes EKS crée une requête HTTPS vers le point de terminaison webhook. Le paquet initial est envoyé via l’ENI du plan de contrôle EKS dans votre VPC, car l’adresse IP de destination `10.85.1.23` appartient au CIDR du pod distant configuré (`10.85.0.0/16`). Le paquet se présente comme suit : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 41892 (random) | | | Dst: 10.85.1.23 | Dst: 8443 | | +-----------------+---------------------+-----------------+ ``` **2. Traitement réseau VPC** Le paquet quitte l’ENI du plan de contrôle EKS et entre dans la couche réseau VPC avec le routeur du sous-réseau comme prochain saut. **3. Recherche dans une table de routage VPC** La table de routage VPC pour le sous-réseau contenant l’ENI du plan de contrôle EKS contient une route spécifique pour le CIDR du pod distant (`10.85.0.0/16`). Cette règle de routage dirige le paquet vers la VPC-to-onprem passerelle (par exemple, une passerelle privée virtuelle pour les connexions Direct Connect ou VPN) : ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` **4. Transit transfrontalier** La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. Le paquet conserve ses adresses IP source et de destination d’origine lorsqu’il traverse cette connexion. **5. Réception réseau sur site** Le paquet arrive à votre routeur local sur site. Le routeur consulte sa table de routage pour déterminer comment atteindre l’adresse 10.85.1.23. Pour que cela fonctionne, votre réseau local doit disposer de routes pour le pod CIDRs qui dirigent le trafic vers le nœud hybride approprié. Dans ce cas, la table de routage du routeur contient une entrée indiquant que le sous-réseau `10.85.1.0/24` est accessible via le nœud hybride avec l’adresse IP `10.80.0.2` : ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **6. Livraison au nœud** Sur la base de l’entrée de la table de routage, le routeur transmet le paquet au nœud hybride (`10.80.0.2`). Lorsque le paquet arrive au nœud, il a le même aspect que lorsqu’il a été envoyé par le serveur API EKS Kubernetes, l’adresse IP de destination étant toujours celle du pod. **7. Traitement CNI** La pile réseau du nœud reçoit le paquet et, constatant que l’adresse IP de destination n’est pas celle du nœud, le transmet au CNI pour traitement. Le CNI identifie que l’adresse IP de destination appartient à un pod s’exécutant localement sur ce nœud et transfère le paquet vers le pod correct via les interfaces virtuelles appropriées : ``` Original packet -> node routing -> CNI -> Pod's network namespace ``` Le serveur Webhook du pod reçoit la demande et la traite. ### Réponse Une fois que le pod webhook a traité la requête, il renvoie une réponse en suivant le même chemin en sens inverse : **7. Le pod envoie une réponse** Le pod webhook crée un paquet de réponse avec sa propre adresse IP comme source et le demandeur d’origine (l’ENI du plan de contrôle EKS) comme destination : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.23 | Src: 8443 | | | Dst: 10.0.0.132 | Dst: 41892 | | +-----------------+---------------------+-----------------+ ``` Le CNI identifie que ce paquet est destiné à un réseau externe (et non à un pod local) et le transmet à la pile réseau du nœud en conservant l’adresse IP source d’origine. **6. Traitement du réseau de nœuds** Le nœud détermine que l’adresse IP de destination (`10.0.0.132`) ne se trouve pas dans le réseau local et transfère le paquet vers sa passerelle par défaut (le routeur local). **5. Routage du routeur local** Le routeur local consulte sa table de routage et détermine que l’adresse IP de destination (`10.0.0.132`) appartient au CIDR VPC (`10.0.0.0/16`). Il transfère le paquet vers la passerelle connectée à AWS. **4. Transit transfrontalier** Le paquet retourne par la même connexion locale vers VPC, traversant la limite du cloud dans le sens inverse. **3. Routage VPC** Lorsque le paquet arrive dans le VPC, les tables de routage identifient que l’adresse IP de destination appartient à un sous-réseau au sein du VPC. Le paquet est acheminé en conséquence au sein du VPC. **2. et 1. Plan de commande EKS ENI Receiption** Le paquet atteint l’ENI rattaché au serveur API EKS Kubernetes, complétant ainsi l’aller-retour. Le serveur API reçoit la réponse du webhook et continue à traiter la requête API initiale en fonction de cette réponse. Ce flux de trafic montre pourquoi le module distant CIDRs doit être correctement configuré et routé : + Le VPC doit disposer de routes pour le pod distant CIDRs pointant vers la passerelle sur site + Votre réseau sur site doit disposer de routes pour les pods CIDRs qui dirigent le trafic vers les nœuds spécifiques hébergeant ces pods + Sans cette configuration de routage, les webhooks et autres services similaires s’exécutant dans des pods sur des nœuds hybrides ne seraient pas accessibles depuis le plan de contrôle EKS. ## Pod-to-Pod exécution sur des nœuds hybrides ![\[Pod-to-Pod s’exécutant sur des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) Cette section explique comment les pods s’exécutant sur différents nœuds hybrides communiquent entre eux. Cet exemple suppose que votre CNI utilise VXLAN pour l'encapsulation, ce qui est courant pour Cilium CNIs ou Calico. Le processus global est similaire pour d'autres protocoles d'encapsulation tels que Geneve ou. IP-in-IP ### Demande **1. Le pod A initie la communication** Le Pod A (`10.85.1.56`) sur le Nœud 1 souhaite envoyer du trafic vers le Pod B (`10.85.2.67`) sur le Nœud 2. Le paquet initial ressemble à ceci : ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` **2. CNI intercepte et traite le paquet** Lorsque le paquet du pod A quitte son espace de noms réseau, le CNI l’intercepte. Le CNI consulte sa table de routage et détermine : – L’adresse IP de destination (`10.85.2.67`) appartient au CIDR du pod – Cette adresse IP ne se trouve pas sur le nœud local, mais appartient au nœud 2 (`10.80.0.3`) – Le paquet doit être encapsulé avec VXLAN. La décision d'encapsuler est essentielle car le réseau physique sous-jacent ne sait pas comment acheminer CIDRs directement le pod. Il sait uniquement comment acheminer le trafic entre les nœuds IPs. Le CNI encapsule l’intégralité du paquet d’origine dans une trame VXLAN. Cela crée effectivement un « paquet dans un paquet » avec de nouveaux en-têtes : ``` +-----------------+----------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node1 MAC | Src: 10.80.0.2 | Src: Random | VNI: 42 | Packet (unchanged | | Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472 | | from above) | +-----------------+----------------+--------------+------------+---------------------------+ ``` Points clés concernant cette encapsulation : – Le paquet externe est adressé du nœud 1 (`10.80.0.2`) au nœud 2 (`10.80.0.3`) – Le port UDP `8472` est le port VXLAN utilisé par défaut par Cilium – L’identifiant de réseau VXLAN (VNI) identifie le réseau superposé auquel appartient ce paquet – Le paquet d’origine complet (avec l’adresse IP du pod A comme source et l’adresse IP du pod B comme destination) est conservé intact à l’intérieur Le paquet encapsulé entre alors dans la pile réseau normale du nœud 1 et est traité de la même manière que n’importe quel autre paquet : 1. **Traitement du réseau de nœuds** : la pile réseau du nœud 1 achemine le paquet en fonction de sa destination (`10.80.0.3`) 1. **Livraison sur le réseau local** : + Si les deux nœuds sont sur le même réseau de couche 2, le paquet est envoyé directement au nœud 2 + S’ils se trouvent sur des sous-réseaux différents, le paquet est d’abord transféré au routeur local 1. **Gestion du routeur** : le routeur transmet le paquet en fonction de sa table de routage et le livre au nœud 2 **3. Traitement des nœuds de réception** Lorsque le paquet encapsulé arrive au nœud 2 (`10.80.0.3`) : 1. La pile réseau du nœud le reçoit et l’identifie comme un paquet VXLAN (port UDP `4789`) 1. Le paquet est transmis à l’interface VXLAN du CNI pour traitement **4. Décapsulation VXLAN** Le CNI sur le nœud 2 traite le paquet VXLAN : 1. Il supprime les en-têtes extérieurs (Ethernet, IP, UDP et VXLAN) 1. Il extrait le paquet intérieur d’origine 1. Le paquet a maintenant retrouvé sa forme d’origine : ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` Le CNI du nœud 2 examine l’adresse IP de destination (`10.85.2.67`) et : 1. Identifie que cette adresse IP appartient à un pod local 1. Achemine le paquet via les interfaces virtuelles appropriées 1. Fournit le paquet à l’espace de noms réseau du Pod B ### Réponse Lorsque le Pod B répond au Pod A, l’ensemble du processus se déroule en sens inverse : 1. Le Pod B envoie un paquet au Pod A (`10.85.1.56`) 1. Le CNI du nœud 2 l’encapsule avec VXLAN, en définissant la destination sur le nœud 1 (`10.80.0.2`) 1. Le paquet encapsulé est livré au nœud 1 1. Le CNI du nœud 1 le décapsule et fournit la réponse initiale au module A ## Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides (trafic est-ouest) ![\[Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### Demande **1. Le module A initie la communication** Le pod A (`10.0.0.56`) sur le EC2 nœud souhaite envoyer du trafic vers le pod B (`10.85.1.56`) sur le nœud hybride. Le paquet initial ressemble à ceci : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.56 | Src: 52390 (random) | | | Dst: 10.85.1.56 | Dst: 8080 | | +-----------------+---------------------+-----------------+ ``` Avec le VPC CNI, le Pod A possède une adresse IP provenant du VPC CIDR et est directement attaché à un ENI sur l'instance. EC2 L’espace de noms réseau du pod est connecté au réseau VPC, de sorte que le paquet entre directement dans l’infrastructure de routage VPC. **2. Routage VPC** La table de routage VPC contient une route spécifique pour le Remote Pod CIDR (`10.85.0.0/16`), dirigeant ce trafic vers la passerelle : VPC-to-onprem ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` Sur la base de cette règle de routage, le paquet est dirigé vers la passerelle qui se connecte à votre réseau sur site. **3. Transit transfrontalier** La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. Le paquet conserve ses adresses IP source et destination d’origine tout au long de ce transit. **4. Réception réseau sur site** Le paquet arrive à votre routeur local sur site. Le routeur consulte sa table de routage pour déterminer le prochain saut permettant d’atteindre l’adresse 10.85.1.56. Votre routeur local doit disposer de routes pour le pod CIDRs qui dirigent le trafic vers le nœud hybride approprié. La table du routeur contient une entrée indiquant que le sous-réseau `10.85.1.0/24` est accessible via le nœud hybride avec l’adresse IP `10.80.0.2` : ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **5. Traitement du réseau de nœuds** Le routeur transmet le paquet au nœud hybride (`10.80.0.2`). Lorsque le paquet arrive au nœud, il a toujours l’adresse IP du pod A comme source et celle du pod B comme destination. **6. Traitement CNI** La pile réseau du nœud reçoit le paquet et, constatant que l’adresse IP de destination n’est pas la sienne, le transmet au CNI pour traitement. Le CNI identifie que l’adresse IP de destination appartient à un pod s’exécutant localement sur ce nœud et transfère le paquet vers le pod correct via les interfaces virtuelles appropriées : ``` Original packet -> node routing -> CNI -> Pod B's network namespace ``` Le pod B reçoit le paquet et le traite selon les besoins. ### Réponse **6. Le pod B envoie une réponse** Le pod B crée un paquet de réponse avec sa propre adresse IP comme source et celle du pod A comme destination : ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 8080 | | | Dst: 10.0.0.56 | Dst: 52390 | | +-----------------+---------------------+-----------------+ ``` Le CNI identifie que ce paquet est destiné à un réseau externe et le transmet à la pile réseau du nœud. **5. Traitement du réseau de nœuds** Le nœud détermine que l’adresse IP de destination (`10.0.0.56`) n’appartient pas au réseau local et transfère le paquet vers sa passerelle par défaut (le routeur local). **4. Routage du routeur local** Le routeur local consulte sa table de routage et détermine que l’adresse IP de destination (`10.0.0.56`) appartient au CIDR VPC (`10.0.0.0/16`). Il transfère le paquet vers la passerelle connectée à AWS. **3. Transit transfrontalier** Le paquet retourne par la même connexion locale vers VPC, traversant la limite du cloud dans le sens inverse. **2. Routage VPC** Lorsque le paquet arrive dans le VPC, le système de routage identifie que l’adresse IP de destination appartient à un sous-réseau au sein du VPC. Le paquet est acheminé via le réseau VPC vers l'instance hébergeant EC2 le Pod A. **1. Le pod A reçoit une réponse** Le paquet arrive à l' EC2 instance et est livré directement au Pod A via son ENI attaché. Étant donné que le CNI VPC n’utilise pas de réseau superposé pour les pods dans le VPC, aucune décapsulation supplémentaire n’est nécessaire : le paquet arrive avec ses en-têtes d’origine intacts. Ce flux de trafic est-ouest montre pourquoi le module distant CIDRs doit être correctement configuré et routable dans les deux sens : + Le VPC doit disposer de routes pour le pod distant CIDRs pointant vers la passerelle sur site + Votre réseau local doit disposer de routes pour les pods CIDRs qui dirigent le trafic vers les nœuds spécifiques hébergeant ces pods. # Référence des nœuds hybrides `nodeadm` L’interface CLI nœuds hybrides Amazon EKS (`nodeadm`) simplifie l’installation, la configuration, l’enregistrement et la désinstallation des composants des nœuds hybrides. Vous pouvez inclure `nodeadm` dans votre système d’exploitation des images permettant d’automatiser le démarrage des nœuds hybrides. Pour plus d’informations, consultez [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md). La `nodeadm` version pour les nœuds hybrides est différente de la `nodeadm` version utilisée pour démarrer les EC2 instances Amazon en tant que nœuds dans des clusters Amazon EKS. Suivez la documentation et les références correspondant à la version `nodeadm` appropriée. Cette page de documentation concerne la version `nodeadm` des nœuds hybrides. Le code source des nœuds hybrides `nodeadm` est publié dans le référentiel https://github.com/aws/ eks-hybridGitHub . **Important** Vous devez exécuter `nodeadm` avec un utilisateur qui possède root/sudo des privilèges. ## Télécharger `nodeadm` La version des nœuds hybrides de `nodeadm` est hébergée sur Amazon S3, géré par Amazon CloudFront. Pour installer `nodeadm` sur chaque hôte sur site, vous pouvez exécuter la commande suivante à partir de vos hôtes sur site. **Pour les hôtes x86\$164** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Pour les hôtes ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Ajoutez les permissions d’exécution au fichier binaire téléchargé sur chaque hôte. ``` chmod +x nodeadm ``` ## `nodeadm install` La commande `nodeadm install` permet d’installer les artefacts et les dépendances nécessaires pour exécuter et joindre des nœuds hybrides à un cluster Amazon EKS. La commande `nodeadm install` peut être exécutée individuellement sur chaque nœud hybride ou pendant les pipelines de création d’images afin de préinstaller les dépendances des nœuds hybrides dans les images du système d’exploitation. **Utilisation** ``` nodeadm install [KUBERNETES_VERSION] [flags] ``` **Arguments positionnels** (Obligatoire) `KUBERNETES_VERSION` La version majeure.mineure d’EKS Kubernetes à installer, par exemple `1.32` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-p`, `--credential-provider` | TRUE | Fournisseur d’informations d’identification à installer. Les valeurs prises en charge sont `iam-ra` et `ssm`. Pour plus d’informations, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). | | `-s`, `--containerd-source` | FALSE | Source pour `containerd`. `nodeadm` prend en charge l’installation de `containerd` à partir de la distribution du système d’exploitation, des paquets Docker et le saute l’installation de `containerd`. **Valeurs** `distro`- Il s'agit de la valeur par défaut. `nodeadm`installera le dernier `containerd` package distribué par le système d'exploitation du nœud compatible avec la version EKS Kubernetes. `distro`n'est pas une valeur prise en charge pour les systèmes d'exploitation Red Hat Enterprise Linux (RHEL). `docker`- `nodeadm` installera le dernier `containerd` package créé et distribué par Docker compatible avec la version EKS Kubernetes. `docker`n'est pas une valeur prise en charge pour Amazon Linux 2023. `none` : `nodeadm` n’installera pas le paquet `containerd`. Vous devez installer `containerd` manuellement avant d’exécuter `nodeadm init`. | | `-r`, `--region` | FALSE | Spécifie la AWS région pour le téléchargement d'artefacts tels que l'agent SSM. La valeur par défaut est `us-west-2` . | | `-t`, `--timeout` | FALSE | Durée maximale de la commande d’installation. La saisie suit le format de durée. Par exemple `1h23m`. Le délai d’expiration par défaut pour le téléchargement de la commande d’installation est fixé à 20 minutes. | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | **Exemples** Installez la version Kubernetes avec AWS Systems `1.32` Manager (SSM) comme fournisseur d'informations d'identification ``` nodeadm install 1.32 --credential-provider ssm ``` Installez la version Kubernetes avec AWS Systems `1.32` Manager (SSM) comme fournisseur d'informations d'identification, Docker comme source containerd, avec un délai de téléchargement de 20 minutes. ``` nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m ``` Installez la version Kubernetes `1.32` avec AWS IAM Roles Anywhere comme fournisseur d'informations d'identification ``` nodeadm install 1.32 --credential-provider iam-ra ``` ## `nodeadm config check` La commande `nodeadm config check` vérifie la configuration du nœud fourni afin de détecter d’éventuelles erreurs. Cette commande peut être utilisée pour vérifier et valider l’exactitude d’un fichier de configuration de nœud hybride. **Utilisation** ``` nodeadm config check [flags] ``` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Source de la configuration nodeadm. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | **Exemples** ``` nodeadm config check -c file://nodeConfig.yaml ``` ## `nodeadm init` La commande `nodeadm init` démarre et connecte le nœud hybride au cluster Amazon EKS configuré. Consultez [Configuration des nœuds pour les activations hybrides SSM](#hybrid-nodes-node-config-ssm) ou [Configuration des nœuds pour Rôles Anywhere IAM](#hybrid-nodes-node-config-iamra) pour plus de détails sur la configuration du fichier `nodeConfig.yaml`. **Utilisation** ``` nodeadm init [flags] ``` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. | | `-s`, `--skip` | FALSE | Phases de `init` à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème. **Valeurs** `install-validation` ignore la vérification du bon déroulement de la commande d’installation précédente. `cni-validation` ignore la vérification de l’ouverture des ports VXLAN de Cilium ou Calico CNI si le pare-feu est activé sur le nœud `node-ip-validation` ignore la vérification si l’adresse IP du nœud se trouve dans un CIDR dans les réseaux de nœuds distants | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | **Exemples** ``` nodeadm init -c file://nodeConfig.yaml ``` ## `nodeadm upgrade` La commande `nodeadm upgrade` met à niveau tous les artefacts installés vers la dernière version et amorce le nœud pour configurer les artefacts mis à niveau et rejoindre le cluster EKS sur AWS. La mise à niveau est une commande perturbatrice pour les charges de travail exécutées sur le nœud. Veuillez déplacer vos charges de travail vers un autre nœud avant de lancer la mise à niveau. **Utilisation** ``` nodeadm upgrade [KUBERNETES_VERSION] [flags] ``` **Arguments positionnels** (Obligatoire) `KUBERNETES_VERSION` La version majeure.mineure d’EKS Kubernetes à installer, par exemple `1.32` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. | | `-t`, `--timeout` | FALSE | Délai d’attente pour le téléchargement des artefacts. La saisie suit le format de durée. Par exemple 1 h 23 min. Le délai d’expiration par défaut pour le téléchargement de la commande de mise à niveau est défini sur 10 minutes. | | `-s`, `--skip` | FALSE | Phases de mise à niveau à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème. **Valeurs** `pod-validation` ignore la vérification si tous les pods ne sont pas en cours d’exécution sur le nœud, à l’exception des ensembles de démons et des pods statiques. `node-validation` ignore la vérification si le nœud a été bouclé. `init-validation` ignore la vérification de l’initialisation réussie du nœud avant d’exécuter la mise à niveau. `containerd-major-version-upgrade`empêche les mises à niveau des versions majeures de containerd lors de la mise à niveau du nœud. | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | **Exemples** ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml ``` ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m ``` ## `nodeadm uninstall` La commande `nodeadm uninstall` arrête et supprime les artefacts que `nodeadm` installe pendant `nodeadm install`, y compris kubelet et containerd. Remarque : La commande de désinstallation ne vide pas et ne supprime pas vos nœuds hybrides de votre cluster. Vous devez exécuter les opérations de vidage et de suppression séparément. Pour plus d’informations, consultez [Supprimer les nœuds hybrides](hybrid-nodes-remove.md). Par défaut, `nodeadm uninstall` ne continuera pas s’il reste des pods sur le nœud. De même, `nodeadm uninstall` ne supprime pas les dépendances CNI ni les dépendances d’autres modules complémentaires Kubernetes que vous exécutez sur votre cluster. Pour supprimer complètement l’installation CNI de votre hôte, consultez les instructions à l’adresse [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). Si vous utilisez des activations hybrides AWS SSM comme fournisseur d'informations d'identification sur site, la `nodeadm uninstall` commande annule l'enregistrement de vos hôtes en tant qu'instances gérées par SSM. AWS **Utilisation** ``` nodeadm uninstall [flags] ``` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-s`, `--skip` | FALSE | Phases de désinstallation à ignorer. Il n’est pas recommandé de sauter l’une des phases, sauf si cela permet de résoudre un problème. **Valeurs** `pod-validation` ignore la vérification si tous les pods ne sont pas en cours d’exécution sur le nœud, à l’exception des ensembles de démons et des pods statiques. `node-validation` ignore la vérification si le nœud a été bouclé. `init-validation` ignore la vérification de l’initialisation réussie du nœud avant d’exécuter la désinstallation. | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | | `-f`, `--force` | FALSE | Supprimer de force les répertoires supplémentaires qui pourraient contenir des fichiers restants provenant des composants Kubernetes et CNI. **WARNING** Cela supprimera tout le contenu des répertoires Kubernetes et CNI par défaut (`/var/lib/cni`, `/etc/cni/net.d`, etc.). N’utilisez pas cet indicateur si vous stockez vos propres données à ces emplacements. À partir de nodeadm `v1.0.9`, la commande `./nodeadm uninstall --skip node-validation,pod-validation --force` ne supprime plus le répertoire `/var/lib/kubelet`. En effet, il peut contenir des volumes Pod et des répertoires volume-subpath qui incluent parfois le système de fichiers du nœud monté. **Conseils pour une manipulation en toute sécurité** – La suppression des chemins montés peut entraîner la suppression accidentelle du système de fichiers du nœud monté. Avant de supprimer manuellement le répertoire `/var/lib/kubelet`, inspectez soigneusement tous les montages actifs et démontez les volumes en toute sécurité afin d’éviter toute perte de données. | **Exemples** ``` nodeadm uninstall ``` ``` nodeadm uninstall --skip node-validation,pod-validation ``` ## `nodeadm debug` La commande `nodeadm debug` peut être utilisée pour dépanner les nœuds hybrides défectueux ou mal configurés. Il vérifie que les exigences suivantes sont respectées. + Le nœud dispose d'un accès réseau aux informations requises AWS APIs pour obtenir les informations d'identification, + Le nœud est en mesure d'obtenir des AWS informations d'identification pour le rôle IAM des nœuds hybrides configuré, + Le nœud dispose d’un accès réseau au point de terminaison de l’API EKS Kubernetes et la validité du certificat du point de terminaison de l’API EKS Kubernetes, + Le nœud est capable de s’authentifier auprès du cluster EKS, son identité dans le cluster est valide et le nœud a accès au cluster EKS via le VPC configuré pour le cluster EKS. Si des erreurs sont détectées, la sortie de la commande suggère des étapes de dépannage. Certaines étapes de validation affichent les processus enfants. Si celles-ci échouent, le résultat s’affiche dans une section stderr sous l’erreur de validation. **Utilisation** ``` nodeadm debug [flags] ``` **Indicateurs** | Name | Obligatoire | Description | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Source de la configuration `nodeadm`. Pour les nœuds hybrides, l’entrée doit suivre un URI avec un schéma de fichier. | | `--no-color` | FALSE | Désactive la sortie couleur. Utile pour l’automatisation. | | `-h`, `--help` | FALSE | Affiche un message d’aide avec les paramètres disponibles pour les métriques, les sous-commandes et les valeurs positionnelles. | **Exemples** ``` nodeadm debug -c file://nodeConfig.yaml ``` ## Emplacements des fichiers Nodeadm ### nodeadm installer Lors de l’exécution `nodeadm install`, les fichiers et emplacements de fichiers suivants sont configurés. | Artefact | Chemin | | --- | --- | | CLI Rôles Anywhere IAM | /usr/local/bin/aws\$1assistant à la signature | | Kubelet binaire | /usr/bin/kubelet | | Kubectl binaire | usr/local/bin/kubectl | | Fournisseur d’informations d’identification ECR | /etc/eks/image-credential-provider/ecr-fournisseur d'informations d'identification | | AWS Authentificateur IAM | /usr/local/bin/aws-iam-authentificateur | | Configuration SSM CLI | /opt/ssm/ssm-setup-cli | | SSM Agent | Sur Ubuntu -/snap/amazon-ssm-agent/current/amazon-ssm-agent Sur RHEL et AL2 023 -/-ssm-agent usr/bin/amazon | | Containerd | Sur Ubuntu et AL2 023 -/usr/bin/containerd Sur RHEL : /bin/containerd | | iptables | Sur Ubuntu et AL2 023 -/usr/sbin/iptables Sur RHEL : /sbin/iptables | | Plug-ins CNI | /opt/cni/bin | | suivi des artefacts installés | /opt/nodeadm/tracker | ### nodeadm init Lors de l’exécution de `nodeadm init`, les fichiers et emplacements de fichiers suivants sont configurés. | Name | Chemin | | --- | --- | | Kubelet kubeconfig | /var/lib/kubelet/kubeconfig | | Configuration Kubelet | /etc/kubernetes/kubelet/config.json | | Unité de système Kubelet | /etc/systemd/system/kubelet.service | | Configuration du fournisseur d’informations d’identification d’image | /etc/eks/image-credential-provider/config.json | | Fichier d’environnement Kubelet | /etc/eks/kubelet/environment | | Certificats Kubelet | /etc/kubernetes/pki/ca.crt | | Config de Containerd | /etc/containerd/config.toml | | Configuration des modules du noyau Containerd | /etc/modules-load.d/contianerd.conf | | AWS fichier de configuration | /etc/aws/hybrid/config | | AWS fichier d'informations d'identification (si le fichier d'informations d'identification est activé) | /eks-hybrid/.aws/identifiants | | AWS unité système d'aide à la signature | /etc/systemd/system/aws\$1signing\$1helper\$1update.service | | fichier de configuration sysctl | /etc/sysctl.d/99-nodeadm.conf | | Ca-certificates | /etc/ssl/certs/ca-certificates.crt | | Fichier de clé Gpg | /etc/apt/keyrings/docker.asc | | Fichier source du dépôt Docker | /etc/apt/sources.list.d/docker.liste | ## Configuration des nœuds pour les activations hybrides SSM Voici un exemple `nodeConfig.yaml` d'utilisation des activations hybrides AWS SSM pour les informations d'identification des nœuds hybrides. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## Configuration des nœuds pour Rôles Anywhere IAM Voici un `nodeConfig.yaml` exemple d'identifiant AWS IAM Roles Anywhere pour les nœuds hybrides. Lorsque vous utilisez AWS IAM Roles Anywhere comme fournisseur d'informations d'identification sur site, celles que `nodeName` vous utilisez dans votre `nodeadm` configuration doivent correspondre aux autorisations que vous avez définies pour votre rôle IAM Hybrid Nodes. Par exemple, si vos autorisations pour le rôle IAM de Hybrid Nodes autorisent uniquement AWS IAM Roles Anywhere à assumer le rôle lorsque le nom de session du rôle est égal au CN du certificat hôte, le `nodeName` CN de votre `nodeadm` configuration doit être le même que le CN de vos certificats. Le `nodeName` que vous utilisez ne peut pas dépasser 64 caractères. Pour de plus amples informations, veuillez consulter [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: iamRolesAnywhere: nodeName: # Name of the node trustAnchorArn: # ARN of the IAM Roles Anywhere trust anchor profileArn: # ARN of the IAM Roles Anywhere profile roleArn: # ARN of the Hybrid Nodes IAM role certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor privateKeyPath: # Path to the private key file for the certificate ``` ## Configuration du nœud pour personnaliser kubelet (facultatif) Vous pouvez transmettre la configuration et les métriques kubelet dans votre configuration `nodeadm`. Consultez l’exemple ci-dessous pour savoir comment ajouter une étiquette de nœud `abc.amazonaws.com/test-label` supplémentaire et configurer `shutdownGracePeriod` sur 30 secondes. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides kubelet: config: # Map of kubelet config and values shutdownGracePeriod: 30s flags: # List of kubelet flags - --node-labels=abc.company.com/test-label=true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## Configuration du nœud pour personnaliser containerd (facultatif) Vous pouvez passer une configuration containerd personnalisée dans votre configuration `nodeadm`. La configuration containerd pour `nodeadm` accepte TOML en ligne. Consultez l’exemple ci-dessous pour savoir comment configurer containerd afin de désactiver la suppression des couches d’image décompressées dans le magasin de contenu containerd. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri".containerd] discard_unpacked_layers = false hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` **Note** Les versions 1.x et 2.x de Containerd utilisent différents formats de configuration. Containerd 1.x utilise la version de configuration 2, tandis que containerd 2.x utilise la version de configuration 3. Bien que containerd 2.x reste rétrocompatible avec la version 2 de configuration, la version 3 de configuration est recommandée pour des performances optimales. Vérifiez la version de votre containerd `containerd --version` ou consultez les journaux d'`nodeadm`installation. Pour plus de détails sur la gestion des versions de configuration, consultez https://containerd.io/releases/ Vous pouvez également utiliser la configuration containerd pour activer SELinux le support. SELinux Lorsque cette option est activée sur containerd, assurez-vous que les pods planifiés sur le nœud disposent du SecurityContext approprié et sont activés. seLinuxOptions Vous trouverez plus d’informations sur la configuration d’un contexte de sécurité dans la [documentation Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). **Note** Red Hat Enterprise Linux (RHEL) 8 et RHEL 9 sont SELinux activés par défaut et définis sur strict sur l'hôte. Amazon Linux 2023 est SELinux activé par défaut et est réglé sur le mode permissif. Lorsqu'il SELinux est défini sur le mode permissif sur l'hôte, son activation sur containerd ne bloquera pas les demandes mais les enregistrera conformément à la SELinux configuration de l'hôte. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri"] enable_selinux = true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` # Dépannage des nœuds hybrides Cette rubrique traite de certaines erreurs courantes que vous pouvez rencontrer lors de l’utilisation des nœuds hybrides Amazon EKS et explique comment les résoudre. Pour d'autres informations de dépannage, consultez le [Résolution des problèmes liés aux clusters et aux nœuds Amazon EKS](troubleshooting.md) [tag Knowledge Center pour Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) sur * AWS Re:Post*. Si vous ne parvenez pas à résoudre le problème, contactez AWS le Support. **Dépannage des nœuds avec `nodeadm debug`**. Vous pouvez exécuter la commande `nodeadm debug` à partir de vos nœuds hybrides pour vérifier que les exigences en matière de réseau et d’informations d’identification sont respectées. Pour plus d’informations sur la commande `nodeadm debug`, voir [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). **Détectez les problèmes liés à vos nœuds hybrides grâce aux informations sur les clusters** Les informations sur les clusters Amazon EKS comprennent des *vérifications* qui détectent les problèmes courants liés à la configuration des nœuds hybrides EKS dans votre cluster. Vous pouvez consulter les résultats de toutes les vérifications d'aperçu à partir de la AWS Management Console AWS CLI et du AWS SDKs. Pour plus d’informations sur les informations relatives aux clusters, consultez [Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters](cluster-insights.md). ## Dépannage de l’installation de nœuds hybrides Les rubriques de dépannage suivantes concernent l’installation des dépendances des nœuds hybrides sur les hôtes à l’aide de la commande `nodeadm install`. **`nodeadm` échec de la commande `must run as root`** La commande `nodeadm install` doit être exécutée avec un utilisateur disposant de droits root ou de `sudo` privilèges sur votre hôte. Si vous exécutez `nodeadm install` avec un utilisateur qui ne dispose pas des droits root ou des privilèges `sudo`, vous verrez l’erreur suivante dans la sortie `nodeadm`. ``` "msg":"Command failed","error":"must run as root" ``` **Impossible de se connecter aux dépendances** La commande `nodeadm install` installe les dépendances requises pour les nœuds hybrides. Les dépendances des nœuds hybrides incluent`containerd`, `kubelet``kubectl`, et les composants AWS SSM ou AWS IAM Roles Anywhere. Vous devez avoir accès à partir de l’endroit où vous exécutez `nodeadm install` pour télécharger ces dépendances. Pour plus d’informations sur la liste des emplacements auxquels vous devez pouvoir accéder, consultez [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). Si vous n’y avez pas accès, vous verrez des erreurs similaires à celles-ci dans la sortie `nodeadm install`. ``` "msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request" ``` **Impossible de mettre à jour le gestionnaire de paquets** La commande `nodeadm install` exécute `apt update`, `yum update` ou `dnf update` avant l’installation des dépendances des nœuds hybrides. Si cette étape échoue, vous pourriez voir apparaître des erreurs similaires à celles ci-dessous. Pour remédier à cette situation, vous pouvez exécuter `apt update`, `yum update` ou `dnf update` avant l’exécution de `nodeadm install` ou essayer de réexécuter `nodeadm install`. ``` failed to run update using package manager ``` **Délai d’expiration ou délai de mise en contexte dépassé** Lors de l’exécution de `nodeadm install`, si vous constatez des problèmes à différentes étapes du processus d’installation avec des erreurs indiquant un délai d’attente ou une limite de contexte dépassée, il se peut que votre connexion soit trop lente et empêche l’installation des dépendances des nœuds hybrides avant l’expiration des délais d’attente. Pour contourner ces problèmes, vous pouvez essayer d’utiliser la balise `--timeout` dans `nodeadm` afin de prolonger la durée des délais d’attente pour le téléchargement des dépendances. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s ``` ## Dépannage des problèmes liés à la connexion Les rubriques de résolution des problèmes de cette section concernent le processus de connexion des nœuds hybrides aux clusters EKS à l’aide de la commande `nodeadm init`. **Erreurs de fonctionnement ou schéma non pris en charge** Lors de l’exécution `nodeadm init`, si vous voyez des erreurs liées à `operation error` ou `unsupported scheme`, vérifiez votre `nodeConfig.yaml` pour vous assurer qu’il est correctement formaté et transmis à `nodeadm`. Pour plus d’informations sur le format et les options disponibles pour `nodeConfig.yaml`, consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). ``` "msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded" ``` **Nœuds hybrides (rôle IAM) : autorisations manquantes pour l’action `eks:DescribeCluster`** Lors de l'exécution`nodeadm init`, `nodeadm` tente de recueillir des informations sur votre cluster EKS en appelant l'`DescribeCluster`action EKS. Si votre rôle IAM Hybrid Nodes n'est pas autorisé à effectuer cette `eks:DescribeCluster` action, vous devez transmettre le point de terminaison de l'API Kubernetes, le bundle CA du cluster et le IPv4 CIDR du service dans la configuration du nœud à laquelle vous passez lors de l'exécution. `nodeadm` `nodeadm init` Pour plus d’informations sur les autorisations requises pour le rôle IAM des nœuds hybrides, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). ``` "msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException" ``` **Nœuds hybrides (rôle IAM) : autorisations manquantes pour l’action `eks:ListAccessEntries`** Lors de l'exécution`nodeadm init`, `nodeadm` tente de valider si votre cluster EKS possède une entrée d'accès de type `HYBRID_LINUX` associée au rôle IAM des nœuds hybrides en appelant l'`ListAccessEntries`action EKS. Si votre rôle IAM Hybrid Nodes n'est pas autorisé à `eks:ListAccessEntries` effectuer cette action, vous devez passer le `--skip cluster-access-validation` drapeau lorsque vous exécutez la `nodeadm init` commande. Pour plus d’informations sur les autorisations requises pour le rôle IAM des nœuds hybrides, consultez [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md). ``` "msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException" ``` **L’adresse IP du nœud ne figure pas dans le réseau de nœuds distants CIDR** Lors de l'exécution`nodeadm init`, vous pouvez rencontrer une erreur si l'adresse IP du nœud ne se trouve pas dans le réseau de nœuds distants spécifié CIDRs. L’erreur ressemblera à l’exemple suivant : ``` node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16] ``` Cet exemple montre un nœud dont l'adresse IP est 10.18.0.1 qui tente de rejoindre un cluster doté du réseau distant CIDRs 10.0.0.0/16 et 192.168.0.0/16. L’erreur se produit car 10.18.0.1 ne se situe dans aucune des plages. Vérifiez que vous avez correctement configuré votre adresse IP `RemoteNodeNetworks` pour inclure toutes les adresses IP des nœuds. Pour plus d’informations sur la configuration réseau, voir [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Exécutez la commande suivante dans la région où se trouve votre cluster pour vérifier vos configurations `RemoteNodeNetwork`. Vérifiez que les blocs CIDR répertoriés dans la sortie incluent la plage IP de votre nœud et correspondent aux blocs CIDR répertoriés dans le message d’erreur. Si elles ne correspondent pas, vérifiez que le nom du cluster et la région dans votre `nodeConfig.yaml` correspondent bien au cluster souhaité. ``` aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks ``` + Vérifiez que vous travaillez avec le nœud prévu : + Vérifiez que vous êtes sur le bon nœud en vérifiant que son nom d’hôte et son adresse IP correspondent à ceux que vous souhaitez enregistrer auprès du cluster. + Vérifiez que ce nœud se trouve dans le bon réseau sur site (celui dont la plage CIDR a été enregistrée en tant que `RemoteNodeNetwork` lors de la configuration du cluster). Si l’adresse IP de votre nœud ne correspond toujours pas à ce que vous attendiez, vérifiez les points suivants : + Si vous utilisez Rôles Anywhere IAM, `kubelet` effectue une recherche DNS sur Rôles Anywhere IAM `nodeName` et utilise une adresse IP associée au nom du nœud, le cas échéant. Si vous conservez des entrées DNS pour vos nœuds, vérifiez qu'elles pointent vers l' IPs intérieur de votre réseau de nœuds distants CIDRs. + Si votre nœud possède plusieurs interfaces réseau, vous `kubelet` pouvez sélectionner une interface avec une adresse IP en dehors du réseau CIDRs de votre nœud distant par défaut. Pour utiliser une interface différente, spécifiez son adresse IP à l’aide de la balise `--node-ip` `kubelet` dans votre fichier `nodeConfig.yaml`. Pour de plus amples informations, veuillez consulter [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). Vous pouvez consulter les interfaces réseau et les adresses IP de votre nœud en exécutant la commande suivante sur votre nœud : ``` ip addr show ``` **Les nœuds hybrides n’apparaissent pas dans le cluster EKS** Si vous avez exécuté `nodeadm init` et qu’il s’est terminé, mais que vos nœuds hybrides n’apparaissent pas dans votre cluster, il se peut qu’il y ait des problèmes avec la connexion réseau entre vos nœuds hybrides et le plan de contrôle EKS, que vous n’ayez pas configuré les autorisations requises pour le groupe de sécurité ou que vous n’ayez pas effectué le mappage requis entre le rôle IAM de vos nœuds hybrides et le contrôle d’accès basé sur les rôles (RBAC) de Kubernetes. Vous pouvez lancer le processus de débogage en vérifiant l’état de `kubelet` et des journaux `kubelet` à l’aide des commandes suivantes. Exécutez les commandes suivantes à partir des nœuds hybrides qui n’ont pas réussi à rejoindre votre cluster. ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **Impossible de communiquer avec le cluster** Si votre nœud hybride n’a pas pu communiquer avec le plan de contrôle du cluster, des journaux similaires aux suivants peuvent s’afficher. ``` "Failed to ensure lease exists, will retry" err="Get ..." ``` ``` "Unable to register node with API server" err="Post ..." ``` ``` Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout ``` Si vous voyez ces messages, vérifiez les points suivants pour vous assurer qu’ils répondent aux exigences relatives aux nœuds hybrides détaillées dans [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). + Vérifiez que le VPC transmis au cluster EKS possède des itinéraires vers votre Transit Gateway (TGW) ou votre passerelle privée virtuelle (VGW) pour votre nœud sur site et éventuellement votre pod. CIDRs + Vérifiez que vous disposez d'un groupe de sécurité supplémentaire pour votre cluster EKS et que des règles d'entrée s'appliquent à votre nœud local CIDRs et, éventuellement, à votre pod. CIDRs + Vérifiez que votre routeur sur site est configuré pour autoriser le trafic vers et depuis le plan de contrôle EKS. **Non autorisé** Si votre nœud hybride a pu communiquer avec le plan de contrôle EKS mais n’a pas pu s’enregistrer, vous pouvez voir des journaux similaires à ceux ci-dessous. Notez que la principale différence dans les messages du journal ci-dessous réside dans l’erreur `Unauthorized`. Cela indique que le nœud n’a pas pu exécuter ses tâches car il ne dispose pas des autorisations requises. ``` "Failed to ensure lease exists, will retry" err="Unauthorized" ``` ``` "Unable to register node with API server" err="Unauthorized" ``` ``` Failed to contact API server when waiting for CSINode publishing: Unauthorized ``` Si vous voyez ces messages, vérifiez les éléments suivants pour vous assurer qu’ils répondent aux exigences relatives aux nœuds hybrides détaillées dans [Préparer les informations d’identification pour les nœuds hybrides](hybrid-nodes-creds.md) et [Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). + Vérifiez que l’identité des nœuds hybrides correspond au rôle IAM des nœuds hybrides que vous attendiez. Pour ce faire, exécutez `sudo aws sts get-caller-identity` depuis vos nœuds hybrides. + Vérifiez que votre rôle IAM des nœuds hybrides dispose des autorisations requises. + Vérifiez que dans votre cluster, vous disposez d'une entrée d'accès EKS pour votre rôle IAM Hybrid Nodes ou confirmez que vous disposez d'`aws-auth` ConfigMap une entrée pour votre rôle IAM Hybrid Nodes. Si vous utilisez des entrées d’accès EKS, vérifiez que votre entrée d’accès pour votre rôle IAM des nœuds hybrides dispose du type d’accès `HYBRID_LINUX`. Si vous utilisez le `aws-auth` ConfigMap, confirmez que votre entrée pour le rôle Hybrid Nodes IAM répond aux exigences et au format détaillés dans[Préparation de l’accès au cluster pour les nœuds hybrides](hybrid-nodes-cluster-prep.md). ### Nœuds hybrides enregistrés dans le cluster EKS mais affichant l’état `Not Ready` Si vos nœuds hybrides se sont correctement enregistrés auprès de votre cluster EKS, mais qu’ils affichent l’état `Not Ready`, la première chose à vérifier est l’état de votre interface réseau de conteneur (CNI). Si vous n’avez pas installé de CNI, vos nœuds hybrides devraient avoir le statut `Not Ready`. Une fois qu’un CNI est installé et fonctionne correctement, les nœuds sont mis à jour vers le statut `Ready`. Si vous avez essayé d’installer un CNI mais qu’il ne fonctionne pas correctement, consultez [Dépannage des nœuds hybrides CNI](#hybrid-nodes-troubleshooting-cni) sur cette page. **Les demandes de signature de certificat (CSRs) sont bloquées en attente** Après avoir connecté des nœuds hybrides à votre cluster EKS, si vous constatez que CSRs des nœuds hybrides sont en attente, cela signifie que ceux-ci ne répondent pas aux exigences d'approbation automatique. CSRs pour les nœuds hybrides sont automatiquement approuvés et émis si les CSRs nœuds hybrides ont été créés par un nœud portant une `eks.amazonaws.com/compute-type: hybrid` étiquette, et que le CSR possède les noms alternatifs de sujet suivants (SANs) : au moins un SAN DNS égal au nom du nœud et l'adresse IP SANs appartient au réseau de nœuds distants CIDRs. **Le profil hybride existe déjà** Si vous avez modifié votre configuration `nodeadm` et que vous essayez de réenregistrer le nœud avec la nouvelle configuration, vous pouvez obtenir une erreur indiquant que le profil hybride existe déjà, mais que son contenu a été modifié. Au lieu d’exécuter `nodeadm init` entre les changements de configuration, exécutez `nodeadm uninstall` suivi d’un `nodeadm install` et `nodeadm init`. Cela garantit un nettoyage correct lors des changements de configuration. ``` "msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration" ``` **Le nœud hybride n’a pas réussi à résoudre l’API privée** Après l’exécution `nodeadm init`, si vous constatez une erreur dans les journaux `kubelet` indiquant des échecs de connexion au serveur API EKS Kubernetes en raison de la présence de `no such host`, vous devrez peut-être modifier votre entrée DNS pour le point de terminaison API EKS Kubernetes dans votre réseau sur site ou au niveau de l’hôte. Consultez la section [Transfert de requêtes DNS entrantes vers votre VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) dans * AWS la* documentation de Route53. ``` Failed to contact API server when waiting for CSINode publishing: Get ... no such host ``` **Impossible d’afficher les nœuds hybrides dans la console EKS** Si vous avez enregistré vos nœuds hybrides mais que vous ne parvenez pas à les afficher dans la console EKS, vérifiez les autorisations du principal IAM que vous utilisez pour afficher la console. Le principal IAM que vous utilisez doit disposer d’autorisations IAM et Kubernetes minimales spécifiques pour afficher les ressources dans la console. Pour de plus amples informations, veuillez consulter [Consultez les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md). ## Résolution des problèmes d’exécution de nœuds hybrides Si vos nœuds hybrides enregistrés dans votre cluster EKS avaient le statut `Ready`, puis sont passés au statut `Not Ready`, plusieurs problèmes peuvent avoir contribué à ce statut non fonctionnel, par exemple un manque de ressources CPU, de mémoire ou d’espace disque disponible, ou une déconnexion du nœud du plan de contrôle EKS. Vous pouvez suivre les étapes ci-dessous pour dépanner vos nœuds, et si vous ne parvenez pas à résoudre le problème, contactez le AWS Support. Exécutez `nodeadm debug` à partir de vos nœuds hybrides pour vérifier que les exigences en matière de réseau et d’informations d’identification sont satisfaites. Pour plus d’informations sur la commande `nodeadm debug` , consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). **Obtenir le statut du nœud** ``` kubectl get nodes -o wide ``` **Vérifiez les conditions et les événements du nœud** ``` kubectl describe node NODE_NAME ``` **Obtenir le statut du pod** ``` kubectl get pods -A -o wide ``` **Vérifiez l’état et les événements du pod** ``` kubectl describe pod POD_NAME ``` **Vérifiez les journaux du pod** ``` kubectl logs POD_NAME ``` **Vérifiez les journaux `kubectl`** ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **Les sondes de durée de vie du pod échouent ou les webhooks ne fonctionnent pas** Si les applications, les modules complémentaires ou les webhooks exécutés sur vos nœuds hybrides ne démarrent pas correctement, vous rencontrez peut-être des problèmes de réseau qui bloquent la communication avec les pods. Pour que le plan de contrôle EKS puisse contacter les webhooks exécutés sur des nœuds hybrides, vous devez configurer votre cluster EKS avec un réseau de pods distant et disposer de routes pour votre CIDR de pod sur site dans votre table de routage VPC, avec comme cible votre Transit Gateway (TGW), votre passerelle privée virtuelle (VPW) ou toute autre passerelle que vous utilisez pour connecter votre VPC à votre réseau sur site. Pour plus d’informations sur les exigences réseau pour les nœuds hybrides, voir [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). Vous devez également autoriser ce trafic dans votre pare-feu local et vous assurer que votre routeur peut acheminer correctement le trafic vers vos pods. Pour plus d’informations sur les conditions requises pour exécuter des webhooks sur des nœuds hybrides, consultez [Configurer les webhooks pour les nœuds hybrides](hybrid-nodes-webhooks.md). Un message de journal de pod courant pour ce scénario est présenté ci-dessous, où l’adresse IP correspond à l’adresse IP du cluster pour le service Kubernetes. ``` dial tcp :443: connect: no route to host ``` **`kubectl logs`ou `kubectl exec` les commandes ne fonctionnent pas (commandes `kubelet` API)** Si`kubectl attach`,`kubectl cp`, `kubectl exec``kubectl logs`, et `kubectl port-forward` les commandes expirent alors que `kubectl` les autres commandes réussissent, le problème est probablement lié à la configuration du réseau distant. Ces commandes se connectent via le cluster au point de terminaison `kubelet` sur le nœud. Pour de plus amples informations, veuillez consulter [Point de terminaison `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api). Vérifiez que votre nœud IPs et votre pod font IPs partie du réseau de nœuds distants et du réseau de nœuds distants CIDRs configurés pour votre cluster. Utilisez les commandes ci-dessous pour examiner les attributions d’adresses IP. ``` kubectl get nodes -o wide ``` ``` kubectl get pods -A -o wide ``` IPs Comparez-les avec votre réseau distant configuré CIDRs pour garantir un routage correct. Pour les exigences de configuration réseau, voir [Préparer la mise en réseau pour les nœuds hybrides](hybrid-nodes-networking.md). ## Dépannage des nœuds hybrides CNI Si vous rencontrez des problèmes lors du démarrage initial de Cilium ou Calico avec des nœuds hybrides, cela est le plus souvent dû à des problèmes de réseau entre les nœuds hybrides ou les pods CNI s’exécutant sur les nœuds hybrides et le plan de contrôle EKS. Assurez-vous que votre environnement répond aux exigences de la section Préparer le réseau pour les nœuds hybrides. Il est utile de décomposer le problème en plusieurs parties. Configuration du cluster EKS Les RemotePodNetwork configurations RemoteNodeNetwork et sont-elles correctes ? Configuration VPC Existe-t-il des itinéraires pour RemoteNodeNetwork et RemotePodNetwork dans la table de routage VPC avec la cible du Transit Gateway ou de la Virtual Private Gateway ? Configuration du groupe de sécurité Existe-t-il des règles d'entrée et de sortie pour le RemoteNodeNetwork et ? RemotePodNetwork Réseau local Existe-t-il des routes et des accès vers et depuis le plan de contrôle EKS, ainsi que vers et depuis les nœuds hybrides et les pods fonctionnant sur des nœuds hybrides ? Configuration CNI Si vous utilisez un réseau superposé, la configuration du pool IP pour le CNI correspond-elle à celle RemotePodNetwork configurée pour le cluster EKS si vous utilisez des webhooks ? **Le nœud hybride a un statut `Ready` sans CNI installé** Si vos nœuds hybrides affichent le statut `Ready`, mais que vous n’avez pas installé de CNI sur votre cluster, il est possible que d’anciens artefacts CNI soient présents sur vos nœuds hybrides. Par défaut, lorsque vous désinstallez Cilium et Calico à l’aide d’outils tels que Helm, les ressources sur disque ne sont pas supprimées de vos machines physiques ou virtuelles. En outre, les définitions de ressources personnalisées (CRDs) correspondantes CNIs peuvent toujours être présentes sur votre cluster à partir d'une ancienne installation. Pour plus d’informations, consultez les sections Supprimer Cilium et Supprimer Calico de [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). **Résolution des problèmes liés à Cilium** Si vous rencontrez des problèmes lors de l’exécution de Cilium sur des nœuds hybrides, consultez les [étapes de dépannage](https://docs.cilium.io/en/stable/operations/troubleshooting/) dans la documentation Cilium. Les sections ci-dessous traitent des problèmes qui peuvent être propres au déploiement de Cilium sur des nœuds hybrides. **Cilium ne démarre pas** Si les agents Cilium qui s’exécutent sur chaque nœud hybride ne démarrent pas, vérifiez les journaux des pods de l’agent Cilium pour détecter d’éventuelles erreurs. L’agent Cilium nécessite une connexion au point de terminaison API EKS Kubernetes pour démarrer. Le démarrage de l’agent Cilium échouera si cette connectivité n’est pas correctement configurée. Dans ce cas, vous verrez des messages de journal similaires aux suivants dans les journaux du pod de l’agent Cilium. ``` msg="Unable to contact k8s api-server" level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ``` L’agent Cilium s’exécute sur le réseau hôte. Votre cluster EKS doit être configuré avec `RemoteNodeNetwork` pour la connectivité Cilium. Vérifiez que vous disposez d’un groupe de sécurité supplémentaire pour votre cluster EKS avec une règle entrante pour votre `RemoteNodeNetwork`, que vous disposez de routes dans votre VPC pour votre `RemoteNodeNetwork`, et que votre réseau sur site est correctement configuré pour permettre la connectivité au plan de contrôle EKS. Si l'opérateur Cilium est en cours d'exécution et que certains de vos agents Cilium sont en cours d'exécution, mais pas tous, vérifiez que vous disposez d'un pod disponible IPs à allouer pour tous les nœuds de votre cluster. Vous configurez la taille de votre pod allouable CIDRs lorsque vous utilisez le pool de clusters IPAM `clusterPoolIPv4PodCIDRList` dans votre configuration Cilium. La taille CIDR par nœud est configurée à l’aide du paramètre `clusterPoolIPv4MaskSize` dans votre configuration Cilium. Voir [Extension du pool de clusters](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) dans la documentation de Cilium pour plus d’informations. **Cilium BGP ne fonctionne pas** Si vous utilisez le plan de contrôle Cilium BGP pour annoncer les adresses de vos pods ou services à votre réseau sur site, vous pouvez utiliser les commandes CLI Cilium suivantes pour vérifier si BGP annonce les routes vers vos ressources. Pour connaître les étapes d’installation de la CLI Cilium, consultez la section [Installer la CLI Cilium dans la](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) documentation de Cilium. Si BGP fonctionne correctement, vous devez indiquer l’état de session de vos nœuds hybrides `established` dans la sortie. Vous devrez peut-être collaborer avec votre équipe réseau afin d’identifier les valeurs correctes pour l’AS local, l’AS pair et l’adresse pair de votre environnement. ``` cilium bgp peers ``` ``` cilium bgp routes ``` Si vous utilisez Cilium BGP pour faire IPs de la publicité pour des Services par type`LoadBalancer`, vous devez avoir la même étiquette sur votre produit `CiliumLoadBalancerIPPool` et sur le Service, qui doit être utilisée dans le sélecteur de votre. `CiliumBGPAdvertisement` Un exemple est illustré ci-dessous. Notez que si vous utilisez Cilium BGP pour promouvoir les services avec type LoadBalancer, les IPs routes BGP peuvent être perturbées lors du redémarrage de l'agent Cilium. Pour plus d’informations, consultez la section [Scénarios de défaillance](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) dans la documentation Cilium. **Service** ``` kind: Service apiVersion: v1 metadata: name: guestbook labels: app: guestbook spec: ports: - port: 3000 targetPort: http-server selector: app: guestbook type: LoadBalancer ``` **CiliumLoadBalancerIPPool** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: guestbook-pool labels: app: guestbook spec: blocks: - cidr: serviceSelector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **CiliumBGPAdvertisement** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisements-guestbook labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - ExternalIP - LoadBalancerIP selector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **Résolution des problèmes liés à Calico** Si vous rencontrez des problèmes lors de l’exécution de Calico sur des nœuds hybrides, consultez les [étapes de dépannage](https://docs.tigera.io/calico/latest/operations/troubleshoot/) dans la documentation Calico. Les sections ci-dessous traitent des problèmes qui peuvent être propres au déploiement de Calico sur des nœuds hybrides. Le tableau ci-dessous récapitule les composants Calico et indique s’ils s’exécutent par défaut sur le réseau du nœud ou du pod. Si vous avez configuré Calico pour utiliser NAT pour le trafic sortant des pods, votre réseau sur site doit être configuré pour acheminer le trafic vers votre CIDR de nœud sur site et vos tables de routage VPC doivent être configurées avec une route pour votre CIDR de nœud sur site avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible. Si vous ne configurez pas Calico pour utiliser NAT pour le trafic sortant des pods, votre réseau sur site doit être configuré pour acheminer le trafic vers votre CIDR de pod sur site et vos tables de routage VPC doivent être configurées avec une route pour votre CIDR de pod sur site avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible. | Composant | Réseau | | --- | --- | | Serveur API Calico | Nœud | | Contrôleurs Calico pour Kubernetes | pod | | Agent de nœud Calico | Nœud | | Calico `typha` | Nœud | | Pilote de nœud Calico CSI | pod | | Opérateur Calico | Nœud | **Les ressources Calico sont planifiées ou en cours d’exécution sur des nœuds cordonnés** Les ressources Calico qui ne s'exécutent pas en tant que telles DaemonSet sont soumises à des tolérances flexibles par défaut qui leur permettent d'être planifiées sur des nœuds cordonés qui ne sont pas prêts à être planifiés ou à exécuter des pods. Vous pouvez renforcer les tolérances pour les ressources autres que DaemonSet Calico en modifiant l'installation de votre opérateur pour inclure les éléments suivants. ``` installation: ... controlPlaneTolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 calicoKubeControllersDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 typhaDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 ``` ## Dépannage des informations d’identification Pour les activations hybrides AWS SSM et pour AWS IAM Roles Anywhere, vous pouvez vérifier que les informations d'identification du rôle Hybrid Nodes IAM sont correctement configurées sur vos nœuds hybrides en exécutant la commande suivante depuis vos nœuds hybrides. Vérifiez que le nom du nœud et le nom du rôle IAM des nœuds hybrides correspondent à vos attentes. ``` sudo aws sts get-caller-identity ``` ``` { "UserId": "ABCDEFGHIJKLM12345678910:", "Account": "", "Arn": "arn:aws: sts:::assumed-role/" } ``` **Dépannage du gestionnaire de systèmes (SSM) AWS ** Si vous utilisez des activations hybrides AWS SSM pour les informations d'identification de vos nœuds hybrides, tenez compte des répertoires et artefacts SSM suivants qui sont installés sur vos nœuds hybrides par. `nodeadm` Pour plus d'informations sur l'agent SSM, consultez la section Utilisation [de l'agent SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) dans le Guide de l'*utilisateur de AWS Systems Manager*. | Description | Location | | --- | --- | | Agent SSM | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL et AL2 023 - `/usr/bin/amazon-ssm-agent` | | Journaux SSM Agent | `/var/log/amazon/ssm` | | AWS informations d'identification | `/root/.aws/credentials` | | Configuration SSM CLI | `/opt/ssm/ssm-setup-cli` | **Redémarrage de l’agent SSM** Certains problèmes peuvent être résolus en redémarrant l’agent SSM. Vous pouvez utiliser les commandes ci-dessous pour le redémarrer. **AL2023 et autres systèmes d'exploitation** ``` systemctl restart amazon-ssm-agent ``` **Ubuntu** ``` systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` **Vérifiez la connectivité aux points de terminaison SSM** Vérifiez que vous pouvez vous connecter aux points de terminaison SSM à partir de vos nœuds hybrides. Pour obtenir la liste des points de terminaison SSM, consultez la section [Points de terminaison et quotas Systems Manager AWS](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Remplacez `us-west-2` la commande ci-dessous par la AWS région pour votre activation hybride AWS SSM. ``` ping ssm.us-west-2.amazonaws.com ``` **Afficher l’état de connexion des instances SSM enregistrées** Vous pouvez vérifier l'état de connexion des instances enregistrées avec les activations hybrides SSM à l'aide de la commande AWS CLI suivante. Remplacez l’ID de machine par l’ID de machine de votre instance. ``` aws ssm get-connection-status --target mi-012345678abcdefgh ``` **Incompatibilité de la somme de contrôle de la CLI de configuration SSM** Si vous constatez un problème de discordance de somme de contrôle `ssm-setup-cli` lors de l’exécution de `nodeadm install`, vous devez vérifier qu’il n’existe pas d’anciennes installations SSM sur votre hôte. Si votre hôte contient d’anciennes installations SSM, supprimez-les et relancez `nodeadm install` pour résoudre le problème. ``` Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli. ``` **SSM `InvalidActivation` ** Si vous constatez une erreur lors de l'enregistrement de votre instance auprès de AWS SSM, confirmez que le `region``activationCode`, et `activationId` dans votre nom `nodeConfig.yaml` sont corrects. La AWS région de votre cluster EKS doit correspondre à la région de votre activation hybride SSM. Si ces valeurs sont mal configurées, vous pourriez voir une erreur similaire à celle-ci. ``` ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation ``` **SSM `ExpiredTokenException` : le jeton de sécurité inclus dans la demande a expiré** Si l’agent SSM n’est pas en mesure d’actualiser les informations d’identification, vous pouvez voir apparaître un `ExpiredTokenException`. Dans ce scénario, si vous parvenez à vous connecter aux points de terminaison SSM à partir de vos nœuds hybrides, vous devrez peut-être redémarrer l’agent SSM pour forcer l’actualisation des informations d’identification. ``` "msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired" ``` **Erreur SSM lors de l’exécution de la commande register machine** Si vous constatez une erreur lors de l’enregistrement de la machine auprès de SSM, vous devrez peut-être relancer `nodeadm install` afin de vous assurer que toutes les dépendances SSM sont correctement installées. ``` "error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory" ``` **SSM `ActivationExpired` ** Lors de l’exécution de `nodeadm init`, si vous constatez une erreur lors de l’enregistrement de l’instance auprès de SSM en raison d’une activation expirée, vous devez créer une nouvelle activation hybride SSM, mettre à jour votre `nodeConfig.yaml` avec le `activationCode` et le `activationId` de votre nouvelle activation hybride SSM, puis relancer `nodeadm init`. ``` "msg":"Command failed","error":"SSM activation expired. Please use a valid activation" ``` ``` ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired ``` **SSM n’a pas réussi à actualiser les informations d’identification mises en cache** Si vous ne parvenez pas à actualiser les informations d’identification mises en cache, le fichier `/root/.aws/credentials` a peut-être été supprimé sur votre hôte. Vérifiez d’abord l’activation hybride SSM et assurez-vous qu’elle est active et que vos nœuds hybrides sont correctement configurés pour utiliser l’activation. Vérifiez les journaux de l’agent SSM à `/var/log/amazon/ssm` et réexécutez la commande `nodeadm init` une fois que vous avez résolu le problème côté SSM. ``` "Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials" ``` **Nettoyez SSM** Pour supprimer l’agent SSM de votre hôte, vous pouvez exécuter les commandes suivantes. ``` dnf remove -y amazon-ssm-agent sudo apt remove --purge amazon-ssm-agent snap remove amazon-ssm-agent rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey ``` **Résolution des problèmes liés à Rôles Anywhere IAM AWS ** Si vous utilisez AWS IAM Roles Anywhere pour les informations d'identification de vos nœuds hybrides, tenez compte des répertoires et artefacts suivants qui sont installés sur vos nœuds hybrides par`nodeadm`. Pour plus d'informations sur la résolution des problèmes liés à IAM Roles Anywhere, consultez la section [Résolution des problèmes d'identité et d'accès à AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) dans le guide de l'utilisateur d'* AWS IAM Roles Anywhere*. | Description | Location | | --- | --- | | CLI Rôles Anywhere IAM | `/usr/local/bin/aws_signing_helper` | | Emplacement et nom du certificat par défaut | `/etc/iam/pki/server.pem` | | Emplacement et nom de la clé par défaut | `/etc/iam/pki/server.key` | **Rôles Anywhere IAM n’a pas pu actualiser les informations d’identification mises en cache** Si vous constatez un échec de l’actualisation des informations d’identification mises en cache, vérifiez le contenu de `/etc/aws/hybrid/config` et assurez-vous que Rôles Anywhere IAM a été correctement configuré dans votre configuration `nodeadm`. Confirmez que `/etc/iam/pki` existe. Chaque nœud doit disposer d’un certificat et d’une clé uniques. Par défaut, lorsque vous utilisez Rôles Anywhere IAM comme fournisseur d’informations d’identification, `nodeadm` utilise `/etc/iam/pki/server.pem` pour l’emplacement et le nom du certificat, et `/etc/iam/pki/server.key` pour la clé privée. Vous devrez peut-être créer les répertoires avant d’y placer les certificats et les clés avec `sudo mkdir -p /etc/iam/pki`. Vous pouvez vérifier le contenu de votre certificat à l’aide de la commande ci-dessous. ``` openssl x509 -text -noout -in server.pem ``` ``` open /etc/iam/pki/server.pem: no such file or directory could not parse PEM data Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"} ``` **Rôles Anywhere IAM n’a pas autorisé à exécuter `sts:AssumeRole`** Dans les journaux `kubelet`, si vous constatez un problème d’accès refusé pour l’opération `sts:AssumeRole` lors de l’utilisation de Rôles Anywhere IAM, vérifiez la politique de confiance de votre rôle IAM des nœuds hybrides afin de confirmer que le principal de service Rôles Anywhere IAM est autorisé à assumer le rôle IAM des nœuds hybrides. Vérifiez également que l’ARN de l’ancre d’approbation est correctement configurée dans votre stratégie de confiance du rôle IAM des nœuds hybrides et que votre rôle IAM des nœuds hybrides est ajouté à votre profil Rôles Anywhere IAM. ``` could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ... ``` **Rôles Anywhere IAM n’est pas autorisé à définir `roleSessionName`** Dans les journaux `kubelet`, si vous constatez un problème d’accès refusé pour la configuration du paramètre `roleSessionName`, vérifiez que vous avez défini la valeur `acceptRoleSessionName` sur true pour votre profil Rôles Anywhere IAM. ``` AccessDeniedException: Not authorized to set roleSessionName ``` ## Résolution des problèmes de système d’exploitation ### RHEL **Échec de l’enregistrement du gestionnaire d’autorisations ou d’abonnements** Lorsque vous exécutez `nodeadm install`, si vous rencontrez un problème lors de l’installation des dépendances des nœuds hybrides en raison d’un problème d’enregistrement des droits, assurez-vous d’avoir correctement défini votre nom d’utilisateur et votre mot de passe Red Hat sur votre hôte. ``` This system is not registered with an entitlement server ``` ### Ubuntu **GLIBC introuvable** Si vous utilisez Ubuntu comme système d’exploitation et Rôles Anywhere IAM comme fournisseur d’informations d’identification avec des nœuds hybrides et que vous rencontrez un problème lié à l’absence de GLIBC, vous pouvez installer cette dépendance manuellement pour résoudre le problème. ``` GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper) ``` Exécutez les commandes suivantes pour installer la dépendance : ``` ldd --version sudo apt update && apt install libc6 sudo apt install glibc-source ``` ### Flacon Rocket Si vous avez activé le conteneur d’administration Bottlerocket, vous pouvez y accéder via SSH pour effectuer un débogage avancé et un dépannage avec des privilèges élevés. Les sections suivantes contiennent des commandes qui doivent être exécutées dans le contexte de l’hôte Bottlerocket. Une fois que vous êtes dans le conteneur d’administration, vous pouvez exécuter `sheltie` pour obtenir un shell root complet dans l’hôte Bottlerocket. ``` sheltie ``` Vous pouvez également exécuter les commandes des sections suivantes à partir du shell du conteneur admin en préfixant chaque commande avec `sudo chroot /.bottlerocket/rootfs`. ``` sudo chroot /.bottlerocket/rootfs ``` **Utilisation de logdog pour la collecte de logs** Bottlerocket fournit l’utilitaire `logdog` permettant de collecter efficacement les journaux et les informations système à des fins de dépannage. ``` logdog ``` L’utilitaire `logdog` rassemble les journaux provenant de divers emplacements sur un hôte Bottlerocket et les combine dans un fichier tar. Par défaut, l’archive tar sera créée à l’emplacement `/var/log/support/bottlerocket-logs.tar.gz` et sera accessible depuis les conteneurs hôtes à l’emplacement `/.bottlerocket/support/bottlerocket-logs.tar.gz`. **Accès aux journaux du système avec journalctl** Vous pouvez vérifier l’état des différents services système tels que `kubelet`, `containerd`, etc., et consulter leurs journaux à l’aide des commandes suivantes. La balise `-f` suivra les bûches en temps réel. Pour vérifier l’état du service `kubelet` et récupérer les journaux `kubelet`, vous pouvez exécuter : ``` systemctl status kubelet journalctl -u kubelet -f ``` Pour vérifier l’état du service `containerd` et récupérer les journaux `containerd` de l’instance orchestrée, vous pouvez exécuter : ``` systemctl status containerd journalctl -u containerd -f ``` Pour vérifier l’état du service `host-containerd` et récupérer les journaux `containerd` de l’instance hôte, vous pouvez exécuter : ``` systemctl status host-containerd journalctl -u host-containerd -f ``` Pour récupérer les journaux des conteneurs bootstrap et des conteneurs hôtes, vous pouvez exécuter : ``` journalctl _COMM=host-ctr -f ```