Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

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 de matériel nu ou des machines virtuelles avec un système d’exploitation pris en charge, et avoir configuré les activations hybrides Rôles Anywhere IAM AWS ou AWS Systems Manager (SSM). 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

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 sont disponibles pour connecter votre environnement sur site à votre VPC, notamment le VPN site à site AWS, Direct Connect AWS ou votre propre connexion VPN. Consultez les guides d’utilisation du VPN site à site AWS et de Direct Connect AWS 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 connexion réseau fiable d’au moins 100 Mbit/s et d’une latence aller-retour maximale de 200 ms pour la connexion des nœuds hybrides à la région AWS. 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 de l’application pour accéder aux données stockées dans d’autres services AWS. 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 entièrement privée sur votre connexion Direct Connect AWS, VPN site à site AWS ou votre propre connexion VPN.

Les plages Routage inter-domaines sans classe (CIDR) que vous utilisez pour vos réseaux de nœuds et de pods sur site doivent utiliser les plages d’adresses IPv4 RFC-1918. 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 réduire au minimum la latence, nous vous recommandons de créer votre cluster Amazon EKS dans la région AWS la plus proche de votre environnement sur site ou périphérique. Vous transmettez les CIDR de votre nœud et de votre pod sur site lors de la création du cluster Amazon EKS via deux champs API : RemoteNodeNetwork et RemotePodNetwork. Vous devrez peut-être discuter avec votre équipe réseau sur site afin d’identifier votre nœud sur site et les CIDR des pods. 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.

Les CIDR des nœuds et pods sur site que vous configurez via les champs RemoteNodeNetwork et RemotePodNetwork sont utilisés pour configurer le plan de contrôle Amazon EKS afin d’acheminer le trafic via votre VPC vers le kubelet et les pods s’exécutant sur vos nœuds hybrides. Les CIDR de vos nœuds et pods sur site ne peuvent pas se chevaucher entre eux, ni avec le CIDR VPC que vous transmettez lors de la création du cluster, ni avec la configuration IPv4 du service pour votre cluster Amazon EKS. De plus, les CIDR Pod doivent être uniques pour chaque cluster EKS afin que votre routeur sur site 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 API Amazon EKS Kubernetes sera toujours résolu vers les adresses IP publiques des nœuds hybrides s’exécutant 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 API Kubernetes est résolu en adresses IP publiques et la communication entre les nœuds hybrides et le plan de contrôle Amazon EKS est acheminée via Internet. Lorsque vous choisissez l’accès à un point de terminaison privé, le point de terminaison du serveur API Kubernetes est résolu en adresses IP privées et la communication entre les nœuds hybrides et le plan de contrôle Amazon EKS est acheminée via votre liaison de connectivité privée, dans la plupart des cas Direct Connect AWS ou VPN site à site AWS.

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.

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.

Infrastructure

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 des nœuds hybrides. Bottlerocket est pris en charge par AWS uniquement dans les environnements VMware vSphere. AL2023 n’est pas couvert par les plans d’assistance AWS lorsqu’il est exécuté en dehors d’Amazon EC2. AL2023 ne peut être utilisé que dans des environnements virtualisés sur site. Pour plus d’informations, consultez le Guide de l’utilisateur Amazon Linux 2023. 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 les activations hybrides AWS SSM ou Rôles Anywhere IAM AWS pour s’authentifier auprès du cluster Amazon EKS. Vous devez utiliser soit les activations hybrides AWS SSM, soit Rôles Anywhere IAM AWS avec l’interface CLI des nœuds hybrides Amazon EKS (nodeadm). Nous vous recommandons d’utiliser les activations hybrides SSM AWS si vous ne disposez pas d’une infrastructure à clé publique (PKI) avec une autorité de certification (CA) et des certificats pour vos environnements sur site. Si vous disposez déjà d’une infrastructure PKI et de certificats sur site, utilisez Rôles Anywhere IAM AWS.

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 Rôles Anywhere IAM AWS, configurez une politique de confiance qui autorise Rôles Anywhere IAM AWS à assumer le rôle IAM des nœuds hybrides et configurez votre profil Rôles Anywhere IAM AWS avec le rôle IAM des nœuds hybrides comme rôle assumable. Si vous utilisez SSM AWS, configurez une stratégie de confiance qui autorise SSM AWS à assumer le rôle IAM des nœuds hybrides et créez 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.