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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page qui se trouve dans le volet droit de chaque 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.
Informations sur le réseau VPC et l’équilibrage de charge dans le mode automatique EKS
Cette rubrique explique comment configurer les fonctionnalités de réseau du cloud privé virtuel (VPC) et d’équilibrage de charge dans le mode automatique EKS. Même si le mode automatique EKS gère automatiquement la plupart des composants réseau, vous pouvez tout de même personnaliser certains aspects de la configuration réseau de votre cluster à l’aide de ressources NodeClass et d’annotations d’équilibreur de charge.
Lorsque vous utilisez le mode automatique EKS, il AWS gère la configuration de l'interface réseau de conteneurs VPC (CNI) et le provisionnement de l'équilibreur de charge pour votre cluster. Vous pouvez influencer le comportement du réseau en définissant des objets NodeClass et en appliquant des annotations spécifiques à vos ressources Service et Ingress, tout en conservant le modèle opérationnel automatisé fourni par le mode automatique EKS.
Fonctionnalité de réseau
Le mode automatique EKS introduit une nouvelle fonctionnalité de réseau qui gère le réseau des nœuds et des pods. Vous pouvez la configurer en créant un objet Kubernetes NodeClass.
Les options de configuration du AWS VPC CNI précédent ne s'appliqueront pas au mode automatique EKS.
Configuration du réseau avec une NodeClass
La ressource NodeClass dans le mode automatique EKS permet de personnaliser certains aspects de la fonctionnalité de réseau. Grâce à NodeClass, vous pouvez définir la sélection des groupes de sécurité, contrôler le placement des nœuds dans les sous-réseaux du VPC ,définir des politiques SNAT, configurer des politiques réseau et activer la journalisation des événements réseau. Cette approche maintient le modèle opérationnel automatisé du mode automatique EKS, tout en offrant une flexibilité de personnalisation du réseau.
Vous pouvez utiliser une NodeClass pour :
-
Sélectionner un groupe de sécurité pour les nœuds
-
Contrôler la manière dont les nœuds sont placés sur les sous-réseaux VPC
-
Définisser la politique SNAT du nœud sur
randomoudisabled -
Activer les politiques réseau Kubernetes, notamment :
-
Définir la politique réseau sur Refuser ou Autoriser par défaut
-
Activer la journalisation des événements réseau dans un fichier.
-
-
Isoler le trafic des pods du trafic des nœuds en attachant des pods à différents sous-réseaux.
Découvrez comment créer un Amazon EKS NodeClass.
Considérations
Le mode automatique EKS prend en charge :
-
Politiques réseau EKS.
-
Les options
HostPortetHostNetworkpour les pods Kubernetes. -
Nœuds et pods dans des sous-réseaux publics ou privés.
-
Mise en cache des requêtes DNS sur le nœud.
-
Configuration d'interface réseau statique pour les charges de travail EFA. Pour de plus amples informations, veuillez consulter Configuration de l'interface réseau statique.
Le mode automatique EKS ne prend pas en charge :
-
Groupes de sécurité par pod (SGPP). Pour appliquer des groupes de sécurité distincts au trafic des pods en mode automatique, utilisez
NodeClassplutôtpodSecurityGroupSelectorTermsdans. Pour de plus amples informations, veuillez consulter Sous-réseaux et groupes de sécurité distincts pour les Pods. -
Réseau personnalisé dans la
ENIConfig. Possibilité de placer des pods dans plusieurs sous-réseaux ou de les isoler complètement du trafic des nœuds via Sous-réseaux et groupes de sécurité distincts pour les Pods. -
Configurations Warm IP, Warm Prefix et Warm ENI.
-
Configuration minimale des cibles IP.
-
Autres configurations prises en charge par le AWS VPC CNI open source.
-
Configurations de politique réseau telles que la personnalisation du temporisateur Conntrack (la valeur par défaut est 300 s).
-
Exportation des journaux d'événements réseau vers CloudWatch.
-
Plug-ins CNI alternatifs (tels que Cilium ou Calico) et plugins alternatifs de politique réseau. Le mode automatique Amazon EKS utilise la fonctionnalité réseau intégrée décrite précédemment. Pour plus d'informations, consultez la section Considérations relatives au mode automatique Amazon EKS.
Gestion des ressources réseau
Le mode automatique EKS gère les préfixes, l'adressage IP et la gestion de l'interface réseau en surveillant les NodeClass ressources pour les configurations réseau. Le service exécute automatiquement plusieurs opérations essentielles :
Délégation de préfixes
Le mode EKS Auto utilise par défaut la délégation de préfixes (préfixes /28) pour la mise en réseau des pods et gère un pool chaud prédéfini de ressources IP qui évolue en fonction du nombre de pods planifiés. Lorsqu'une fragmentation du sous-réseau du pod est détectée, le mode automatique fournit des adresses IP secondaires (/32). Grâce à cet algorithme de mise en réseau des pods par défaut, le mode automatique calcule le nombre maximum de pods par nœud en fonction du nombre d'ENI et d'IP pris en charge par type d'instance (en supposant le pire cas de fragmentation). Pour plus d'informations sur le nombre maximum d'ENI et les adresses IP par type d'instance, consultez la section Adresses IP maximales par interface réseau dans le guide de l'utilisateur EC2. Les familles d'instances de nouvelle génération (Nitro v6 et versions ultérieures) ont généralement des ENI et des IP plus élevés par type d'instance, et le mode automatique ajuste le calcul du nombre maximum de pods en conséquence.
Pour les clusters IPv6, seule la délégation de préfixe est utilisée. Le mode automatique applique le même IPv4-based calcul et limite le nombre maximum de pods à 110 par nœud, en utilisant la valeur calculée si elle est inférieure à 110.
Gestion de la stabilisation
Le service met en œuvre un groupe de stabilisation pour les préfixes ou adresses IPv4 secondaires qui ne sont plus utilisés. Une fois le temps de stabilisation expiré, ces ressources sont renvoyées au VPC. Cependant, si des pods réutilisent ces ressources pendant le temps de stabilisation, elles sont restaurées à partir du groupe de stabilisation.
Prise en charge d’IPv6
Pour les clusters IPv6, le mode automatique EKS provisionne un préfixe IPv6 /80 par nœud sur l’interface réseau principale. Lors de l'utilisationpodSubnetSelectorTerms, le préfixe est plutôt attribué sur une interface réseau secondaire du sous-réseau du pod.
Le service assure également une gestion et une récupération de mémoire appropriées de toutes les interfaces réseau.
Équilibrage de charge
Vous configurez les AWS Elastic Load Balancers provisionnés par EKS Auto Mode à l'aide d'annotations sur les ressources de service et d'entrée.
Pour plus d’informations, consultez Créez un IngressClass pour configurer un Application Load Balancer ou Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer.
Considérations relatives à l’équilibrage de charge avec le mode automatique EKS
-
Le mode de ciblage par défaut est le mode IP, et non le mode instance.
-
Le mode automatique EKS prend uniquement en charge le mode groupe de sécurité pour les équilibreurs de charge réseau Network Load Balancer.
-
AWS ne prend pas en charge la migration des équilibreurs de charge depuis le contrôleur d'équilibrage de AWS charge autogéré vers la gestion par le mode automatique EKS.
-
Le champ
networking.ingress.ipBlockdans la spécificationTargetGroupBindingn’est pas pris en charge. -
Si vos composants master utilisent des groupes de sécurité personnalisés (et non ceux suivant le modèle de nommage
eks-cluster-sg-), le rôle de votre cluster doit disposer d’autorisations IAM supplémentaires. La EKS-managed politique par défaut autorise uniquement EKS à modifier les groupes de sécurité nomméseks-cluster-sg-. Sans l'autorisation de modifier vos groupes de sécurité personnalisés, EKS ne peut pas ajouter les règles d'entrée requises qui permettent au ALB/NLB trafic d'atteindre vos pods.
Considérations relatives à CoreDNS
Le mode automatique EKS n'utilise pas le déploiement CoreDNS traditionnel pour fournir une résolution DNS au sein du cluster. Au lieu de cela, les nœuds en mode automatique utilisent CoreDNS exécuté en tant que service système directement sur chaque nœud. Si vous faites passer un cluster traditionnel en mode automatique, vous pouvez supprimer le déploiement CoreDNS de votre cluster une fois que vos charges de travail ont été déplacées vers les nœuds en mode automatique.
Important
Si vous envisagez de gérer un cluster avec à la fois des nœuds en mode automatique et des nœuds en mode non automatique, vous devez conserver le déploiement CoreDNS. Non-Auto Les nœuds de mode s'appuient sur les pods CoreDNS traditionnels pour la résolution DNS, car ils ne peuvent pas accéder au service DNS au niveau du nœud fourni par le mode automatique.