Auswählen einer Container-Netzwerkschnittstelle

Virtual Private Cloud

Lesen Sie die folgenden Informationen zur Auswahl einer Container-Netzwerkschnittstelle (CNI).

In Red Hat OpenShift on IBM Cloud Version 4.20 und höher ist Calico die Standard-CNI, aber VPC-Cluster, die RHCOS-Arbeitsknoten verwenden, haben die Möglichkeit, Open Virtual Network (OVN) als Cluster-CNI zu wählen.

Calico Standard: Calico ist eine einzige Plattform für Netzwerke, Netzwerksicherheit und Beobachtbarkeit für jede Kubernetes Distribution in der Cloud, vor Ort oder am Rande. Ganz gleich, ob Sie gerade erst mit Kubernetes beginnen oder in großem Umfang arbeiten, die Open-Source-, Enterprise- und Cloud-Editionen von Calico bieten Ihnen das Netzwerk, die Sicherheit und die Beobachtbarkeit, die Sie benötigen. Weitere Informationen finden Sie in der Dokumentation Calico.
OVN- Kubernetes (OVN) 4.20 und später Nur RHCOS-Arbeitsknoten: OVN- Kubernetes basiert auf Open Virtual Network (OVN) und bietet eine Overlay-basierte Netzwerkimplementierung. Ein Cluster, der das OVN- Kubernetes Plugin verwendet, führt auch Open vSwitch (OVS) auf jedem Knoten aus. OVN konfiguriert OVS auf jedem Knoten, um die angegebene Netzwerkkonfiguration zu implementieren. Weitere Informationen finden Sie in der Dokumentation Red Hat

Vergleich zwischen Calico und OVN

In der folgenden Tabelle finden Sie einen Vergleich der Merkmale und Funktionen von Calico und OVN.

Wenn Sie OVN verwenden, müssen Sie sicherstellen, dass sich Ihre VPC-Subnetze nicht mit den in der folgenden Tabelle angegebenen zusätzlichen Subnetzen überschneiden. Wenn sich die Subnetze überschneiden, schlägt die Vernetzung von Pod zu Pod fehl.

Layer2 layer3-benutzerdefinierte Netzwerke (UDN) werden bei Workloads, die DHCP verwenden, wie z. B. Virtualisierungs-VMs von OpenShift, nicht unterstützt.

Calico und OVN-Vergleichstabelle
Komponente	Calico	OVN- Kubernetes
Verkapselung	IP in IP-Protokoll (nicht UDP oder TCP ) Verkapselt nur den Pod-zu-Pod-Verkehr von Pods, die auf Knoten laufen, die sich in verschiedenen Subnetzen befinden.	Geneve: UDP Protokoll auf Port 6081 kapselt den gesamten Pod-zu-Pod-Verkehr
Standard Cluster Netzwerk / Pod MTU	1480 Bytes (20 Byte IPinIP header) standardmäßig. Dies kann geändert werden.	1400 Bytes (100 Byte Geneve-Header) standardmäßig. Dies kann geändert werden. Daemonset muss die Datei NetworkManager erstellen, anstatt nur `ip link set dev ens3 mtu` auszuführen. Sie müssen auch neue Arbeiterknoten neu starten.
Pod IPAM	Calico weist jedem neuen Knoten zunächst ein /26-Subnetz zu (64 IPs, von denen mindestens eine typischerweise als tunl0 IP verwendet wird, der Rest ist für Pods verfügbar). Wenn alle Pod-IPs in einem /26 verwendet werden, weist Calico dem Knoten ein zweites /26-Subnetz zu, und bei Bedarf weitere. Sie können die `calicoctl ipam check` verwenden, um die jedem Knoten zugewiesenen Teilnetze zu sehen.	OVN weist jedem neuen Clusterknoten zunächst ein /24-Pod-Subnetz (256 IPs) zu. Es gibt keine Möglichkeit, weitere Pod-Subnetze hinzuzufügen. Außerdem wird jedem neuen Knoten eine IP für das Join-Subnetz zugewiesen, die intern von OVN verwendet wird
Pod-zu-Pod-Routing	Verwendet Linux-Routen. Verwendet BGP zur Verteilung von Routen. `tunl0` schnittstelle auf jedem Knoten für die Einkapselung.	Open vSwitch (OVS) läuft auf jedem Knoten und leitet den Pod-zu-Pod-Verkehr. OVN konfiguriert OVS-Ströme, um das Pod-zu-Pod-Routing zu definieren. Auf jedem Knoten werden viele andere Schnittstellen erstellt, wie z. B.: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, `br-ex` und werden von OVN und OVS verwendet
Kubernetes-Netzrichtlinien	Implementiert durch `calico-node` Hinzufügen von iptables-Regeln. Die Protokollierung des durch Netzwerkrichtlinien blockierten Datenverkehrs ist möglich, aber kompliziert. Es erfordert zusätzliche Calico Richtlinien, die eine "Log"-Aktion verwenden, sowie eine gewisse Überlegung und Planung, wo/wann diese Log-Aktionen platziert werden sollen. Protokolle auf `syslog` auf dem Arbeitsknoten, die schwer abrufbar sein können. Die Protokolle enthalten nicht, welche Richtlinie den Datenverkehr erlaubt oder blockiert hat.	Implementiert von OVS unter Verwendung von ACLs für logische Ports (nicht iptables). Die Protokollierung des von der Netzwerkrichtlinie abgelehnten und/oder erlaubten Datenverkehrs ist viel einfacher, wenn Sie Anmerkungen verwenden. Geben Sie den/die Namensraum/e an, in dem/denen Sie Richtlinienaktivitäten protokollieren möchten, und ob Sie erlaubten, verweigerten oder beides protokollieren möchten. Die Protokolle werden an die Datei `/var/log/ovn/acl-audit-log.log` im `ovnkube-node` pod gesendet. Es gibt Konfigurationsoptionen, um diese Protokolle an andere Protokollziele zu senden. In den Protokollen wird angegeben, welche Richtlinie den Datenverkehr zugelassen hat, aber nicht, welcher Datenverkehr verweigert wurde, da die Richtlinien nur zulassen. Es muss mindestens eine Richtlinie vorhanden sein, damit erlaubter Verkehr protokolliert werden kann.
Richtlinien für Hostnetzwerke	Calico GlobalNetworkPolicies	Keine
Zusätzliche Teilnetze	Keine	Subnetz beitreten: `100.64.0.0/16` ( OpenShift Standard). Masquerade-Subnetz: `169.254.64.0/18`. Dies unterscheidet sich von der Standardeinstellung OpenShift von `169.254.0.0/17`. Dieser Unterschied dient dazu, Konflikte mit den `169.254.2.0/24` IPs zu vermeiden, die für den lokalen Registry-Haproxy verwendet werden. Transit-Subnetz:`100.88.0.0/16` ( OpenShift Standard).
APIserver Uhren	`calico-typha` registriert Ressourcenüberwachungen und fungiert als Proxy für `calico-node` Pods, um über Änderungen zu informieren. `calico-node` stellt eine Verbindung zu einem der `calico-typha` Pods her und registriert sich für die Benachrichtigung über Ressourcenänderungen.	Der Container `ovnkube-cluster-manager` in der Steuerungsebene sucht nach neuen Knoten. Der Container `ovnkube-controller` auf jedem Clusterknoten sucht nach Ressourcen und übersetzt sie in logische OVN-Einträge in der nbdb.
CNI	Die CNI-Binärdateien `calico` und `calico-ipam` werden von `install-cni` initContainer auf dem Pod `calico-node` auf jeden Knoten kopiert.	Der `ovnkube-controller` Container des `ovnkube-node` Pods führt das CNI-Binary für Add- und Delete-Aufrufe aus.
Ressourcen erstellt	`calico-apiserver` Namensraum `calico-apiserver` (Bereitstellung, 2 Pods) `calico-system` Namensraum `calico-node` (jeder Knoten) `calico-typha` (Bereitstellung, von 2 - 10 Pods). `calico-kube-controllers` (1 Knoten). `openshift-kube-proxy` Namespace. `openshift-kube-proxy` (jeder Knoten). `tigera-operator` Namespace. `tigera-operator` (Bereitstellung, 1 Pod). Die CNI-Binärdatei `calico`, die CNI-Binärdatei `calico-ipam` und verschiedene andere CNI-Binärdateien werden von `install-cni` initContainer auf `calico-node` auf jeden Knoten kopiert.	`openshift-ovn-kubernetes` namespace, `ovnkube-node` auf jedem Knoten mit 8 Containern, `ovnkube-controller` überwacht Ressourcen, weist Pod-IPs zu und übersetzt Ressourcen in logische OVN-Einträge in `nbdb`. Bearbeitet auch das Hinzufügen und Löschen von CNI. `nbdb` speichert logische Einträge. `northd` konvertiert logische Einträge von `nbdb` in logische Abläufe in `sbdb`. `sbdb` speichert logische Abläufe. `ovn-controller` konvertiert logische Flüsse in `sbdb` und programmiert OVS-Switch. `ovn-acl-logging`. `kube-rbac-proxy-node` schützt Knotenmetriken, damit nur autorisierte Benutzer sie abrufen können. `kube-rbac-proxy-ovn-metrics` schützt OVN-Metriken, so dass nur autorisierte Benutzer sie abrufen können.
Verbindungen zwischen Gondeln	Der `calico-node`-Pod verbindet sich zunächst mit dem Kube-Apiserver über den lokalen Haproxy im Proxy-Pod, der auf TCP 172.20.0.1:2040 lauscht, um die `calico-typha`-Pod-Liste zu erhalten. Der `calico-node`-Pod stellt eine Verbindung zu einem der `calico-typha`-Pods auf TCP Port 5473 her, um auf Aktualisierungen der Cluster-Ressourcen zu warten. Der `calico-node`-Pod führt den BGP-Daemon bird aus, der sich in einem vollständigen Netz mit allen anderen `calico-node` bird BGP-Daemons auf TCP Port 179 verbindet. Der Pod-zu-Pod-Verkehr erfolgt direkt für Pods auf Knoten im selben Subnetz. Der Pod-zu-Pod-Verkehr zwischen Pods auf Knoten in verschiedenen Subnetzen wird mit IPinIP encapsulation (oder VxLAN für Satellite clusters) gekapselt.	Der Container `ovnkube-controller` auf jedem Knoten verbindet sich mit dem Kube-Apiserver über einen lokalen Haproxy im Proxy-Pod, der auf TCP `172.20.0.1:2040` für Ressourcenüberwachungen lauscht. Der gesamte Pod-zu-Pod-Verkehr wird mit Geneve gekapselt und über UDP Port 6081 gesendet. Weitere Informationen finden Sie unter Konfigurieren Ihrer Firewall.