Verstehen von virtuellen Netzwerkschnittstellen in VPC-Clustern
Virtuelle private Cloud 4.20 und später Nur Bare Metal Worker Nodes
Virtuelle Netzwerkschnittstellen (VNIs) bieten erweiterte Netzwerkkonnektivitätsoptionen für Workloads, die auf Red Hat OpenShift on IBM Cloud VPC-Clustern mit Bare Metal Worker Nodes ausgeführt werden.
Was sind virtuelle Netzwerkschnittstellen?
Ein Virtual Network Interface (VNI) ist eine IBM Cloud VPC-Abstraktion, die einzelne Netzwerkverbindungen darstellt. VNIs betten Eigenschaften einer Netzverbindung ein, darunter:
- IP-Adressen (primär und sekundär)
- MAC-Adressen
- VPC-Subnetz-Zuordnung
- Mitgliedschaft in einer Sicherheitsgruppe
VNIs sind nur auf Clustern mit Bare Metal Worker Nodes verfügbar, auf denen Red Hat CoreOS (RHCOS) läuft.
VNI-Architektur in OpenShift Clustern
Statische VNI
Wenn Sie einen Bare-Metal-basierten Red Hat OpenShift on IBM Cloud-Cluster erstellen oder einen neuen Bare-Metal-Worker-Pool unter IBM Cloud VPC hinzufügen, werden automatisch zwei VNIs erstellt und jedem Bare-Metal-Worker-Node zugeordnet:
- Primäre VNI
- Verarbeitet den regulären Datenverkehr der Mitarbeiter, einschließlich des Pod-Netzwerks, der benutzerdefinierten Overlay-Netzwerke (UDNs) und der Kommunikation mit dem Clustermaster.
- Sekundäres VNI (Träger)
- Er fungiert als Träger für dynamische VNI-Anhänge, die Sie verwalten. Mit dieser VNI können Sie zusätzliche Netzwerkschnittstellen an Workloads anschließen, die auf dem Arbeitsknoten ausgeführt werden.
Dynamische VNI
Dynamische VNIs werden nach der Erstellung des Clusters nach Bedarf erstellt und verwaltet. Diese VNI können sein:
- Angeschlossen an bestimmte Arbeitsknoten
- Konfiguriert, um zwischen Arbeitern in derselben Zone zu pendeln
- Wird für direkte VPC-Netzwerkkonnektivität verwendet
Wichtige Leistungsmerkmale
- Direkte VPC-Konnektivität
- VNIs ermöglichen es Workloads, sich direkt mit VPC-Netzwerken zu verbinden und dabei das Pod-Netzwerk-Overlay zu umgehen. Dies bietet native VPC-Netzwerkfunktionen wie Sicherheitsgruppen, Netzwerk-ACLs und Routing.
- Integration von Sicherheitsgruppen
- VNIs können mit VPC-Sicherheitsgruppen verknüpft werden, was eine fein abgestufte Netzwerkzugangskontrolle auf Schnittstellenebene ermöglicht.
- Zonenspezifische Vernetzung
- VNIs sind mit einem bestimmten VPC-Subnetz und einer Zone verbunden. Sie können nur Datenverkehr für Workloads verarbeiten, die auf Cluster-Arbeitern in derselben Zone laufen, in der die VNI bereitgestellt wird.
- Erhaltung des Netzwerks während der Migration
- Bei Workloads, die Live-Migration unterstützen (z. B. OpenShift Virtualization VMs), können VNIs implizit zwischen Bare-Metal-Worker-Instanzen innerhalb derselben Zone schweben und dem Workload folgen, wobei die Netzwerkverbindungen erhalten bleiben.
Anwendungsfälle
- OpenShift-Virtualisierung
- Aktivieren Sie die direkte VPC-Netzwerkkonnektivität für virtuelle Maschinen, so dass VMs ihre eigenen VPC-IP-Adressen haben. Siehe Verwaltung virtueller Netzwerkschnittstellen für OpenShift Virtualisierung.
- Multinetzwerk-Arbeitslasten
- Verbinden Sie Workloads gleichzeitig mit mehreren VPC-Subnetzen und ermöglichen Sie so komplexe Netzwerktopologien und die Trennung des Datenverkehrs.
- Migration bestehender Anwendungen
- Bereitstellung eines VM-ähnlichen Netzwerks für containerisierte Anwendungen, die bestimmte IP-Adressen oder direkten Netzwerkzugang benötigen.
- Virtualisierung von Netzwerkfunktionen
- Stellen Sie Netzwerkfunktionen bereit, die einen direkten Zugriff auf VPC-Netzwerkfunktionen erfordern.
Beschränkungen und Überlegungen
- Statische VNI-Änderungen
- Ändern Sie nicht die statischen VNIs, die automatisch für jeden Arbeitsknoten erstellt werden. Diese VNIs sind zwar in Ihrem VPC-Konto sichtbar, Änderungen an ihren Einstellungen werden jedoch nicht unterstützt. Dazu gehören das Anhängen von Floating IPs, das Ändern von Sicherheitsgruppen oder das Ändern anderer VNI-Eigenschaften. Das Ändern statischer VNIs kann zu Problemen mit der Cluster-Konnektivität führen.
- VNI-Änderungsbeschränkungen für schwimmende Anbauteile
- Sie können die VNI-Eigenschaften für gleitende (cluster-scoped) dynamische Anhänge nicht ändern. Dazu gehören Änderungen des VNI-Namens, der Floating-IP-Adressen, der Infrastruktur-NAT-Einstellungen und der Zuweisung von Sicherheitsgruppen. Um diese Einstellungen zu aktualisieren, müssen Sie die VNI zunächst abnehmen, die Änderungen vornehmen und sie dann wieder an den Cluster anschließen. Diese Einschränkung ist vorübergehend.
- Beschränkungen der Zone
- VNI können nicht zwischen Zonen wechseln. In Clustern mit mehreren Zonen können VNIs nur Datenverkehr für Workloads in derselben Zone verarbeiten, in der die VNI bereitgestellt wurde.
- Bare-Metal-Anforderung
- VNIs werden nur auf Bare Metal Worker Nodes unterstützt. Arbeiterknoten für virtuelle Serverinstanzen (VSI) unterstützen keine VNIs.
- RHCOS-Anforderung
- Die Arbeiterknoten müssen mit dem Betriebssystem Red Hat CoreOS (RHCOS) betrieben werden.
- OVN- Kubernetes CNI
- Cluster müssen das OVN- Kubernetes Container Network Interface (CNI) Plugin verwenden.
- Kontoübergreifende Verwaltung
- In Red Hat OpenShift on IBM Cloud werden die Arbeitsknoten im Konto von IBM bereitgestellt, nicht in Ihrem Konto. Das bedeutet, dass sich das VNI-Lebenszyklusmanagement von eigenständigen VPC-Bare-Metal-Instanzen unterscheidet und Sie einen anderen Einblick in VNI-Anhänge haben.
- Anforderung an die Version
- VNI-Unterstützung erfordert OpenShift 4.20 oder höher.
Voraussetzungen
Vergewissern Sie sich vor der Verwendung von VNIs in Ihrem Cluster, dass Sie darüber verfügen:
- Ein Red Hat OpenShift on IBM Cloud-Cluster mit der Version 4.20 oder höher
- Bare Metal Worker Nodes in Ihrem Cluster
- Red Hat CoreOS (RHCOS) auf den Arbeitsknotenpunkten
- OVN- Kubernetes CNI konfiguriert
- VPC-Infrastruktur mit entsprechenden Subnetzen
- Die Plattform-Zugangsrolle Operator für Kubernetes Service in IBM Cloud IAM
- Die Plattform-Zugangsrolle Editor oder Administrator für VPC-Infrastrukturdienste in IBM Cloud IAM
Verwaltung von VNI
Sie können VNIs über die Konsole IBM Cloud oder über die CLI verwalten.
Anhängen eines VNI von der Konsole aus
-
Wählen Sie in der Konsole Red Hat OpenShift on IBM Cloud clusters Ihren Cluster aus.
-
Klicken Sie im Navigationsmenü auf Networking > VNI attachments.
-
Klicken Sie auf VNIs anhängen.
-
Konfigurieren Sie im Bereich Attach VNIs die folgenden Einstellungen:
- Teilnetz: Wählen Sie das Teilnetz aus, in dem sich Ihr VNI befindet.
- Arbeiterknoten: Wählen Sie einen bestimmten Arbeitsknoten aus, oder wählen Sie Alle Arbeitsknoten für eine schwebende VNI-Anlage.
- VNI: Wählen Sie die zu verbindende VNI aus.
- VLAN-ID: Geben Sie die VLAN-ID (Bereich: 1-500) ein, die Ihrer Netzwerkkonfiguration entspricht.
- Auto-Löschen: Optional. Wählen Sie diese Option, um die VNI automatisch zu löschen, wenn sie aus dem Cluster entfernt wird.
-
Klicken Sie auf Zuordnen.
Anhängen eines VNI über die CLI
Um eine VNI an einen bestimmten Bare Metal Worker Node anzuhängen, verwenden Sie den Befehl vni attach baremetal. Sie müssen eine VLAN-ID (Bereich: 1-500) angeben, die Ihrer Netzwerkkonfiguration entspricht.
ibmcloud ks vni attach baremetal --worker WORKER_ID --vni VNI_ID --vlan VLAN_ID [--auto-delete]
Um eine schwebende VNI zuzuordnen, die Workloads zwischen Workern in derselben Zone verfolgen kann, geben Sie die Cluster-ID anstelle einer Worker-ID an:
ibmcloud ks vni attach baremetal --cluster-id CLUSTER_ID --vni VNI_ID --vlan VLAN_ID [--auto-delete]
Das Kennzeichen --auto-delete löscht die VNI automatisch, wenn sie aus dem Cluster entfernt wird.
Anzeigen von VNI-Anhängen über die Konsole
-
Wählen Sie in der Konsole Red Hat OpenShift on IBM Cloud clusters Ihren Cluster aus.
-
Klicken Sie im Navigationsmenü auf Networking > VNI attachments.
-
Zeigen Sie die Liste der angeschlossenen VNI mit Details wie VNI-Name, Worker Node, Subnetz, VLAN-ID und primäre IP an.
Anzeigen von VNI-Anhängen über die CLI
So listen Sie alle VNIs auf, die mit einem Cluster verbunden sind:
ibmcloud ks vni ls --cluster-id CLUSTER_ID
Zur Auflistung von VNIs, die mit einem bestimmten Arbeitsknoten verbunden sind:
ibmcloud ks vni ls --worker WORKER_ID
Lösen eines VNI von der Konsole
-
Wählen Sie in der Konsole Red Hat OpenShift on IBM Cloud clusters Ihren Cluster aus.
-
Klicken Sie im Navigationsmenü auf Networking > VNI attachments.
-
Suchen Sie die VNI, die Sie abtrennen möchten, und klicken Sie auf das Symbol für das Aktionsmenü (⋯).
-
Wählen Sie Trennen und bestätigen Sie die Aktion.
Trennen eines VNI von der CLI
Um eine VNI von einem Arbeitsknoten zu trennen, geben Sie sowohl die VNI-ID als auch die Arbeitsknoten-ID an:
ibmcloud ks vni detach --worker WORKER_ID --vni VNI_ID
Bei schwebenden VNIs listen Sie zunächst die VNIs auf, um die aktuelle Worker-ID zu finden, und trennen dann die Verbindung unter Verwendung dieser Worker-ID.
Ausführlichere Beispiele und Anwendungsfälle finden Sie unter Verwaltung virtueller Netzwerkschnittstellen für OpenShift Virtualisierung.