Auswahl einer Container-Netzwerkschnittstelle

Virtual Private Cloud

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

In der Version IBM Cloud Kubernetes Service 4.20 und höher ist Calico die Standard-CNI, aber VPC-Cluster, die RHCOS-Worker-Knoten verwenden, haben die Möglichkeit, Open Virtual Network (OVN) als ihre Cluster-CNI auszuwählen.

Calico Standard: Calico ist eine einheitliche Plattform für Netzwerke, Netzwerksicherheit und Observability für jede Kubernetes-Distribution in der Cloud, vor Ort oder am Netzwerkrand. Ganz gleich, ob Sie gerade erst mit Kubernetes beginnen oder bereits in großem Maßstab arbeiten – die Open-Source-, Enterprise- und Cloud-Editionen von Calico bieten Ihnen die Netzwerkfunktionen, Sicherheit und Überwachungsmöglichkeiten, die Sie benötigen. Weitere Informationen finden Sie in der Dokumentation zu Calico.
OVN-Kubernetes (OVN) 4.20 und spätere VersionenNur RHCOS-Worker-Knoten: OVN- Kubernetes basiert auf Open Virtual Network (OVN) und bietet eine Overlay-basierte Netzwerkimplementierung. Ein Cluster, der das OVN- Kubernetes-Plugin verwendet, führt außerdem auf jedem Knoten Open vSwitch s (OVS) aus. OVN konfiguriert OVS auf jedem Knoten, um die angegebene Netzwerkkonfiguration zu implementieren. Weitere Informationen finden Sie in der Dokumentation zu Red Hat.

Vergleich zwischen Calico und OVN

Sehen Sie sich die folgende Tabelle an, um die Merkmale und Funktionen von Calico und OVN zu vergleichen.

Bei der Verwendung von OVN müssen Sie sicherstellen, dass sich Ihre VPC-Subnetze nicht mit den in der folgenden Tabelle angegebenen zusätzlichen Subnetzen überschneiden. Bei einer Überlappung von Subnetzen schlägt die Netzwerkverbindung zwischen den Pods fehl.

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

Calico sowie OVN-Vergleichstabelle
Komponente	Calico	OVN- Kubernetes
Kapselung	IP im IP-Protokoll (nicht UDP oder TCP ) – Kapseln nur den Datenverkehr zwischen Pods, die auf Knoten in unterschiedlichen Subnetzen laufen.	Geneve: UDP-Protokoll auf Port 6081 – Kapseln den gesamten Datenverkehr zwischen Pods
Standard-Cluster-Netzwerk / Pod-MTU	Standardmäßig 1.480 Byte (20-Byte- IPinIP-Header). Dies kann geändert werden.	Standardmäßig 1.400 Byte (100-Byte-Geneve-Header). Dies kann geändert werden. Daemonset muss eine NetworkManager-Datei erstellen, anstatt nur die Datei auszuführen `ip link set dev ens3 mtu`. Außerdem müssen Sie neue Worker-Knoten neu starten.
Pod IPAM	Calico Weist jedem neuen Knoten zunächst ein /26-Subnetz zu (64 IP-Adressen, von denen in der Regel mindestens eine als tunl0-IP verwendet wird; die übrigen stehen für Pods zur Verfügung). Wenn alle Pod-IP-Adressen in einem /26-Subnetz belegt sind, weist Calico dem Knoten ein zweites /26-Subnetz zu und bei Bedarf weitere. Mit dem können Sie die jedem Knoten zugewiesenen Subnetze `calicoctl ipam check` anzeigen.	OVN weist jedem neuen Cluster-Knoten zunächst ein /24-Pod-Subnetz (256 IP-Adressen) zu. Es besteht keine Möglichkeit, weitere Pod-Subnetze hinzuzufügen. Außerdem wird jedem neuen Knoten eine Join-Subnetz-IP 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 zur Kapselung.	Open vSwitch (OVS) läuft auf jedem Knoten und leitet den Datenverkehr zwischen den Pods weiter. OVN konfiguriert OVS-Flows, um das Routing zwischen den Pods zu definieren. Auf jedem Knoten werden viele weitere Schnittstellen erstellt, wie z. B.: `ovs-system`, `genev_sys_6081`, `ovn-k8s-mp0`, `br-int`, und `br-ex`, die von OVN und OVS genutzt werden
Kubernetes-Netzrichtlinien	Die Implementierung erfolgte durch das `calico-node` Hinzufügen von iptables-Regeln. Die Protokollierung von durch Netzwerkrichtlinien blockiertem Datenverkehr ist möglich, jedoch aufwendig. Dies erfordert zusätzliche Calico-Richtlinien, die eine Log-Aktion verwenden, sowie einige Überlegungen und Planungen dazu, wo und wann diese Log-Aktionen eingesetzt werden sollen. – Die Protokolle werden auf `syslog` dem Worker-Knoten gespeichert, was das Abrufen erschweren kann. – Die Protokolle enthalten keine Angaben dazu, welche Richtlinie den Datenverkehr zugelassen oder blockiert hat.	Die Umsetzung erfolgt durch OVS mithilfe von ACLs an logischen Ports (nicht über iptables). Die Protokollierung von durch die Netzwerkrichtlinie abgelehnten und/oder zugelassenen Datenverkehren ist durch die Verwendung von Annotationen wesentlich einfacher. Versehen Sie den oder die Namespaces, in denen Sie Richtlinienaktivitäten protokollieren möchten, mit Annotationen und geben Sie an, ob Sie Zulassungen, Ablehnungen oder beides protokollieren möchten. Die Protokolle werden an eine Datei im `/var/log/ovn/acl-audit-log.log` Pod `ovnkube-node` gesendet. Es gibt Konfigurationsoptionen, um diese Protokolle an andere Protokollziele zu senden. Die Protokolle enthalten Angaben dazu, welche Richtlinie den Datenverkehr zugelassen hat, jedoch nicht, welche ihn abgelehnt hat, da die Richtlinien ausschließlich Zulassungen vorsehen. Es muss mindestens eine Richtlinie vorhanden sein, damit zugelassener Datenverkehr protokolliert wird.
Richtlinien für Host-Netzwerke	Calico GlobalNetworkPolicies	Keine
Zusätzliche Subnetze	Keine	Subnetz zuweisen: `100.64.0.0/16` (Standard: OpenShift ). Masquerade-Subnetz: `169.254.64.0/18`. Dies weicht von der Standardeinstellung von OpenShift ab `169.254.0.0/17`. Dieser Unterschied dient dazu, Konflikte mit den IP-Adressen `169.254.2.0/24` zu vermeiden, die für den lokalen Registry-Haproxy verwendet werden. – Transit-Subnetz:`100.88.0.0/16` (Standard: OpenShift ).
APIserver-Überwachung	registriert `calico-typha` Ressourcenüberwachungen und fungiert als Proxy für Pods `calico-node`, um über Änderungen zu benachrichtigen. stellt `calico-node` eine Verbindung zu einem der Pods `calico-typha` her und registriert sich für Benachrichtigungen über Ressourcenänderungen.	Der Container `ovnkube-cluster-manager` in der Control Plane überwacht neue Knoten. Der `ovnkube-controller` Container auf jedem Clusterknoten überwacht Ressourcen und wandelt diese in logische OVN-Einträge in der nbdb um.
CNI	Die und `calico` `calico-ipam` CNI-Binärdateien werden vom initContainer`install-cni` auf dem Pod `calico-node` auf jeden Knoten kopiert.	Der Container `ovnkube-controller` des `ovnkube-node` Pods führt die CNI-Binärdatei für Add- und Delete-Aufrufe aus.
Ressourcen erstellt	`calico-apiserver` Namespace – ( `calico-apiserver` Deployment, 2 Pods) – `calico-system` Namespace – `calico-node` (jeder Knoten) – `calico-typha` (Deployment, 2 bis 10 Pods). – `calico-kube-controllers` (1 Knoten). – Namespace `openshift-kube-proxy`. – `openshift-kube-proxy` (jeder Knoten). – `tigera-operator` Namespace. – `tigera-operator` (Deployment, 1 Pod). Die `calico` CNI-Binärdatei, die `calico-ipam` CNI-Binärdatei und verschiedene andere CNI-Binärdateien werden von initContainer`install-cni` am auf jeden Knoten kopiert `calico-node`.	`openshift-ovn-kubernetes` Namespace, `ovnkube-node` auf jedem Knoten mit 8 Containern, `ovnkube-controller` überwacht Ressourcen, weist Pod-IPs zu und wandelt Ressourcen in logische OVN-Einträge in um `nbdb`. Behandelt außerdem das Hinzufügen und Löschen von CNI. – `nbdb` speichert logische Einträge. – `northd` konvertiert logische Einträge aus `nbdb` in logische Flows in `sbdb`. – `sbdb` speichert logische Flows. – `ovn-controller` konvertiert logische Flows in `sbdb` und programmiert den OVS-Switch. – `ovn-acl-logging`. – `kube-rbac-proxy-node` schützt Knotenmetriken, sodass nur autorisierte Benutzer diese abrufen können. – `kube-rbac-proxy-ovn-metrics` schützt OVN-Metriken, sodass nur autorisierte Benutzer diese abrufen können.
Verbindungen zwischen Pods	Der `calico-node` Pod stellt zunächst über den lokalen HAProxy im Proxy-Pod, der auf TCP172.20.0.1:2040 lauscht, eine Verbindung zum Kube-API-Server her, um die `calico-typha` Pod-Liste abzurufen. Der Pod `calico-node` verbindet sich mit einem der `calico-typha` Pods auf TCP, Port 5473, um auf Aktualisierungen der Cluster-Ressourcen zu warten. Der Pod `calico-node` führt den Bird-BGP-Daemon aus, der über ein Full-Mesh-Netzwerk mit allen anderen `calico-node` Bird-BGP-Daemons unter TCP auf Port 179 verbunden ist. Der Datenverkehr zwischen Pods erfolgt direkt, wenn sich die Pods auf Knoten im selben Subnetz befinden. Der Datenverkehr zwischen Pods auf Knoten in unterschiedlichen Subnetzen wird mithilfe der IPinIP-Kapselung (oder VxLAN für Satellite-Cluster) gekapselt.	Der Container `ovnkube-controller` auf jedem Knoten stellt über einen lokalen HAProxy im Proxy-Pod, der auf TCP lauscht, eine Verbindung zum Kube-API-Server her, `172.20.0.1:2040` um Ressourcenüberwachungen durchzuführen. Der gesamte Datenverkehr zwischen Pods wird mit Geneve gekapselt und über UDP auf Port 6081 gesendet. Weitere Informationen finden Sie unter Konfigurieren Ihrer Firewall.