View a markdown version of this page

Configurer la sélection de sous-réseaux pour les adresses IP des pods - Amazon EKS
Découverte améliorée des sous-réseauxComportement des balises de sous-réseau (kubernetes). io/role/cni)Flux de travail recommandéConsidérations

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 sur 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.

Configurer la sélection de sous-réseaux pour les adresses IP des pods

S’applique à : nœuds Linux avec instances Amazon EC2

Le plug-in Amazon VPC CNI pour Kubernetes crée des interfaces réseau élastiques (ENI) secondaires sur vos nœuds et attribue les adresses IP de ces ENI aux pods. Par défaut, le VPC CNI crée des ENI secondaires dans le même sous-réseau que l'interface réseau principale du nœud. Vous pouvez contrôler les sous-réseaux que le VPC CNI utilise pour les adresses IP des pods à l'aide des méthodes suivantes :

  • Découverte améliorée des sous-réseaux : le VPC CNI découvre et utilise automatiquement les sous-réseaux étiquetés kubernetes.io/role/cni dans le même VPC et la même zone de disponibilité. Nécessite VPC CNI version 1.18.0 ou ultérieure. Nous recommandons cette méthode pour la plupart des cas d'utilisation.

  • Réseau personnalisé : spécifiez manuellement les sous-réseaux et les groupes de sécurité par zone de disponibilité à l'aide de ressources ENIConfig personnalisées. Pour de plus amples informations, veuillez consulter Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé.

Note

La mise en réseau personnalisée est prioritaire lorsque les deux fonctionnalités sont activées.

Découverte améliorée des sous-réseaux

Les versions 1.18.0 et ultérieures de VPC CNI permettent une découverte améliorée des sous-réseaux par défaut (). ENABLE_SUBNET_DISCOVERY=true Le VPC CNI découvre automatiquement les sous-réseaux dans le même VPC et la même zone de disponibilité que le nœud, puis les utilise pour créer des ENI secondaires et allouer des adresses IP de pod. Cela augmente l'espace d'adresse IP disponible sans ENIConfig configuration manuelle.

Pour vérifier que la fonctionnalité est activée :

kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY

Pour désactiver cette fonctionnalité, ENABLE_SUBNET_DISCOVERY=false sélectionnez aws-node DaemonSet.

Comportement des balises de sous-réseau (kubernetes). io/role/cni)

La kubernetes.io/role/cni balise contrôle la façon dont le VPC CNI traite les sous-réseaux pour les opérations ENI et l'allocation des adresses IP des pods. La balise a des effets différents selon que le VPC CNI crée une nouvelle ENI ou réconcilie une ENI existante.

Important

Les mécanismes de balisage Cluster-scoped et d'exclusion ne sont disponibles qu'à partir de v1.22.2 la version du VPC CNI. Avant cette version, seul le comportement d'opt-in standard était disponible via le tagkubernetes.io/role/cni=1.

Tag Value (Valeur d'identification)

Le tableau suivant résume l'impact de chaque valeur de balise sur le comportement du sous-réseau :

Valeur de balise Nouvelle création d'ENI Réconciliation ENI existante

1

Opt-in: Le VPC CNI crée de nouveaux ENI dans ce sous-réseau.

L'ENI reste disponible pour l'attribution des adresses IP des pods.

0

Exclus : le VPC CNI ne crée pas de nouveaux ENI dans ce sous-réseau.

Exclus : le VPC CNI exclut les ENI existants dans ce sous-réseau de l'allocation d'adresses IP du pod. Aucune nouvelle adresse IP de pod n'est attribuée par cet ENI.

Absent (aucune étiquette)

Non utilisé pour les nouveaux ENI : le VPC CNI ne sélectionne pas les sous-réseaux secondaires sans le tag pour la création de nouveaux ENI. Le sous-réseau principal (le sous-réseau dans lequel le nœud a été lancé) est toujours utilisé pour la création de nouvelles ENI, même sans la balise, pour des raisons de rétrocompatibilité.

Aucune interruption : les ENI existants dans les sous-réseaux non balisés restent disponibles pour l'allocation des adresses IP des pods. Le VPC CNI ne supprime ni n'exclut ces ENI.

Comportement de création ou de réconciliation

Le VPC CNI applique intentionnellement différentes politiques lors de la création de nouveaux ENI et lors du rapprochement des ENI existants :

  • Création (fermeture automatique pour les sous-réseaux secondaires) : lorsque le CNI du VPC doit créer un nouvel ENI secondaire, il utilise uniquement des sous-réseaux secondaires explicitement étiquetés avec. kubernetes.io/role/cni=1 Les sous-réseaux secondaires non balisés ne sont jamais sélectionnés pour la création de nouveaux ENI. Cela garantit que les nouvelles interfaces réseau ne sont placées que dans des sous-réseaux explicitement approuvés par les administrateurs.

  • Réconciliation (ouverture automatique pour les sous-réseaux non balisés) : lorsque le VPC CNI démarre ou réconcilie les ENI existants déjà attachés au nœud, il n'exclut pas les ENI car leur sous-réseau ne possède pas la balise. kubernetes.io/role/cni Cela évite d'interrompre le fonctionnement des pods qui utilisent déjà les adresses IP de ces ENI.

Le VPC CNI utilise cette conception intentionnellement. L'exclusion forcée d'une ENI déjà attachée d'un sous-réseau non balisé interromprait les pods qui utilisent actuellement les adresses IP de cette ENI.

Important

Pour empêcher un sous-réseau de servir de nouvelles adresses IP de pod, y compris celles provenant d'ENI existants, balisez le sous-réseau avec. kubernetes.io/role/cni=0 Une balise absente empêche uniquement la création de nouvelles ENI dans ce sous-réseau. Il n'exclut pas les ENI existants de l'allocation.

Gestion du sous-réseau principal

Le VPC CNI inclut toujours le sous-réseau principal du nœud (le sous-réseau dans lequel le nœud a été lancé) pour la création de l'ENI, même sans le tag. kubernetes.io/role/cni Cela permet de maintenir la rétrocompatibilité avec les clusters existants. Comportement du sous-réseau principal :

  • Inclus pour la création d'ENI indépendamment de la présence de balises (sauf si elles sont étiquetées0).

  • S'il est marqué aveckubernetes.io/role/cni=0, le CNI VPC exclut le sous-réseau principal à la fois de la création d'une nouvelle ENI et de l'allocation d'ENI existante.

Cluster-scoped filtrage des sous-réseaux

Lorsqu'un sous-réseau est balisé aveckubernetes.io/role/cni=1, le VPC CNI vérifie également la présence de balises spécifiques au cluster à l'aide du format de clé. cni.networking.k8s.aws/cluster/<cluster-name> Si un sous-réseau possède des balises de cluster dans ce format, seul le cluster dont le nom correspond utilise ce sous-réseau. Les sous-réseaux avec kubernetes.io/role/cni=1 ou sans balises spécifiques au cluster sont disponibles pour tous les clusters du VPC.

Par exemple, pour restreindre un sous-réseau à un cluster spécifique :

aws ec2 create-tags --resources subnet-example \
  --tags Key=kubernetes.io/role/cni,Value=1 Key=cni.networking.k8s.aws/cluster/my-cluster,Value=shared

Cela est utile lorsque plusieurs clusters EKS partagent un VPC et que vous souhaitez que chaque cluster utilise des sous-réseaux différents pour les adresses IP des pods.

Flux de travail recommandé

Pour ajouter de nouveaux sous-réseaux pour les adresses IP des pods :

  1. Créez de nouveaux sous-réseaux dans le même VPC et la même zone de disponibilité que vos nœuds.

  2. Marquez les sous-réseaux aveckubernetes.io/role/cni=1.

  3. Assurez-vous que les sous-réseaux disposent des tables de routage et des ACL réseau appropriées.

  4. Vérifiez que le VPC CNI découvre et commence à utiliser les nouveaux sous-réseaux.

Pour supprimer un sous-réseau de l'allocation IP du pod, procédez comme suit :

  1. Marquez le sous-réseau aveckubernetes.io/role/cni=0.

  2. Attendez que les pods utilisant les adresses IP de ce sous-réseau se terminent ou soient reprogrammés naturellement.

  3. Vérifiez que le VPC CNI arrête d'allouer de nouvelles adresses IP de pod à partir des ENI de ce sous-réseau.

Important

Ne supprimez pas la kubernetes.io/role/cni balise pour arrêter d'utiliser un sous-réseau. La suppression de la balise empêche la création de nouvelles ENI mais n'exclut pas les ENI existantes de l'allocation. Pour exclure activement un sous-réseau, ajoutez-le. kubernetes.io/role/cni=0

Considérations

  • La découverte améliorée des sous-réseaux nécessite Amazon VPC CNI version 1.18.0 ou ultérieure.

  • La fonctionnalité nécessite une ec2:DescribeSubnets autorisation dans le rôle VPC CNI IAM. La politique AmazonEKS_CNI_Policy gérée inclut cette autorisation. La politique IAM autogérée IPv6 ne l'inclut pas. Si vous utilisez une stratégie IAM autogérée (par exemple, pour les clusters IPv6), ajoutez-la ec2:DescribeSubnets manuellement pour activer la découverte de sous-réseaux.

  • La fonctionnalité fonctionne à la fois avec le mode adresse IP secondaire et avec le mode délégation de préfixe.

  • Tous les sous-réseaux découverts doivent se trouver dans le même VPC que le nœud.

  • Le VPC CNI crée uniquement des ENI dans des sous-réseaux situés dans la même zone de disponibilité que le nœud.

  • Le VPC CNI ne désalloue pas les ENI dont les adresses IP sont toujours attribuées aux pods, quelles que soient les modifications de balises.

  • Lorsque vous utilisez des VPC partagés (sous-réseaux entre comptes), balisez les sous-réseaux dans le compte du participant sur lequel le cluster est lancé.

  • Vous pouvez utiliser la découverte améliorée des sous-réseaux ainsi que les groupes de sécurité pour les pods, les politiques réseau, la délégation de préfixes et le SNAT.