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éparer le 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 de connecter 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, de AWS Direct Connect 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 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 directive générale qui s'adapte à 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, et les dépendances des applications en matière d'accès aux données stockées dans d'autres AWS services. Nous vous recommandons de tester 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 nœud CIDR est alloué depuis votre réseau sur site et le nœud CIDR est alloué depuis votre interface réseau de conteneurs (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 plus d'informations sur la routabilité du module CIDR sur site.

Les blocs CIDR du nœud et du pod locaux doivent répondre aux exigences suivantes :

Routage réseau du pod 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 parvenez à rendre votre réseau de modules 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 modules routables sur votre réseau local, suivez les instructions ci-dessous.

Accès requis lors de l'installation et de la mise à niveau du nœud hybride

Vous devez avoir accès aux domaines suivants pendant le processus d'installation au cours duquel vous installez les dépendances des nœuds hybrides sur vos hôtes. Ce processus peut être effectué une seule fois lorsque vous créez les images de votre système d'exploitation ou sur chaque hôte lors de l'exécution. Cela inclut l'installation initiale et la mise à niveau de la version Kubernetes de vos nœuds hybrides.

Accès requis pour les opérations continues du cluster

L'accès réseau suivant pour votre pare-feu local est requis pour les opérations de cluster en cours.

Interfaces réseau Amazon EKS

Amazon EKS attache 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 EC2 console Amazon ou à l'aide de la AWS CLI. 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 de 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 lorsque vous créez un cluster ou vous pouvez mettre à jour les sous-réseaux après avoir créé le cluster.

Les interfaces réseau mises en service par Amazon EKS contiennent une description du formatAmazon 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. VPC_IDRemplacez-le par l'ID du VPC que vous transmettez lors de la création du cluster.

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 pour Amazon EKS s'appliquent aux clusters dotés de 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 itinéraires doivent être configurés 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 pièce jointe 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

Étape 2 : Création de 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 les exigences et considérations relatives aux sous-réseaux.

(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, attachez votre VPC au TGW ou au VGW. Pour plus d'informations, consultez les pièces jointes Amazon VPC dans Amazon VPC Transit Gateways ou les associations de passerelles privées AWS virtuelles Direct Connect.

Passerelle de transit

Exécutez la commande suivante pour connecter un 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. TGW_IDRemplacez-le par l'identifiant 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 un Transit Gateway. VPN_IDRemplacez-le 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éation d'une table de routage

Vous pouvez modifier la table de routage principale du 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 la section Tables de routage de sous-réseaux. Remplacez VPC_ID par l'ID du VPC.

aws ec2 create-route-table --vpc-id VPC_ID
         

Étape 5 : créer des itinéraires pour les nœuds et les pods locaux

Créez des itinéraires dans la table de routage pour chacun de vos nœuds distants locaux. Vous pouvez modifier la table de routage principale du 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.

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 Remote Pod

aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_POD_CIDR \
    --transit-gateway-id TGW_ID
         

(Facultatif) Étape 6 : associer des 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 au cours des étapes précédentes. RT_IDRemplacez-le par la table de routage que vous avez créée à l'étape précédente. Remplacez 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 requis pour les opérations de cluster en cours.

Pour créer un groupe de sécurité avec les règles d'accès entrant, exécutez les commandes suivantes. Ce groupe de sécurité doit être transmis lorsque vous créez votre cluster Amazon EKS. 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 pour inclure uniquement les règles ci-dessus. Si vous envisagez de limiter les règles de sortie, nous vous recommandons de tester minutieusement toutes vos applications et la connectivité des pods avant d'appliquer les 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"}]}]'