Exigences et considérations Amazon EKS requises pour le VPC et les sous-réseaux - Amazon EKS
Exigences et considérations requises pour le VPCExigences 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 tout le monde.

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.

Exigences et considérations Amazon EKS requises pour le VPC et les sous-réseaux

Lorsque vous créez un cluster, vous spécifiez un VPC et au moins deux sous-réseaux situés dans des zones de disponibilité différentes. Cette rubrique fournit une vue d'ensemble des exigences et considérations spécifiques à Amazon EKS qui sont requises pour le VPC et les sous-réseaux que vous utilisez avec votre cluster. Si vous n'avez pas de VPC à utiliser avec Amazon EKS, vous pouvez en créer un à l'aide d'un modèle fourni par AWS CloudFormation Amazon EKS. Si vous créez un cluster local ou étendu sur AWS Outposts, consultez Exigences et considérations Amazon EKS requises pour le VPC et les sous-réseaux des clusters locaux plutôt cette rubrique.

Exigences et considérations requises pour le VPC

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

  • Le VPC doit disposer d'un nombre suffisant d'adresses IP disponibles pour le cluster, pour tous les nœuds et pour les autres ressources Kubernetes que vous souhaitez créer. Si le VPC que vous souhaitez utiliser ne dispose pas d'un nombre suffisant d'adresses IP, 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 se trouver dans le même ensemble d'AZ 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 se trouver dans le même VPC que les sous-réseaux d'origine.

    Si vous avez besoin de plus d'adresses IP que les blocs CIDR du VPC, vous pouvez ajouter des blocs CIDR supplémentaires en associant des blocs CIDR (Routage inter-domaines sans classe) supplémentaires à votre VPC. Vous pouvez associer des blocs d'adresse privés (RFC 1918) et publics (non RFC 1918) à votre VPC avant ou après la création de votre cluster. Un cluster peut prendre jusqu'à cinq heures avant qu'un bloc d'adresse CIDR associé à un VPC ne soit reconnu.

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

  • Si vous souhaitez que Kubernetes attribue des adresses IPv6 à des Pods et des services, associez un bloc d'adresse CIDR IPv6 à votre VPC. Pour plus d'informations, veuillez consulter la section Associer un bloc d'adresse CIDR IPv6 à votre VPC dans le Guide de l'utilisateur Amazon VPC.

  • Le VPC doit prend en charge le nom d'hôte DNS et la résolution DNS. Sinon, les nœuds ne peuvent pas rejoindre votre cluster. Pour plus d'informations, consultez Attributs DNS pour votre VPC dans le guide de l'utilisateur d'Amazon VPC.

  • Le VPC peut nécessiter l'utilisation de points de terminaison VPC. AWS PrivateLink Pour plus d’informations, consultez Exigences et considérations requises pour les sous-réseaux.

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

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

Cette identification n'a été utilisée que par Amazon EKS. 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 doit créer entre 2 et 4 interfaces réseau Elastic dans les sous-réseaux que vous spécifiez. Ces interfaces réseau permettent la communication entre votre cluster et votre VPC. Ces interfaces réseau activent également des fonctionnalités Kubernetes telles que kubectl exec et kubectl logs. Chaque interface réseau créée par Amazon EKS possède le texte Amazon EKS cluster-name dans sa description.

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 version Kubernetes 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 comporter chacun au moins six adresses IP à utiliser par Amazon EKS. 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 votre VPC, vous pouvez déployer des nœuds autogérés et des ressources Kubernetes 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 Identifiants de zone de disponibilité non autorisés
    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'Amazon EKS. 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
Point de terminaison public d'API EKS Oui Non Non
Point de terminaison VPC de l'API EKS Oui Non Non
Point de terminaison public de l'API EKS Auth Oui 1 Oui 1 Oui 1
Point de terminaison VPC de l'API EKS Auth Oui 1 Oui 1 Oui 1
Point de terminaison public du cluster EKS Oui Non Non
Point de terminaison privé du cluster EKS Oui 2 Oui 2 Non
Sous-réseaux du cluster EKS Oui 2 Non Oui 2
Adresses IP principales du nœud Oui 2 Non Oui 2
CIDRPlage de clusters pour les adresses Service IP Oui 2 Oui 2 Non
PodAdresses IP du VPC CNI Oui 2 Oui 2 Non
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 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 migrez vos charges de travail.

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 cluster 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 souhaitez que Kubernetes attribue des adresses IPv6 à des Pods et des services, vous devez disposer d'un bloc d'adresse CIDR IPv6 et d'un bloc d'adresse CIDR IPv4 associés à votre sous-réseau. Pour plus d'informations, consultez la section Associer un bloc d'adresse CIDR IPv6 à votre sous-réseau dans le guide de l'utilisateur d'Amazon VPC. Les tables de routage associées aux sous-réseaux doivent inclure des routes vers les adresses IPv4 et IPv6. Pour plus d'informations, veuillez consulter Routes dans le guide de l'utilisateur d'Amazon VPC. 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 adresse IPv6.

  • 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é doté d'un bloc d'adresse CIDR IPv6 associé, le sous-réseau privé doit également attribuer automatiquement des adresses IPv6. Si vous avez utilisé un AWS CloudFormation modèle Amazon EKS pour déployer votre VPC après le 26 mars 2020, ce paramètre est activé. Si vous avez utilisé les modèles pour déployer votre VPC avant cette date ou si vous utilisez votre propre VPC, vous devez activer ce paramètre manuellement. Pour plus d'informations, consultez Modifier l'attribut d'adressage IPv4 de votre sous-réseau et Modifier l'attribut d'adressage IPv6 de votre sous-réseau dans le guide de l'utilisateur d'Amazon VPC.

  • 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 appareil de traduction d'adresses réseau (NAT) (IPv4) ou une passerelle de sortie uniquement (IPv6), ajoutez des points de terminaison d'un VPC à l'aide d' AWS PrivateLink à votre VPC. Les points de terminaison VPC sont nécessaires pour tous les éléments avec Services AWS lesquels vos nœuds Pods doivent communiquer. Les exemples incluent Amazon ECR, 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 ne sont pas Services AWS compatibles avec les points de terminaison VPC. Pour plus d'informations, voir Qu'est-ce que c'est AWS PrivateLink ? et AWS des services qui s'intègrent à AWS PrivateLink. Pour obtenir une liste complète des exigences Amazon EKS, consultez Exigences relatives aux clusters privés.

  • 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 cluster Kubernetes version 1.18 et antérieure était créé, Amazon EKS ajoutait l'identification suivante à tous les sous-réseaux qui avaient été spécifiés.

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

Désormais, lorsque vous créez un cluster Kubernetes, Amazon EKS n'ajoute pas l'identification à 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 VPC à l'aide de l'un eksctldes modèles de AWS CloudFormation VPC Amazon EKS, 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 Partage de VPC pour partager des sous-réseaux avec d'autres comptes  AWS  au sein d'un même AWS Organizations. Vous pouvez créer des clusters Amazon EKS dans des sous-réseaux partagés, en tenant compte des points suivants :

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

  • Vous ne pouvez pas lancer de ressources en utilisant le groupe de sécurité par défaut du 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 propriétaire du VPC partagé ne peut pas afficher, mettre à jour ou supprimer un cluster créé par un participant dans le sous-réseau partagé. Cela s'ajoute aux ressources VPC auxquelles chaque compte a un accès différent. Pour plus d'informations, consultez Responsabilités et autorisations pour les propriétaires et les participants dans le Guide de l'utilisateur Amazon VPC.

  • 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 plus d’informations, consultez Mise en réseau personnalisée pour les pods.

Pour plus d'informations sur le partage de sous-réseaux VPC, consultez Partager votre VPC avec d'autres comptes dans le Guide de l'utilisateur Amazon VPC.