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 sous-réseau CIDR auquel le principal ENI est attaché, généralement le sous-réseau du nœud ou de l'hôte.

Si le sous-réseau CIDR est trop petit, il se CNI peut qu'ils ne soient pas en mesure d'acquérir suffisamment d'adresses IP secondaires à attribuer à vos pods. Il s'agit d'un défi courant pour les EKS IPv4 clusters.

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 le nœud et le pod IPs à partir des espaces d'VPCadressage secondaires (CIDR). Le support réseau personnalisé prend en charge les ressources ENIConfig personnalisées. ENIConfigCela inclut une CIDR plage de sous-réseaux alternative (découpée à partir d'un sous-réseau secondaire VPCCIDR), ainsi que le ou les groupes de sécurité auxquels les pods appartiendront. Lorsque le réseau personnalisé est activé, il VPC CNI crée un réseau secondaire ENIs dans le sous-réseau défini ci-dessous. ENIConfig CNIAttribue aux Pods des adresses IP à partir d'une CIDR plage définie dans un ENIConfigCRD.

Le principal n'ENIétant pas utilisé par le réseau personnalisé, 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 au module principalENI. En outre, le serveur principal ENI 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 VPC une plage valide comme CIDR plage secondaire, nous vous recommandons d'utiliser CIDRs (/16) depuis l'NATespace CG-, c'est-à-dire 100.64.0.0/10 ou 198.19.0.0/16, car ces plages sont moins susceptibles d'être utilisées dans un environnement d'entreprise que les autres plages. RFC1918 Pour plus d'informations sur les associations de CIDR blocs autorisées et restreintes que vous pouvez utiliser avec votreVPC, consultez les restrictions relatives aux associations de IPv4 CIDR blocs dans la section VPC relative au dimensionnement des sous-réseaux de la VPC documentation.

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

Si vous souhaitez CNI utiliser un réseau personnalisé, définissez la variable d'AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFGenvironnement surtrue.

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, l'adresse IP du pod CNI sera attribuée à partir d'un sous-réseau défini dansENIConfig. 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 un réseau personnalisé si vous êtes IPv4 épuisé et que vous ne pouvez pas IPv6 encore l'utiliser. L'EKSassistance Amazon en matière d'RFC6598espace vous permet de faire évoluer les pods au-delà de la résolution des RFC1918problèmes d'é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 de ENIConfig ceux définis dans 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 EKS clusters et applications afin de connecter les services de centre de données sur site. Vous pouvez augmenter le nombre d'adresses privées (RFC1918) accessibles EKS à des services tels qu'Amazon Elastic Load Balancing et NAT -GW, tout en utilisant un NAT espace CG- non routable pour vos pods sur plusieurs clusters. VPC Un réseau personnalisé avec une passerelle de transit et des services partagés VPC (y compris des NAT passerelles 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 des 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 à être mis en œuvre 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 une solution à double pile (IPv4/IPv6) VPC ou si votre plan inclut un IPv6 support, nous vous recommandons d'implémenter des IPv6 clusters à la place. Vous pouvez configurer des IPv6 EKS clusters et migrer vos applications. Dans un IPv6 EKS cluster, Kubernetes et Pods obtiennent une IPv6 adresse et peuvent communiquer entre eux et avec les points de terminaison. IPv4 IPv6 Consultez les meilleures pratiques relatives à l'exécution de IPv6 EKS clusters.

CG- NAT Space épuisé

De plus, si vous utilisez actuellement CIDRs depuis l'NATespace CG ou si vous ne parvenez pas à relier un secondaire CIDR à votre clusterVPC, vous devrez peut-être explorer d'autres options, telles que l'utilisation d'une alternativeCNI. 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 CNI plugin open source. Reportez-vous au guide de l'utilisateur d'Alternate CNI Plugins pour plus de détails.

Utiliser une NAT passerelle privée

Amazon propose VPC désormais des fonctionnalités de NATpasserelle privée. La NAT passerelle privée d'Amazon permet aux instances situées dans des sous-réseaux privés de se connecter à d'autres réseaux VPCs et à des réseaux locaux qui se chevauchent. CIDRs Envisagez d'utiliser la méthode décrite dans ce billet de blog pour utiliser une NAT passerelle privée afin de surmonter les problèmes de communication liés aux EKS charges de travail causées par le chevauchementCIDRs, une plainte importante exprimée par nos clients. La mise en réseau personnalisée ne peut pas résoudre à elle seule les CIDR problèmes de chevauchement, et elle 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 VPC la documentation Amazon. Comme le montre ce billet de blog, vous pouvez étendre l'utilisation de Private NAT Gateway en conjonction avec des RFC6598 adresses pour gérer les problèmes d'épuisement des adresses IP privées des clients. Les EKS clusters et les nœuds de travail sont déployés dans la CIDR plage VPC secondaire non routable 100.64.0.0/16, tandis que la NAT passerelle privée et la passerelle sont déployées dans les plages routables. NAT RFC1918 CIDR Le blog explique comment une passerelle de transit est utilisée pour se connecter VPCs afin de faciliter la communication entre des plages non VPCs CIDR routables qui se chevauchent. Pour les cas d'utilisation dans lesquels les EKS ressources d'une plage VPC d'adresses non routable doivent communiquer avec d'autres ressources VPCs dont les plages d'adresses ne se chevauchent pas, les clients ont la possibilité d'utiliser VPC Peering pour les interconnecter. VPCs 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 de VPC peering 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 les nœuds et les pods sur un sous-réseau à partir d'un CIDR bloc secondaire plus grand (par exemple 100.64.0.0/8). Après avoir installé le nouveau CIDR dans votreVPC, vous pouvez déployer un autre groupe de nœuds à l'aide du nœud secondaire CIDR 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 votre VPC CIDR gamme secondaire, tels que VPC 100.64.0.0/10. Vous pouvez continuer à faire fonctionner le EKS cluster (le plan de contrôle restera sur le plan d'origine)subnet/s), but the nodes and Pods will be moved to a secondary 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 unVPC. 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 la zone de disponibilité (AZ) correspondante ENIConfig pour le 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 ENI configuration lorsque vous ne disposez que d'un seul sous-réseau secondaire (alternatifCIDR) par zone de disponibilité. 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

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 eniConfig des noms 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é le réseau personnalisé, nous vous suggérons de mettre à jour le AWS CloudFormation modèle du guide de EKS démarrage avec une ressource personnalisée qui appelle une fonction Lambda pour mettre à jour le aws-node Daemonset avec la variable d'environnement afin d'activer le réseau personnalisé 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é CNI réseau 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'ENIConfigétiquette 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 secondaireCIDR.

Calculer le nombre maximum de pods par nœud

Étant donné que le nœud principal n'ENIest plus utilisé pour attribuer les adresses IP des pods, le nombre de pods que vous pouvez exécuter sur un type d'EC2instance 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 l'adresse secondaire. ENIs

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 ne contient qu'un nombre assez restreint de virtuels. CPUs Sur les instances plus EKS volumineuses, 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 de l'instance CPU et de la mémoire bien avant ses adresses IP.

Identifier l'utilisation existante de CG-Space NAT

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à l'NATespace CG pour votre cluster, ou si vous n'êtes tout simplement pas en mesure d'associer un espace secondaire CIDR à votre clusterVPC, nous vous suggérons d'explorer d'autres options, comme utiliser une alternative CNI ou passer à des IPv6 clusters.

📝 Modifiez cette page sur GitHub