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.
Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. 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.
Afficher les exigences réseau d'Amazon EKS pour les 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, consultez. Créez un Amazon VPC pour votre cluster Amazon EKS Si vous créez un cluster local ou étendu sur AWS Outposts, consultez Création d'un VPC et de sous-réseaux pour les clusters Amazon EKS sur Outposts AWS plutôt cette rubrique. Le contenu de cette rubrique s'applique aux clusters Amazon EKS dotés de nœuds hybrides. Pour connaître les exigences de mise en réseau supplémentaires pour les nœuds hybrides, consultezPréparer le réseau pour les nœuds hybrides.
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, tous les nœuds et autres Kubernetes les ressources que vous souhaitez créer. Si le VPC que vous souhaitez utiliser ne possède pas 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 la AWS CLI et de
eksctl
la versionv0.164.0-rc.0
ou ultérieure. AWS CloudFormation 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 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 un compte privé (RFC 1918) et public (non-RFC 1918) Des blocs CIDR sont envoyés à 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 Isolated VPCs with shared services et Modèles de conservation des adresses IP routables Amazon EKS VPC dans un
réseau hybride. -
Si tu veux Kubernetes pour attribuer
IPv6
des adresses à Pods et services, associez un blocIPv6
CIDR à votre VPC. Pour plus d'informations, consultez Associer un bloc IPv6 CIDR à votre VPC dans le guide de l'utilisateur Amazon VPC. Vous ne pouvez pas utiliser d'IPv6
adresses avec des pods et des services exécutés sur des nœuds hybrides et vous ne pouvez pas utiliser de nœuds hybrides avec des clusters configurés avec la famille d'adressesIPv6
IP. -
Le VPC doit prend en charge le nom d'hôte
DNS
et la résolutionDNS
. Dans le cas contraire, les nœuds ne pourront pas s'enregistrer dans 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 que les points de terminaison du VPC utilisent. AWS PrivateLink 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 une version antérieure, Amazon EKS a ajouté la balise suivante à votre VPC :
Clé | Valeur |
---|---|
|
|
Cette identification n'a été utilisée que par Amazon EKS. Vous pouvez supprimer l'identification sans affecter vos services. Il n'est pas utilisé avec les clusters de 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 permettent également Kubernetes fonctionnalités telles que kubectl exec
etkubectl logs
. Chaque interface réseau créée par Amazon EKS possède le texte Amazon EKS
dans sa description.cluster-name
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 comporter chacun au moins six adresses IP à utiliser par Amazon EKS. Toutefois, nous vous recommandons au moins 16 adresses IP.
-
Les sous-réseaux doivent se trouver dans au moins deux zones de disponibilité différentes.
-
Les sous-réseaux ne peuvent pas résider dans AWS Outposts ou AWS Wavelength. Toutefois, si vous en avez dans votre VPC, vous pouvez déployer des nœuds autogérés et Kubernetes ressources pour ces types de sous-réseaux. Pour plus d'informations sur les nœuds autogérés, consultezGérez vous-même les nœuds grâce à des nœuds autogérés.
-
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 avec une table de routage qui inclut une route vers une passerelle Internet, tandis qu'un sous-réseau privé est un sous-réseau avec 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 :
AWS Région Nom de la région Zone de disponibilité non autorisée IDs us-east-1
US East (N. Virginia)
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 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é IPv4 cluster, et un cluster dont la valeur de réglage est IPv6 est appelé IPv6 cluster.
Composant | IPv4 adresses | IPv6 adresses | Adresses à double pile |
---|---|---|---|
Point de terminaison public d'API EKS |
Oui 1,3 |
Oui 1,3 |
Oui 1,3 |
Point de terminaison VPC de l'API EKS |
Oui |
Non |
Non |
Point de terminaison public de l'API EKS Auth (EKS Pod Identity) |
Oui1 |
Oui1 |
Oui1 |
Point de terminaison VPC de l'API EKS Auth (EKS Pod Identity) |
Oui1 |
Oui1 |
Oui1 |
|
Oui |
Non |
Non |
|
Oui |
Non |
Non |
|
Oui 1,4 |
Oui 1,4 |
Oui4 |
|
Oui 1,4 |
Oui 1,4 |
Oui4 |
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 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 la AWS CLI, consultez la configuration des points de terminaison à double pile et FIPS dans le AWS SDKs guide de référence des outils et. Voici la liste des nouveaux points de terminaison :
- Point de terminaison public d'API EKS
-
eks.
region
.api.aws - IRSA OIDC Émetteur URLs
-
oidc-eks.
region
.api.aws
4 Le point de terminaison du cluster à double pile a été introduit en octobre 2024. EKS crée le point de terminaison suivant pour les nouveaux clusters créés après cette date et sélectionnés IPv6
dans le paramètre de famille d'adresses IP (IPFamily) du cluster :
- Point de terminaison public/privé du cluster EKS
-
eks-cluster.
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. Cependant, 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 blocIPv6
CIDR et un blocIPv4
CIDR associés à votre sous-réseau. Pour plus d'informations, consultez Associer un bloc IPv6 CIDR à votre sous-réseau dans le guide de l'utilisateur Amazon VPC. Les tables de routage associées aux sous-réseaux doivent inclure des routes vers les adressesIPv4
etIPv6
. Pour plus d'informations, veuillez consulter Routes dans le guide de l'utilisateur d'Amazon VPC. Les pods se voient attribuer uniquement une adresseIPv6
. Toutefois, les interfaces réseau créées par Amazon EKS pour votre cluster et vos nœuds se voient attribuer une adresseIPv4
et une adresseIPv6
. -
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 adressesIPv6
. Si vous déployez des nœuds sur un sous-réseau privé doté d'un bloc d'adresse CIDRIPv6
associé, le sous-réseau privé doit également attribuer automatiquement des adressesIPv6
. Si vous avez utilisé le AWS CloudFormation modèle fourni par 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 le modèle, voirCréez un Amazon VPC pour votre cluster Amazon EKS. Pour plus d'informations, consultez Modifier l'attribut d' IPv4 adressage public de votre sous-réseau et Modifier l'attribut d' IPv6 adressage de votre sous-réseau dans le guide de l'utilisateur 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 périphérique de traduction d'adresses réseau (NAT) () ou une passerelle de sortie uniquement (
IPv4
)IPv6
, ajoutez des points de terminaison VPC à votre VPC. AWS PrivateLink Les points de terminaison VPC sont nécessaires pour tous les AWS services que vos nœuds et Pods J'ai besoin de communiquer avec. Les exemples incluent Amazon ECR, Elastic Load Balancing CloudWatch, Amazon, AWS Security Token Service 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 AWS services ne prennent pas en charge 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 Dé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 |
---|---|
|
|
Lorsque vous créez un nouveau Kubernetes Maintenant, Amazon EKS n'ajoute pas le tag à vos sous-réseaux. Si la balise se trouvait sur des sous-réseaux utilisés par un cluster dont la version était antérieure à1.19
, elle 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 balise. Si vous utilisez une version plus récente du Load Balancer Controller, vous pouvez supprimer l'identification sans interrompre vos services. Pour plus d'informations sur le contrôleur, consultezAcheminez le trafic Internet avec le AWS Load Balancer Controller.
Si vous avez déployé un VPC à l'aide de l'un eksctl
des 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
IPv4
adresses 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 le 22 avril 2020 ou après cette date, l'attribution automatique des adresses IP publiques doit être activée pour le sous-réseau public. Pour plus d'informations, consultez la section Modification de l'attribut d' IPv4 adressage 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 le 26 mars 2020 ou après cette date, l'attribution automatique des adresses IP publiques doit être activée pour 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' IPv4 adressage public pour votre sous-réseau ou Affectation d'une IPv4 adresse publique lors du lancement de l'instance.
Exigences et considérations requises pour les sous-réseaux partagés
Vous pouvez utiliser le partage VPC pour partager des sous-réseaux avec d'autres AWS comptes au sein des mêmes Organisations. AWS 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 à l'aide du groupe de sécurité par défaut du VPC car celui-ci 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 rôle IAM de cluster et les rôles IAM de nœud doivent être créés dans ce compte. Pour plus d’informations, consultez Rôle IAM de cluster Amazon EKS 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 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 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 sous-réseaux VPC, consultez Partager votre VPC avec d'autres comptes dans le Guide de l'utilisateur Amazon VPC.