Selezione di un'interfaccia di rete del container

Cloud privato virtuale

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

Nella versione 4.20 di IBM Cloud Kubernetes Service e successive, Calico è il CNI predefinito, ma i cluster VPC che utilizzano nodi di lavoro RHCOS hanno la possibilità di selezionare Open Virtual Network (OVN) come CNI del cluster.

Calico Predefinito: Calico è un'unica piattaforma dedicata al networking, alla sicurezza di rete e all'osservabilità per qualsiasi distribuzione di Kubernetes nel cloud, in locale o all'edge. Che tu stia muovendo i primi passi con Kubernetes o che la tua attività sia già su larga scala, le edizioni open source, enterprise e cloud di Calico ti offrono le funzionalità di rete, sicurezza e osservabilità di cui hai bisogno. Per ulteriori informazioni, consultare la documentazione su Calico.
OVN - Kubernetes (OVN) 4.20 e versioni successive Solo nodi di lavoro 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 ciascun nodo. OVN configura OVS su ciascun nodo per implementare la configurazione di rete specificata. Per ulteriori informazioni, consultare la documentazione relativa a “ Red Hat ”

Confronto tra " Calico " e OVN

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

Quando si utilizza OVN, è necessario assicurarsi che le sottoreti della propria VPC non si sovrappongano alle sottoreti aggiuntive specificate nella tabella seguente. Se si verifica una sovrapposizione delle sottoreti, la connessione tra i pod non funzionerà.

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

Calico e tabella comparativa OVN
Componente	Calico	OVN- Kubernetes
Incapsulamento	Protocollo IP in IP (non UDP o TCP ) Incapsula solo il traffico da pod a pod proveniente da pod in esecuzione su nodi che si trovano in sottoreti diverse.	Ginevra: UDP Protocollo sulla porta 6081 Incapsula tutto il traffico da pod a pod
MTU predefinita della rete del cluster / del pod	1480 byte (intestazione " IPinIP " da 20 byte) per impostazione predefinita. Questo può essere modificato.	1400 byte (intestazione Geneve da 100 byte) per impostazione predefinita. Questo può essere modificato. Daemonset deve creare un file denominat NetworkManager, invece di limitarsi a eseguire il comando `ip link set dev ens3 mtu`. È inoltre necessario riavviare i nuovi nodi di lavoro.
Pod IPAM	Calico Inizialmente assegna a ogni nuovo nodo una sottorete /26 (64 indirizzi IP, di cui almeno uno viene solitamente utilizzato come IP dell' tunl0, mentre gli altri sono disponibili per i pod). Se tutti gli indirizzi IP dei pod in una subrete /26 sono occupati, Calico assegna una seconda subrete /26 al nodo e, se necessario, altre ancora. È possibile utilizzare il comando calicoctl ipam check per visualizzare le sottoreti assegnate a ciascun nodo.	OVN assegna inizialmente una sottorete /24 per i pod (256 indirizzi IP) a ciascun nuovo nodo del cluster. Non è possibile aggiungere altre sottoreti di pod. Inoltre, assegna a ogni nuovo nodo un indirizzo IP della sottorete di join, che viene utilizzato internamente da OVN
Instradamento da pod a pod	Utilizza le rotte Linux. Utilizza il BGP per distribuire le rotte. Interfaccia `tunl0` su ciascun nodo per l'incapsulamento.	Su ogni nodo è in esecuzione l’Open vSwitch (OVS), che instrada il traffico da pod a pod. OVN configura i flussi OVS per definire l’instradamento da pod a pod. Su ogni nodo vengono create molte altre interfacce, quali: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex`, che vengono utilizzate da OVN e OVS
Politiche di rete Kubernetes	Implementato da `calico-node` tramite l'aggiunta di regole iptables. È possibile registrare i traffici bloccati dalle politiche di rete, ma l'operazione risulta complessa. Richiede politiche di Calico aggiuntive che utilizzino un'azione "Log" e una certa riflessione e pianificazione su dove e quando inserire tali azioni "Log". I log vengono salvati su `syslog` sul nodo di lavoro, il che può rendere difficile il loro recupero. I log non indicano quale politica abbia consentito o bloccato il traffico.	Implementato da OVS tramite ACL sulle porte logiche (non tramite iptables). La registrazione degli eventi relativi al traffico rifiutato e/o consentito in base alle politiche di rete è molto più semplice utilizzando le annotazioni. È possibile annotare i namespace in cui si desidera registrare l’attività relativa alle politiche e specificare se si desidera registrare gli eventi di autorizzazione, di rifiuto o entrambi. I log vengono inviati al file `/var/log/ovn/acl-audit-log.log` nel pod `ovnkube-node`. Esistono opzioni di configurazione per inviare questi log ad altre destinazioni. I log includono quale politica ha consentito il traffico, ma non quale lo ha negato, poiché le politiche sono esclusivamente di tipo "consenti". Deve essere in vigore almeno una politica affinché il traffico consentito venga registrato.
Politiche di rete dell'host	Calico GlobalNetworkPolicies	Nessuno
Sottoreti aggiuntive	Nessuno	Sottorete di appartenenza: `100.64.0.0/16` ( OpenShift, impostazione predefinita). Sottorete di masquerade: `169.254.64.0/18`. Ciò differisce dall'impostazione predefinita di OpenShift, ovvero `169.254.0.0/17`. Questa differenza serve ad evitare conflitti con gli indirizzi IP `169.254.2.0/24` utilizzati per il registry locale di HAProxy. Sottorete di transito:`100.88.0.0/16` ( OpenShift per impostazione predefinita).
APIserver monitora	`calico-typha` registra i monitoraggi delle risorse e funge da proxy per i pod di `calico-node` per notificare le modifiche. `calico-node` si connette a uno dei pod di `calico-typha` e si registra per ricevere le notifiche relative alle modifiche delle risorse.	Il container " `ovnkube-cluster-manager` " nel piano di controllo monitora la presenza di nuovi nodi. Il container " `ovnkube-controller` " su ciascun nodo del cluster monitora le risorse e le traduce in voci logiche OVN nel database nbdb.
CNI	I file binari CNI `calico` e `calico-ipam` vengono copiati su ciascun nodo tramite il comando `install-cni` initContainer nel pod `calico-node`.	Il container `ovnkube-controller` del pod “ `ovnkube-node` ” esegue il binario CNI per le chiamate di aggiunta e cancellazione.
Risorse create	`calico-apiserver` namespace `calico-apiserver` (deployment, 2 pod) `calico-system` namespace `calico-node` (ogni nodo) `calico-typha` (deployment, da 2 a 10 pod). `calico-kube-controllers` (1 nodo). `openshift-kube-proxy` namespace. `openshift-kube-proxy` (ogni nodo). `tigera-operator` namespace. `tigera-operator` (distribuzione, 1 pod). Il binario CNI `calico`, il binario CNI `calico-ipam` e vari altri binari CNI vengono copiati su ogni nodo tramite `install-cni` initContainer su `calico-node`.	Lo spazio dei nomi `openshift-ovn-kubernetes`, `ovnkube-node` su ciascun nodo con 8 container, `ovnkube-controller` monitora le risorse, assegna gli indirizzi IP ai pod e traduce le risorse in voci logiche OVN in `nbdb`. Gestisce anche l'aggiunta e l'eliminazione di voci CNI. `nbdb` memorizza le voci logiche. `northd` converte le voci logiche da `nbdb` in flussi logici in `sbdb`. `sbdb` memorizza i flussi logici. `ovn-controller` converte i flussi logici in `sbdb` e configura lo switch OVS. `ovn-acl-logging`. `kube-rbac-proxy-node` protegge le metriche dei nodi in modo che solo gli utenti autorizzati possano estrarle. `kube-rbac-proxy-ovn-metrics` protegge le metriche OVN in modo che solo gli utenti autorizzati possano estrarle.
Collegamenti tra i pod	Il pod " `calico-node` " si connette inizialmente all'apiserver di Kubernetes tramite un haproxy locale nel pod proxy, in ascolto su TCP 172.20.0.1:2040, per ottenere l'elenco dei pod `calico-typha`. Il pod `calico-node` si connette a uno dei pod `calico-typha` su TCP alla porta 5473 per ascoltare gli aggiornamenti delle risorse del cluster. Il pod `calico-node` esegue il daemon BGP bird che si connette in una rete a maglia completa a tutti gli altri daemon BGP bird `calico-node` su TCP alla porta 179. Il traffico da pod a pod avviene direttamente per i pod sui nodi nella stessa sottorete. Il traffico da pod a pod tra pod su nodi in sottoreti diverse viene incapsulato utilizzando l’incapsulamento IPinIP (o VxLAN per i cluster Satellite ).	Il container ovnkube-controller su ciascun nodo si connette a `kube apiserver` tramite un `haproxy` locale nel pod proxy, in ascolto su TCP `172.20.0.1:2040` per il monitoraggio delle risorse. Tutto il traffico da pod a pod viene incapsulato utilizzando Geneve e inviato tramite UDP sulla porta 6081. Per ulteriori informazioni, consultare la sezione "Configurazione del firewall".