Planung Ihres Netzwerks für die Virtualisierung nach dem „ Red Hat OpenShift “-Prinzip auf IBM Cloud VPC
Entwerfen Sie das Netzwerk für die Virtualisierung von „ Red Hat OpenShift “ auf „ IBM Cloud VPC “ und berücksichtigen Sie dabei VPC-Netzwerke, „ OpenShift “, Software-Defined Networking (SDN) sowie benutzerdefinierte Netzwerke mit Open Virtual Networking (OVN).
Das Netzwerkdesign in Red Hat OpenShift Virtualization auf IBM Cloud VPC besteht aus den folgenden unterschiedlichen Schichten.
- VPC-Vernetzung
- Red Hat OpenShift Vernetzung
- OVN-Vernetzung
Die wichtigsten Elemente der Netzarchitektur sind in der folgenden Abbildung dargestellt.
IBM Cloud VPC Vernetzung
Sie verwenden das Netzwerk IBM Cloud VPC, um Cloud-Ressourcen bereitzustellen und zu verwalten. Sie bildet die Grundlage für Ihre Workloads, einschließlich virtueller Server, Container und Bare-Metal-Implementierungen, die zur Netzwerksegmentierung, Sicherheit und Skalierbarkeit beitragen können.
Sie müssen eine VPC erstellen, um eine „ Red Hat® OpenShift® “ bereitzustellen. Kubernetes Service Cluster.
Standardmäßige private Netzwerke mit Subnetzen
Sie müssen ein VPC-Subnetz in mindestens einer Verfügbarkeitszone erstellen, um einen Red Hat OpenShift Kubernetes Service-Cluster bereitzustellen. Weitere Informationen finden Sie unter Standardmäßige private Netzwerke mit Subnetzen.
Lastausgleichsfunktionen
Ein Red Hat OpenShift Ingress-Controller wird in Ihrem Red Hat OpenShift Kubernetes Service Cluster eingesetzt, der als Ingress-Endpunkt für externen Netzwerkverkehr fungiert. In einem Red Hat OpenShift Kubernetes Service Cluster wird automatisch ein VPC Application Load Balancer pro Cluster erstellt, um den Ingress-Controller freizugeben. Weitere Informationen finden Sie unter Load-Balancer.
Red Hat OpenShift Kubernetes Service erfüllt die folgenden Funktionen.
- Der DNS-Dienst löst die Subdomäne der Route in den Hostnamen des VPC-Lastverteilers auf.
- Der VPC-Load-Balancer ordnet den VPC-Hostnamen einer verfügbaren externen IP-Adresse eines Ingress-Controller-Dienstes zu, der als ordnungsgemäß funktionierend gemeldet wurde.
- Der VPC-Loadbalancer sendet die Anfrage an einen Ingress-Controller-Dienst.
- Der Ingress-Controller leitet die Anforderung über das private Netz an die private IP-Adresse des App-Pods weiter.
Virtuelle private Endpunkte
Virtuelle private Endpunkte (VPE) in Red Hat OpenShift Kubernetes Service Umgebungen werden in erster Linie verwendet, um eine private Konnektivität zwischen dem Red Hat OpenShift Cluster und den IBM Cloud Plattformdiensten zu ermöglichen, ohne dass der Netzwerkverkehr über das öffentliche Internet läuft.
In der folgenden Tabelle sind alle virtuellen privaten Endpunkte aufgeführt, die von IBM Cloud automatisch für wichtige Clusteroperationen bereitgestellt werden.
| Virtueller privater Endpunkt | Verwaltet von | Beschreibung |
|---|---|---|
| iks-api | Kubernetes Service API |
|
| iks-riaas | VPC Infrastructure Services |
|
| iks-Register | Container-Registry |
|
| iks-<cluster_id> | Spezifische Cluster-Instanz |
|
| iks-cos-config | Cloud Object Storage (Konfiguration) |
|
| iks-cos | Cloud Object Storage (Daten) |
|
Red Hat OpenShift Virtualisierung und Netzwerke
Red Hat OpenShift Die Virtualisierung nutzt die Netzwerkfunktionen von Red Hat OpenShift, um ein flexibles, softwaredefiniertes Netzwerk für virtuelle Server bereitzustellen, die neben containerisierten Arbeitslasten ausgeführt werden. Es ist
wichtig, den Unterschied zwischen virtuellen Server-Netzwerken und Pod-Netzwerken zu verstehen. Jeder virtuelle Server läuft innerhalb eines virt-launcher Pods, der immer mit dem Standard-Pod-Netzwerk verbunden ist.
┌────────────────────────────────┐
│ Worker Node │
│ ┌──────────────────────────┐ │
│ │ virt-launcher │ │ ← Kubernetes Pod Security Context
│ │ pod │ │
│ │ ┌────────────────────┐ │ │
│ │ │ virtual server │ │ │ ← KVM/QEMU Hypervisor Isolation
│ │ │ (QEMU) │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────┘ │
└────────────────────────────────┘
Je nachdem, wie Sie Ihren virtuellen Server bereitstellen und einrichten, teilt er sich ein Pod-Netzwerk (oder er kann sich mit Hilfe von multus mit verschiedenen Netzwerken verbinden).
Das folgende Beispiel beschreibt die Standard-Pod-Vernetzung in Red Hat OpenShift, die Sie mit OVN- Kubernetes Networking ändern können.
Pod-Netzwerke (Cluster-Netzwerk)
- Jeder Pod erhält eine private IP-Adresse aus dem Cluster-Netzwerk nach dem Classless Inter-Domain Routing (CIDR)-Schema
- Ermöglicht Pod-zu-Pod-Kommunikation zwischen Knotenpunkten
- Pods kommunizieren direkt über ihre privaten IPs innerhalb des Clusters
- Netzwerkrichtlinien steuern den Pod-zu-Pod-Verkehr auf Schicht 3/4
- Flaches Netzwerkmodell - alle Pods können standardmäßig kommunizieren
- Kein NAT zwischen Pods (direkte Pod-zu-Pod-Kommunikation)
- Netzwerkrichtlinien bieten Segmentierung und Sicherheit
- DNS-basierte Dienstsuche innerhalb des Clusters
- Wenn ein virtueller Server innerhalb des „virt-launcher“-Pods ausgeführt wird, wird die IP-Adresse mittels NAT (Network Address Translation) auf die IP-Adresse des „virt-launcher“-Pods umgeleitet
IP-Masquerading (Source-NAT (SNAT))
- Wenn Pods ausgehende Verbindungen zu externen Netzwerken initiieren, wird die Quell-IP maskiert
- Die Quell-IP-Adresse des Anforderungspakets wird in die IP-Adresse des Worker-Knotens geändert, auf dem der Pod ausgeführt wird
- IP-Masquerading ist notwendig, weil Pod-IPs außerhalb des Clusters nicht routbar sind
- Der zurückkehrende Verkehr wird an die ursprüngliche Pod-IP zurückgegeben
- Externe Dienste sehen Anfragen, die von Worker-Node-IPs kommen, nicht von Pod-IPs
ClusterIP dienstleistung
Dienste bieten stabile Endpunkte und Lastausgleich für Pods. Sie abstrahieren Pod-IPs und bieten einheitliche Zugangspunkte für Anwendungen. Der Dienst ClusterIP bietet die folgenden Funktionen.
- Erzeugt eine virtuelle IP ( ClusterIP ), die nur innerhalb des Clusters zugänglich ist
- ClusterIP ist der Standarddiensttyp, wenn nicht angegeben
- Bietet internen Lastausgleich zwischen Backend-Pods
- Verwendet kube-proxy oder OVN- Kubernetes für die Verkehrsverteilung
Die folgenden Anwendungsfälle sind ein Beispiel dafür, wofür eine ClusterIP verwendet wird.
- Interne Kommunikation der Mikrodienste
- Backend-Dienste, die keinen externen Zugriff erfordern
- Datenbankdienste, auf die nur von Cluster-Arbeitslasten zugegriffen wird
- Erkundung von Diensten zwischen den Pods
NodePort-Service
Dienste bieten stabile Endpunkte und Lastausgleich für Pods. Sie abstrahieren Pod-IPs und bieten einheitliche Zugangspunkte für Anwendungen. Der Dienst NodePort bietet die folgenden Funktionen.
- Stellt den Dienst an einem statischen Anschluss (Bereich 30000-32767) auf jedem Arbeitsknoten bereit
- Ermöglicht den Zugang zu Dienstleistungen durch
<NodeIP>:<NodePort> - Automatisch erstellter ClusterIP Dienst
- Der Verkehr zu einer beliebigen NodePort wird an den Dienst weitergeleitet
Das folgende Beispiel zeigt den Verkehrsfluss von NodePort.
- Externer Client verbindet sich mit
<WorkerNodeIP>:<NodePort> - Die Knoten leiten den Verkehr an den Dienst ClusterIP weiter
- Der Dienst gleicht die Last auf Backend-Pods aus
- Die Antwort wird mit SNAT (Source Network Address Translation) auf dem umgekehrten Weg zurückgesendet
Die folgenden Anwendungsfälle sind ein Beispiel dafür, wofür NodePorts verwendet wird.
- Entwicklungs- und Testumgebungen
- Schneller externer Zugriff ohne Load Balancer
- Integration mit externen Lastverteilern
- Kundenspezifische Lastausgleichslösungen
Lastausgleichsservice
Auf IBM Cloud Red Hat OpenShift Kubernetes Service stellt der Load Balancer Service automatisch einen VPC Netzwerk Load Balancer oder Application Load Balancer bereit. Der Lastausgleichsdienst bietet folgende Funktionen.
- Automatische Bereitstellung eines externen Load Balancers
- Weist dem Dienst eine externe IP oder einen Hostnamen zu
- Erstellt automatisch die Dienste NodePort und ClusterIP
- Bietet Schicht-4-Lastausgleich für Service-Backends
Das folgende Beispiel zeigt den Verkehrsfluss in einer VPC.
- Externer Client verbindet sich mit VPC Load Balancer IP oder Hostname
- VPC-Lastausgleicher verteilt an Arbeitsknoten NodePorts
- Node weiterleitung an den Dienst ClusterIP
- Der Dienst gleicht die Last auf Backend-Pods aus
Die folgenden Anwendungsfälle sind ein Beispiel für den Einsatz von Lastverteilern.
- Produktionsanwendungen, die einen speziellen externen Zugang erfordern
- Nicht HTTP Protokolle ( TCP oder UDP Dienste)
- Anwendungen, die stabile externe IPs benötigen
- Dienste, die die Eingangs- oder Routenschicht umgehen
Red Hat OpenShift Strecken
Red Hat OpenShift Routen machen Dienste für den externen Netzwerkverkehr zugänglich, indem sie vollqualifizierte Domänennamen (FQDNs) den Backend-Diensten zuordnen, wodurch Anwendungen auch außerhalb des Clusters erreichbar sind. Die folgende Liste enthält die wichtigsten Funktionen von Red Hat OpenShift Routes.
- Layer 7-Routing - HTTP / HTTPS Verkehr mit Hostnamen-basiertem Routing
- Automatisches DNS - Routen verwenden Cluster-Subdomain:
<route-name>-<namespace>.apps.<cluster-domain> - Ungesicherte Strecken ( HTTP )
- TLS-Terminierung
- Edge-terminierte Routen ( TLS am Router)
- Durchgangsrouten ( TLS bei Pod)
- Routen neu verschlüsseln ( TLS am Router und Pod)
- HAProxy-basiert, wird durch den Red Hat OpenShift Ingress Controller (Router) implementiert
- Verkehrsmanagement - Pfadbasiertes Routing, Verkehrsteilung und Sitzungsaffinität
Offene virtuelle Vernetzung (OVN)
Das OVN- Kubernetes- CNI-Plugin (Container Network Interface) ist die empfohlene Netzwerkoption für die „ Red Hat OpenShift “-Virtualisierung, die Anwendungsfälle für die Vernetzung virtueller Server unterstützt, die parallel zur herkömmlichen Pod-Vernetzung ausgeführt werden. OVN – „ Kubernetes “ basiert auf Open Virtual Networking (OVN) und nutzt auf jedem Worker-Knoten Open vSwitch (OVS). Es unterstützt Multi-Tenancy, NetworkPolicies, und hybride virtuelle Server und Pod-Netzwerke. Red Hat OpenShift on IBM Cloud VPC unterstützt OVN- Kubernetes als Standard-Netzwerk-Plugin.
Administratoren, die mit „ VMware vSphere “ und „NSX-T“ vertraut sind, finden unter „OVN-Netzwerk in OpenShift “ für „ vSphere “-Administratoren eine Zuordnung der OVN-Konzepte zu ihren Entsprechungen in „ vSphere “.
Unter Red Hat OpenShift mit OVN bieten die folgenden drei Netzwerktopologien eine sekundäre Netzwerkkonnektivität für Pods und virtuelle Server.
- Schicht 2 ( L2 )- Software-definierte L2 Broadcast-Domänen unter Verwendung der Geneve-Kapselung
- Schicht 3 ( L3 )- Geroutete Netzwerksegmente mit benutzerdefinierten IP-Subnetzen. Ein „ L3 “-Netzwerk verfügt pro Knoten über einen eigenen CIDR (Classless Inter-Domain Routing).
- Localnet - Direkter Zugang zu den VLANs des zugrunde liegenden physischen Netzwerks
In Red Hat OpenShift Virtualization auf IBM Cloud sind OVN Layer 2 und OVN Localnet die beiden primären Topologien, die mit User-Defined Networks (UDN) verwendet werden.
- OVN Layer 2 bietet Overlay-Netzwerke, die den NSX-Overlay-Segmenten ähnlich sind, indem sie Geneve-Kapselung verwenden, um softwaredefinierte L2 Broadcast-Domänen im gesamten Cluster zu erstellen. Diese Netzwerke sind von den VPC-Subnetzen isoliert. Sie benötigen einen Gateway-Pod oder virtuellen Server, der mit einem OVN Localnet verbunden ist, um Ingress und Egress zum VPC-Subnetz und eine VPC-Route bereitzustellen.
- OVN Localnet bietet VLAN-Zugriff auf das zugrunde liegende VPC-Netzwerk und ähnelt den NSX-Segmenten mit VLAN-Unterstützung. In IBM Cloud VPC ermöglicht diese direkte Konnektivität virtuellen Servern und Pods eine direkte Verbindung zu VPC-Subnetzen unter Verwendung eines Virtual Network Interface (VNI) und VLAN-Anhängen.
Die folgende Grafik gibt einen Überblick über die Vernetzung der virtuellen Server mit OVN und multus. Standardmäßig weist Kubernetes (und Red Hat OpenShift ) jedem Pod eine einzelne Netzwerkschnittstelle zu, indem es ein primäres
CNI-Plug-in (wie OVN- Kubernetes ) verwendet. Multus in Red Hat OpenShift ist ein CNI-Plug-in, das mehrere Netzwerkschnittstellen für Pods und virtuelle Server ermöglicht.
Anfänglich ist nur das OVN Layer 2 Netzwerk verfügbar.
OVN Benutzerdefinierte Netzwerke
Red Hat OpenShift Virtualisierung
Ein benutzerdefiniertes Netzwerk (UDN) in Red Hat OpenShift ist ein benutzerdefiniertes Netzwerk, das von OVN- Kubernetes bereitgestellt wird. Ein UDN ersetzt das standardmäßige Clusternetzwerk (auch als standardmäßiges Pod-Netzwerk bezeichnet). Mit UDNs können Sie Netzwerke mit eigenen IP-Subnetzen, Gateways und Routing-Domänen erstellen. UDNs sind unabhängig vom primären Pod-Netzwerk und werden in der Regel verwendet, wenn Arbeitslasten die folgenden Funktionen erfordern.
- Netzwerkisolierung von anderen Anwendungen im Cluster
- Benutzerdefinierte IP-Adressbereiche oder sich überschneidende Subnetze
- Direkte Kontrolle über den Ost-West-Verkehr zwischen ausgewählten Namespaces oder Workloads
- Integration mit virtuellen Servern ( Red Hat OpenShift virtualization), die mehrere Netzwerkschnittstellen benötigen
- Dedizierte Netzwerksegmente für Sicherheits- oder Compliance-Anforderungen
Im Gegensatz zum Standard-Pod-Netzwerk sind UDNs explizit mit Namespaces verbunden. Jeder UDN erzeugt einen zusätzlichen logischen Schalter im OVN. Wenn ein UDN als primäres benutzerdefiniertes Netzwerk des Namespaces gekennzeichnet ist, verwenden alle Pods und virtuellen Server in diesem Namespace dieses Netzwerk als Hauptnetzwerk anstelle des Standardclusters.
Cluster User-Defined Network (CUDN) erweitert das UDN-Konzept, indem es eine Cluster-Ressource bereitstellt, die keinem bestimmten Namespace angehört. Ein CUDN wird erstellt und ist mit einem oder mehreren Namensräumen verbunden. Im Gegensatz
zu NAD-Ressourcen (NAD = Namespace-scoped NetworkAttachmentDefinition ), die eine Ressource pro Namespace erfordern, erstellt ein CUDN automatisch NADs in Namespaces, wenn diese Namespaces zur CUDN-Definition hinzugefügt werden.
UDNs bieten flexible Netzwerkoptionen auf der Grundlage von Umfang, Anbringungsmethode und Topologie:
Umfang des Netzes
- Namespace-scoped UDN - Netzdefinition, die auf einen einzigen Namespace beschränkt ist und für jeden Namespace eine eigene NetworkAttachmentDefinitions erfordert
- Cluster-scoped CUDN - Netzwerkdefinition clusterweit verfügbar, automatische Erstellung von NetworkAttachmentDefinitions in ausgewählten Namespaces
Pfändungsmethode
- Primäres Netzwerk - fungiert als Standardnetzwerk für alle Pods/virtuellen Server im Namensraum und ersetzt das Standardnetzwerk des Clusters
- Sekundäres Netzwerk - wird über Multus CNI angeschlossen, um neben dem primären Netzwerk zusätzliche Netzwerkschnittstellen für Pods/virtuelle Server bereitzustellen
Netztopologie
- Schicht 2 – Softwaredefinierte Broadcast-Domäne „ L2 “ unter Verwendung der Geneve-Kapselung, die eine Erkennung auf Basis des Address Resolution Protocol (ARP) sowie die MAC-zu-MAC-Kommunikation ermöglicht
- Schicht 3 - Geroutete Netzwerksegmente mit benutzerdefinierten IP-Subnetzen und Gateways
- Localnet - Direkter VLAN-Zugang zu den zugrundeliegenden VPC-Subnetzen durch Verwendung von Virtual Network Interface (VNI)-Anhängen
Sie können diese Eigenschaften kombinieren, um maßgeschneiderte Netzwerklösungen zu schaffen. Ein CUDN mit Cluster-Abdeckung, das eine lokale Netztopologie verwendet, kann beispielsweise mehrere Namespaces mit direktem VPC-Subnetzzugang als primäres oder sekundäres Netzwerk bereitstellen.
OVN Schicht-2-Netze
Ein OVN-Layer-2-Netzwerk ist eine softwaredefinierte Layer-2-Broadcast-Domäne, die einem NSX-Overlay-Segment oder einem herkömmlichen VLAN ähnlich ist. Schicht 2 wird vollständig in OVN implementiert, indem Geneve-Kapselung über die bestehende Netzwerkinfrastruktur des Clusters verwendet wird. Ein Layer-2-Netzwerk ermöglicht es Pods und virtuellen Servern, so zu kommunizieren, als befänden sie sich im selben Ethernet-Segment, mit Unterstützung für ARP-Erkennung, Broadcast, Multicast und direkte MAC-zu-MAC-Kommunikation.
Ein Red Hat OpenShift Cluster hat ein primäres Clusternetzwerk, in dem Pods und virtuelle Server IPs von der Standard-Cluster-CIDR erhalten, die über OVN geroutet wird. Sie definieren ein sekundäres Layer-2-Netz durch ein ClusterUserDefinedNetwork (CUDN) oder ein Namespace-scoped UDN. Ein sekundäres Layer-2-Netzwerk ist jedes zusätzliche Netzwerk, das Sie über das Standard-Pod-Netzwerk hinaus erstellen.
Die folgenden Punkte sind wichtige Merkmale von Layer-2-Netzen.
- Bereitstellung von Layer-2-Broadcast-Domänen, die von OVN mit IPAM, MAC-Zuweisung und Konnektivität erstellt werden
- Keine integrierte DNS-Auflösung für Pod-Namen in sekundären Netzwerken
- Der Datenverkehr aus dem primären Layer-2-Netzwerk wird beim Verlassen des virtuellen Servers einer Quell-Netzwerkadressübersetzung (NAT) unterzogen und außerdem an das Layer-2-Netzwerk weitergeleitet, das mithilfe von „
FRR-K8s“ und VPC-Routen konfiguriert werden kann - Sekundäre Layer-2-Netze sind standardmäßig isoliert und haben keinen direkten Internetzugang, es sei denn, sie sind ausdrücklich konfiguriert
- Geeignet für die Kommunikation von virtuellem Server zu virtuellem Server innerhalb des Clusters und für Multicast-abhängige Anwendungen
OVN Lokale Netze
Ein OVN Localnet-Netzwerk bietet virtuellen Servern und Pods einen direkten VLAN-Zugang zur zugrunde liegenden VPC-Netzwerkinfrastruktur. OVN Localnet ermöglicht es virtuellen Servern und Pods, sich mit VPC-Subnetzen zu verbinden, indem sie eine virtuelle Netzwerkschnittstelle (VNI) und VLAN-Zuordnungen verwenden.
Mit VLAN-Anhängen können Sie virtuelle Server, die auf Red Hat OpenShift Virtualization laufen, direkt an VPC-Subnetze anhängen. Mit diesem Ansatz können Sie Ihr bestehendes VPC-Subnetzdesign für neue oder migrierte virtuelle Server verwenden, indem Sie ein konsistentes Netzwerk für Ihre Workloads bereitstellen.
Für die lokale Vernetzung muss jede virtuelle Server-NIC, die mit einem VPC-Subnetz verbunden ist, die folgenden Anforderungen erfüllen:
- Eine VNI-Ressource (Virtual Network Interface), die eine IP-Adresse definiert, die für das VPC-Subnetz reserviert ist, sowie eine oder mehrere Sicherheitsgruppen, die den ein- und ausgehenden Verkehr zur VNI kontrollieren.
- Eine Bare-Metal-Server-VLAN-Anlage. Die „Floating“-Funktion dieser VLAN-Zuordnung, die bestimmt, ob die Zuordnung zwischen Worker-Knoten verschoben werden kann, muss aktiviert sein, damit der virtuelle Server per Live-Migration auf einen anderen Worker-Knoten verschoben werden kann.
- EINE VLAN-ID. Das VLAN-Tag ordnet die PCI-Schnittstelle auf den Worker-Knoten zu. Normalerweise ist diese Zuordnung eine Eins-zu-Eins-Zuordnung zwischen VLAN-ID und VPC-Subnetz.
Beim Entwurf von Sicherheitsgruppenregeln für lokale Netze ist zu berücksichtigen, dass ein Teil des Netzwerkwechsels innerhalb von OVS auf dem Arbeitsknoten stattfindet und nie die VPC-Infrastruktur erreicht. Sicherheitsgruppenregeln werden nur auf den Verkehr angewendet, der die VPC-Netzwerkstruktur durchläuft. Der Verkehr zwischen virtuellen Servern auf demselben Arbeitsknoten kann die VPC-Sicherheitskontrollen umgehen.
Die folgenden Beispiele sind Anwendungsfälle für Localnet.
- Migrierte virtuelle Server, die bestehende VPC-Subnetz-IP-Adressen benötigen
- Integration in bestehende VPC-Sicherheitsgruppen und Netzwerkrichtlinien
- Direkte Konnektivität zu anderen VPC-Ressourcen
- Compliance-Anforderungen für die Netzwerksegmentierung durch die Verwendung von VPC-Subnetzen
- Hybride Architekturen, die eine einheitliche IP-Adressierung über VPC und Red Hat OpenShift Virtualisierung erfordern
Nächste Schritte
Nachdem Sie nun das Netzwerkdesign für die Red Hat OpenShift Virtualisierung verstanden haben, sollten Sie sich mit diesen verwandten Themen beschäftigen:
- Sicherheit: Überprüfung von Überlegungen zum Sicherheitsdesign, einschließlich Netzwerkrichtlinien und SCCs
- Berechnen: Untersuchen Sie Optionen für das Rechendesign von Arbeitsknoten
- Speicherung: Erfahren Sie mehr über Speicherdesignmuster für persistente Volumes
- Überprüfbarkeit: Verstehen von Observability-Lösungen für die Netzwerküberwachung