Uso del plugin CNI Networking pod VCN nativo OCI per il networking pod

Scopri il plugin CNI Pod Networking VCN nativo OCI per la comunicazione pod sui nodi di lavoro nei cluster creati utilizzando Kubernetes Engine (OKE).

Il plugin CNI di networking pod VCN nativo OCI fornisce indirizzi IP ai pod dal blocco CIDR di una VCN. Il plugin CNI Pod Networking VCN nativo OCI consente ad altre risorse all'interno della stessa subnet (o di una subnet diversa) di comunicare direttamente con i pod in un cluster Kubernetes. Gli indirizzi IP del pod vengono instradati direttamente da altre VCN connesse (con peer) a tale VCN e dalle reti on premise.

Poiché i pod sono instradabili direttamente, puoi utilizzare la funzionalità VCN 'nativa' per:

Controlla l'accesso a e dai pod utilizzando regole di sicurezza definite come parte dei gruppi di sicurezza di rete (consigliato) o degli elenchi di sicurezza. Le regole di sicurezza si applicano a tutti i pod in tutti i nodi di lavoro connessi alla subnet pod specificata per un pool di nodi. Vedere Gruppi di sicurezza di rete ed Elenchi di sicurezza.
Osservare il traffico verso, da e tra i pod utilizzando i log di flusso della VCN per la risoluzione dei problemi e l'audit della conformità. Vedere Log di flusso VCN.
Instrada le richieste in entrata ai pod in base ai criteri di instradamento specificati dalle regole di instradamento e dalle tabelle di instradamento. Vedere Tabelle di instradamento della VCN.

Quando si utilizza il plugin CNI di networking pod VCN nativo OCI, i nodi di lavoro sono connessi a due subnet specificate per il pool di nodi:

Subnet nodo lavoratore: la subnet nodo lavoratore supporta la comunicazione tra i processi in esecuzione sul piano di controllo cluster (ad esempio kube-apiserver, kube-controller-manager, kube-scheduler) e i processi in esecuzione sul nodo di lavoro (ad esempio kubelet, kube-proxy). La subnet del nodo di lavoro può essere privata o pubblica e può essere una subnet regionale (consigliata) o su subnet diverse specifiche di AD (una in ogni dominio di disponibilità nell'area).
Subnet del pod: la subnet del pod supporta la comunicazione tra i pod e l'accesso diretto ai singoli pod utilizzando gli indirizzi IP dei pod privati. La subnet pod deve essere privata e deve essere una subnet regionale. La subnet pod consente ai pod di comunicare con altri pod sullo stesso nodo di lavoro, con i pod su altri nodi di lavoro, con i servizi OCI (tramite un gateway di servizi) e con Internet (tramite un gateway NAT). È possibile specificare una singola subnet pod per tutti i pod in esecuzione sui nodi di lavoro in un pool di nodi. È possibile specificare la stessa subnet pod o subnet pod diverse per pool di nodi diversi in un cluster. È possibile specificare la stessa subnet pod per i pool di nodi in cluster diversi.

La subnet del nodo di lavoro e la subnet del pod devono trovarsi nella stessa VCN. In alcuni casi, la subnet del nodo di lavoro e la subnet del pod possono essere la stessa subnet (vedere Numero massimo di VNIC e pod supportati da forme diverse). Se la subnet del nodo di lavoro e la subnet del pod sono la stessa subnet, Oracle consiglia di definire le regole di sicurezza nei gruppi di sicurezza di rete (anziché nelle liste di sicurezza) per instradare il traffico di rete ai nodi e ai pod di lavoro. La subnet del nodo di lavoro e la subnet del pod si aggiungono alla subnet dell'endpoint API Kubernetes e a qualsiasi subnet del load balancer definita per il cluster.

Quando si utilizza il plugin CNI di networking pod VCN nativo OCI, a ogni nodo di lavoro vengono collegate almeno due VNIC. La prima VNIC è connessa alla subnet del nodo di lavoro. La seconda VNIC è connessa alla subnet pod. Per impostazione predefinita, 31 indirizzi IP vengono assegnati alla VNIC per essere utilizzati dai pod in esecuzione sul nodo di lavoro. Per evitare l'esaurimento degli indirizzi IP, gli indirizzi IP vengono preallocati nella subnet pod prima che i pod vengano creati nel cluster.

Se la forma selezionata per il pool di nodi supporta più di due VNIC, è possibile connettere le VNIC aggiuntive alla subnet pod per fornire ulteriori indirizzi IP per supportare più pod.

È possibile specificare il numero massimo di pod che si desidera eseguire su un singolo nodo di lavoro in un pool di nodi, fino a un limite di 110. Il limite di 110 è imposto da Kubernetes. Se si desidera disporre di più di 31 pod su un singolo nodo di lavoro, la forma specificata per il pool di nodi deve supportare tre o più VNIC (una VNIC per connettersi alla subnet del nodo di lavoro e almeno due VNIC per connettersi alla subnet del pod). Vedere Maximum number of VNICs and Pods Supported by Different Shapes.

Se si desidera conservare lo spazio di indirizzi della subnet pod, ridurre il numero massimo di pod che si desidera eseguire su un singolo nodo di lavoro e quindi ridurre il numero di indirizzi IP preallocati nella subnet pod.

Tenere presente quanto riportato di seguito quando si utilizza il plugin CNI Networking pod VCN nativo:

È possibile utilizzare il plugin CNI di networking pod VCN nativo OCI con entrambi i pool di nodi virtuali e i pool di nodi gestiti.
È possibile utilizzare il plugin CNI di networking pod VCN nativo OCI con nodi autogestiti, a condizione che i nodi del piano di controllo del cluster eseguano Kubernetes versione 1.27.10 (o successiva). Per ulteriori informazioni, vedere Utilizzo dei nodi gestiti automaticamente.
È possibile utilizzare solo il plugin CNI di networking pod nativo VCN OCI con cluster che eseguono Kubernetes 1.22 o versioni successive (vedere Uso del plugin CNI di networking pod nativo VCN OCI per il networking pod). Per maggiori informazioni, vedere Pod Networking.
Se si utilizza il plugin CNI di networking pod VCN nativo OCI e si desidera specificare un'immagine OKE come immagine di base per i nodi di lavoro, non selezionare un'immagine OKE rilasciata prima di giugno 2022.
Se si utilizza il plugin CNI di networking pod nativo VCN OCI e si desidera instradare il traffico da una rete in locale a un pod, tenere presente che l'indirizzo IP del pod non è persistente se il pod viene ricreato. Ad esempio, un pod Nginx potrebbe inizialmente avere 10.0.0.5 come indirizzo IP, ma se il pod viene eliminato e ricreato, il pod potrebbe avere un indirizzo IP diverso (ad esempio 10.0.0.8).
I prodotti di mesh di servizio (come Istio e Linkerd) sono supportati quando si utilizza il plugin CNI di networking pod nativo per la VCN OCI per il pod networking. Si noti che, ad eccezione del componente aggiuntivo Istio, il supporto è attualmente limitato a Oracle Linux 7 (è previsto il supporto per Oracle Linux 8). L'add-on Istio è supportato sia da Oracle Linux 7 che da Oracle Linux 8. I nodi di lavoro devono eseguire Kubernetes 1.26 (o versioni successive).

Regole di sicurezza per nodi e pod di lavoratori

Quando si utilizza il plugin CNI di networking pod nativo VCN OCI per il networking pod, sono necessarie alcune regole di sicurezza per la subnet pod e la subnet nodo di lavoro. Vedere Regole di sicurezza per le subnet pod.

Numero massimo di VNIC e pod supportati da forme diverse

Il numero massimo di VNIC (e quindi il numero massimo di pod) per i nodi di lavoro in un pool di nodi dipende dalla forma selezionata per il pool di nodi.

Per informazioni sul numero massimo di VNIC per una determinata forma, vedere Forme di computazione.

Per calcolare il numero massimo di pod in un pool di nodi di una particolare forma, utilizzare l'equazione seguente:

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

Criterio IAM aggiuntivo per accedere alle risorse con indirizzi IPv6

Per utilizzare il plugin CNI di networking pod VCN nativo OCI in cui le risorse correlate di un cluster (ad esempio l'endpoint API Kubernetes, il load balancer e i nodi di lavoro) dispongono di indirizzi IPv6, includere un'istruzione dei criteri simile alla seguente in un criterio IAM:

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

Criterio IAM aggiuntivo quando un cluster e le relative risorse correlate si trovano in compartimenti diversi

Per utilizzare il plugin CNI di networking pod VCN nativo OCI nello scenario non comune in cui le risorse correlate di un cluster (ad esempio i pool di nodi, le risorse VCN e VCN) si trovano in un compartimento diverso rispetto al cluster stesso, è necessario includere istruzioni dei criteri simili alle seguenti in un criterio 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' }

Se si ritiene che queste istruzioni dei criteri siano troppo permissive, è possibile limitare le autorizzazioni per specificare in modo esplicito il compartimento a cui appartengono le risorse correlate e/o per specificare in modo esplicito il cluster che dispone di risorse correlate in un compartimento diverso. Ad esempio:

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>' }

Dove:

<compartment-ocid-of-nodepool> è l'OCID del compartimento a cui appartengono nodepools e le istanze di computazione.
<compartment-ocid-of-network-resources> è l'OCID del compartimento a cui appartengono la VCN e le subnet.

Aggiornamento del plugin CNI Networking pod VCN nativo

Quando si specifica il pod networking nativo per la VCN come tipo di rete di un cluster, il cluster e i relativi pool di nodi eseguono inizialmente la versione più recente del plugin CNI per il pod networking nativo per la VCN OCI.

Gli aggiornamenti al plugin CNI di rete pod nativa per la VCN OCI vengono rilasciati periodicamente.

Nelle versioni del plugin CNI per la rete dei pod nativi della VCN OCI precedenti alla versione 2.3.0 (agosto 2025), è possibile specificare che si desidera che Oracle distribuisca automaticamente gli aggiornamenti nel cluster. In alternativa, è possibile specificare che si desidera scegliere la versione da distribuire. Se si decide di scegliere una versione (e la versione è precedente alla versione 2.3.0), si assume la responsabilità di mantenere il componente aggiuntivo aggiornato. Il plugin CNI per il pod networking nativo VCN OCI utilizza la strategia di aggiornamento RollingUpdate, quindi i pod del plugin CNI esistenti vengono interrotti automaticamente e vengono creati nuovi pod che eseguono la nuova versione del plugin CNI (per ulteriori informazioni sulla strategia di aggiornamento di RollingUpdate, vedere DaemonSet Update Strategy nella documentazione di Kubernetes). Gli aggiornamenti vengono applicati al successivo reboot dei nodi di lavoro.

Nel plugin CNI per la rete di pod nativi della VCN OCI versione 2.3.0 (agosto 2025) e versioni successive, gli aggiornamenti del plugin CNI non vengono mai distribuiti automaticamente nel cluster. Il plugin CNI di pod networking nativo per la VCN OCI utilizza la strategia di aggiornamento OnDelete, quindi il plugin CNI può essere aggiornato solo eliminando in modo esplicito i pod del plugin CNI (per ulteriori informazioni sulla strategia di aggiornamento di OnDelete, vedere DaemonSet Update Strategy nella documentazione di Kubernetes). Questo approccio evita riavvii imprevisti dei pod del plugin CNI durante gli aggiornamenti del cluster. La versione 2.3.0 introduce anche un criterio di ammissione di convalida che limita la cancellazione dei pod del plugin CNI. Per aggiornare il plugin CNI a una versione più recente quando si utilizza la versione 2.3.0 o successiva, adottare una delle seguenti tecniche:

(consigliato) Eseguire il provisioning di nuovi nodi nel cluster: quando si esegue il provisioning di nuovi nodi nel cluster, questi ricevono automaticamente i pod del plugin CNI che eseguono la versione più recente del plugin CNI. Facoltativamente, è possibile svuotare e rimuovere i nodi con i pod del plugin CNI che eseguono versioni precedenti.
Aggiorna nodi esistenti nel cluster: è possibile aggiornare la versione del plugin CNI sui nodi esistenti eliminando i pod del plugin CNI esistenti. È necessario rimuovere il criterio di ammissione di convalida che limita l'eliminazione del pod del plugin CNI, eliminare i pod del plugin CNI esistenti e quindi ripristinare il criterio. DaemonsetController ricrea i pod del plugin CNI, eseguendo l'ultima versione del plugin CNI. Attenersi alla procedura seguente:
1. Identificare i pod del plugin CNI dei nodi esistenti da aggiornare, inserendo:
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. Eliminare il criterio di ammissione di convalida per consentire l'eliminazione dei pod del plugin CNI come indicato di seguito.
  1. Salvare la polizza di ammissione di convalida e l'associazione della polizza di ammissione di convalida come vap-policy.yaml e vap-binding.yaml in modo da poterli ripristinare in un secondo momento, inserendo i seguenti comandi:
```
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. Eliminare il criterio di ammissione di convalida e il binding del criterio di ammissione di convalida immettendo i comandi seguenti:
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. Eliminare i pod del plugin CNI identificati in precedenza, immettendo il seguente comando per ogni pod:
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. Ripristinare il criterio di ammissione di convalida e l'associazione dei criteri precedentemente eliminati, utilizzando i file vap-policy.yaml e vap-binding.yaml creati in precedenza, immettendo i seguenti comandi:
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

Per determinare se gli aggiornamenti sono stati distribuiti e sono in attesa di essere applicati, esaminare i log di vcn-native-ip-cni Daemonset immettendo:

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

Interpretare la risposta al comando come indicato di seguito.