Selezione di un'interfaccia di rete del container

Cloud privato virtuale

Esaminare le seguenti informazioni per la selezione di un'interfaccia di rete del container (CNI).

In Red Hat OpenShift on IBM Cloud versione 4.20 e successive, Calico è il CNI predefinito, ma i cluster VPC che utilizzano i nodi worker RHCOS hanno la possibilità di selezionare Open Virtual Network (OVN) come CNI del cluster.

Calico Predefinito: Calico è un'unica piattaforma per il networking, la sicurezza di rete e l'osservabilità per qualsiasi distribuzione di Kubernetes nel cloud, on-premise o ai margini. Sia che abbiate appena iniziato con Kubernetes o che stiate operando su scala, le edizioni open source, enterprise e cloud di Calico forniscono la rete, la sicurezza e l'osservabilità di cui avete bisogno. Per ulteriori informazioni, consultare la documentazione di Calico.
OVN- Kubernetes (OVN) 4.20 e successivi Solo nodi worker RHCOS: OVN- Kubernetes si basa su Open Virtual Network (OVN) e fornisce un'implementazione di rete basata su overlay. Un cluster che utilizza il plugin OVN- Kubernetes esegue anche Open vSwitch (OVS) su ogni nodo. OVN configura OVS su ogni nodo per implementare la configurazione di rete dichiarata. Per ulteriori informazioni, consultare la sezione Red Hat documentazione

Confronto tra Calico e OVN

Esaminare la seguente tabella per confrontare le caratteristiche e le funzionalità di Calico e OVN.

Quando si utilizza OVN, è necessario assicurarsi che le sottoreti VPC non si sovrappongano alle sottoreti aggiuntive specificate nella tabella seguente. Se c'è una sovrapposizione di subnet, il collegamento in rete da pod a pod fallirà.

Layer2 Inoltre, le reti definite dall'utente (UDN) di layer3 non sono supportate con i carichi di lavoro che utilizzano il protocollo DHCP, come le macchine virtuali (VM) di OpenShift Virtualization.

Calico e tabella di confronto OVN
Componente	Calico	OVN- Kubernetes
Incapsulamento	IP in IP Protocol (non UDP o TCP ) Incapsula solo il traffico pod to pod da pod in esecuzione su nodi che si trovano in sottoreti diverse.	Geneve: UDP Protocollo sulla porta 6081 Incapsula tutto il traffico pod to pod
MTU predefinito della rete del cluster / Pod	1480 byte (20 byte di intestazione IPinIP ) per impostazione predefinita. Questo può essere modificato.	1400 byte (100 byte di intestazione Geneve) per impostazione predefinita. Questo può essere modificato. Daemonset deve creare il file NetworkManager invece di eseguire semplicemente `ip link set dev ens3 mtu`. È inoltre necessario riavviare i nuovi nodi worker.
Pod IPAM	Calico inizialmente assegna a ogni nuovo nodo una sottorete /26 (64 IP, di cui almeno uno tipicamente usato come IP tunl0, il resto è disponibile per i pod). Se tutti gli IP dei pod in una /26 sono utilizzati, Calico assegna una seconda subnet /26 al nodo e altre se/quando necessario. È possibile utilizzare il sito `calicoctl ipam check` per vedere le sottoreti assegnate a ciascun nodo.	OVN alloca inizialmente la subnet /24 pod (256 IP) a ogni nuovo nodo del cluster. Non è possibile aggiungere altre sottoreti pod. Inoltre, assegna un IP di sottorete a ogni nuovo nodo, che viene utilizzato internamente da OVN
Routing da pod a pod	Utilizza le rotte di Linux. Utilizza BGP per distribuire i percorsi. `tunl0` interfaccia su ogni nodo per l'incapsulamento.	Open vSwitch (OVS) viene eseguito su ogni nodo e instrada il traffico da pod a pod. OVN configura i flussi OVS per definire il routing pod to pod. Su ogni nodo vengono create molte altre interfacce, quali: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` e sono utilizzate da OVN e OVS
Politiche di rete Kubernetes	Implementato da `calico-node` aggiungendo regole iptables. La registrazione del traffico bloccato dalle politiche di rete è possibile, ma complicata. Richiede politiche aggiuntive di Calico che utilizzano un'azione "Log" e una certa riflessione e pianificazione su dove/quando inserire queste azioni di Log. I log vengono inviati a `syslog` sul nodo worker, che può essere difficile da recuperare. I log non includono la politica che ha permesso o bloccato il traffico.	Implementato da OVS utilizzando ACL su porte logiche (non iptables). La registrazione delle cadute dei criteri di rete e/o del traffico consentito è molto più semplice utilizzando le annotazioni. Si annotano gli spazi dei nomi in cui si vuole registrare l'attività della policy e se si vuole registrare i permessi, i dinieghi o entrambi. I registri vengono inviati al file `/var/log/ovn/acl-audit-log.log` nel pod `ovnkube-node`. Esistono opzioni di configurazione per inviare questi log ad altri target di log. I registri includono quale criterio ha permesso il traffico, ma non quale traffico lo ha negato, perché i criteri sono di sola autorizzazione. Per registrare il traffico consentito, deve essere presente almeno un criterio.
Politiche di rete dell'host	Calico GlobalNetworkPolicies	Nessuno
Sottoreti aggiuntive	Nessuno	Sottorete Join: `100.64.0.0/16` ( OpenShift default). Sottorete mascherata: `169.254.64.0/18`. Questo è diverso dall'impostazione predefinita di OpenShift di `169.254.0.0/17`. Questa differenza serve a evitare conflitti con gli IP di `169.254.2.0/24` utilizzati per l'haproxy del registro locale. Sottorete di transito:`100.88.0.0/16` ( OpenShift default).
Orologi APIserver	`calico-typha` registra gli orologi delle risorse e agisce come proxy verso i pod `calico-node` per notificare le modifiche. `calico-node` si connette a uno dei pod `calico-typha` e si registra per ricevere la notifica delle modifiche alle risorse.	Il contenitore `ovnkube-cluster-manager` nel piano di controllo controlla la presenza di nuovi nodi. Il contenitore `ovnkube-controller` su ogni nodo del cluster controlla le risorse e le traduce in voci logiche OVN nell'nbdb.
CNI	I binari CNI `calico` e `calico-ipam` vengono copiati su ogni nodo dal pod `install-cni` initContainer sul pod `calico-node`.	Il contenitore `ovnkube-node` del pod `ovnkube-controller` esegue il binario CNI per le chiamate di aggiunta e cancellazione.
Risorse create	`calico-apiserver` namespace `calico-apiserver` (distribuzione, 2 pod) `calico-system` namespace `calico-node` (ogni nodo) `calico-typha` (distribuzione, da 2 a 10 pod). `calico-kube-controllers` (1 nodo). `openshift-kube-proxy` spazio dei nomi. `openshift-kube-proxy` (ogni nodo). `tigera-operator` spazio dei nomi. `tigera-operator` (distribuzione, 1 pod). Il binario CNI `calico`, il binario CNI `calico-ipam` e vari altri binari CNI sono copiati su ogni nodo da `install-cni` initContainer su `calico-node`.	`openshift-ovn-kubernetes` `ovnkube-node` su ogni nodo con 8 container, `ovnkube-controller` controlla le risorse, alloca gli IP dei pod e traduce le risorse in voci logiche OVN in `nbdb`. Gestisce anche le aggiunte e le cancellazioni CNI. `nbdb` memorizza le voci logiche. `northd` converte le voci logiche di `nbdb` in flussi logici in `sbdb`. `sbdb` memorizza i flussi logici. `ovn-controller` converte i flussi logici in `sbdb` e programma lo switch OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protegge le metriche dei nodi, in modo che solo gli utenti autorizzati possano scalfirle. `kube-rbac-proxy-ovn-metrics` protegge le metriche di OVN, in modo che solo gli utenti autorizzati possano scraperarle.
Connessioni tra i baccelli	Il pod `calico-node` si connette inizialmente all'apiserver kube tramite haproxy locale in ascolto proxy su TCP 172.20.0.1:2040 per ottenere l'elenco di pod `calico-typha`. Il pod `calico-node` si connette a uno dei pod `calico-typha` sulla porta 5473 di TCP per ascoltare gli aggiornamenti delle risorse del cluster. Il pod `calico-node` esegue il demone BGP dell'uccello che si connette in una rete completa a tutti gli altri demoni BGP dell'uccello `calico-node` sulla porta 179 di TCP. Il traffico da pod a pod avviene direttamente per i pod sui nodi della stessa subnet. Il traffico da pod a pod tra pod su nodi in sottoreti diverse è incapsulato usando l'incapsulamento IPinIP (o VxLAN per i cluster Satellite ).	Il contenitore `ovnkube-controller` su ogni nodo si connette a kube apiserver tramite haproxy locale in pod proxy in ascolto su TCP `172.20.0.1:2040` per gli orologi delle risorse. Tutto il traffico da pod a pod è incapsulato con Geneve e viene inviato tramite la porta UDP 6081. Per ulteriori informazioni, vedere Configurazione del firewall.