Utilisation du module d'extension CNI de fonctions de réseau de pod natif de réseau cloud virtuel OCI pour les fonctions de réseau de pod

Découvrez le module d'extension CNI OCI VCN-Native Pod Networking pour la communication de pod sur les noeuds de processus actif dans les clusters créés à l'aide de Kubernetes Engine (OKE).

Le module d'extension CNI de mise en réseau de pod natif OCI VCN fournit des adresses IP aux pods à partir du bloc CIDR d'un VCN. Le module d'extension CNI OCI VCN-Native Pod Networking permet à d'autres ressources du même sous-réseau (ou d'un autre sous-réseau) de communiquer directement avec les pods d'un cluster Kubernetes. Les adresses IP de pod sont directement routables à partir d'autres réseaux cloud virtuels connectés (appairés) à ce VCN et à partir de réseaux sur site.

Les pods étant directement routables, vous pouvez utiliser la fonctionnalité VCN native pour :

Contrôlez l'accès aux pods et à partir de ceux-ci à l'aide de règles de sécurité définies dans le cadre de groupes de sécurité réseau (recommandé) ou de listes de sécurité. Les règles de sécurité s'appliquent à tous les pods de tous les noeuds de processus actif connectés au sous-réseau de pod indiqué pour un pool de noeuds. Reportez-vous à Groupes de sécurité réseau et à Listes de sécurité.
Observez le trafic vers, depuis et entre les pods à l'aide des journaux de flux VCN à des fins de dépannage et d'audit de conformité. Reportez-vous à la section VCN Flow Logs.
Acheminez les demandes entrantes vers les pods en fonction des stratégies de routage indiquées par les règles de routage et les tables de routage. Reportez-vous à la section VCN Route Tables.

Lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking, les noeuds de processus actif sont connectés à deux sous-réseaux indiqués pour le pool de noeuds :

Sous-réseau de noeud de processus actif : le sous-réseau de noeud de processus actif prend en charge la communication entre les processus exécutés sur le plan de contrôle du cluster (tels que kube-apiserver, kube-controller-manager, kube-scheduler) et les processus exécutés sur le noeud de processus actif (tels que kubelet, kube-proxy). Le sous-réseau de noeud de processus actif peut être privé ou public, et peut être un sous-réseau régional (recommandé) ou sur différents sous-réseaux propres à un domaine de disponibilité (un dans chaque domaine de disponibilité de la région).
Sous-réseau de pod : le sous-réseau de pod prend en charge la communication entre les pods et l'accès direct à des pods individuels à l'aide d'adresses IP de pod privées. Le sous-réseau de pod doit être privé et doit être un sous-réseau régional. Le sous-réseau de pod permet aux pods de communiquer avec d'autres pods sur le même noeud de processus actif, avec des pods sur d'autres noeuds de processus actif, avec des services OCI (via une passerelle de service) et avec Internet (via une passerelle NAT). Vous indiquez un seul sous-réseau de pod pour tous les pods exécutés sur les noeuds de processus actif d'un pool de noeuds. Vous pouvez spécifier le même sous-réseau de pod ou des sous-réseaux de pod différents pour différents pools de noeuds d'un cluster. Vous pouvez indiquer le même sous-réseau de pod pour les pools de noeuds dans différents clusters.

Le sous-réseau du noeud de processus actif et le sous-réseau du pod doivent se trouver dans le même VCN. Dans certains cas, le sous-réseau de noeud de processus actif et le sous-réseau de pod peuvent être le même sous-réseau (reportez-vous à Nombre maximal de cartes d'interface réseau virtuelles et de pods pris en charge par différentes formes). Si le sous-réseau de noeud de processus actif et le sous-réseau de pod sont le même sous-réseau, Oracle recommande de définir des règles de sécurité dans les groupes de sécurité réseau (plutôt que dans les listes de sécurité) pour acheminer le trafic réseau vers les noeuds de processus actif et les pods. Le sous-réseau de noeud de processus actif et le sous-réseau de pod s'ajoutent au sous-réseau d'adresse d'API Kubernetes et à tous les sous-réseaux d'équilibreur de charge définis pour le cluster.

Lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking, au moins deux cartes d'interface réseau virtuelles sont attachées à chaque noeud de processus actif. La première carte d'interface réseau virtuelle est connectée au sous-réseau du noeud de processus actif. La deuxième carte d'interface réseau virtuelle est connectée au sous-réseau de pod. Par défaut, 31 adresses IP sont affectées à la carte d'interface réseau virtuelle pour être utilisées par les pods exécutés sur le noeud de processus actif. Pour éviter de manquer d'adresses IP, les adresses IP sont préallouées dans le sous-réseau du pod avant la création des pods dans le cluster.

Si la forme que vous sélectionnez pour le pool de noeuds prend en charge plus de deux cartes d'interface réseau virtuelles, les cartes d'interface réseau virtuelles supplémentaires peuvent être connectées au sous-réseau de pod afin de fournir d'autres adresses IP pour prendre en charge davantage de pods.

Vous pouvez indiquer le nombre maximal de pods à exécuter sur un seul noeud de processus actif dans un pool de noeuds, jusqu'à une limite de 110. La limite de 110 est imposée par Kubernetes. Si vous voulez plus de 31 pods sur un seul noeud de processus actif, la forme que vous indiquez pour le pool de noeuds doit prendre en charge au moins trois cartes d'interface réseau virtuelles (une carte d'interface réseau virtuelle pour la connexion au sous-réseau de noeud de processus actif et au moins deux cartes d'interface réseau virtuelles pour la connexion au sous-réseau de pod). Reportez-vous à Nombre maximal de cartes d'interface réseau virtuelles et de pods pris en charge par différentes formes.

Si vous souhaitez conserver l'espace d'adressage du sous-réseau de pod, réduisez le nombre maximal de pods à exécuter sur un seul noeud de processus actif et réduisez ainsi le nombre d'adresses IP préallouées dans le sous-réseau de pod.

Tenez compte des points suivants lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking :

Vous pouvez utiliser le module d'extension CNI OCI VCN-Native Pod Networking avec des pools de noeuds virtuels et des pools de noeuds gérés.
Vous pouvez utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN avec des noeuds autogérés, à condition que les noeuds de plan de contrôle du cluster exécutent Kubernetes version 1.27.10 (ou ultérieure). Pour plus d'informations, reportez-vous à Utilisation des noeuds autogérés.
Vous pouvez uniquement utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN avec des clusters exécutant Kubernetes 1.22 ou une version ultérieure (reportez-vous à Utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour le réseau de pod). Pour plus d'informations, reportez-vous à la section Pod Networking.
Si vous utilisez le module d'extension CNI OCI VCN-Native Pod Networking et que vous voulez indiquer une image OKE en tant qu'image de base pour les noeuds de processus actif, ne sélectionnez pas d'image OKE publiée avant juin 2022.
Si vous utilisez le module d'extension CNI de mise en réseau de pod natif OCI VCN et que vous souhaitez acheminer le trafic d'un réseau sur site vers un pod, l'adresse IP du pod n'est pas persistante si le pod est recréé. Par exemple, un pod Nginx peut initialement avoir 10.0.0.5 comme adresse IP, mais si le pod est supprimé et recréé, il peut avoir une adresse IP différente (par exemple, 10.0.0.8).
Les produits de maillage de services (comme Istio et Linkerd) sont pris en charge lors de l'utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour la mise en réseau de pods. Notez qu'à l'exception de l'extension Istio, le support est actuellement limité à Oracle Linux 7 (le support Oracle Linux 8 est prévu). Le module complémentaire Istio est pris en charge avec Oracle Linux 7 et Oracle Linux 8. Les noeuds de processus actif doivent exécuter Kubernetes 1.26 (ou version ultérieure).

Règles de sécurité pour les noeuds de processus actif et les pods

Lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking pour la mise en réseau de pod, certaines règles de sécurité sont requises pour le sous-réseau de pod et le sous-réseau de noeud de processus actif. Reportez-vous à Règles de sécurité pour les sous-réseaux de pod.

Nombre maximal de cartes d'interface réseau virtuelles et de pods pris en charge par différentes formes

Le nombre maximal de cartes d'interface réseau virtuelles (et donc le nombre maximal de pods) pour les noeuds de processus actif d'un pool de noeuds dépend de la forme que vous sélectionnez pour le pool de noeuds.

Pour connaître le nombre maximal de cartes d'interface réseau virtuelles pour une forme particulière, reportez-vous à Formes de calcul.

Pour calculer le nombre maximal de pods dans un pool de noeuds d'une forme particulière, utilisez l'équation suivante :

Maximum number of Pods per node = MIN( (Number of VNICs - 1) * 31 ), 110)

Stratégie IAM supplémentaire permettant d'accéder aux ressources avec des adresses IPv6

Pour utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN dans lequel les ressources associées d'un cluster (telles que l'adresse d'API Kubernetes, l'équilibreur de charge et les noeuds de processus actif) ont des adresses IPv6, incluez une instruction de stratégie semblable à la suivante dans une stratégie IAM :

Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Stratégie IAM supplémentaire lorsqu'un cluster et ses ressources associées se trouvent dans des compartiments différents

Pour utiliser le module d'extension CNI OCI VCN-Native Pod Networking dans le scénario peu courant où les ressources associées d'un cluster (telles que les pools de noeuds, VCN et les ressources VCN) se trouvent dans un compartiment différent du cluster lui-même, vous devez inclure des instructions de stratégie similaires aux suivantes dans une stratégie IAM :

Allow any-user to manage instances in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use private-ips in tenancy where all { request.principal.type = 'cluster' }

Allow any-user to use network-security-groups in tenancy where all { request.principal.type = 'cluster' }

Si vous considérez ces instructions de stratégie comme trop permissives, vous pouvez limiter les droits d'accès afin d'indiquer explicitement le compartiment auquel les ressources associées appartiennent et/ou d'indiquer explicitement le cluster qui dispose de ressources associées dans un autre compartiment. Par exemple :

Allow any-user to manage instances in compartment <compartment-ocid-of-nodepool> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use private-ips in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

Allow any-user to use network-security-groups in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

où :

<compartment-ocid-of-nodepool> est l'OCID du compartiment auquel appartiennent les pools de noeuds et les instances de calcul.
<compartment-ocid-of-network-resources> est l'OCID du compartiment auquel le VCN et les sous-réseaux appartiennent.

Mise à jour du module d'extension CNI OCI VCN-Native Pod Networking

Lorsque vous spécifiez la mise en réseau de pod natif VCN en tant que type de réseau d'un cluster, le cluster et ses pools de noeuds exécutent initialement la dernière version du module d'extension CNI de mise en réseau de pod natif OCI VCN.

Les mises à jour du module d'extension CNI de mise en réseau de pod natif OCI VCN sont publiées régulièrement.

Dans les versions du module d'extension CNI de mise en réseau de pod natif OCI VCN antérieures à la version 2.3.0 (août 2025), vous pouvez indiquer qu'Oracle doit déployer automatiquement les mises à jour sur le cluster. Vous pouvez également indiquer que vous souhaitez choisir la version à déployer. Si vous décidez de choisir une version (et que la version est antérieure à la version 2.3.0), vous prenez la responsabilité de garder le module à jour. Le module d'extension CNI de mise en réseau de pod natif OCI VCN utilise la stratégie de mise à jour RollingUpdate, de sorte que les pods de module d'extension CNI existants prennent fin automatiquement et que de nouveaux pods sont créés en exécutant la nouvelle version du module d'extension CNI (pour plus d'informations sur la stratégie de mise à jour RollingUpdate, reportez-vous à Stratégie de mise à jour DaemonSet dans la documentation Kubernetes). Les mises à jour sont appliquées lors de la prochaine réinitialisation des noeuds de processus actif.

Dans le module d'extension CNI de mise en réseau de pod natif OCI VCN version 2.3.0 (août 2025) et versions ultérieures, les mises à jour de module d'extension CNI ne sont jamais déployées automatiquement sur le cluster. Le module d'extension CNI de mise en réseau de pod natif OCI VCN utilise la stratégie de mise à jour OnDelete. Le module d'extension CNI ne peut donc être mis à jour qu'en supprimant explicitement les pods de module d'extension CNI (pour plus d'informations sur la stratégie de mise à jour OnDelete, reportez-vous à Stratégie de mise à jour DaemonSet dans la documentation Kubernetes). Cette approche évite les redémarrages inattendus des pods de module d'extension CNI lors des mises à jour de cluster. La version 2.3.0 introduit également une politique d'admission de validation qui limite la suppression des pods de plug-in CNI. Pour mettre à jour le module d'extension CNI vers une version plus récente lors de l'utilisation de la version 2.3.0 ou ultérieure, adoptez l'une des techniques suivantes :

(recommandé) Provisionner de nouveaux noeuds dans le cluster : lorsque vous provisionnez de nouveaux noeuds dans le cluster, ils reçoivent automatiquement les pods de module d'extension CNI exécutant la dernière version de module d'extension CNI. Vous pouvez éventuellement purger et supprimer des noeuds avec des pods de module d'extension CNI qui exécutent des versions plus anciennes.
Mettre à jour les noeuds existants dans le cluster : vous pouvez mettre à jour la version du module d'extension CNI sur les noeuds existants en supprimant les pods de module d'extension CNI existants. Vous devez enlever la stratégie d'admission de validation qui limite la suppression du pod de module d'extension CNI, supprimer les pods de module d'extension CNI existants, puis restaurer la stratégie. DaemonsetController recrée les pods de module d'extension CNI, en exécutant la dernière version du module d'extension CNI. Suivez les étapes ci-après :
1. Identifiez les pods de plug-in CNI des noeuds existants à mettre à jour, en saisissant ce qui suit :
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Supprimez la stratégie d'admission de validation pour vous permettre de supprimer les pods de plug-in CNI comme suit :
  1. Enregistrez la stratégie d'admission de validation et la liaison de stratégie d'admission de validation sous les noms vap-policy.yaml et vap-binding.yaml afin de pouvoir les restaurer ultérieurement, en saisissant les commandes suivantes :
```
kubectl get validatingadmissionpolicy npn-pod-deletion-deny-policy -o yaml > vap-policy.yaml
```
```
kubectl get validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding -o yaml > vap-binding.yaml
```
  2. Supprimez la stratégie d'admission de validation et la liaison de stratégie d'admission de validation en saisissant les commandes suivantes :
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. Supprimez les pods de plug-in CNI que vous avez identifiés précédemment, en entrant la commande suivante pour chaque pod :
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. Restaurez la stratégie et la liaison de stratégie d'admission de validation que vous avez précédemment supprimées à l'aide des fichiers vap-policy.yaml et vap-binding.yaml que vous avez créés précédemment, en entrant les commandes suivantes :
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

Pour déterminer si des mises à jour ont été déployées et sont en attente d'application, examinez les journaux du jeu de démons vcn-native-ip-cni en saisissant la commande suivante :

kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"

Interprétez la réponse à la commande comme suit :