**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é](cni-custom-network.md).
**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 tag`kubernetes.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ées`0`).
+ S'il est marqué avec`kubernetes.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é avec`kubernetes.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/` 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.
1. Marquez les sous-réseaux avec`kubernetes.io/role/cni=1`.
1. Assurez-vous que les sous-réseaux disposent des tables de routage et des ACL réseau appropriées.
1. 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 avec`kubernetes.io/role/cni=0`.
1. Attendez que les pods utilisant les adresses IP de ce sous-réseau se terminent ou soient reprogrammés naturellement.
1. 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.