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.

Réseau personnalisé

Par défaut, Amazon VPC CNI attribue 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, il est possible que le CNI ne soit pas 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 constitue une solution à ce problème.

La mise en réseau personnalisée résout le problème d'épuisement des adresses IP en attribuant des adresses IP aux nœuds et aux 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 (extraite d'un CIDR VPC secondaire), ainsi que le ou les groupes de sécurité auxquels les pods appartiendront. Lorsque la mise en réseau personnalisée est activée, le VPC CNI crée des ENI secondaires dans le sous-réseau défini dans ENIconfig. Le CNI attribue aux Pods une adresse IP à partir d'une plage d'adresses CIDR définie dans un CRD ENIconfig.

Étant donné que l'ENI principal n'est pas utilisé par la mise en réseau personnalisée, 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 Pods en dehors du nœud.

Exemple de configuration

Bien que la mise en réseau personnalisée accepte une plage de VPC valide pour la plage d'adresses CIDR secondaire, nous vous recommandons d'utiliser les CIDR de l'espace d'100.64.0.0/10adressage partagé (RFC 6598) car ils sont moins susceptibles d'être utilisés dans un environnement d'entreprise que les autres plages RFC1918. Par exemple, vous pouvez l'utiliser 100.64.0.0/16 comme CIDR secondaire pour votre VPC. Pour plus d'informations sur les associations de blocs CIDR autorisées et restreintes que vous pouvez utiliser avec votre VPC, consultez la section Restrictions d'association de blocs d'adresse CIDR IPv4 dans la section VPC et dimensionnement des sous-réseaux de la documentation VPC.

Comme le montre le schéma ci-dessous, l'interface réseau Elastic (ENI) principale du nœud de travail utilise toujours la plage CIDR du VPC principale (dans ce cas, 10.0.0). 0/16) mais les ENI secondaires utilisent la plage d'adresses CIDR du 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 la mise en réseau personnalisée. 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 la mise en réseau personnalisée lorsque

Nous vous recommandons d'envisager une mise en réseau personnalisée si vous êtes confronté à un épuisement du protocole IPv4 et que vous ne pouvez pas encore utiliser IPv6. La prise en charge par Amazon EKS de l'espace RFC6598 vous permet de faire évoluer les Pods au-delà de la RFC1918 pour résoudre les problèmes d'épuisement. Pensez à 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 l'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 des 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 et 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 Shared Services (y compris des passerelles NAT sur 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 la mise en réseau personnalisée 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 la prise en charge d'IPv6, nous vous recommandons d'implémenter plutôt des clusters IPv6. Vous pouvez configurer des clusters IPv6 EKS 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 des 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 à associer 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 plug-in open source CNI. Consultez le guide de l'utilisateur des plugins CNI alternatifs 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 de sous-réseaux privés de se connecter à d'autres VPC et à des réseaux locaux dont les CIDR se chevauchent. Envisagez d'utiliser la méthode décrite dans cet article de blog pour utiliser une passerelle NAT privée afin de surmonter les problèmes de communication des 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 problèmes de chevauchement du CIDR, et elle aggrave les problèmes de configuration.

L'architecture réseau utilisée dans la mise en œuvre de cet article de blog suit les recommandations de la section Activer la communication entre réseaux superposés dans la documentation Amazon VPC. Comme indiqué dans cet article 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 et les nœuds de travail sont déployés dans la version non routable 100.64.0. 0/16 La plage CIDR secondaire du VPC est étendue, tandis que la passerelle NAT privée et la passerelle NAT sont déployées sur les plages d'adresses CIDR RFC1918 routables. Le blog explique comment une passerelle de transit est utilisée pour connecter des VPC afin de faciliter la communication entre VPC dont les plages 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 toutes les données transitent dans une zone de disponibilité via une connexion d'appairage VPC désormais gratuitement.

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 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 manière de l'implémenter, consultez ce billet de https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/ 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 CIDR secondaire de votre VPC, telle que 100.64.0. 0/10. Vous pouvez continuer à faire fonctionner le cluster EKS (le plan de contrôle restera le même que celui 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 non conventionnelle, visant à 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 zone de disponibilité. 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 ENI_CONFIG_LABEL_DEF les nœuds as k8s.amazonaws.com/eniConfig et label avec des noms ENIconfig personnalisés, tels k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 que et. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

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

L'activation de la mise en réseau personnalisée 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 d'activer la mise en réseau personnalisée avant que les nœuds de travail ne soient provisionnés.

Si vous aviez des nœuds dans votre cluster dotés de pods en cours d'exécution avant de passer à la fonction réseau CNI personnalisée, vous devez mettre en cordon et vider les nœuds pour arrêter progressivement les pods, puis terminer les nœuds. Seuls les nouveaux nœuds correspondant à l'étiquette ou aux annotations ENIconfig 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.

Calculez 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é a diminué. Pour contourner cette limitation, vous pouvez utiliser l'attribution de préfixes avec une mise en réseau personnalisée. Avec l'attribution de préfixes, 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 avec mise en réseau personnalisée.

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 porte le nombre de pods à 290.

Cependant, nous vous suggérons de définir max-pods sur 110 plutôt que 290, car l'instance possède un nombre relativement restreint de processeurs virtuels. Sur les instances plus importantes, EKS recommande une valeur maximale de 250 pods. Lorsque vous utilisez des pièces jointes avec des préfixes avec des types d'instances 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 utiliser un CNI alternatif ou passer à des clusters IPv6.