Open Virtual Network (OVN)-Netzwerkfunktionen in „ Red Hat OpenShift “ für Administratoren von „ vSphere “

Erfahren Sie, wie sich das Open Virtual Networking (OVN)-Netzwerk in „ Red Hat OpenShift on IBM Cloud “ im Vergleich zu NSX-T darstellt und wie Sie die Netzwerktypen „User-Defined Network“ (UDN), „Cluster User-Defined Network“ (CUDN) und „Localnet“ nutzen können.

Wenn Sie bereits mit NSX-T gearbeitet haben, ist Ihnen das Grundkonzept bereits bekannt. Open Virtual Networking (OVN) ist die softwaredefinierte Netzwerkebene, die in „ OpenShift “ integriert ist. Es ersetzt den älteren Netzwerkstack „ Calico “ auf dieselbe Weise, wie NSX-T das Standard- vSwitches, abgelöst hat, indem die Netzwerkintelligenz in die Software verlagert wird, anstatt sich auf das zugrunde liegende physische Netzwerk zu stützen. OVN übernimmt die gesamte interne Cluster-Vernetzung: die Kommunikation zwischen den virtuellen Maschinen, den Zugriff auf externe Netzwerke sowie die Isolierung des Datenverkehrs zwischen Mandanten oder Workloads.

Bei der Bereitstellung eines neuen ROKS-Clusters wählen Sie zum Zeitpunkt der Bereitstellung entweder OVN oder „ Calico “ aus. Es gibt keinen Migrationspfad zwischen diesen beiden, genauso wie man auf einem laufenden VM ohne geplante Umstellung nicht zwischen einem Standard- vSwitch und einem dvSwitch wechseln kann.

OVN ist die softwaredefinierte Netzwerkebene, die in „ Red Hat OpenShift on IBM Cloud “ integriert ist. Ähnlich wie NSX-T die Standard- vSwitches, t OVN der ältere „ Calico “-Netzwerkstack, indem es die Netzwerkintelligenz in die Software verlagert, anstatt sich auf das zugrunde liegende physische Netzwerk zu stützen. OVN übernimmt die gesamte interne Cluster-Vernetzung, einschließlich der Kommunikation zwischen virtuellen Maschinen, des Zugriffs auf externe Netzwerke sowie der Isolierung des Datenverkehrs zwischen Mandanten oder Workloads.

Wenn Sie einen neuen „ Red Hat® OpenShift® on IBM Cloud® “-Cluster bereitstellen, müssen Sie sich bereits bei der Bereitstellung entweder für OVN oder „ Calico “ entscheiden, da es keinen Migrationspfad zwischen diesen beiden Optionen gibt. Der Wechsel zwischen Netzwerkstacks erfordert eine Planung der Umstellung, ähnlich wie beim Wechsel zwischen einem Standard- vSwitch und einem dvSwitch auf einer laufenden virtuellen Maschine.

Netzwerktypen

Die folgende Tabelle ordnet OVN-Konzepte den bekannten Konstrukten von „ vSphere “ zu:

OVN-Konzepte, die bekannten Netzwerkkonstrukten von „ vSphere “ zugeordnet sind
OVN-Konzept vSphere entsprechend
UDN oder CUDN Logisches NSX-Segment oder dvPortGroup
Cluster-Infrastruktur-Netzwerk (Primär) Hintergrundprozesse – Zustandsprüfungen, DNS, „ Kubernetes “-Dienste
VM Workload-Netzwerk (sekundär) Ihr aktuelles Netzwerk unter VM – die IP-Adresse, die Ihre Anwendung verwendet
Maskenball Netzwerk mit Network Address Translation (NAT) – VMs können Daten nach außen senden, es kommen jedoch keine Daten direkt herein
Sekundarstufe der Stufe 2 Isoliertes NSX-Overlay-Segment – statische IP-Adressen, vollständige Kontrolle
Ebene 2 – Primär Geroutetes NSX-Segment mit einem BGP-Uplink zum physischen Netzwerk
Localnet VLAN-gestützte „ dvPortGroup “ – direkte Weiterleitung an das physische Netzwerk

UDNs und CUDNs

Red Hat OpenShift gruppiert Workloads in Namespaces. Stellen Sie sich Namespaces als Ressourcenpools oder Ordner vor, die eine Anwendung oder ein Team von einer anderen bzw. einem anderen Team trennen. Netzwerkdefinitionen folgen dem gleichen Muster:

Benutzerdefiniertes Netzwerk (UDN)
Auf einen einzelnen Namespace beschränkt – entspricht einer Portgruppe, die nur von einem Cluster oder Ordner genutzt werden kann.
Cluster User-Defined Network (CUDN)
Kann sich über mehrere Namespaces erstrecken – vergleichbar mit einem gemeinsam genutzten „ dvPortGroup “, auf den von mehreren Clustern aus zugegriffen werden kann.

In der Regel konfiguriert man CUDNs, da sie flexibler sind und doppelte Netzwerkdefinitionen für jeden Namespace vermeiden, der Zugriff auf dasselbe Segment benötigt.

Cluster-Infrastrukturnetzwerk im Vergleich zum „ VM “-Workload-Netzwerk

Die Terminologie ist nicht intuitiv, daher ist es wichtig, dieses Konzept zu verstehen. OVN stuft Netzwerke als primär oder sekundär ein, doch diese Bezeichnungen beschreiben lediglich ihre Rolle im „ Red Hat OpenShift on IBM Cloud “-Cluster und nicht ihre Bedeutung für Ihre virtuellen Maschinen. Die Zuordnung sieht wie folgt aus:

Cluster-Infrastruktur-Netzwerk (primär)
Hintergrundprozesse, die den internen Datenverkehr von Kubernetes verarbeiten, wie z. B. Zustandsprüfungen, Service-Erkennung, virtuelle IP-Adressen (VIPs) des Lastenausgleichs und internes DNS. In der Regel nutzen Ihre virtuellen Maschinen dieses Netzwerk nicht für den Anwendungsdatenverkehr. Behalte es als Masquerade-Netzwerk bei. Dieses Netzwerk muss vorhanden sein, damit interne Pods und Dienste unter Red Hat OpenShift on IBM Cloud weiterhin funktionieren.
VM Workload-Netzwerk (sekundär)
Wo virtuelle Maschinen ausgeführt werden. Ihre Anwendungen nutzen dieses Netzwerk, Sie stellen über SSH eine Verbindung zu dessen IP-Adresse her und verwalten dessen Subnetz. Da es sich um ein sekundäres Netzwerk handelt, haben Sie die volle Kontrolle über die IP-Adressvergabe, einschließlich der statischen Zuweisung. Dieses Netzwerk ist für nahezu jede Workload auf virtuellen Maschinen die richtige Wahl.

Aus Sicht einer virtuellen Maschine mag diese Namensgebung zunächst widersprüchlich erscheinen. Aus Sicht des Clusters bedeutet „primär“ das „eigene Netzwerk des Clusters“ und „sekundär“ alles andere, was man daran anschließt Bei Workloads auf virtuellen Maschinen ist „sekundär“ kein nachträglicher Einfall. Dieses Netzwerk ist das Hauptnetzwerk.

Ein Namespace benötigt kein Netzwerk der Cluster-Infrastruktur. Wenn Ihre virtuellen Maschinen keine „ Kubernetes “-Dienste, Lastverteiler oder internes DNS benötigen, können Sie diesen Schritt überspringen und ausschließlich sekundäre Netzwerke betreiben.

Netztopologien

Masquerade – Cluster-Infrastruktur-Netzwerk (NAT)

Verwenden Sie dieses Netzwerk als Standard für das primäre Netzwerk der Cluster-Infrastruktur und für die Pods, die im Cluster ausgeführt werden. Wenn Sie es für Netzwerke virtueller Maschinen verwenden, funktioniert es wie eine virtuelle Maschine hinter einer NAT-Regel auf einem NSX Edge:

  • Virtuelle Maschinen können ausgehende Verbindungen zur Außenwelt herstellen.
  • Virtuelle Maschinen können keine direkten eingehenden Verbindungen von externen Quellen empfangen. Der Datenverkehr muss über einen Load Balancer oder einen Dienst geleitet werden, genauso wie Sie eine Destination-NAT-Regel (DNAT) auf einem NSX Edge verwenden würden, um einen Dienst zugänglich zu machen.
  • Virtuelle Maschinen verwenden eine automatische IP-Adressvergabe. Das schaffst du nicht.
  • Virtuelle Maschinen können alle Netzwerkfunktionen von „ Kubernetes “ nutzen, darunter Lastenausgleichsserver, Dienste, Netzwerkrichtlinien und DNS.

In einigen Edge-Anwendungsfällen ist möglicherweise das Masquerade-Netzwerk für Ihre virtuelle Maschine erforderlich, beispielsweise wenn Ihre virtuellen Maschinen direkten Zugriff auf Kubernetes-Dienste benötigen. In den meisten Anwendungsfällen für virtuelle Maschinen wird das Masquerade-Netzwerk jedoch nicht genutzt.

Layer-2-Primärnetz – direkt routingfähiges Netzwerk für virtuelle Maschinen (BGP-Uplink)

Diese Topologie entspricht einem NSX-Overlay-Segment, das mit einem „ Tier-0 “-Gateway verbunden ist, bei dem die BGP-Routenweiterverteilung aktiviert ist. Verwenden Sie diese eher selten genutzte Option, wenn virtuelle Maschinen direkt von externen Netzwerken aus erreichbar sein sollen, ohne dass ein Load Balancer oder NAT zwischengeschaltet wird:

  • Virtuelle Maschinen erhalten ihre IP-Adressen direkt aus dem Segment-Subnetz und sind von außen über das Routing erreichbar.
  • Externe Netzwerke erreichen einzelne virtuelle Maschinen über BGP-Routenankündigungen von jedem Worker-Knoten. Dieser Ansatz entspricht der Vorgehensweise des NSX Edge Service Routers (SR) bei der Weiterverteilung angeschlossener Routen.
  • Virtuelle Maschinen unterstützen Multicast und Broadcast.
  • Namespaces können die Masquerade-Funktion nicht nutzen, wenn Sie ein primäres Layer-2-Netzwerk aktivieren. Beides lässt sich nicht miteinander vereinbaren.

Derzeit unterstützt VPC keinen dynamischen Routing-Dienst (Border Gateway Protocol (BGP)), daher müssen benutzerdefinierte VPC-Routen mit Next-Hop verwendet werden.

Bei der IP-Adressvergabe kommt ein DHCP-System nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ zum Einsatz. IP-Adressen ändern sich während der Laufzeit einer virtuellen Maschine nicht, allerdings können Sie einer bestimmten virtuellen Maschine keine bestimmte IP-Adresse vorab zuweisen. Wenn Sie statische IP-Adressen benötigen, verwenden Sie stattdessen ein sekundäres Layer-2-Netzwerk.

In einigen Edge-Anwendungsfällen ist möglicherweise das Primärnetzwerk für Ihre virtuelle Maschine erforderlich, beispielsweise wenn Ihre virtuellen Maschinen direkten Zugriff auf Kubernetes-Dienste benötigen. In den meisten Anwendungsfällen für virtuelle Maschinen wird das primäre Netzwerk jedoch nicht genutzt.

Layer-2-Sekundärnetzwerk – Netzwerk für die Workloads virtueller Maschinen (isoliertes Segment)

Verwenden Sie diesen Netzwerktyp für nahezu alle Anwendungsfälle bei virtuellen Maschinen. Diese Topologie entspricht einem NSX-Overlay-Segment ohne externen Uplink: ein dediziertes Segment, über das Sie die vollständige Kontrolle haben.

  • Dieses Netzwerk unterstützt die Zuweisung statischer IP-Adressen. Sie verwalten die IP-Adressierung, was bei Workloads auf virtuellen Maschinen üblich ist.
  • Dieses Netzwerk stellt keine automatische Verbindung zur Außenwelt her. Um externen Zugriff zu ermöglichen, verbinden Sie eine virtuelle Firewall oder einen Router mit dem Segment – genau so, wie Sie eine virtuelle Maschine vom Typ „NSX Edge“ oder „ pfSense “ mit einem Segment in „ vSphere “ verbinden würden.
  • Unterstützt Multicast und Broadcast.
  • Sie können mehrere sekundäre Layer-2-Netzwerke an dieselbe virtuelle Maschine anbinden. Diese Konfiguration eignet sich dazu, den Anwendungs-, Verwaltungs- und Speicherdatenverkehr auf verschiedene Segmente aufzuteilen.
  • Das Netzwerk kann sich über mehrere Namespaces erstrecken, wenn es als CUDN konfiguriert ist.

Dieses Netzwerk ist die richtige Wahl für die meisten Workloads virtueller Maschinen in der Virtualisierungsumgebung „ Red Hat OpenShift “.

Localnet – direkter VLAN-Pass-Through

Diese Topologie entspricht am ehesten einer VLAN-gestützten Standard-Portgruppe oder einer verteilten virtuellen Portgruppe ( dvPortGroup ) ohne NSX-Overlay. Die virtuelle Maschine stellt eine direkte Verbindung zu dem Netzwerk her, mit dem der physische Host verbunden ist:

  • Diese Topologie nutzt kein Software-Defined-Networking-Overlay (SDN). Der Datenverkehr umgeht die OVN-Software-Switches vollständig.
  • Diese Topologie bietet keine Netzwerkdienste v Red Hat OpenShift on IBM Cloud, wie z. B. Lastenausgleich, Netzwerkrichtlinien oder internes DNS.
  • Diese Topologie umfasst keine integrierte IP-Adressverwaltung. Die Zuweisung von IP-Adressen erfolgt über VPC-Schnittstellen (VNIs).
  • Diese Topologie konfigurieren Sie pro Verfügbarkeitszone.
  • Diese Topologie unterstützt mehrere lokale Netzwerke auf derselben virtuellen Maschine.

Verwenden Sie „localnet“ für virtuelle Maschinen, die direkten Zugriff auf ein vorhandenes VPC-Subnetz benötigen. Beispielsweise könnten Sie eine ältere Anwendung migrieren, die über ein bestimmtes VLAN mit lokalen Systemen kommuniziert, oder eine Verbindung zu einem Speichernetzwerk herstellen, das außerhalb des Clusters liegt.

Zusammenfassung

Vergleich der Optionen für die OVN-Netzwerktopologie bei Workloads virtueller Maschinen
Netztyp Rolle Externer Zugriff Statische IP-Adressen Kubernetes-Services Broadcast / Multicast
Maskenball Cluster-Infrastruktur Ausgehende Verbindungen über NAT Nein Ja Nein
Ebene 2 – primär Direkt routbare virtuelle Maschinen Ja, über BGP-Routing Nein (nur DHCP) Ja Ja
Sekundarstufe der Stufe 2 Netzwerk für die Auslastung virtueller Maschinen Über einen angeschlossenen Router oder eine Firewall Ja Ja Ja
Localnet Physikalischer VLAN-Pass-Through Direkter VLAN-Zugang Manuell Nein Ja

Nächste Schritte

Lesen Sie die folgenden verwandten Themen, um weitere Informationen zu bestimmten OVN-Netzwerkoptionen zu erhalten: