Utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour la gestion de réseau de pods

Découvrez le plugiciel CNI de réseau de pods natif du VCN OCI pour la communication de pods sur les noeuds de travail dans les grappes créées à l'aide du moteur Kubernetes (OKE).

Le plugiciel CNI de réseau de pods natif du VCN OCI fournit des adresses IP aux pods à partir du bloc CIDR d'un VCN. Le plugiciel CNI de réseau de pods natif du VCN OCI permet à d'autres ressources du même sous-réseau (ou d'un sous-réseau différent) de communiquer directement avec les pods d'une grappe Kubernetes. Les adresses IP de pod sont directement routables à partir d'autres réseaux en nuage virtuels connectés (appairés) à ce VCN et à partir de réseaux sur place.

Comme les pods sont directement routables, vous pouvez utiliser la fonctionnalité VCN 'native' pour :

Contrôler 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é de réseau (recommandées) ou de listes de sécurité. Les règles de sécurité s'appliquent à tous les pods de tous les noeuds de travail connectés au sous-réseau de pod spécifié pour un groupe de noeuds. Voir Groupes de sécurité de réseau et Listes de sécurité.
Observez le trafic vers, depuis et entre les pods à l'aide des journaux de flux de VCN à des fins de dépannage et de vérification de la conformité. Voir Journaux de flux VCN.
Acheminer les demandes entrantes vers les pods en fonction des politiques d'acheminement spécifiées par les règles d'acheminement et les tables de routage. Voir Tables de routage de VCN.

Lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN OCI, les noeuds de travail sont connectés à deux sous-réseaux spécifiés pour le groupe de noeuds :

Sous-réseau de noeuds de travail : Le sous-réseau de noeuds de travail prend en charge la communication entre les processus exécutés sur le plan de contrôle de la grappe (tels que kube-apiserver, kube-controller-manager, kube-scheduler) et les processus exécutés sur le noeud de travail (tels que kubelet, kube-proxy). Le sous-réseau de noeuds de travail 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 travail, avec les pods sur d'autres noeuds de travail, avec les services OCI (au moyen d'une passerelle de service) et avec Internet (au moyen d'une passerelle NAT). Vous spécifiez un sous-réseau de pod unique pour tous les pods exécutés sur les noeuds de travail d'un groupe 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 groupes de noeuds d'une grappe. Vous pouvez spécifier le même sous-réseau de pod pour les groupes de noeuds dans des grappes différentes.

Le sous-réseau de noeuds de travail et le sous-réseau de pod doivent se trouver dans le même VCN. Dans certains cas, le sous-réseau de noeuds de travail et le sous-réseau de pod peuvent être le même sous-réseau (voir Nombre maximal de cartes vNIC et de pods pris en charge par différentes formes). Si le sous-réseau de noeuds de travail 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é de réseau (plutôt que dans les listes de sécurité) pour acheminer le trafic réseau vers les noeuds de travail et les pods. Le sous-réseau de noeuds de travail et le sous-réseau de pod s'ajoutent au sous-réseau de point d'extrémité de l'API Kubernetes et à tous les sous-réseaux d'équilibreurs de charge définis pour la grappe.

Lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN OCI, au moins deux cartes vNIC sont attachées à chaque noeud de travail. La première carte VNIC est connectée au sous-réseau de noeuds de travail. La deuxième carte VNIC est connectée au sous-réseau de pod. Par défaut, 31 adresses IP sont affectées à la carte VNIC pour être utilisées par les pods exécutés sur le noeud de travail. Pour éviter le manque d'adresses IP, les adresses IP sont préallouées dans le sous-réseau de pod avant la création des pods dans la grappe.

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

Vous pouvez spécifier le nombre maximal de pods à exécuter sur un seul noeud de travail dans un groupe 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 travail, la forme que vous spécifiez pour le groupe de noeuds doit prendre en charge trois cartes VNIC ou plus (une carte VNIC pour se connecter au sous-réseau de noeuds de travail et au moins deux cartes VNIC pour se connecter au sous-réseau de pod). Voir Nombre maximal de cartes vNIC et de pods pris en charge par différentes formes.

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

Notez ce qui suit lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI :

Vous pouvez utiliser le plugiciel CNI de réseau de pods natif du VCN OCI avec les groupes de noeuds virtuels et les groupes de noeuds gérés.
Vous pouvez utiliser le plugiciel CNI de réseau de pods natifs du VCN OCI avec des noeuds autogérés, à condition que les noeuds de plan de contrôle de la grappe exécutent Kubernetes version 1.27.10 (ou ultérieure). Pour plus d'informations, voir Utilisation de noeuds autogérés.
Vous pouvez uniquement utiliser le plugiciel CNI de réseau de pods natif du VCN pour OCI avec des grappes exécutant Kubernetes 1.22 ou une version ultérieure (voir Utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le réseau de pods). Pour plus d'informations, voir Réseau de pods.
Si vous utilisez le plugiciel CNI de réseau de pods natif du VCN OCI et que vous voulez spécifier une image OKE comme image de base pour les noeuds de travail, ne sélectionnez pas d'image OKE publiée avant juin 2022.
Si vous utilisez le plugiciel CNI de réseau de pods natif du VCN OCI et que vous voulez acheminer le trafic d'un réseau sur place vers un pod, notez que 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 (tels que Istio et Linkerd) sont pris en charge lors de l'utilisation du plugiciel CNI de réseau de pods natifs du VCN OCI pour le réseau de pods. Notez qu'à l'exception du module complémentaire Istio, la prise en charge est actuellement limitée à Oracle Linux 7 (la prise en charge d'Oracle Linux 8 est planifiée). Le module complémentaire Istio est pris en charge à la fois avec Oracle Linux 7 et Oracle Linux 8. Les noeuds de travail doivent exécuter Kubernetes 1.26 (ou version ultérieure).

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

Lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le réseau de pods, certaines règles de sécurité sont requises pour le sous-réseau de pod et le sous-réseau de noeud de travail. Voir Règles de sécurité pour les sous-réseaux de pods.

Nombre maximal de cartes vNIC et de pods pris en charge par différentes formes

Le nombre maximal de cartes vNIC (et donc le nombre maximal de pods) pour les noeuds de travail d'un groupe de noeuds dépend de la forme que vous sélectionnez pour le groupe de noeuds.

Pour connaître le nombre maximal de cartes vNIC pour une forme particulière, voir Formes de calcul.

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

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

Politique IAM supplémentaire pour accéder aux ressources avec les adresses IPv6

Pour utiliser le plugiciel CNI de réseau de pods natif du VCN OCI où les ressources connexes d'une grappe (telles que le point d'extrémité de l'API Kubernetes, l'équilibreur de charge et les noeuds de travail) ont des adresses IPv6, incluez un énoncé de politique similaire à celui qui suit dans une politique IAM :

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

Politique IAM supplémentaire lorsqu'une grappe et ses ressources connexes se trouvent dans des compartiments différents

Pour utiliser le plugiciel CNI de réseau de pods natif du VCN OCI dans le scénario inhabituel où les ressources connexes d'une grappe (telles que les groupes de noeuds, les ressources de VCN et de VCN) se trouvent dans un compartiment différent de celui de la grappe elle-même, vous devez inclure des énoncés de politique similaires aux suivants dans une politique 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 que ces énoncés de politique sont trop permissifs, vous pouvez restreindre les autorisations pour spécifier explicitement le compartiment auquel appartiennent les ressources connexes ou pour spécifier explicitement la grappe qui a des ressources connexes 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 groupes de noeuds et les instances de calcul.
<compartment-ocid-of-network-resources> est l'OCID du compartiment auquel appartiennent le VCN et les sous-réseaux.

Mise à jour du plugiciel CNI de réseau de pods natif du VCN pour OCI

Lorsque vous spécifiez un réseau de pods natif du VCN comme type de réseau d'une grappe, la grappe et ses groupes de noeuds exécutent initialement la dernière version du plugiciel CNI de réseau de pods natifs du VCN OCI.

Les mises à jour du plugiciel CNI de réseau de pods natif du VCN pour OCI sont publiées périodiquement.

Dans les versions de plugiciel CNI de réseau de pods natifs du VCN OCI antérieures à la version 2.3.0 (août 2025), vous pouvez spécifier qu'Oracle doit déployer automatiquement les mises à jour sur la grappe. Vous pouvez également spécifier 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 êtes responsable de la mise à jour du module complémentaire. Le plugiciel CNI de réseau de pods natifs du VCN OCI utilise la stratégie de mise à jour RollingUpdate. Les pods de plugiciel CNI existants sont donc arrêtés automatiquement et de nouveaux pods sont créés en exécutant la nouvelle version du plugiciel CNI (pour plus d'informations sur la stratégie de mise à jour RollingUpdate, voir DaemonSet Update Strategy dans la documentation sur Kubernetes). Les mises à jour sont appliquées lors du redémarrage suivant des noeuds de travail.

Dans le plugiciel CNI de réseau de pods natifs du VCN OCI version 2.3.0 (août 2025) et versions ultérieures, les mises à jour de plugiciel CNI ne sont jamais déployées automatiquement sur la grappe. Le plugiciel CNI de réseau de pods natifs du VCN OCI utilise la stratégie de mise à jour OnDelete. Le plugiciel CNI ne peut donc être mis à jour qu'en supprimant explicitement les pods du plugiciel CNI (pour plus d'informations sur la stratégie de mise à jour OnDelete, voir DaemonSet Update Strategy dans la documentation sur Kubernetes). Cette approche évite les redémarrages inattendus des pods de plugiciel CNI lors des mises à jour de grappe. La version 2.3.0 introduit également une politique d'admission de validation qui restreint la suppression des pods de plugiciel CNI. Pour mettre à jour le plugin 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 la grappe : Lorsque vous provisionnez de nouveaux noeuds dans la grappe, ils reçoivent automatiquement les pods de plugiciel CNI exécutant la dernière version du plugiciel CNI. Vous pouvez éventuellement drainer et supprimer des noeuds avec des pods de plugiciel CNI qui exécutent des versions plus anciennes.
Mettre à jour les noeuds existants dans la grappe : Vous pouvez mettre à jour la version du plugiciel CNI sur les noeuds existants en supprimant les pods de plugiciel CNI existants. Vous devez supprimer la politique d'admission de validation qui restreint la suppression du module d'extension CNI, supprimer les modules d'extension CNI existants, puis restaurer la politique. DaemonsetController recrée les pods du plugiciel CNI, en exécutant la dernière version du plugiciel CNI. Effectuez les étapes suivantes :
1. Identifiez les pods de plugiciel CNI des noeuds existants à mettre à jour, en entrant :
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Supprimez la politique d'admission en cours de validation pour vous permettre de supprimer les pods de plugiciel CNI comme suit :
  1. Enregistrez la politique d'admission de validation et la liaison de politique d'admission de validation en tant que vap-policy.yaml et vap-binding.yaml afin de pouvoir les restaurer plus tard, en entrant 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 politique d'admission de validation et la liaison de politique d'admission de validation, en entrant 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 plugiciel 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 politique d'admission et la liaison de politique 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 les mises à jour ont été déployées et attendent d'être appliquées, consultez les journaux du jeu de démons vcn-native-ip-cni en entrant :

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

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