Configuration préalable requise pour les nœuds hybrides - Amazon EKS

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.

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.

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 dans Amazon EKS pour la mise en réseau du plan de contrôle vers les nœuds. Plusieurs options documentées 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 et de AWS Direct Connect 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.

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 etRemotePodNetwork. 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_NODE_CIDR

tgw-abcdef123456

CIDR du nœud sur site, acheminer le trafic vers le TGW

REMODE_POD_CIDR

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-<cluster-name>-<uniqueID>. 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_NODE_CIDR

Envoi du pod sur site

sgr-abcdef654321

IPv4

HTTPS

TCP

443

REMOTE_POD_CIDR

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 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 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 pour découvrir comment créer le rôle IAM des nœuds hybrides avec les autorisations requises.