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

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 voulez 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 mise à jour à partir de la AWS Management Console, de la dernière version de l’AWS CLI, d’AWS CloudFormation et de la version v0.164.0-rc.0 ou ultérieure de eksctl. 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.

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'adresses CIDR privés (RFC 1918) et publics (non-RFC 1918) à votre VPC avant ou après la création de votre cluster.

Vous pouvez ajouter des nœuds qui utilisent le nouveau bloc CIDR immédiatement après l’avoir ajouté. Cependant, comme le plan de contrôle ne reconnaît le nouveau bloc CIDR qu’une fois la réconciliation terminée, il peut s’écouler jusqu’à une heure avant qu’un bloc CIDR que vous avez associé à un VPC soit reconnu par un cluster. Vous pouvez ensuite exécuter les commandes kubectl cp, kubectl exec, kubectl logs et kubectl port-forward (ces commandes utilisent l’kubelet API) pour les nœuds et les pods du nouveau bloc CIDR. De plus, si vous avez des pods qui fonctionnent comme un dorsal webhook, vous devez attendre que la réconciliation du plan de contrôle soit terminée.

Évitez les chevauchements de plages d’adresses IP lorsque vous connectez votre cluster EKS à d’autres VPC via Transit Gateway, l’appairage VPC ou d’autres configurations réseau. Des conflits CIDR se produisent lorsque le CIDR de service de votre cluster EKS chevauche le CIDR d’un VPC connecté. Dans ces scénarios, les adresses ServiceIP ont priorité sur les ressources des VPC connectés ayant la même adresse IP, bien que le routage du trafic puisse devenir imprévisible et que les applications puissent ne pas parvenir à se connecter aux ressources souhaitées.

Pour éviter les conflits CIDR, assurez-vous que le CIDR de votre service EKS ne chevauche aucun CIDR de VPC connecté et conservez un registre centralisé de toutes les attributions CIDR. Si vous rencontrez des chevauchements CIDR, vous pouvez utiliser 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. Reportez-vous également à la section Communication entre VPC de la page Considérations relatives aux VPC et aux sous-réseaux du guide des bonnes pratiques EKS.

Si vous voulez que Kubernetes attribue des adresses IPv6 aux pods et aux services, associez un bloc 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. Vous ne pouvez pas utiliser d’adresses IPv6 avec des pods et des services s’exécutant sur des nœuds hybrides, et vous ne pouvez pas utiliser de nœuds hybrides avec des clusters configurés avec la famille d’adresses IP IPv6.

Le VPC doit prend en charge le nom d'hôte DNS et la résolution DNS. Sinon, les nœuds ne pourront pas s’enregistrer sur 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 des points de terminaison d’un VPC utilisant AWS PrivateLink. Pour de plus amples informations, consultez Exigences et considérations requises pour les sous-réseaux.

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 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. Pour plus d’informations sur les nœuds autogérés, consultez Gérer vous-même les nœuds grâce aux 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 dont la table de routage comprend une route vers une passerelle Internet, tandis qu’un sous-réseau privé est un sous-réseau dont la table de routage ne comprend pas de route vers une passerelle Internet.

Les sous-réseaux ne peuvent pas résider dans les zones de disponibilité 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 voulez que Kubernetes attribue des adresses IPv6 aux pod et aux services, vous devez disposer d’un bloc CIDR IPv6 et d’un bloc CIDR IPv4 associés à votre sous-réseau. Pour plus d’informations, consultez Associer un bloc CIDR IPv6 à 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 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 vers 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 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é le modèle AWS CloudFormation 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, consultez Création d’un VPC Amazon pour votre cluster Amazon EKS. Pour plus d’informations, consultez Modifier l’attribut d’adressage IPv4 public de votre sous-réseau et Modifier l’attribut d’adressage IPv6 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 ne comprend pas de route vers un dispositif de traduction d’adresses réseau (NAT) (IPv4) ou une passerelle de sortie uniquement (IPv6), ajoutez des points de terminaison d’un VPC à votre VPC à l’aide d’AWS PrivateLink. Les points de terminaison d’un VPC sont nécessaires pour tous les services AWS avec lesquels vos nœuds et vos pods doivent communiquer. Parmi les exemples, citons Amazon ECR, Elastic Load Balancing, Amazon CloudWatch, le service de jetons de sécurité AWS 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 services AWS ne prennent pas en charge les points de terminaison d’un VPC. Pour plus d’informations, consultez Qu’est-ce qu’AWS PrivateLink ? et Services AWS qui s’intègrent à AWS PrivateLink. Pour obtenir une liste complète des exigences Amazon EKS, consultez Déployer 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 :

À 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 les sous-réseaux publics.

Groupes de nœuds gérés  : si le groupe de nœuds est déployé sur un sous-réseau public à compter du 22 avril 2020, l’attribution automatique d’adresses IP publiques doit être activée pour 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 à compter du 26 mars 2020, l’attribution automatique d’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'adressage IPv4 public de votre sous-réseau ou Attribution d'une adresse IPv4 publique lors du lancement d'une instance.

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 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 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é réseau personnalisé du module complément CNI Amazon VPC pour 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, consultez Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé.