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.
Meilleures pratiques en matière de mise en réseau
Astuce
Découvrez les
Il est essentiel de comprendre le réseau Kubernetes pour exploiter efficacement votre cluster et vos applications. La mise en réseau des pods, également appelée réseau de clusters, est au cœur de la mise en réseau Kubernetes. Kubernetes prend en charge les plugins CNI (
Amazon EKS prend officiellement en charge le plug-in CNI Amazon Virtual Private Cloud (VPC) pour implémenter la mise en réseau Kubernetes Pod. Le VPC CNI assure une intégration native avec AWS VPC et fonctionne en mode sous-couche. En mode sous-couche, les pods et les hôtes sont situés sur la même couche réseau et partagent l'espace de noms réseau. L'adresse IP du Pod est cohérente du point de vue du cluster et du VPC.
Ce guide présente l'interface réseau Amazon VPC Container
Amazon EKS exécute Kubernetes en amont et est certifié conforme à Kubernetes. Bien que vous puissiez utiliser des plug-ins CNI alternatifs, ce guide ne fournit pas de recommandations pour la gestion des plug-ins CNI alternatifs. Consultez la documentation EKS Alternate CNI pour obtenir une liste de partenaires et de ressources permettant de gérer efficacement les CNI alternatifs.
Modèle de mise en réseau Kubernetes
Kubernetes définit les exigences suivantes en matière de mise en réseau des clusters :
-
Les pods planifiés sur le même nœud doivent pouvoir communiquer avec d'autres pods sans utiliser la NAT (Network Address Translation).
-
Tous les démons système (processus d'arrière-plan, par exemple, kubelet
) exécutés sur un nœud particulier peuvent communiquer avec les pods exécutés sur le même nœud. -
Les pods qui utilisent le réseau hôte
doivent être en mesure de contacter tous les autres pods sur tous les autres nœuds sans utiliser le NAT.
Consultez le modèle de réseau Kubernetes
Interface réseau de conteneurs (CNI)
Kubernetes prend en charge les spécifications CNI et les plugins pour implémenter le modèle de réseau Kubernetes. Un CNI se compose d'une spécification
Le plugin CNI est activé en passant l'option de ligne de commande à kubelet. --network-plugin=cni Kubelet lit un fichier depuis --cni-conf-dir (default/etc/cni/net.d) et utilise la configuration CNI de ce fichier pour configurer le réseau de chaque pod. Le fichier de configuration CNI doit correspondre à la spécification CNI (version 0.4.0 minimale) et tous les plugins CNI requis référencés par la configuration doivent être présents dans le --cni-bin-dir répertoire (par défaut//bin). opt/cni S'il existe plusieurs fichiers de configuration CNI dans le répertoire, le kubelet utilise le fichier de configuration qui vient en premier par son nom dans l'ordre lexicographique.
Cloud privé virtuel Amazon (VPC) CNI
Le AWS-provided VPC CNI est le module complémentaire réseau par défaut pour les clusters EKS. Le module complémentaire VPC CNI est installé par défaut lorsque vous provisionnez des clusters EKS. Le VPC CNI s'exécute sur les nœuds de travail Kubernetes. Le module complémentaire VPC CNI comprend le binaire CNI et le plug-in de gestion des adresses IP (ipamd). Le CNI attribue une adresse IP du réseau VPC à un Pod. L'ipamd gère les interfaces réseau élastiques AWS (ENI) pour chaque nœud Kubernetes et gère le pool chaud d'adresses IP. Le VPC CNI fournit des options de configuration pour la pré-allocation des ENI et des adresses IP pour des temps de démarrage rapides des Pod. Consultez Amazon VPC CNI pour connaître les meilleures pratiques recommandées en matière de gestion des plugins.
Amazon EKS vous recommande de spécifier des sous-réseaux dans au moins deux zones de disponibilité lorsque vous créez un cluster. Amazon VPC CNI attribue des adresses IP aux pods à partir des sous-réseaux des nœuds. Nous vous recommandons vivement de vérifier les adresses IP disponibles dans les sous-réseaux. Veuillez prendre en compte les recommandations relatives aux VPC et aux sous-réseaux avant de déployer des clusters EKS.
Amazon VPC CNI alloue un pool chaud d'ENI et d'adresses IP secondaires depuis le sous-réseau connecté à l'ENI principal du nœud. Ce mode de VPC CNI est appelé mode IP secondaire. Le nombre d'adresses IP et donc le nombre de Pods (densité de pods) sont définis par le nombre d'ENI et l'adresse IP par ENI (limites) telles que définies par le type d'instance. Le mode secondaire est le mode par défaut et fonctionne bien pour les petits clusters avec des types d'instances plus petits. Pensez à utiliser le mode préfixe si vous rencontrez des problèmes de densité de capsules. Vous pouvez également augmenter les adresses IP disponibles sur le nœud pour les Pods en attribuant des préfixes aux ENI.
Amazon VPC CNI s'intègre nativement à AWS VPC et permet aux utilisateurs d'appliquer les meilleures pratiques de sécurité et de mise en réseau AWS VPC existantes pour créer des clusters Kubernetes. Cela inclut la possibilité d'utiliser les journaux de flux VPC, les politiques de routage VPC et les groupes de sécurité pour isoler le trafic réseau. Par défaut, Amazon VPC CNI applique aux pods le groupe de sécurité associé à l'ENI principal sur le nœud. Envisagez d'activer les groupes de sécurité pour les pods lorsque vous souhaitez attribuer différentes règles réseau à un pod.
Par défaut, le VPC CNI attribue des adresses IP aux pods à partir du sous-réseau attribué à l'ENI principal d'un nœud. Il est courant de rencontrer une pénurie d'adresses IPv4 lors de l'exécution de grands clusters comportant des milliers de charges de travail. AWS VPC vous permet d'étendre les adresses IP disponibles en attribuant un CIDR secondaire pour contourner l'épuisement des blocs CIDR IPv4. AWS VPC CNI vous permet d'utiliser une plage d'adresses CIDR de sous-réseau différente pour les pods. Cette fonctionnalité du VPC CNI est appelée mise en réseau personnalisée. Vous pouvez envisager d'utiliser un réseau personnalisé avec un CIDR de la 100.64.0.0/10 plage (espace d'adressage partagé, RFC 6598) pour EKS. Cela vous permet de créer un environnement dans lequel les Pods ne consomment plus aucune adresse IP RFC1918 de votre VPC.
La mise en réseau personnalisée est l'une des options permettant de résoudre le problème d'épuisement des adresses IPv4, mais elle nécessite des frais opérationnels. Pour résoudre ce problème, nous vous recommandons de recourir à des clusters IPv6 plutôt qu'à une mise en réseau personnalisée. Plus précisément, nous vous recommandons de migrer vers des clusters IPv6 si vous avez complètement épuisé tout l'espace d'adressage IPv4 disponible pour votre VPC. Évaluez les plans de votre organisation en matière de prise en charge de l'IPv6 et demandez-vous si investir dans IPv6 pourrait avoir une plus grande valeur à long terme.
La prise en charge d'IPv6 par EKS vise à résoudre le problème d'épuisement des adresses IP causé par un espace d'adressage IPv4 limité. En réponse aux problèmes des clients liés à l'épuisement du protocole IPv4, EKS a donné la priorité aux Pods par rapport aux IPv6-only Pods à double pile. En d'autres termes, les Pods peuvent accéder aux ressources IPv4, mais aucune adresse IPv4 ne leur est attribuée à partir de la plage d'adresses CIDR du VPC. Le VPC CNI attribue des adresses IPv6 aux pods à partir du bloc CIDR IPv6 du VPC géré par AWS.
Calculateur de sous-réseaux
Ce projet inclut un document Excel de calculateur de WARM_IP_TARGET etWARM_ENI_TARGET. Le document comprend deux feuilles, une première pour le mode Warm ENI et une seconde pour le mode Warm IP. Consultez le guide VPC CNI pour plus d'informations sur ces modes.
Entrées :
-
Taille CIDR du sous-réseau
-
Cible ENI chaude ou cible IP chaude
-
Liste des instances
-
type, nombre et nombre de modules de charge de travail planifiés par instance
-
Sorties :
-
Nombre total de pods hébergés
-
Nombre d'adresses IP de sous-réseau consommées
-
Nombre d'adresses IP de sous-réseau restantes
-
Détails du niveau de l'instance
-
Nombre de Warm IPs/ENIs par instance
-
Nombre d'actifs IPs/ENIs par instance
-