Afficher les exigences EKS réseau d'Amazon pour VPC et les sous-réseaux

Lorsque vous créez un cluster, vous spécifiez un VPCet au moins deux sous-réseaux situés dans des zones de disponibilité différentes. Cette rubrique fournit un aperçu des exigences et considérations EKS spécifiques d'Amazon concernant les sous-réseaux VPC et sous-réseaux que vous utilisez avec votre cluster. Si vous n'en avez pas VPC à utiliser avec AmazonEKS, vous pouvez en créer un à l'aide d'un AWS CloudFormation modèle EKS fourni par Amazon. Si vous créez un cluster local ou étendu sur AWS Outposts, consultez à la Créez un VPC et des sous-réseaux pour les EKS clusters Amazon sur AWS Outposts place de cette rubrique.

VPCexigences et considérations

Lorsque vous créez un cluster, le cluster VPC que vous spécifiez doit répondre aux exigences et considérations suivantes :

• Vous VPC devez disposer d'un nombre suffisant d'adresses IP disponibles pour le cluster, les nœuds et les autres Kubernetes ressources que vous souhaitez créer. Si le nombre d'adresses IP VPC que vous souhaitez utiliser n'est pas suffisant, essayez d'augmenter le nombre d'adresses IP disponibles.

  Pour ce faire, vous pouvez mettre à jour la configuration du cluster afin de modifier les sous-réseaux et les groupes de sécurité utilisés par le cluster. Vous pouvez effectuer la AWS Management Console mise à jour à partir de la dernière version de AWS CLI AWS CloudFormation, et v0.164.0-rc.0 ou d'une eksctl version ultérieure. Vous pouvez avoir besoin de procéder ainsi pour fournir aux sous-réseaux davantage d'adresses IP disponibles afin de réussir la mise à niveau d'une version de cluster.

  Important

  Tous les sous-réseaux que vous ajoutez doivent appartenir au même ensemble AZs que celui fourni à l'origine lors de la création du cluster. Les nouveaux sous-réseaux doivent répondre à toutes les autres exigences, par exemple disposer d'un nombre suffisant d'adresses IP.

  Par exemple, supposons que vous avez créé un cluster et spécifié quatre sous-réseaux. Dans l'ordre où vous les avez spécifiés, le premier sous-réseau se trouve dans la zone de disponibilité us-west-2a, les deuxième et troisième sous-réseaux se trouvent dans la zone de disponibilité us-west-2b et le quatrième sous-réseau se trouve dans la zone de disponibilité us-west-2c. Si vous souhaitez modifier les sous-réseaux, vous devez fournir au moins un sous-réseau dans chacune des trois zones de disponibilité, et les sous-réseaux doivent être identiques aux sous-réseaux d'VPCorigine.

  Si vous avez besoin de plus d'adresses IP que le nombre de CIDR blocs que vous VPC avez, vous pouvez ajouter des CIDR blocs supplémentaires en associant des blocs de routage interdomaines sans classe (CIDR) supplémentaires à votre. VPC Vous pouvez associer des CIDR blocs privés (RFC 1918) et publics (nonRFC 1918) à votre cluster avant VPC ou après la création de votre cluster. Un cluster peut mettre jusqu'à cinq heures pour qu'un CIDR bloc que vous avez associé soit reconnu. VPC

  Vous pouvez économiser l'utilisation des adresses IP en utilisant une passerelle de transit avec des services partagésVPC. Pour plus d'informations, consultez Isolated VPCs with shared services et Modèles de conservation des adresses IP EKS VPC routables Amazon dans un réseau hybride.

• Si vous Kubernetes souhaitez attribuer IPv6 des adresses Pods et des services, associez un IPv6 CIDR bloc à votreVPC. Pour plus d'informations, consultez Associer un IPv6 CIDR bloc à votre VPC dans le guide de VPC l'utilisateur Amazon.

• Le DNS nom d'hôte et la DNS résolution VPC doivent être pris en charge. Sinon, les nœuds ne peuvent pas rejoindre votre cluster. Pour plus d'informations, consultez DNSles attributs correspondants VPC dans le guide de VPC l'utilisateur Amazon.

• Ils VPC peuvent nécessiter l'utilisation AWS PrivateLink de VPC points de terminaison. Pour de plus amples informations, veuillez consulter Exigences et considérations requises pour les sous-réseaux.

Si vous avez créé un cluster avec Kubernetes 1.14 ou avant, Amazon EKS a ajouté la balise suivante à votre VPC :

Clé	Valeur
kubernetes.io/cluster/my-cluster	owned

Cette balise n'a été utilisée que par AmazonEKS. Vous pouvez supprimer l'identification sans affecter vos services. Elle n'est pas utilisée avec des clusters version 1.15 ou ultérieure.

Exigences et considérations requises pour les sous-réseaux

Lorsque vous créez un cluster, Amazon EKS crée 2 à 4 interfaces réseau élastiques dans les sous-réseaux que vous spécifiez. Ces interfaces réseau permettent la communication entre votre cluster et votreVPC. Ces interfaces réseau activent également des fonctionnalités Kubernetes telles que kubectl exec et kubectl logs. Le texte figure Amazon EKS cluster-name dans la description de chaque interface réseau EKS créée par Amazon.

Amazon EKS peut créer ses interfaces réseau dans n'importe quel sous-réseau que vous spécifiez lorsque vous créez un cluster. Vous pouvez modifier les sous-réseaux dans lesquels Amazon EKS crée ses interfaces réseau après la création de votre cluster. Lorsque vous mettez à jour la Kubernetes version d'un cluster, Amazon EKS supprime les interfaces réseau d'origine qu'il a créées et crée de nouvelles interfaces réseau. Ces interfaces réseau peuvent être créées dans les mêmes sous-réseaux que les interfaces réseau d'origine ou dans des sous-réseaux différents des interfaces réseau d'origine. 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 à seulement deux lorsque vous créez un cluster ou mettre à jour les sous-réseaux après la création du cluster.

Exigences requises pour les sous-réseaux des clusters

Les sous-réseaux que vous spécifiez lors de la création ou de la mise à jour d'un cluster doivent répondre aux exigences suivantes :

• Les sous-réseaux doivent chacun avoir au moins six adresses IP pour être utilisés par AmazonEKS. Toutefois, nous vous recommandons au moins 16 adresses IP.

• Les sous-réseaux ne peuvent pas résider dans AWS Outposts une zone AWS locale ou dans une telle zone. AWS Wavelength Toutefois, si vous en avezVPC, vous pouvez déployer des nœuds et des Kubernetes ressources autogérés sur ces types de sous-réseaux.

• Les sous-réseaux peuvent être publics ou privés. Toutefois, nous vous recommandons de spécifier des sous-réseaux privés, si possible. Un sous-réseau public est un sous-réseau comportant une table de routage comprenant une route vers une passerelle Internet, tandis qu'un sous-réseau privé est un sous-réseau comportant une table de routage qui n'inclut pas de route vers une passerelle Internet.

• Les sous-réseaux ne peuvent pas résider dans les zones de disponibilité suivantes :

  Région AWS	Nom de la région	Zone de disponibilité non autorisée IDs
  us-east-1	USA Est (Virginie du Nord)	use1-az3
  us-west-1	USA Ouest (Californie du Nord)	usw1-az2
  ca-central-1	Canada (Centre)	cac1-az3

Utilisation de la famille d'adresses IP par composant

Le tableau suivant indique la famille d'adresses IP utilisée par chaque composant d'AmazonEKS. Vous pouvez utiliser un système de traduction d'adresses réseau (NAT) ou un autre système de compatibilité pour vous connecter à ces composants à partir d'adresses IP sources appartenant à des familles dont la "No" valeur correspond à une entrée de table.

Les fonctionnalités peuvent varier en fonction du paramètre IP family (ipFamily) du cluster. Ce paramètre modifie le type d'adresses IP utilisé pour le CIDR bloc Kubernetes attribué àServices. Un cluster avec la valeur de réglage de IPv4 est appelé unIPv4 cluster, et un cluster avec la valeur de réglage IPv6 est appelé unIPv6 cluster.

Composant	IPv4adresses uniquement	IPv6adresses uniquement	Adresses à double pile
EKSAPIpoint de terminaison public	Oui 1,3	Oui 1,3	Oui 1,3
EKSAPIVPCpoint final	Oui	Non	Non
EKSPoint de terminaison API public d'authentification (EKSPod Identity)	Oui1	Oui1	Oui1
EKSPoint de API VPC terminaison d'authentification (EKSPod Identity)	Oui1	Oui1	Oui1
Kubernetespoint de terminaison public du cluster	Oui	Non	Non
Kubernetespoint de terminaison privé du cluster	Oui2	Oui2	Non
Kubernetessous-réseaux de clusters	Oui2	Non	Oui2
Adresses IP principales du nœud	Oui2	Non	Oui2
CIDRPlage de clusters pour les adresses Service IP	Oui2	Oui2	Non
PodAdresses IP provenant du VPC CNI	Oui2	Oui2	Non
IRSAOIDCÉmetteur URLs	Oui 1,3	Oui 1,3	Oui 1,3

Note

¹ Le point de terminaison est à double pile avec à la fois IPv4 des IPv6 adresses et. Vos applications extérieures AWS, vos nœuds pour le cluster et vos pods à l'intérieur du cluster peuvent atteindre ce point de terminaison par l'un IPv4 ou l'autre des moyensIPv6.

² Vous choisissez entre un IPv4 cluster et un IPv6 cluster dans le paramètre IP family (ipFamily) du cluster lorsque vous créez un cluster et cela ne peut pas être modifié. Vous devez plutôt choisir un autre paramètre lorsque vous créez un autre cluster et que vous migrez vos charges de travail.

³ Le point de terminaison à double pile a été introduit en août 2024. Pour utiliser les points de terminaison à double pile avec le AWS CLI, consultez la configuration de la double pile et des FIPS points de terminaison dans le guide de référence des outils AWS SDKset. Voici la liste des nouveaux points de terminaison :

EKSAPIpoint de terminaison public

eks.region.api.aws

IRSAOIDCÉmetteur URLs

oidc-eks.region.api.aws

Exigences requises pour les sous-réseaux des nœuds

Vous pouvez déployer des nœuds et des ressources Kubernetes sur les mêmes sous-réseaux que ceux que vous avez spécifiés lors de la création de votre cluster. Toutefois, cela n'est pas nécessaire. En effet, vous pouvez également déployer des nœuds et des ressources Kubernetes sur des sous-réseaux que vous n'avez pas spécifiés lors de la création du cluster. Si vous déployez des nœuds sur différents sous-réseaux, Amazon EKS ne crée pas d'interfaces réseau de clusters dans ces sous-réseaux. Tout sous-réseau sur lequel vous déployez des nœuds et des ressources Kubernetes doit répondre aux exigences suivantes :

• Les sous-réseaux doivent disposer de suffisamment d'adresses IP disponibles pour déployer tous vos nœuds et ressources Kubernetes.

• Si vous Kubernetes souhaitez attribuer IPv6 des adresses Pods et des services, vous devez avoir un IPv6 CIDR bloc et un IPv4 CIDR bloc associés à votre sous-réseau. Pour plus d'informations, consultez Associer un IPv6 CIDR bloc à votre sous-réseau dans le guide de l'VPCutilisateur Amazon. Les tables de routage associées aux sous-réseaux doivent inclure des routes vers les adresses IPv4 et IPv6. Pour plus d'informations, consultez Routes dans le guide de VPC l'utilisateur Amazon. Les pods se voient attribuer uniquement une adresse IPv6. Toutefois, les interfaces réseau créées par Amazon EKS pour votre cluster et vos nœuds se voient attribuer une adresse IPv4 et une IPv6 adresse.

• Si vous avez besoin d'un accès entrant depuis Internet à vos Pods, assurez-vous de disposer d'au moins un sous-réseau public avec suffisamment d'adresses IP disponibles pour déployer des équilibreurs de charge et des entrées. Vous pouvez déployer des équilibreurs de charge sur des sous-réseaux publics. Les équilibreurs de charge peuvent équilibrer la charge vers des Pods situés dans des sous-réseaux privés ou publics. Nous vous recommandons de déployer vos nœuds sur des sous-réseaux privés, si possible.

• Si vous envisagez de déployer des nœuds sur un sous-réseau public, ce sous-réseau doit attribuer automatiquement des adresses publiques IPv4 ou des adresses IPv6. Si vous déployez des nœuds sur un sous-réseau privé auquel est associé un IPv6 CIDR bloc, le sous-réseau privé doit également attribuer automatiquement IPv6 des adresses. Si vous avez utilisé un EKS AWS CloudFormation modèle Amazon pour déployer le vôtre VPC après le 26 mars 2020, ce paramètre est activé. Si vous avez utilisé les modèles pour déployer le vôtre VPC avant cette date ou si vous utilisez les vôtresVPC, vous devez activer ce paramètre manuellement. Pour plus d'informations, consultez Modifier l'attribut d'IPv4adressage public de votre sous-réseau et Modifier l'attribut d'IPv6adressage de votre sous-réseau dans le guide de VPCl'utilisateur Amazon.

• Si le sous-réseau sur lequel vous déployez un nœud est un sous-réseau privé et que sa table de routage n'inclut pas de route vers un périphérique de traduction d'adresses réseau (NAT) () ou une passerelle de sortie uniquement (IPv4IPv6), ajoutez VPC des points de terminaison utilisant votre. AWS PrivateLink VPC VPCdes points de terminaison sont nécessaires pour tous Services AWS les nœuds avec lesquels ils Pods doivent communiquer. Les exemples incluent AmazonECR, Elastic Load Balancing CloudWatch AWS Security Token Service, Amazon et Amazon Simple Storage Service (Amazon S3). Le point de terminaison doit inclure le sous-réseau dans lequel se trouvent les nœuds. Tous les VPC points de terminaison ne sont pas pris en Services AWS charge. Pour plus d'informations, voir Qu'est-ce que c'est AWS PrivateLink ? et AWS des services qui s'intègrent à AWS PrivateLink. Pour une liste des autres EKS exigences d'Amazon, consultezDéployez des clusters privés avec un accès Internet limité.

• Si vous souhaitez déployer des équilibreurs de charge sur un sous-réseau, le sous-réseau doit comporter l'identification suivante :

  • Sous-réseaux privés

    Clé	Valeur
    kubernetes.io/role/internal-elb	1

  • Sous-réseaux publics

    Clé	Valeur
    kubernetes.io/role/elb	1

Lorsqu'un Kubernetes cluster correspondant à une version 1.18 ou à une version antérieure a été créé, Amazon EKS a ajouté la balise suivante à tous les sous-réseaux spécifiés.

Clé	Valeur
kubernetes.io/cluster/my-cluster	shared

Lorsque vous créez un nouveau Kubernetes cluster maintenant, Amazon EKS n'ajoute pas le tag à vos sous-réseaux. Si l'identification se trouvait sur des sous-réseaux utilisés par un cluster dont la version était antérieure à 1.19, l'identification n'était pas automatiquement supprimée des sous-réseaux lors de la mise à jour du cluster vers une version plus récente. La version 2.1.1 ou antérieure du AWS Load Balancer Controller nécessite cette identification. Si vous utilisez une version plus récente du Load Balancer Controller, vous pouvez supprimer l'identification sans interrompre vos services.

Si vous avez déployé un en VPC utilisant l'eksctlun des EKS AWS CloudFormation VPC modèles Amazon, les règles suivantes s'appliquent :

• À partir du 26 mars 2020 : les adresses IPv4 publiques sont automatiquement attribuées par des sous-réseaux publics aux nouveaux nœuds déployés sur des sous-réseaux publics.

• Avant le 26 mars 2020 : les adresses IPv4 publiques ne sont pas automatiquement attribuées par les sous-réseaux publics aux nouveaux nœuds déployés sur des sous-réseaux publics.

Cette modification affecte les nouveaux groupes de nœuds déployés sur des sous-réseaux publics de la manière suivante :

• Groupes de nœuds gérés : si le groupe de nœuds est déployé sur un sous-réseau public à partir du 22 avril 2020, l'affectation automatique des adresses IP publiques doit être activée dans le sous-réseau public. Pour plus d'informations, consultez Modification de l'attribut d'adressage IPv4 public de votre sous-réseau.

• Groupes de nœuds autogérés Linux, Windows ou Arm : si le groupe de nœuds est déployé sur un sous-réseau public à partir du 26 mars 2020, l'attribution automatique des adresses IP publiques doit être activée dans le sous-réseau public. Sinon, les nœuds doivent être lancés avec une adresse IP publique. Pour plus d'informations, consultez Modification de l'attribut d'adressage IPv4 public de votre sous-réseau ou Attribution d'une adresse IPv4 publique lors du lancement d'une instance.

Exigences et considérations requises pour les sous-réseaux partagés

Vous pouvez utiliser VPCle partage pour partager des sous-réseaux avec d'autres AWS comptes du même AWS Organizations compte. Vous pouvez créer des EKS clusters Amazon dans des sous-réseaux partagés, en tenant compte des points suivants :

• Le propriétaire du VPC sous-réseau doit partager un sous-réseau avec un compte participant avant que ce compte puisse y créer un EKS cluster Amazon.

• Vous ne pouvez pas lancer de ressources en utilisant le groupe de sécurité par défaut pour le, VPC car il appartient au propriétaire. De plus, les participants ne peuvent pas lancer de ressources avec des groupes de sécurité détenus par d'autres participants ou par le propriétaire.

• Dans un sous-réseau partagé, le participant et le propriétaire contrôlent séparément les groupes de sécurité au sein de leur compte respectif. Le propriétaire du sous-réseau peut voir ces groupes de sécurité créés par les participants, mais ne peut pas exécuter d'actions sur ceux-ci. Si le propriétaire du sous-réseau souhaite supprimer ou modifier ces groupes de sécurité, le participant qui a créé le groupe de sécurité doit effectuer l'action.

• Si un cluster est créé par un participant, il faut tenir compte des éléments suivants :

  • Les IAM rôles de cluster IAM et de nœud doivent être créés dans ce compte. Pour plus d’informations, consultez IAMRôle EKS du cluster Amazon et Rôle IAM de nœud Amazon EKS.

  • Tous les nœuds doivent être créés par le même participant, y compris les groupes de nœuds gérés.

• Le VPC propriétaire du partage ne peut pas afficher, mettre à jour ou supprimer un cluster créé par un participant dans le sous-réseau partagé. Cela s'ajoute aux VPC ressources auxquelles chaque compte a un accès différent. Pour plus d'informations, consultez la section Responsabilités et autorisations des propriétaires et des participants dans le guide de VPC l'utilisateur Amazon.

• Si vous utilisez la fonctionnalité de mise en réseau personnalisée du Amazon VPC CNI plugin for Kubernetes, vous devez utiliser les mappages d'ID de zone de disponibilité répertoriés dans le compte propriétaire pour créer chaque ENIConfig. Pour de plus amples informations, veuillez consulter Déploiement pods dans des sous-réseaux alternatifs avec mise en réseau personnalisée.

Pour plus d'informations sur le partage de VPC sous-réseau, consultez la section Partager votre compte VPC avec d'autres comptes dans le guide de VPC l'utilisateur Amazon.