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.

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 suppose que vous remplissez les conditions préalables requises pour la connectivité réseau hybride à l’aide d’un VPN site à site AWS, de Direct Connect AWS ou de votre propre solution VPN.

Configuration réseau sur site

Configuration réseau minimale requise

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.

CIDR des nœuds et pods sur site

Identifiez les CIDR de nœuds et de pods que vous utiliserez pour vos nœuds hybrides et les charges de travail qui s’exécutent sur ceux-ci. 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 vos CIDR de nœuds sur site et vos CIDR de pods en tant qu’entrées lorsque vous créez votre cluster EKS à l’aide des champs RemoteNodeNetwork et RemotePodNetwork. Les CIDR de vos nœuds sur site doivent être routables sur votre réseau sur site. 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 :

Routage du réseau de pods sur site

Lorsque vous utilisez des nœuds hybrides EKS, nous vous recommandons généralement de rendre vos CIDR de pods sur site routables sur votre réseau local afin de permettre une communication de cluster complète et toutes les fonctionnalités 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.

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.

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 commande yum sert à 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.

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.

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 sont accessibles après la création du cluster dans la console Amazon EC2 ou via l’interface 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 pour les 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 local afin d’autoriser la connectivité entrante/sortante vers cet ensemble connu et limité d’adresses IP. 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 connaître la commande CLI AWS que vous pouvez utiliser pour trouver les adresses IP des interfaces réseau provisionné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'

Configuration du VPC et du sous-réseau AWS

Les exigences existantes en matière de VPC et de sous-réseau pour Amazon EKS s’appliquent aux clusters avec des nœuds hybrides. De plus, votre CIDR VPC ne peut pas chevaucher les CIDR de vos nœuds et pods sur site. Vous devez configurer les routes dans votre table de routage VPC pour votre nœud sur site et, éventuellement, les CIDR des pods. 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 l’interface CLI AWS. Vous pouvez également créer ces ressources dans le AWS Management Console ou avec d’autres interfaces telles que CloudFormation AWS, CDK AWS ou Terraform.

Étape 1 : créer un VPC

É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.

(Facultatif) Étape 3 : connecter le VPC à la passerelle de transit (TGW) Amazon VPC ou à la passerelle privée virtuelle (VGW) AWS Direct Connect

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 ou Associations de passerelles privées virtuelles Direct Connect AWS.

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 les identifiants des 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 permettent de créer une table de routage personnalisée avec les routes vers les CIDR des nœuds et des pods sur site. Pour plus d’informations, consultez Tables de routage de sous-réseau. 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 routes pour vos CIDR de nœuds et de pods sur site. Dans les exemples, une passerelle de transit (TGW) est utilisée pour connecter le VPC à l’environnement sur site. Si vous disposez de plusieurs CIDR de nœuds et de pods sur site, répétez les étapes pour chaque CIDR.

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.

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.

(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.

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"}]}]'