Hinweis:

• Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zum Anmelden für einen kostenlosen Account finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
• Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. Wenn Sie Ihre Übung abgeschlossen haben, ersetzen Sie diese Werte durch die Werte, die für Ihre Cloud-Umgebung spezifisch sind.

SR-IOV-Schnittstellen für Pods mit Multus für VM-basierte Oracle Container Engine for Kubernetes-Knoten konfigurieren

Einführung

Wenn stark netzwerkorientierte Workloads die Einrichtung sekundärer Netzwerkschnittstellen innerhalb von Pods erfordern, können wir dies mit einem Meta-CNI wie Multus erreichen. Die sekundären Netzwerkschnittstellen, die in diesen Fällen normalerweise angehängt sind, verfügen über spezielle Netzwerkfunktionen oder -eigenschaften wie Single Root IO Virtualization (SR-IOV).

In einem früheren Tutorial: SR-IOV-Schnittstellen für Pods mit Multus für Bare-Metal-OKE-Knoten konfigurieren (Sie können den Link aus dem Abschnitt "Zugehörige Links" aufrufen), wurde beschrieben, wie Sie dies auf Bare-Metal-Kubernetes-Knoten auf Oracle Cloud Infrastructure (OCI) erreichen. Dort können Sie virtuelle Funktionen (VFs) direkt auf der Hardware erstellen, die an die Bare-Metal-Instanz angeschlossen ist.

Dieses Tutorial verfolgt einen ähnlichen Ansatz für Virtual-Machine-Knoten in einem Oracle Container Engine for Kubernetes-(OKE-)Cluster und verfolgt einen ähnlichen Ansatz mit verschiedenen Konfigurationen und Plug-ins als auf Bare-Metal-Knoten. Es gibt erhebliche Unterschiede beim Erstellen und Verwalten der Schnittstellen zwischen Bare Metal, bei denen Sie die volle Kontrolle über die Hardware und virtuelle Maschinen haben, wobei ein Hypervisor Ihren Zugriff auf die zugrunde liegende Hardware abstrahiert und Sie nicht so viel Kontrolle darüber haben.

Bei dem hier beschriebenen Ansatz wird Multus verwendet, um einem Pod mehrere Schnittstellen bereitzustellen. Allerdings werden SR-IOV CNI und das zugehörige Geräte-Plug-in nicht verwendet. Das liegt daran, dass der SR-IOV CNI Zugriff auf die zugrunde liegende Hardware benötigt, die physische Funktion (PF), die offensichtlich eine Herausforderung für virtuelle Maschinen darstellt. Um diese Herausforderung zu meistern, können wir die OCI-Netzwerk-APIs für VNICs verwenden, um eine virtuelle Funktion (VF) in der physischen Funktion (PF) wie im Bare-Metal-Szenario zu erstellen und der VM direkten und uneingeschränkten Zugriff auf dieses VF zu gewähren. Diese VFs können als Netzwerkschnittstellen an eine Compute-Instanz, einschließlich OKE-Knoten, angehängt werden. Diese Schnittstellen/VFs können in die Netzwerk-Namespaces für Pods verschoben werden, sodass der Pod die VF direkt und ausschließlich als Netzwerkschnittstelle verwenden kann. Aus Sicht der Pods kann sie nicht zwischen den beiden unterscheiden, und in beiden Fällen hat sie Zugriff auf eine VF, die sie direkt verwenden können.

Um einer VM direkten Zugriff auf ein VF zu erteilen, müssen Sie die VM mit dem VFIO-Netzwerkanhangsmodus im Gegensatz zum Standardmodus paravirtualisiert starten. Diese Auswahl wird über den Startmodus für die Compute-Instanz gesteuert. Nachdem der Netzwerkanhangsmodus als VFIO festgelegt wurde, können Sie Netzwerkanhänge mit den OCI-APIs erstellen, die VFs auf dem zugrunde liegenden PF erstellen und das VF direkt an die VM bereitstellen. Das Betriebssystem auf dem Host erkennt diese Schnittstellen als Netzwerkschnittstellen. Sobald das VF für die VM verfügbar ist, kann es in den Pod-Namespace verschoben werden. In diesem Modell werden die VFs mit OCI-APIs anstelle von Systembefehlen im Bare-Metal-Szenario erstellt.

Zielsetzung

Konfigurieren Sie SR-IOV-Schnittstellen für Pods mit Multus für VM-basierte Oracle Container Engine for Kubernetes-Knoten.

Voraussetzungen

• Ein OKE-Cluster mit einem Knotenpool, der aus mindestens zwei VMs besteht.

Hinweis: Dieses Tutorial wurde in OKE-Clustern mit Flannel-Networking (Flannel als primäres CNI) validiert.

Aufgabe 1: Knoten einrichten

Jeder Knoten, der Zugriff auf SR-IOV-Schnittstellen benötigt, muss für hardwaregestützte Netzwerkanhänge vorbereitet werden, bevor er von den Pods verwendet werden kann.

1. Knoten im VFIO-Modus booten

   • Erstellen Sie einen Knotenpool und eine Gruppe von Knoten in Ihrem Cluster.

   • Nachdem die Knoten erstellt wurden, bearbeiten Sie die Instanzeigenschaften.

     

   • Klicken Sie in den Instanzeigenschaften auf Erweiterte Optionen anzeigen, um die zusätzlichen Eigenschaften anzuzeigen. Wählen Sie auf der Registerkarte Startoptionen für den Netzwerktyp die Option Hardwareunterstütztes (SR-IOV-)Netzwerk aus.

     

     Hinweis: Nachdem eine Instanz im paravirtualisierten Netzwerkanhänge in den hardwaregestützten Modus (SR-IOV oder VFIO) gewechselt wurde, sind sie nicht mehr für die Livemigration zur Infrastrukturwartung berechtigt.

   • Der Aktualisierungsworkflow fordert Sie auf, die Instanz neu zu starten. Nach dem Neustart verfügt die Instanz über VFIO-Netzwerkanhänge. Dies kann auf der Konsole überprüft werden.

     

   • Eine weitere Methode zur Prüfung, ob Ihre Instanzen SR-IOV-Netzwerkanhänge verwenden, besteht darin, SSH auf dem Knoten zu verwenden und die PCI-Geräte auf der VM mit lspci aufzulisten. Sie sollten die zugrunde liegende virtuelle Funktion direkt auf der VM im Gegensatz zu einem Gerät anzeigen können, das einen virtio-Treiber verwendet (wie der Speichercontroller in der Abbildung unten).

     

   • An dieser Stelle verfügt der Knoten über einen einzelnen VNIC-Anhang. Dies ist die primäre VNIC, die für die gesamte Kommunikation mit dem Knoten verwendet wird. Da die Instanz hardwaregestützte Netzwerkanhänge verwendet, ist der Netzwerkanhang für den Knoten als virtuelle Funktion auf der zugrunde liegenden Hardware sichtbar. Damit Pods eine virtuelle Funktion (VF) exklusiv nutzen können, benötigen wir zusätzliche VFs auf der VM. Sie können diese Angaben über die Konsole oder API machen, um der Instanz weitere VNIC-Anhänge hinzuzufügen. Diese VNIC-Anhänge sind VFs in der zugrunde liegenden PF. Diese können mit lspci verifiziert werden.

2. Weitere VNIC-Anhänge hinzufügen

   • Wählen Sie auf der Instanzseite die Option Angehängte VNICs aus, und klicken Sie auf VNIC erstellen.

     

   • Konfigurieren Sie die VNIC mit dem erforderlichen VCN und Subnetz.

     

   • Prüfen Sie, ob die VNIC wie zuvor auf dem Host als virtuelle Funktion angezeigt werden kann, indem Sie SSH auf dem Knoten ausführen und lspci ausführen.

     

   • Wenn Sie einer Linux-VM-Instanz eine sekundäre VNIC hinzufügen, wird der Instanz eine neue Schnittstelle (also ein Ethernetgerät) hinzugefügt und automatisch vom BS erkannt. DHCP ist jedoch für die sekundäre VNIC nicht aktiv, und Sie müssen die Schnittstelle mit der statischen IP-Adresse und der Standardroute konfigurieren.

3. BS für sekundäre VNICs konfigurieren

   • OCI stellt Dokumentation und ein Skript zum Konfigurieren des BS für sekundäre VNICs bereit. Um die sekundäre VNIC zu konfigurieren, laden Sie das Skript auf den Knoten herunter, und führen Sie es basierend auf den Anweisungen aus, die in der OCI-Dokumentation angegeben sind.

     Note: The secondary VNICs on each node must be set up by repeating these steps for each node. These steps can be optionally and automated using a custom cloud_init script for the nodes.

   • Stellen Sie sicher, dass die Schnittstelle jetzt mit ihrer IP-Adresse und der Standardroute verbunden ist. Verwenden Sie zur Prüfung den Befehl ip addr oder nmcli.

     

   • Prüfen Sie optional das Routing mithilfe eines Pings, um die sekundären IP-Adressen voneinander zu erreichen. In den folgenden Images ist 10.0.10.238 die sekundäre IP auf einem zweiten Knoten im Cluster.

     

     

Aufgabe 2: Meta-Plugin-CNI (Multus) installieren

Multus ist ein Meta-Plug-in, das einem nachgelagerten CNI wie dem SR-IOV CNI-Plug-in die VF-Informationen zur Verfügung stellen kann, damit es die Netzwerkressourcen-Podierung verarbeiten kann, während "Multihomed"-Pods oder -Pods mit mehreren Netzwerkschnittstellen aktiviert werden.

Hinweis: Mit Multus 4.0 wurde mit Multus ein neues Client-Server-Deployment namens "Thick Plug-in" eingeführt. Das neue dicke Plug-in unterstützt zusätzliche Features wie Metriken, die zuvor nicht unterstützt wurden. Dieses Dokument verwendet das "dünne" Plug-in, da es weniger Ressourcen verbraucht.

1. Um Multus zu installieren, führen Sie die folgenden Befehle aus.

   git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
   kubectl apply -f deployments/multus-daemonset.yml && cd ..
   

Hinweis: Bei der Installation muss das Kubelet für das Standardimage, das vom Daemonset mit dem Tag stable verwendet wird, v1.20.x sein. Bearbeiten Sie bei der Installation in einem älteren Cluster das Deamonset im Manifest, und verwenden Sie das Multus Image Tag v3.7.1.

Dieses Manifest erstellt eine neue CRD für kind:NetworkAttachmentDefinition und stellt die Multus-Binärdatei auf allen Knoten über ein Daemonset bereit. Sie können die Installation prüfen, indem Sie sicherstellen, dass das Multus-Daemonset auf Ihren Knoten ausgeführt wird.

Aufgabe 3: Mehrere Schnittstellen an Pods anhängen

• Um weitere Schnittstellen an Pods anzuhängen, ist eine Konfiguration erforderlich, damit die Schnittstelle angeschlossen wird. Dies ist in der benutzerdefinierten Ressource des Typs NetworkAttachmentDefinition gekapselt. Diese Konfiguration ist im Wesentlichen eine CNI-Konfiguration, die als benutzerdefinierte Ressource verpackt ist.

• Dazu gibt es mehrere CNI-Plug-ins, die zusammen mit Multus verwendet werden können. Bei dem hier beschriebenen Ansatz besteht das Ziel darin, eine virtuelle SR-IOV-Funktion ausschließlich für einen einzelnen Pod bereitzustellen, sodass der Pod die Funktionen ohne Störungen oder dazwischen liegende Schichten nutzen kann. Um einem Pod exklusiven Zugriff auf die VF zu erteilen, können wir das Host-Gerät-Plug-in nutzen, mit dem Sie die Schnittstelle in den Namespace des Pods verschieben können, sodass sie exklusiven Zugriff darauf hat.

• Die folgenden Beispiele zeigen NetworkAttachmentDefinition-Objekte, mit denen die sekundäre ens5-Schnittstelle konfiguriert wird, die den Knoten hinzugefügt wurde. Die Plug-in-Konfiguration ipam bestimmt, wie IP-Adressen für diese Schnittstellen verwaltet werden. Da Sie in diesem Beispiel dieselben IP-Adressen verwenden möchten, die den sekundären Schnittstellen von OCI zugewiesen wurden, verwenden wir die statische ipam-Konfiguration mit den entsprechenden Routen. Die ipam-Konfiguration unterstützt auch andere Methoden wie host-local oder dhcp für flexiblere Konfigurationen.

  
  ## network attachment for the first node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: sriov-vnic-1
  spec:
    config: '{
          "cniVersion": "0.3.1",
          "type": "host-device",
          "device": "ens5",
          "ipam": {
                  "type": "static",
                  "addresses": [
                      {
                          "address": "10.0.10.93/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  
  ## network attachment for the second node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: sriov-vnic-2
  spec:
    config: '{
          "cniVersion": "0.3.1",
          "type": "host-device",
          "device": "ens5",
          "ipam": {
                  "type": "static",
                  "addresses": [
                      {
                          "address": "10.0.10.238/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  

Aufgabe 4: Pods mit mehreren Schnittstellen bereitstellen und testen

Pods können jetzt zusätzliche Schnittstellen mit einer Annotation anfordern. Mit der Annotation kann das Meta-Plug-in (Multus) wissen, wie NetworkAttachmentDefinition (CNI-Konfiguration) beim Erstellen des Pods zusätzliche Schnittstellen bereitstellen soll.

Hinweis: Wenn Sie eine statische Konfiguration wie in diesem Beispiel verwenden, müssen die Pods eine Knotenaffinität festlegen, damit der Pod auf dem Knoten geplant wird, auf dem das gewünschte Hostgerät verfügbar ist.

• Beispiel mit einem Testpod:

  ## Create the first pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod1
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic-1
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  ## Create a second pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod2
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  

• Wenn zwei Pods erstellt wurden, sollten wir sehen, dass sie beide ausgeführt werden. Wir sollten in der Lage sein zu sehen, dass während der Erstellung der Pods zusätzliche Netzwerkschnittstellen erstellt wurden. Multus stellt die eth0-Schnittstelle bereit, die vom standardmäßigen CNI (in diesem Beispiel "Flannel") gesichert wird, und eine zusätzliche net1-Schnittstelle, die die virtuelle SR-IOV-Funktion ist. Sie können die Pods describe und den Abschnitt Ereignisse der Ausgabe anzeigen, um die verschiedenen Ereignisse anzuzeigen, einschließlich der Schnittstellen, die an den Pod angehängt werden.

  

• Nachdem die Pods gestartet wurden, können wir einen Schnelltest durchführen.

  ## Verify that both pods have two interfaces. An `eth0` on the overlay and a `net1` which is the VF, along with the IP address for the secondary VNIC.
  kubectl exec -it testpod1 -- ip addr show
  kubectl exec -it testpod2 -- ip addr show
  

• Die Ausgabe muss den folgenden Bildern ähneln.

  

  

• Außerdem können wir die Kommunikation zwischen den beiden Pods über diese sekundären Schnittstellen prüfen.

  ## test communication
  kubectl exec -it testpod1 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  kubectl exec -it testpod2 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  
  

• Die Ausgabe muss den folgenden Bildern ähneln.

  

  

• Außerdem können Sie prüfen, ob die Pods mit ihren Netzwerkanhängen routbar sind, indem Sie versuchen, sie von den VMs oder einer beliebigen anderen Quelle im VCN zu erreichen.

  ## Test that the pod is routable from outside Kubernetes. This is executed from node1.
  ping 10.0.10.238
  
  ## similarly, from node 2
  ping 10.0.10.93
  
  

• Die Ausgabe sollte den folgenden Bildern ähneln.

  

  

Verwandte Links

• SR-IOV-Schnittstellen für Pods mit Multus für Bare-Metal-OKE-Knoten konfigurieren

• Mehrere

• SRIOV-CNI

• CNI-Plug-ins in virtuellen Umgebungen

Danksagungen

• Autor - Jeevan Joseph (Principal Product Manager)

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem die Website education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Produktdokumentation finden Sie im Oracle Help Center.

---

Titel und Copyright-Informationen

Configure SR-IOV interfaces for pods using Multus for VM-based Oracle Container Engine for Kubernetes nodes

F80585-01

May 2023

Copyright © 2023, Oracle and/or its affiliates.