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.

Mise en réseau personnalisée

Par défaut, Amazon VPC CNI attribuera aux Pods une adresse IP sélectionnée dans le sous-réseau principal. Le sous-réseau principal est le CIDR du sous-réseau auquel l'ENI principal est attaché, généralement le sous-réseau du. node/host

Si le CIDR du sous-réseau est trop petit, le CNI risque de ne pas être en mesure d'acquérir suffisamment d'adresses IP secondaires à attribuer à vos pods. Il s'agit d'un défi courant pour les clusters IPv4 EKS.

La mise en réseau personnalisée est l'une des solutions à ce problème.

La mise en réseau personnalisée résout le problème d'épuisement des adresses IP en attribuant les adresses IP des nœuds et des pods à partir des espaces d'adressage VPC secondaires (CIDR). Le support réseau personnalisé prend en charge la ressource personnalisée ENIConfig. L'EniConfig inclut une plage d'adresses CIDR de sous-réseau alternative (découpée à partir d'un CIDR VPC secondaire), ainsi que le ou les groupes de sécurité auxquels appartiendront les pods. Lorsque le réseau personnalisé est activé, le VPC CNI crée des ENI secondaires dans le sous-réseau défini sous ENIConfig. Le CNI attribue aux Pods des adresses IP à partir d'une plage CIDR définie dans un CRD ENIConfig.

Étant donné que l'ENI principal n'est pas utilisé par les réseaux personnalisés, le nombre maximum de pods que vous pouvez exécuter sur un nœud est inférieur. Les pods du réseau hôte continuent d'utiliser l'adresse IP attribuée à l'ENI principal. En outre, l'ENI principal est utilisé pour gérer la traduction du réseau source et acheminer le trafic des Pods en dehors du nœud.

Exemple de configuration

Bien que le réseau personnalisé accepte une plage VPC valide pour la plage de CIDR secondaire, nous vous recommandons d'utiliser des CIDR (/16) depuis l'espace, c'est-à-dire 100.64.0. CG-NAT 0/10 ou 198,19,0. 0/16 car ils sont moins susceptibles d'être utilisés dans un environnement d'entreprise que les autres gammes RFC1918. Pour plus d'informations sur les associations de blocs d'adresse CIDR autorisées et restreintes que vous pouvez utiliser avec votre VPC, consultez les restrictions relatives aux associations de blocs d'adresse CIDR IPv4 dans la section relative au dimensionnement des VPC et des sous-réseaux de la documentation du VPC.

Comme le montre le schéma ci-dessous, l'interface réseau élastique (ENI) principale du nœud de travail utilise toujours la plage d'adresses CIDR VPC principale (dans ce cas, 10.0.0). 0/16) mais les ENI secondaires utilisent la plage d'adresses CIDR VPC secondaire (dans ce cas 100.64.0. 0/16). Maintenant, pour que les Pods utilisent le 100.64.0. 0/16 Plage CIDR, vous devez configurer le plugin CNI pour utiliser un réseau personnalisé. Vous pouvez suivre les étapes décrites ici.

Si vous souhaitez que le CNI utilise un réseau personnalisé, définissez la variable d'AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFGtrueenvironnement sur.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

QuandAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, le CNI attribuera l'adresse IP du pod à partir d'un sous-réseau défini dans. ENIConfig La ressource ENIConfig personnalisée est utilisée pour définir le sous-réseau dans lequel les pods seront planifiés.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

Lors de la création des ressources ENIconfig personnalisées, vous devrez créer de nouveaux nœuds de travail et vider les nœuds existants. Les nœuds de travail et les pods existants ne seront pas affectés.

Recommandations

Utilisez un réseau personnalisé lorsque

Nous vous recommandons d'envisager une mise en réseau personnalisée si vous êtes confronté à un problème d'épuisement du protocole IPv4 et que vous ne pouvez pas encore utiliser IPv6. La prise en charge de l'espace RFC6598 par Amazon EKS vous permet de faire évoluer les pods au-delà de la norme RFC1918 pour relever les défis liés à l'épuisement. Envisagez d'utiliser la délégation de préfixes avec un réseau personnalisé pour augmenter la densité des pods sur un nœud.

Vous pouvez envisager une mise en réseau personnalisée si vous avez des exigences de sécurité pour exécuter des Pods sur un réseau différent avec des exigences de groupe de sécurité différentes. Lorsque la mise en réseau personnalisée est activée, les pods utilisent des sous-réseaux ou des groupes de sécurité différents, tels que définis dans EniConfig, de ceux de l'interface réseau principale du nœud.

La mise en réseau personnalisée est en effet une option idéale pour déployer plusieurs clusters et applications EKS afin de connecter les services de centre de données sur site. Vous pouvez augmenter le nombre d'adresses privées (RFC1918) accessibles à EKS dans votre VPC pour des services tels qu'Amazon Elastic Load Balancing NAT-GW, tout en utilisant de l' CG-NAT espace non routable pour vos pods sur plusieurs clusters. La mise en réseau personnalisée avec la passerelle de transit et un VPC à services partagés (y compris des passerelles NAT entre plusieurs zones de disponibilité pour une haute disponibilité) vous permet de fournir des flux de trafic évolutifs et prévisibles. Ce billet de blog décrit un modèle architectural qui constitue l'une des méthodes les plus recommandées pour connecter les EKS Pods à un réseau de centre de données à l'aide d'un réseau personnalisé.

Évitez les réseaux personnalisés lorsque

Prêt à implémenter IPv6

La mise en réseau personnalisée peut atténuer les problèmes d'épuisement des adresses IP, mais elle nécessite des frais opérationnels supplémentaires. Si vous déployez actuellement un VPC à double pile (IPv4/IPv6) ou si votre plan inclut le support IPv6, nous vous recommandons d'implémenter des clusters IPv6 à la place. Vous pouvez configurer des clusters EKS IPv6 et migrer vos applications. Dans un cluster EKS IPv6, Kubernetes et Pods obtiennent une adresse IPv6 et peuvent communiquer en entrée et en sortie avec les points de terminaison IPv4 et IPv6. Consultez les meilleures pratiques relatives à l'exécution de clusters EKS IPv6.

CG-NAT Espace épuisé

En outre, si vous utilisez actuellement des CIDR depuis l' CG-NAT espace ou si vous ne parvenez pas à lier un CIDR secondaire à votre VPC de cluster, vous devrez peut-être explorer d'autres options, telles que l'utilisation d'un CNI alternatif. Nous vous recommandons vivement d'obtenir un support commercial ou de posséder les connaissances internes nécessaires pour déboguer et soumettre des correctifs au projet de plugin open source CNI. Consultez le guide de l'utilisateur d'Alternate CNI Plugins pour plus de détails.

Utiliser une passerelle NAT privée

Amazon VPC propose désormais des fonctionnalités de passerelle NAT privée. La passerelle NAT privée d'Amazon permet aux instances situées dans des sous-réseaux privés de se connecter à d'autres VPC et à des réseaux sur site dont les CIDR se chevauchent. Envisagez d'utiliser la méthode décrite dans ce billet de blog pour utiliser une passerelle NAT privée afin de résoudre les problèmes de communication liés aux charges de travail EKS causés par le chevauchement des CIDR, une plainte importante exprimée par nos clients. La mise en réseau personnalisée ne peut pas résoudre à elle seule les difficultés liées au chevauchement des CIDR, ce qui aggrave les problèmes de configuration.

L'architecture réseau utilisée dans la mise en œuvre de ce billet de blog suit les recommandations de la section Activer la communication entre les réseaux qui se chevauchent dans la documentation Amazon VPC. Comme démontré dans ce billet de blog, vous pouvez étendre l'utilisation de la passerelle NAT privée en conjonction avec les adresses RFC6598 pour gérer les problèmes d'épuisement des adresses IP privées des clients. Les clusters EKS, les nœuds de travail sont déployés dans la version 100.64.0 non routable. 0/16 Plage d'adresses CIDR secondaire VPC, tandis que la passerelle NAT privée et la passerelle NAT sont déployées sur les plages d'adresses CIDR routables de la RFC1918. Le blog explique comment une passerelle de transit est utilisée pour connecter des VPC afin de faciliter la communication entre les VPC dont les plages d'adresses CIDR non routables se chevauchent. Dans les cas d'utilisation dans lesquels les ressources EKS de la plage d'adresses non routable d'un VPC doivent communiquer avec d'autres VPC dont les plages d'adresses ne se chevauchent pas, les clients ont la possibilité d'utiliser le peering VPC pour interconnecter ces VPC. Cette méthode pourrait permettre de réaliser des économies, car tous les transferts de données au sein d'une zone de disponibilité via une connexion d'appairage VPC sont désormais gratuits.

Réseau unique pour les nœuds et les pods

Si vous devez isoler vos nœuds et vos pods sur un réseau spécifique pour des raisons de sécurité, nous vous recommandons de déployer des nœuds et des pods sur un sous-réseau à partir d'un bloc d'adresse CIDR secondaire plus important (par exemple 100.64.0). 0/8). Après l'installation du nouveau CIDR dans votre VPC, vous pouvez déployer un autre groupe de nœuds à l'aide du CIDR secondaire et vider les nœuds d'origine pour redéployer automatiquement les pods vers les nouveaux nœuds de travail. Pour plus d'informations sur la façon de l'implémenter, consultez ce billet de blog.

La mise en réseau personnalisée n'est pas utilisée dans la configuration représentée dans le schéma ci-dessous. Les nœuds de travail Kubernetes sont plutôt déployés sur des sous-réseaux de la plage d'adresses CIDR VPC secondaire de votre VPC, telle que 100.64.0. 0/10. Vous pouvez continuer à exécuter le cluster EKS (le plan de contrôle restera sur le cluster d'origine subnet/s), mais les nœuds et les pods seront déplacés vers un cluster secondaire subnet/s. Il s'agit d'une autre technique, quoique peu conventionnelle, pour atténuer le risque d'épuisement de la propriété intellectuelle dans un VPC. Nous proposons de vider les anciens nœuds avant de redéployer les pods vers les nouveaux nœuds de travail.

Automatisez la configuration avec des étiquettes de zone de disponibilité

Vous pouvez permettre à Kubernetes d'appliquer automatiquement l'ENIConfig correspondant à la zone de disponibilité (AZ) du nœud de travail.

Kubernetes ajoute automatiquement la balise topology.kubernetes.io/zoneà vos nœuds de travail. Amazon EKS recommande d'utiliser la zone de disponibilité comme nom de configuration ENI lorsque vous ne disposez que d'un seul sous-réseau secondaire (CIDR alternatif) par AZ. Vous pouvez ensuite définir l'étiquette utilisée pour découvrir le nom de configuration ENI surtopology.kubernetes.io/zone. Notez que la balise failure-domain.beta.kubernetes.io/zone est obsolète et remplacée par la balise. topology.kubernetes.io/zone

kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"

Si vous avez plusieurs sous-réseaux secondaires par zone de disponibilité, vous devez en créer un spécifiqueENI_CONFIG_LABEL_DEF. Vous pouvez envisager de configurer des nœuds ENI_CONFIG_LABEL_DEF en tant que k8s.amazonaws.com/eniConfiget d'étiqueter des nœuds avec des noms ENIConfig personnalisés, tels que k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1et. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Remplacez les pods lors de la configuration du réseau secondaire

L'activation du réseau personnalisé ne modifie pas les nœuds existants. La mise en réseau personnalisée est une action perturbatrice. Plutôt que de remplacer progressivement tous les nœuds de travail de votre cluster après avoir activé la mise en réseau personnalisée, nous vous suggérons de mettre à jour le CloudFormation modèle AWS du guide de démarrage EKS avec une ressource personnalisée qui appelle une fonction Lambda pour mettre à jour le aws-node Daemonset avec la variable d'environnement afin de permettre une mise en réseau personnalisée avant le provisionnement des nœuds de travail.

Si des nœuds de votre cluster étaient équipés de pods en cours d'exécution avant de passer à la fonctionnalité réseau CNI personnalisée, vous devez boucler et vider les nœuds pour arrêter correctement les pods, puis mettre fin aux nœuds. Seuls les nouveaux nœuds correspondant à l'étiquette EniConfig ou aux annotations utilisent un réseau personnalisé. Par conséquent, les pods planifiés sur ces nouveaux nœuds peuvent se voir attribuer une adresse IP à partir du CIDR secondaire.

Calculer le nombre maximum de pods par nœud

Étant donné que l'ENI principal du nœud n'est plus utilisé pour attribuer les adresses IP des pods, le nombre de pods que vous pouvez exécuter sur un type d'instance EC2 donné diminue. Pour contourner cette limitation, vous pouvez utiliser l'attribution de préfixes avec un réseau personnalisé. Avec l'attribution d'un préfixe, chaque adresse IP secondaire est remplacée par un préfixe /28 sur les ENI secondaires.

Tenez compte du nombre maximum de pods pour une instance m5.large dotée d'un réseau personnalisé.

Le nombre maximum de pods que vous pouvez exécuter sans attribution de préfixe est de 29

L'activation des pièces jointes par préfixe augmente le nombre de pods à 290.

Cependant, nous vous suggérons de définir max-pods sur 110 plutôt que sur 290 car l'instance dispose d'un nombre relativement restreint de processeurs virtuels. Pour les instances de plus grande taille, EKS recommande une valeur maximale de 250 pods. Lorsque vous utilisez des pièces jointes de préfixes avec des types d'instance plus petits (par exemple m5.large), il est possible que vous épuisiez les ressources du processeur et de la mémoire de l'instance bien avant ses adresses IP.

Identifier l'utilisation actuelle de l' CG-NAT espace

La mise en réseau personnalisée vous permet d'atténuer le problème d'épuisement des adresses IP, mais elle ne peut pas résoudre tous les problèmes. Si vous utilisez déjà de CG-NAT l'espace pour votre cluster, ou si vous n'êtes tout simplement pas en mesure d'associer un CIDR secondaire à votre VPC de cluster, nous vous suggérons d'explorer d'autres options, comme l'utilisation d'un CNI alternatif ou le passage à des clusters IPv6.