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 networking pod nativo VCN come tipo di rete di un cluster, il cluster e i relativi pool di nodi utilizzano inizialmente la versione più recente del plugin CNI di networking pod nativo VCN OCI.

Gli aggiornamenti al plugin CNI di networking pod VCN nativo OCI vengono rilasciati periodicamente. È possibile specificare che si desidera che Oracle distribuisca automaticamente gli aggiornamenti sul cluster (impostazione predefinita). In alternativa, è possibile specificare che si desidera scegliere la versione da distribuire. Se decidi di scegliere la versione più recente, sei responsabile dell'aggiornamento del componente aggiuntivo. Vedere Configurazione dei componenti aggiuntivi cluster.

Indipendentemente dal fatto che tu o Oracle siate responsabili della distribuzione degli aggiornamenti al plugin CNI Pod Networking VCN nativo OCI, gli aggiornamenti vengono applicati solo al successivo riavvio dei nodi di lavoro. Per determinare se gli aggiornamenti sono stati distribuiti e sono in attesa di essere applicati, ispezionare i log del Daemonset vcn-native-ip-cni 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.