Afficher les exigences EKS réseau d'Amazon pour VPC et les sous-réseaux - Amazon EKS
VPCexigences et considérationsExigences et considérations requises pour les sous-réseauxExigences et considérations requises pour les sous-réseaux partagés

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tous.

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.

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 :

  • Le VPC doit disposer d'un nombre suffisant d'adresses IP disponibles pour le cluster, tous les nœuds et autres Kubernetes les 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 un compte privé (RFC 1918) et public (non-RFC 1918) vous CIDR bloque 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 tu veux Kubernetes pour attribuer IPv6 des adresses à Pods et 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.14ou une version antérieure, Amazon EKS a ajouté le tag suivant à 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 permettent également Kubernetes fonctionnalités telles que kubectl exec etkubectl 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 le 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 destinées à être utilisées 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 les avez dans votreVPC, vous pouvez déployer des nœuds autogérés et Kubernetes ressources pour 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 avec "No" valeur d'une entrée de table.

Les fonctionnalités peuvent varier en fonction du IP family (ipFamily) réglage du cluster. Ce paramètre modifie le type d'adresses IP utilisées pour CIDR bloquez ça Kubernetes assigne à Services. Un cluster dont la valeur de réglage est IPv4 est appelé IPv4cluster, et un cluster dont la valeur de réglage est IPv6 est appelé IPv6cluster.

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
Kubernetes point de terminaison public du cluster Oui Non Non
Kubernetes point de terminaison privé du cluster Oui2 Oui2 Non
Kubernetes sous-réseaux de clusters Oui2 Non Oui2
Adresses IP principales du nœud Oui2 Non Oui2
Cluster CIDR gamme pour Service Adresses IP Oui2 Oui2 Non
Pod Adresses IP provenant du VPC CNI Oui2 Oui2 Non
IRSA OIDC Émetteur URLs Oui 1,3 Oui 1,3 Oui 1,3
Note

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

2 Vous pouvez choisir entre un IPv4 cluster et un IPv6 cluster dans IP family (ipFamily) paramètre 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.

3 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

IRSA OIDC É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 Kubernetes ressources vers les mêmes sous-réseaux que ceux que vous spécifiez lors de la création de votre cluster. Toutefois, cela n'est pas nécessaire. Cela est dû au fait que vous pouvez également déployer des nœuds et Kubernetes des ressources vers des sous-réseaux que vous n'avez pas spécifiées 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 Kubernetes les ressources doivent 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 Kubernetes ressources pour.

  • Si tu veux Kubernetes pour attribuer IPv6 des adresses à Pods et services, alors 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 à votre 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 pour Pods 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 les vôtres 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 à l'aide de votre. AWS PrivateLink VPC VPCdes points de terminaison sont nécessaires pour tous vos nœuds et Services AWS Pods J'ai besoin de communiquer avec. 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 Services AWS compatibles. 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

Quand un Kubernetes dans le cluster dont la version 1.18 et la version antérieure ont été créées, 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 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. Version 2.1.1 ou antérieure du AWS Load Balancer Controllernécessite cette balise. 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 :

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 :

  • 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 du propriétaire pour les créer. 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.