Hauptmerkmale

Statische VNIs pro Arbeitsknoten

Wenn Sie einen Bare-Metal-basierten Red Hat OpenShift on IBM Cloud-Cluster oder einen neuen Worker-Pool in IBM Cloud VPC erstellen, werden automatisch zwei VNIs erstellt und statisch mit jedem Bare-Metal-Worker-Node verbunden. Eine VNI wickelt den regulären Arbeitsverkehr ab (Pod-Netzwerk, Overlay-UDNs und Master-Kommunikation). Der zweite VNI dient als Träger für dynamische VNI-Anhänge, die Sie verwalten.

Dynamische VNI-Anhänge

Sie können VNIs nach der Cluster-Erstellung nach Bedarf erstellen und verwalten. Dynamische VNIs können mit bestimmten Workern verbunden oder so konfiguriert werden, dass sie zwischen Workern in derselben Zone wechseln, um VM Workloads während der Live-Migration zu folgen.

Unterstützung der Live-Migration

Mit VNIs, die an Bare Metal Worker Nodes angeschlossen sind, können Live-Migrationen von OpenShift Virtualization-basierten VMs die Netzwerkverbindungen aufrechterhalten. Der VNI gleitet implizit und folgt der Arbeitslast zwischen Bare-Metal-Worker-Instanzen innerhalb derselben Zone.

Wichtige Einschränkungen und Überlegungen zu VNI finden Sie unter Einschränkungen und Überlegungen.

Kontoübergreifende Pfändung

In Red Hat OpenShift on IBM Cloud werden Worker Nodes nicht in Ihrem Konto bereitgestellt, was bedeutet, dass sich die Verwaltung des Lebenszyklus von VNIs leicht von eigenständigen VPC-Bare-Metal-Instanzen unterscheidet. Der Red Hat OpenShift on IBM Cloud Cluster-Administrator hat eine andere Sicht auf die Attachments der VNIs, da diese an Workloads angehängt sind, die innerhalb des Kontos nicht sichtbar sind. Die Unterschiede in der VNI-Verwaltung werden in dieser Dokumentation behandelt.

Weitere Informationen zu VNIs auf eigenständigen VPC-Bare-Metal-Instanzen finden Sie unter Über virtuelle Netzwerkschnittstellen.

Erstellen eines primären UDN

Um ein primäres benutzerdefiniertes Netzwerk für Pods oder VM Workloads zu verwenden, erstellen Sie zunächst das UDN selbst.

Beispiel für ein Cluster User Defined Network, das über Namespaces hinweg verwendet werden kann:

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

Erstellen Sie dann den/die Namespace(s), der/die ihn verwenden soll(en). Der Namensraum muss bei der Erstellung ein bestimmtes Label ( k8s.ovn.org/primary-user-defined-network) für die Verwendung von Primary UDN enthalten.

Beispiel:

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

Sobald der (C)UDN und die Namespaces eingerichtet sind, wird jede in diesem Namespace erstellte Arbeitslast mit der Standardroute auf den UDN zugreifen.

Erstellen eines sekundären UDN

Die Konfiguration des sekundären UDN ist ähnlich wie die des primären UDN, jedoch ist die Rolle auf Secondary eingestellt. Ausführliche Informationen finden Sie in der Dokumentation Red Hat OpenShift multiple networks.

Installieren des NMState-Operators

OpenShift In Virtualisierungsdienst- Clustern ist der NMState-Operator vorinstalliert und wird vom Add-on „ openshift-virtualization “ verwaltet. Überspringen Sie diesen Schritt, wenn Sie den Virtualisierungsdienst verwenden.

1. Stellen Sie den NMState Operator über OperatorHub in der Konsole Red Hat OpenShift on IBM Cloud oder über die CLI bereit.

2. Erstellen Sie eine NMState-Instanz mit der Standardkonfiguration.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

Erstellen der OVS-Brücke

OpenShift In Virtualisierungsdienst-Clustern sind die erforderlichen NNCP-Ressourcen bereits vorkonfiguriert. Diese Ressourcen müssen Sie nur bei Standard-„ OpenShift “-Clustern mit manueller Installation von „ OpenShift Virtualization“ manuell erstellen.

1. Erstellen Sie eine dedizierte OVS-Brücke, an die eth1 angeschlossen ist, indem Sie die folgende benutzerdefinierte NMState-Ressource bereitstellen.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. Überprüfen Sie den Status der benutzerdefinierten Ressource und warten Sie, bis alle betroffenen Clusterknoten die Anfrage zur Erstellung der Brücke abgestimmt haben.

3. Passen Sie die neue OVS-Brücke an die Standardbrücke an, indem Sie die folgende benutzerdefinierte Ressource NMState erstellen. Ersetzen Sie vpc-vlans durch den gewünschten Netzwerknamen.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. Überprüfen Sie den Status der benutzerdefinierten Ressource und warten Sie, bis alle betroffenen Clusterknoten die Bridge-Zuordnungsanfrage abgestimmt haben.

Erstellen eines benutzerdefinierten localnet-Netzwerks

Erstellen Sie einen UDN oder ClusterUserDefinedNetwork (CUDN), der den Verkehr von VNIs unter Verwendung des ausgewählten VLANs verfügbar macht.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

Ersetzen Sie die folgenden Werte:

• vlan250: Der Name Ihres CUDN
• default: Der Namespace, in dem Sie den CUDN verwenden möchten
• vpc-vlans: Der physische Netzwerkname, den Sie in der Bridge-Zuordnung definiert haben
• 250: Ihre gewünschte VLAN-ID (Bereich: 1-500)

Damit ist die Netzwerkinstallation für ein bestimmtes VLAN abgeschlossen. Sie können mehrere CUDNs definieren, indem Sie unterschiedliche VLAN-IDs verwenden und die Bridge-Zuordnungen wiederverwenden.

Nach Abschluss der localnet UDN-Einrichtung können Sie VNIs über die Konsole IBM Cloud oder den CLI-Befehl IBM Cloud ks vni mit dem Cluster verbinden. Siehe die Beispiele in den folgenden Abschnitten.

Vorbereitende Schritte

1. Erstellen Sie VNIs in Ihrer VPC mit der entsprechenden Subnetz- und IP-Adresskonfiguration.

2. Vergewissern Sie sich, dass Sie über die erforderlichen Berechtigungen zur Verwaltung des Clusters und der VNIs verfügen.

Beispiel

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

Beispielausgabe

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

Beispielausgabe

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

Beispiel

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

Warum kann ich keine normalen Pods an Localnet UDNs anhängen?

Bei Localnet UDNs ist die IP-Adressverwaltung (IPAM) auf der OVN-Seite deaktiviert, was bedeutet, dass die statische IP-Adresszuweisung an Pods nicht vom OVN aus erfolgt. Diese Konfiguration ist für VM Workloads gedacht, die DHCP verwenden oder statische IPs innerhalb des Gastbetriebssystems einrichten. Diese Optionen sind für Pod-Workloads nicht verfügbar.

Warum ist die Live-Migration über Arbeitnehmerpools hinweg noch nicht abgeschlossen?

Verschiedene Worker-Pools können verschiedene Worker-Flavors mit CPUs unterschiedlicher Generationen und Fähigkeiten haben. Wenn der vollständige CPU-Funktionssatz für die Arbeitslast VM transparent ist, können Sie die VM nicht live auf einen anderen Arbeiter migrieren, der nicht alle CPU-Funktionen unterstützt. Sie können die sichtbaren CPU-Funktionen des Gastbetriebssystems zu Beginn einschränken, um mehr Kompatibilität zwischen den Worker-Flavors zu erreichen.

Warum funktionieren dynamisch angeschlossene VNI nicht?

Überprüfen Sie die folgenden Punkte:

• Überprüfen Sie, ob die VLAN-ID im CUDN mit der VLAN-ID in der VNI-Anlage übereinstimmt. VPC DHCP kann auch ohne weiteren Datenverkehr funktionieren, wenn das VLAN nicht übereinstimmt.
• Wenn Floating nicht aktiviert ist, stellen Sie sicher, dass der Workload auf dem Worker geplant ist, an den die VNI angeschlossen ist.
• Vergewissern Sie sich, dass die dedizierte OVS-Brücke und die Zuordnung bei den Mitarbeitern vorhanden sind. Überprüfen Sie den Status der Ressource NodeNetworkConfigurationPolicy.