Container-Apps für SR-IOV-fähige Netzwerkschnittstellen in OKE mit Multus CNI-Plug-in bereitstellen

Einführung

In diesem Tutorial erfahren Sie, wie Sie containerisierte Anwendungen auf virtuellen Instanz-Worker-Knoten in Oracle Cloud Infrastructure Kubernetes Engine (OKE) bereitstellen und erweiterte Netzwerkfunktionen nutzen. Insbesondere aktivieren wir Single Root-I/O-Virtualisierung (SR-IOV) für Containernetzwerkschnittstellen und konfigurieren das Multus CNI-Plug-in, um Multi-Homed-Netzwerke für Ihre Container zu aktivieren.

Durch die Kombination von SR-IOV mit Multus können Sie leistungsstarke Netzwerke mit geringer Latenz für spezialisierte Workloads wie KI, maschinelles Lernen und Echtzeitdatenverarbeitung erreichen. In diesem Tutorial werden Schritt-für-Schritt-Anweisungen zum Konfigurieren Ihrer OKE-Umgebung, zum Bereitstellen von Worker-Knoten mit SR-IOV-fähigen Schnittstellen und zum Verwenden von Multus CNI zum Verwalten mehrerer Netzwerkschnittstellen in Ihren Pods bereitgestellt. Egal, ob Sie eine Hochgeschwindigkeits-Paketverarbeitung anstreben oder Ihr Kubernetes-Netzwerk optimieren müssen, dieses Tutorial stattet Sie mit den Tools und dem Wissen aus, um loszulegen.

Hinweis:

Zum Zeitpunkt der Veröffentlichung dieses Tutorials kann SR-IOV CNI nicht von Pods oder Containern auf einer virtuellen Instanz verwendet werden, die zusammen mit dem Multus CNI-Plug-in Teil eines OKE-Clusters ist.

In diesem Tutorial zeigen wir Ihnen, wie Sie eine SR-IOV-fähige Schnittstelle in einem Pod verwenden können, der auf Pods oder Containern auf einer virtuellen Instanz ausgeführt wird, die Teil eines OKE-Clusters ist, indem Sie die Virtuelle Netzwerkkarten (VNIC) (d.h. auf einer virtuellen Instanz) in einen Pod und kann mit Hilfe des Multus CNI-Plugins (wo das SR-IOV CNI-Plugin überhaupt nicht verwendet wird) verwendet werden.

Das SR-IOV CNI-Plug-in wird auf einer Bare-Metal-Instanz unterstützt, die zusammen mit dem Multus CNI-Plug-in zu einem OKE-Cluster gehört. Dieses Tutorial wurde nicht im Leistungsumfang enthalten.

Ziele

Stellen Sie Container-Apps auf virtuellen Instanz-Worker-Knoten in OKE mit SR-IOV-fähigen Netzwerkschnittstellen mit Multus-CNI-Plug-in bereit.

Aufgabe 1: OKE mit Bastion, Operator, drei VM-Worker-Knoten und dem Flannel-CNI-Plug-in bereitstellen

Stellen Sie sicher, dass OKE mit dem folgenden Setup bereitgestellt wird:

Bastion
Operator
3 VM-Mitarbeiterknoten
Flannel CNI-Plug-in

Dieses Setup wird im Tutorial hier beschrieben: Kubernetes-Cluster mit Terraform mit Oracle Cloud Infrastructure Kubernetes Engine bereitstellen.

Die folgende Abbildung zeigt einen visuellen Überblick über die Komponenten, mit denen wir in diesem Tutorial arbeiten werden.

Aufgabe 2: SR-IOV-(Hardware-Assisted-)Netzwerk auf jedem Worker-Knoten aktivieren

Hinweis: Die folgenden Schritte müssen auf allen Worker-Knoten ausgeführt werden, die Teil des OKE-Clusters sind.

Die folgende Abbildung zeigt einen visuellen Überblick über unsere Worker-Knoten im OKE-Cluster, mit denen wir in diesem Tutorial arbeiten werden.

SR-IOV auf der Instanz aktivieren

Melden Sie sich mit SSH bei der Instanz oder dem Worker-Knoten an.
1. Führen Sie den Befehl lspci aus, um zu prüfen, welcher Netzwerktreiber derzeit auf allen VNICs verwendet wird.
2. Beachten Sie, dass der Netzwerktreiber Virtio verwendet wird.
1. Gehen Sie zur Seite Instanzdetails in der OCI-Konsole.
2. Bildlauf nach unten.
3. Beachten Sie, dass der NIC-Anhangstyp jetzt PARAVIRTUALIZED ist.
1. Gehen Sie zur Seite Instanzdetails in der OCI-Konsole.
2. Klicken Sie auf Weitere Aktionen.
3. Klicken Sie auf Bearbeiten.
Klicken Sie auf Erweiterte Einstellungen anzeigen.
1. Klicken Sie auf Startoptionen, und wählen Sie Hardwareassisted-(SR-IOV-)Netzwerk als Netzwerktyp aus.
2. Klicken Sie auf Änderungen speichern.
Klicken Sie auf Instanz neu starten, um den Neustart der Instanz zu bestätigen.
Beachten Sie, dass der Instanzstatus in STOPPING geändert wurde.
Beachten Sie, dass der Instanzstatus in STARTING geändert wurde.
Beachten Sie, dass der Instanzstatus in Wird ausgeführt geändert wurde.
1. Bildlauf nach unten.
2. Beachten Sie, dass der NIC-Anhangstyp jetzt VFIO lautet.
Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 3: Neues Subnetz für die SR-IOV-fähigen VNICs erstellen

Wir erstellen ein dediziertes Subnetz, das unsere SR-IOV-fähigen Schnittstellen verwenden.

Aufgabe 3.1: Sicherheitsliste erstellen

Da wir bereits Sicherheitslisten für die anderen Subnetze verwenden, aber auch eine dedizierte Sicherheitsliste für das neu erstellte SR-IOV-Subnetz benötigen.

Gehen Sie zur OCI-Konsole.
1. Navigieren Sie zu Virtuelle Cloud-Netzwerke.
2. Klicken Sie auf das vorhandene VCN.
1. Klicken Sie auf Sicherheitslisten.
2. Klicken Sie auf Sicherheitsliste erstellen.
Geben Sie für die Ingress-Regel 1 die folgenden Informationen ein.
1. Geben Sie einen Namen ein.
2. Wählen Sie CIDR als Quelltyp aus.
3. Geben Sie 0.0.0.0/0 als Quell-CIDR ein.
4. Wählen Sie unter IP-Protokoll die Option "Alle Protokolle".
5. Bildlauf nach unten.
1. Geben Sie für die Egress-Regel 1 die folgenden Informationen ein.
2. Wählen Sie CIDR als Quelltyp aus.
3. Geben Sie 0.0.0.0/0 als Quell-CIDR ein.
4. Wählen Sie unter IP-Protokoll die Option "Alle Protokolle".
5. Klicken Sie auf Sicherheitsliste erstellen.
Beachten Sie, dass die neue Sicherheitsliste erstellt wird.

Aufgabe 3.2: Subnetz erstellen

Rufen Sie die Seite Details virtuelles Cloud-Netzwerk auf.
1. Klicken Sie auf Subnetze.
2. Beachten Sie die vorhandenen Subnetze, die bereits für die OKE-Umgebung erstellt wurden.
3. Klicken Sie auf Subnetz erstellen.
1. Geben Sie einen Namen ein.
2. Geben Sie IPv4 CIDR-Block ein.
3. Bildlauf nach unten.
1. Wählen Sie Privates Subnetz aus.
2. Bildlauf nach unten.
1. Wählen Sie unter DHCP-Optionen die Option DHCP-Standardoptionen aus.
2. Wählen Sie Sicherheitsliste aus, die in Aufgabe 3.1 erstellt wurde.
3. Klicken Sie auf Subnetz erstellen.
Beachten Sie, dass das Netzsubnetz erstellt wird.
Hinweis:
- Das Subnetz selbst verfügt über keine SR-IOV-fähigen technischen Komponenten.
- In diesem Tutorial verwenden wir ein Standard-OCI-Subnetz, um den Transport von Traffic mit der SR-IOV-Technologie zu ermöglichen.
Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 4: Zweiten VNIC-Anhang hinzufügen

Die folgende Abbildung zeigt einen visuellen Überblick darüber, wie die Worker-Knoten eine einzelne VNIC aufweisen, die mit dem Subnetz der Worker-Knoten verbunden ist, bevor eine zweite VNIC hinzugefügt wird.

Bevor Sie den Worker-Knoten einen zweiten VNIC-Anhang hinzufügen, erstellen Sie eine Netzwerksicherheitsgruppe.

Aufgabe 4.1: Netzwerksicherheitsgruppe (NSG) erstellen

Wir verwenden NSG bereits für die anderen VNICs, aber wir benötigen auch eine dedizierte NSG für die neu erstellte VNIC, die wir einer vorhandenen virtuellen Instanz hinzufügen, die Teil des OKE-Clusters ist und als Kubernetes-Worker-Knoten fungiert. Diese Schnittstelle ist eine VNIC, bei der SR-IOV aktiviert ist.

Rufen Sie die Seite Details virtuelles Cloud-Netzwerk auf.
1. Navigieren Sie zu Netzwerksicherheitsgruppen.
2. Klicken Sie auf Netzwerksicherheitsgruppe erstellen.
Fügen Sie die folgenden Regeln hinzu.
1. Ingress:
  - Quelltyp zulassen: Wählen Sie CIDR aus.
  - Quelle: Geben Sie 0.0.0.0/0 ein.
  - Ziel: Lassen Sie das Ziel leer.
  - Protokoll: Alle Protokolle zulassen.
2. Egress:
  - Quelltyp zulassen: Wählen Sie CIDR aus.
  - Quelle: Lassen Sie die Quelle leer.
  - Ziel: Geben Sie 0.0.0.0/0 ein.
  - Protokoll: Alle Protokolle zulassen.
Die NSG wird erstellt. Wir wenden sie auf die neue (sekundäre) VNIC an, die wir erstellen (auf jedem Worker-Knoten im OKE-Cluster).

Aufgabe 4.2: VNIC hinzufügen

Navigieren Sie zu jeder virtuellen Worker-Knoteninstanz, und fügen Sie jedem Worker-Knoten eine zweite VNIC hinzu.
1. Navigieren Sie zu jeder virtuellen Worker-Knoteninstanz, und klicken Sie auf Angehängte VNICs.
2. Beachten Sie, dass bereits eine VNIC vorhanden ist.
3. Klicken Sie auf VNIC erstellen, um eine zweite VNIC hinzuzufügen.
1. Geben Sie einen Namen ein.
2. Wählen Sie das VCN aus.
3. Wählen Sie das in Aufgabe 3.2 erstellte Subnetz aus.
4. Wählen Sie Netzwerksicherheitsgruppen zur Kontrolle des Traffics nutzen aus.
5. Wählen Sie das in Aufgabe 4.1 erstellte NSG aus.
6. Bildlauf nach unten.
1. Wählen Sie Private IPv4-Adresse automatisch zuweisen aus.
2. Klicken Sie auf Änderungen speichern.
Beachten Sie, dass die zweite VNIC erstellt und an die Instanz des virtuellen Worker-Knotens angehängt und auch an unser Subnetz angehängt wird.
Melden Sie sich mit SSH bei der Instanz oder dem Worker-Knoten an.
1. Führen Sie den Befehl lspci aus, um zu prüfen, welcher Netzwerktreiber derzeit auf allen VNICs verwendet wird.
2. Beachten Sie, dass der Netzwerktreiber Mellanox Technologies ConnectX Family mlx5Gen Virtual Function verwendet wird.
Der Netzwerktreiber der Mellanox Technologies ConnectX-Familie mlx5Gen Virtual Function ist der Virtual Function-(VF-)Treiber, der von SR-IOV verwendet wird. Die VNIC ist also für SR-IOV mit einer VF aktiviert.
Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 5: IP-Adresse der neuen zweiten VNIC mit einem Standardgateway zuweisen

Nachdem die zweite VNIC in Aufgabe 4 erstellt und angehängt wurde, müssen wir ihr eine IP-Adresse zuweisen. Wenn Sie eine zweite Schnittstelle zu einer Instanz hinzufügen, können Sie sie demselben Subnetz wie die erste Schnittstelle zuweisen, oder Sie können ein neues Subnetz auswählen.

DHCP ist für die zweite Schnittstelle nicht aktiviert, daher muss die IP-Adresse manuell zugewiesen werden.

Es gibt verschiedene Methoden, die IP-Adresse für die zweite Schnittstelle zuzuweisen.

Methode 1: Mit der Oracle Cloud Infrastructure-Befehlszeilenschnittstelle (OCI-CLI) (Package oci-utils) können Sie der zweiten Schnittstelle einer OCI Compute-Instanz mit dem Befehl OCI-network-config eine IP-Adresse zuweisen.
Methode 2: Mit der OCI-CLI (Package oci-utils) weisen Sie der zweiten Schnittstelle einer OCI Compute-Instanz mit dem ocid-Daemon eine IP-Adresse zu.
Methode 3: Verwenden Sie das Skript OCI_Multi_VNIC_Setup.
Methode 4: Erstellen Sie die Schnittstellenkonfigurationsdatei manuell für die neue VNIC im Ordner /etc/sysconfig/network-scripts/.

Für alle Worker-Knoten haben wir der sekundären vNIC (ens5) eine IP-Adresse zugewiesen. Wir haben Methode 3 verwendet, um der sekundären vNIC eine IP-Adresse zuzuweisen (ens5). Weitere Informationen zum Zuweisen einer IP-Adresse zur zweiten VNIC finden Sie unter IP-Adresse einer zweiten Schnittstelle auf einer Oracle Linux-Instanz zuweisen.

Nachdem die IP-Adresse einer VNIC zugewiesen wurde, müssen wir prüfen, ob die IP-Adresse der zweiten VNICs korrekt konfiguriert ist. Außerdem können wir prüfen, ob SR-IOV auf allen Knotenpool-Worker-Knoten aktiviert ist.

Unser OKE-Cluster besteht aus:

Knotenpool
NP1	1 x Worker-Knoten
NP2	3 x Worker-Knoten

Wir prüfen alle Worker-Knoten in allen Knotenpools.

Aufgabe 5.1: Alle Knoten in Knotenpool 1 prüfen (`np1`)

Klicken Sie im OKE-Cluster auf Knoten.
Klicken Sie auf den ersten Knotenpool (np1).
Klicken Sie auf den Worker-Knoten, der Teil dieses Knotenpools ist.
1. Beachten Sie, dass der NIC-Anhangstyp VFIO lautet (das bedeutet, dass SR-IOV für diesen virtuellen Instanz-Worker-Knoten aktiviert ist).
2. Beachten Sie, dass die zweite VNIC für diesen Worker-Knoten erstellt und angehängt wird.

Aufgabe 5.2: Alle Knoten in Knotenpool 2 prüfen (`np2`)

Klicken Sie einzeln auf die Knoten, und starten Sie die Verifizierung.
1. Beachten Sie, dass der NIC-Anhangstyp VFIO lautet (das bedeutet, dass SR-IOV für diesen virtuellen Instanz-Worker-Knoten aktiviert ist).
2. Beachten Sie, dass die zweite VNIC für diesen Worker-Knoten erstellt und angehängt wird.
Gehen Sie zur Übersichtsseite für Knotenpool 2 (np2). Klicken Sie im Knotenpool auf den zweiten Worker-Knoten.
1. Beachten Sie, dass der NIC-Anhangstyp VFIO lautet (das bedeutet, dass SR-IOV für diesen virtuellen Instanz-Worker-Knoten aktiviert ist).
2. Beachten Sie, dass die zweite VNIC für diesen Worker-Knoten erstellt und angehängt wird.
Gehen Sie zur Übersichtsseite für Knotenpool 2 (np2). Klicken Sie im Knotenpool auf den dritten Worker-Knoten.
1. Beachten Sie, dass der NIC-Anhangstyp VFIO lautet (das bedeutet, dass SR-IOV für diesen virtuellen Instanz-Worker-Knoten aktiviert ist).
2. Beachten Sie, dass die zweite VNIC für diesen Worker-Knoten erstellt und angehängt wird.

Melden Sie sich mit SSH beim Kubernetes-Operator an.

Führen Sie den Befehl kubectl get nodes aus, um eine Liste und IP-Adressen aller Worker-Knoten abzurufen.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Um die SSH-Verbindung zu allen Worker-Knoten zu vereinfachen, haben wir die folgende Tabelle erstellt.

Worker-Knotenname	ens3-IP	SSH-Komand-Workernode
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

Bevor Sie eine SSH-Verbindung zu allen virtuellen Worker-Knoten herstellen können, stellen Sie sicher, dass der richtige Private Key verfügbar ist.
Führen Sie den Befehl ssh -i <private key> opc@<ip-address> aus, um SSH auf alle Worker-Knoten auszuführen.

Führen Sie den Befehl ip a auf dem Worker-Knoten cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 aus.

Wenn die IP-Adresse erfolgreich konfiguriert wurde, weist die ens5 (zweite VNIC) eine IP-Adresse im Bereich des Subnetzes auf, das in Aufgabe 3.2 für die SR-IOV-Schnittstellen erstellt wurde.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

Führen Sie den Befehl ip a auf dem Worker-Knoten cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 aus.

Wenn die IP-Adresse erfolgreich konfiguriert wurde, weist die ens5 (zweite VNIC) eine IP-Adresse im Bereich des Subnetzes auf, das in Aufgabe 3.2 für die SR-IOV-Schnittstellen erstellt wurde.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

Führen Sie den Befehl ip a auf dem Worker-Knoten cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 aus.

Wenn die IP-Adresse erfolgreich konfiguriert wurde, weist die ens5 (zweite VNIC) eine IP-Adresse im Bereich des Subnetzes auf, das in Aufgabe 3.2 für die SR-IOV-Schnittstellen erstellt wurde.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

Führen Sie den Befehl ip a auf dem Worker-Knoten cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 aus.

Wenn die IP-Adresse erfolgreich konfiguriert wurde, weist die ens5 (zweite VNIC) eine IP-Adresse im Bereich des Subnetzes auf, das in Aufgabe 3.2 für die SR-IOV-Schnittstellen erstellt wurde.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

Wir haben geprüft, ob alle IP-Adressen auf der zweiten VNIC (ens5) konfiguriert sind. Sie können die folgende Tabelle mit den Informationen erstellen.

ens3-IP	ens3 GW	ens5-IP	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 6: Meta-Plugin-CNI (Multus CNI) auf Worker-Knoten installieren

Multus CNI ist ein Kubernetes-Plug-in für die Containernetzwerkschnittstelle (CNI), mit dem Sie mehrere Netzwerkschnittstellen an einen Pod anhängen können.

Wie Multus CNI funktioniert

fungiert als Meta-Plug-in: Multus stellt kein Networking selbst bereit, sondern ruft andere CNI-Plug-ins auf.
Erstellt mehrere Netzwerkschnittstellen: Jeder Pod kann mehrere Netzwerkschnittstellen haben, indem mehrere CNI-Plug-ins kombiniert werden (z.B. Flannel, Calico, SR-IOV).
Verwendet eine Konfigurationsdatei: Das primäre Netzwerk wird mit dem Standard-CNI eingerichtet, und zusätzliche Netzwerke werden basierend auf einer benutzerdefinierten Ressourcendefinition (CRD) zugeordnet.

Warum wir Multus CNI brauchen

Isolation mehrerer Netzwerke: Nützlich für Workloads, die separate Verwaltungs- und Datenebenen erfordern.
Hochleistungsnetzwerk: Ermöglicht direkten Hardwarezugriff über SR-IOV oder DPDK.
Multi-Homing für Pods: Unterstützt Network Function Virtualization (NFV) und Telco-Anwendungsfälle, bei denen mehrere Netzwerkschnittstellen wichtig sind.

Aufgabe 6.1: Multus CNI mit der Thin-Installationsmethode installieren

Greifen Sie mit SSH auf den Kubernetes-Operator zu.
1. Führen Sie den folgenden Befehl aus, um die Multus Git-Library zu klonen.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Führen Sie den folgenden Befehl aus, um das Multus Daemon-Set mit der Thin-Installationsmethode zu installieren.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

Funktionsweise des Multus-Daemon-Sets

Startet ein Multus-Daemon-Set. Dadurch wird ein Pod auf jedem Knoten ausgeführt, der eine Multus-Binärdatei auf jedem Knoten in /opt/cni/bin platziert.
Liest die lexikographisch (alphabetisch) erste Konfigurationsdatei in /etc/cni/net.d und erstellt eine neue Konfigurationsdatei für Multus auf jedem Knoten als /etc/cni/net.d/00-multus.conf. Diese Konfiguration wird automatisch generiert und basiert auf der Standardnetzwerkkonfiguration (die als alphabetisch erste Konfiguration angenommen wird).
Erstellt ein Verzeichnis mit dem Namen /etc/cni/net.d/multus.d auf jedem Knoten mit Authentifizierungsinformationen für Multus für den Zugriff auf die Kubernetes-API.

Aufgabe 6.2: Multus-Installation validieren

Führen Sie den folgenden Befehl (auf dem Kubernetes-Operator) aus, um zu validieren, ob das Multus-Daemon-Set auf allen Worker-Knoten installiert ist.
```
kubectl get pods --all-namespaces | grep -i multus
```
Sie können auch prüfen, ob das Multus-Daemon-Set auf den Worker-Knoten selbst installiert ist.
1. Führen Sie den Befehl ssh -i id_rsa opc@10.0.112.134 aus, um mit dem folgenden Befehl eine SSH-Verbindung zum Worker-Knoten herzustellen.
2. Führen Sie den Befehl cd /etc/cni/net.d/ aus, um das Verzeichnis mit dem folgenden Befehl zu ändern.
3. Führen Sie den Befehl ls -l aus, um die Verzeichnisausgabe mit dem folgenden Befehl aufzulisten.
4. Beachten Sie, dass die Dateien 00-multus.conf und multus.d aufgelistet sind.
1. Führen Sie den Befehl sudo more 00-multus.conf aus, um den Inhalt der Datei 00-multus.conf anzuzeigen.
2. Halten Sie den Inhalt der Datei 00-multus.conf fest.

Aufgabe 7: Netzwerkschnittstellen an Pods anhängen

In dieser Aufgabe mappen oder anhängen Sie eine Containerschnittstelle an diese VNIC an.

Um zusätzliche Schnittstellen an Pods anzuschließen, benötigen wir eine Konfiguration, damit die Schnittstelle angeschlossen werden kann.

Dies ist in der benutzerdefinierten Ressource der Art NetworkAttachmentDefinition eingekapselt.
Diese Konfiguration ist im Wesentlichen eine CNI-Konfiguration, die als benutzerdefinierte Ressource verpackt ist.

Es gibt mehrere CNI-Plugins, die neben Multus verwendet werden können, um dies zu erreichen. Weitere Informationen finden Sie unter Überblick über Plugins.

In dem hier beschriebenen Ansatz ist es das Ziel, eine SR-IOV Virtual Function (VF) ausschließlich für einen einzelnen Pod bereitzustellen, so dass der Pod die Fähigkeiten ohne Störungen oder irgendwelche Ebenen dazwischen nutzen kann.
Um einem Pod exklusiven Zugriff auf das VF zu gewähren, können wir das Host-Geräte-Plug-in nutzen, mit dem Sie die Schnittstelle in den Namespace des Pods verschieben können, sodass es exklusiven Zugriff darauf hat. Weitere Informationen finden Sie unter host-device.

Das folgende Beispiel zeigt 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.
In diesem Beispiel verwenden wir die statische ipam-Konfiguration mit den entsprechenden Routen, da wir dieselben IP-Adressen verwenden möchten, die den sekundären Schnittstellen von OCI zugewiesen wurden.
Die ipam-Konfiguration unterstützt auch andere Methoden wie host-local oder dhcp für flexiblere Konfigurationen.

Aufgabe 7.1: Netzwerkanhangsdefinition erstellen

Mit NetworkAttachmentDefinition wird der Netzwerkanhang eingerichtet, z.B. die sekundäre Schnittstelle für den Pod.

Es gibt zwei Möglichkeiten, die NetworkAttachmentDefinition zu konfigurieren:

NetworkAttachmentDefinition mit JSON-CNI-Konfiguration.
NetworkAttachmentDefinition mit CNI-Konfigurationsdatei.

Hinweis: In diesem Tutorial wird die Methode mit der CNI-Konfigurationsdatei verwendet.

Wir haben 4 x Worker-Knoten und jeder Worker-Knoten hat eine zweite VNIC, die wir einer Schnittstelle auf einem Container (Pod) zuordnen.

Führen Sie die folgenden Befehle aus, um die CNI-Konfigurationsdateien für alle Worker-Knoten und die entsprechenden VNICs zu erstellen.

ens3	ens5	name	Netzwerk	Nano-Befehl
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Führen Sie die folgenden Schritte für den Kubernetes-Operator aus. Erstellen Sie mit dem Befehl sudo nano sriov-vnic-1.yaml eine neue YAML-Datei für den ersten Worker-Knoten.
- Stellen Sie sicher, dass der Name eindeutig und beschreibend ist. In diesem Beispiel wird sriov-vnic-1 verwendet.
- Verwenden Sie die IP-Adresse des zweiten Adapters, den Sie gerade hinzugefügt haben (ens5).
- Stellen Sie sicher, dass dst network ebenfalls korrekt ist und mit dem in Aufgabe 3.2 erstellten Subnetz identisch ist.
sriov-vnic-1.yaml:
```
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.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

Erstellen Sie mit dem Befehl sudo nano sriov-vnic-2.yaml eine neue YAML-Datei für den zweiten Worker-Knoten.

sriov-vnic-2.yaml:

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.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Erstellen Sie mit dem Befehl sudo nano sriov-vnic-3.yaml eine neue YAML-Datei für den dritten Worker-Knoten.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Erstellen Sie mit dem Befehl sudo nano sriov-vnic-4.yaml eine neue YAML-Datei für den vierten Worker-Knoten.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Wenden Sie NetworkAttachmentDefinition auf die Worker-Knoten an.

Führen Sie den Befehl kubectl apply -f sriov-vnic-1.yaml für den ersten Knoten aus.
Führen Sie den Befehl kubectl apply -f sriov-vnic-2.yaml für den zweiten Knoten aus.
Führen Sie den Befehl kubectl apply -f sriov-vnic-3.yaml für den dritten Knoten aus.
Führen Sie den Befehl kubectl apply -f sriov-vnic-4.yaml für den vierten Knoten aus.

Wenn NetworkAttachmentDefinition korrekt angewendet wird, wird eine ähnliche Ausgabe angezeigt.

[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$

Führen Sie den Befehl kubectl get network-attachment-definitions.k8s.cni.cncf.io aus, um zu prüfen, ob NetworkAttachmentDefinitions korrekt angewendet wird.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

Führen Sie den Befehl kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml aus, um die angewendete NetworkAttachmentDefinition für den ersten Worker-Knoten abzurufen.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Führen Sie den Befehl kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml aus, um die angewendete NetworkAttachmentDefinition für den zweiten Worker-Knoten abzurufen.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Führen Sie den Befehl kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml aus, um die angewendete NetworkAttachmentDefinition für den dritten Worker-Knoten abzurufen.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Führen Sie den Befehl kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml aus, um die angewendete NetworkAttachmentDefinition für den vierten Worker-Knoten abzurufen.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 7.2: Pods mit angehängtem `NetworkDefinitionAttachment` erstellen

In dieser Aufgabe verknüpfen wir die NetworkAttachmentDefinitions mit einem tatsächlichen Container oder Pod.

In der folgenden Tabelle haben wir ein Mapping für den Pod erstellt, den wir auf welchem Worker-Knoten hosten möchten.

Worker-Knoten-IP (primär)	ens5	name	Podname	beendet
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	JA
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	JA
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	JA
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	JA

Aufgabe 7.3: Pods mit Knotenaffinität erstellen

Standardmäßig entscheidet Kubernetes, wo die Pods platziert werden (Worker-Knoten). In diesem Beispiel ist dies nicht möglich, weil eine NetworkAttachmentDefinition an eine IP-Adresse gebunden ist und diese IP-Adresse an eine VNIC gebunden ist und diese VNIC an einen bestimmten Worker-Knoten gebunden ist. Daher müssen wir sicherstellen, dass die von uns erstellten Pods auf dem gewünschten Worker-Knoten enden. Dies ist erforderlich, wenn wir die NetworkAttachmentDefinition an einen Pod anhängen.

Wenn wir dies nicht tun, kann es passieren, dass ein Pod an einem anderen Ort landet, an dem die IP-Adresse für den Pod verfügbar ist. Daher kann der Pod nicht über die SR-IOV-fähige Schnittstelle kommunizieren.

Rufen Sie alle verfügbaren Knoten mit dem Befehl kubectl get nodes ab.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Weisen Sie Worker-Knoten 1 mit dem Befehl kubectl label node 10.0.112.134 node_type=testpod1 ein Label zu.
Weisen Sie Worker-Knoten 2 mit dem Befehl kubectl label node 10.0.66.97 node_type=testpod2 ein Label zu.
Weisen Sie Worker-Knoten 3 mit dem Befehl kubectl label node 10.0.73.242 node_type=testpod3 ein Label zu.
Weisen Sie Worker-Knoten 4 mit dem Befehl kubectl label node 10.0.89.50 node_type=testpod4 ein Label zu.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Erstellen Sie eine YAML-Datei für testpod1 mit dem Befehl sudo nano testpod1-v2.yaml.

Beachten Sie den Abschnitt annotations, in dem die zuvor erstellte NetworkAttachmentDefinition (sriov-vnic-1) an diesen Testpod gebunden wird.
Beachten Sie den Abschnitt spec:affinity:nodeAffinity, in dem der Testpod an einen bestimmten Worker-Knoten mit dem Label testpod1 gebunden wird.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Erstellen Sie eine YAML-Datei für testpod2 mit dem Befehl sudo nano testpod2-v2.yaml.

Beachten Sie den Abschnitt annotations, in dem die zuvor erstellte NetworkAttachmentDefinition (sriov-vnic-2) an diesen Testpod gebunden wird.
Beachten Sie den Abschnitt spec:affinity:nodeAffinity, in dem der Testpod an einen bestimmten Worker-Knoten mit dem Label testpod2 gebunden wird.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Erstellen Sie eine YAML-Datei für testpod3 mit dem Befehl sudo nano testpod3-v2.yaml.

Beachten Sie den Abschnitt annotations, in dem die zuvor erstellte NetworkAttachmentDefinition (sriov-vnic-3) an diesen Testpod gebunden wird.
Beachten Sie den Abschnitt spec:affinity:nodeAffinity, in dem der Testpod an einen bestimmten Worker-Knoten mit dem Label testpod3 gebunden wird.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Erstellen Sie eine YAML-Datei für die testpod4 mit dem Befehl sudo nano testpod4-v2.yaml.
- Beachten Sie den Abschnitt annotations, in dem die zuvor erstellte NetworkAttachmentDefinition (sriov-vnic-4) an diesen Testpod gebunden wird.
- Beachten Sie den Abschnitt spec:affinity:nodeAffinity, in dem der Testpod an einen bestimmten Worker-Knoten mit dem Label testpod4 gebunden wird.
```
sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]
```
- Erstellen Sie die Datei testpod1, indem Sie die YAML-Datei mit dem Befehl kubectl apply -f testpod1-v2.yaml anwenden.
- Erstellen Sie die Datei testpod2, indem Sie die YAML-Datei mit dem Befehl kubectl apply -f testpod2-v2.yaml anwenden.
- Erstellen Sie die Datei testpod3, indem Sie die YAML-Datei mit dem Befehl kubectl apply -f testpod3-v2.yaml anwenden.
- Erstellen Sie die Datei testpod4, indem Sie die YAML-Datei mit dem Befehl kubectl apply -f testpod4-v2.yaml anwenden.
```
[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$
```

Prüfen Sie mit dem Befehl kubectl get pod, ob die Testpods erstellt wurden. Beachten Sie, dass alle Testpods erstellt werden und den STATUS von Running aufweisen.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

Prüfen Sie mit dem Befehl kubectl get pod testpod1 -o wide, ob testpod1 auf Worker-Knoten 10.0.112.134 mit dem Label testpod1 ausgeführt wird.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

Prüfen Sie mit dem Befehl kubectl get pod testpod2 -o wide, ob testpod2 auf Worker-Knoten 10.0.66.97 mit dem Label testpod2 ausgeführt wird.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

Prüfen Sie mit dem Befehl kubectl get pod testpod3 -o wide, ob testpod3 auf Worker-Knoten 10.0.73.242 mit dem Label testpod3 ausgeführt wird.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

Prüfen Sie mit dem Befehl kubectl get pod testpod4 -o wide, ob testpod4 auf Worker-Knoten 10.0.89.50 mit dem Label testpod4 ausgeführt wird.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 7.4: IP-Adresse in den Testpods prüfen

Prüfen Sie die IP-Adresse von testpod1 für die Podschnittstelle net1 mit dem Befehl kubectl exec -it testpod1 -- ip addr show.

Beachten Sie, dass die IP-Adresse der Schnittstelle net1 10.0.3.30/27 lautet.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

Prüfen Sie die IP-Adresse von testpod2 für die Podschnittstelle net1 mit dem Befehl kubectl exec -it testpod2 -- ip addr show.

Beachten Sie, dass die IP-Adresse der Schnittstelle net1 10.0.3.15/27 lautet.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

Prüfen Sie die IP-Adresse von testpod3 für die Podschnittstelle net1 mit dem Befehl kubectl exec -it testpod3 -- ip addr show.

Beachten Sie, dass die IP-Adresse der Schnittstelle net1 10.0.3.14/27 lautet.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

Prüfen Sie die IP-Adresse von testpod4 für die Podschnittstelle net1 mit dem Befehl kubectl exec -it testpod4 -- ip addr show.

Beachten Sie, dass die IP-Adresse der Schnittstelle net1 10.0.3.16/27 lautet.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

In der folgenden Tabelle wird ein Überblick über alle IP-Adressen der net1-Schnittstellen für alle Testpods angezeigt.

Podname	net1-IP
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

Hinweis: Diese IP-Adressen liegen im selben Bereich wie das OCI-Subnetz, das in Aufgabe 3 erstellt wurde, um unsere SR-IOV-fähigen VNICs zu platzieren.

Aufgabe 7.5: IP-Adresse auf den Worker-Knoten prüfen

Nachdem die net1-Schnittstellen der Testpods eine IP-Adresse haben, beachten Sie, dass diese IP-Adresse früher die IP-Adresse der ens5-Schnittstelle auf den Worker-Knoten war. Diese IP-Adresse wird jetzt von der Worker-Knotenschnittstelle ens5 in die Testpodschnittstelle net1 verschoben.

Stellen Sie mit dem Befehl ssh -i id_rsa opc@10.0.112.134 eine SSH-Verbindung zum ersten Worker-Knoten her.

Rufen Sie die IP-Adressen aller Schnittstellen mit dem Befehl ip a ab.
Beachten Sie, dass die Schnittstelle ens5 aus dem Worker-Knoten entfernt wurde.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

Stellen Sie mit dem Befehl ssh -i id_rsa opc@10.0.66.97 eine SSH-Verbindung zum zweiten Worker-Knoten her.

Rufen Sie die IP-Adressen aller Schnittstellen mit dem Befehl ip a ab.
Beachten Sie, dass die Schnittstelle ens5 aus dem Worker-Knoten entfernt wurde.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

Stellen Sie mit dem Befehl ssh -i id_rsa opc@10.0.73.242 eine SSH-Verbindung zum dritten Worker-Knoten her.

Rufen Sie die IP-Adressen aller Schnittstellen mit dem Befehl ip a ab.
Beachten Sie, dass die Schnittstelle ens5 aus dem Worker-Knoten entfernt wurde.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

Stellen Sie mit dem Befehl ssh -i id_rsa opc@10.0.89.50 eine SSH-Verbindung zum vierten Worker-Knoten her.

Rufen Sie die IP-Adressen aller Schnittstellen mit dem Befehl ip a ab.
Beachten Sie, dass die Schnittstelle ens5 aus dem Worker-Knoten entfernt wurde.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 8: Pingtests zwischen mehreren Pods ausführen

Alle Pods verfügen über eine IP-Adresse aus dem OCI-Subnetz, an das die SR-IOV-fähigen VNICs angehängt sind. Wir können einige Ping-Tests durchführen, um zu prüfen, ob die Netzwerkkonnektivität ordnungsgemäß funktioniert.

Die folgende Tabelle enthält die Befehle für die Verbindung zu den Testpods über den Kubernetes-Operator.

Diese müssen in jedem Pod exec enthalten sein, um entweder einen Ping-Test auszuführen oder die Routentabelle zu prüfen.

ens3	net1	name	Podname	Befehl
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

Führen Sie den Befehl kubectl exec -it testpod1 -- route -n aus, um die Routing-Tabelle direkt aus dem Kubernetes-Operatorterminal für testpod1 anzuzeigen.

Beachten Sie, dass die Routing-Tabelle von testpod1 über ein Standardgateway für eth0 und net1 verfügt, das unsere SR-IOV-fähige Schnittstelle ist.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Führen Sie den Befehl kubectl exec -it testpod2 -- route -n aus, um die Routing-Tabelle direkt aus dem Kubernetes-Operatorterminal für testpod2 anzuzeigen.

Beachten Sie, dass die Routing-Tabelle von testpod2 über ein Standardgateway für eth0 und net1 verfügt, das unsere SR-IOV-fähige Schnittstelle ist.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Führen Sie den Befehl kubectl exec -it testpod3 -- route -n aus, um die Routing-Tabelle direkt aus dem Kubernetes-Operatorterminal für testpod3 anzuzeigen.

Beachten Sie, dass die Routing-Tabelle von testpod3 über ein Standardgateway für eth0 und net1 verfügt, das unsere SR-IOV-fähige Schnittstelle ist.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

Führen Sie den Befehl kubectl exec -it testpod4 -- route -n aus, um die Routing-Tabelle direkt aus dem Kubernetes-Operatorterminal für testpod4 anzuzeigen.

Beachten Sie, dass die Routing-Tabelle von testpod4 über ein Standardgateway für eth0 und net1 verfügt, das unsere SR-IOV-fähige Schnittstelle ist.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Um den Ping-Test vom Kubernetes-Operator direkt aus den Testpods auszuführen, benötigen wir den Ping-Befehl.

In der folgenden Tabelle haben wir alle Ping-Befehle für alle Testpods bereitgestellt. Der Befehl pingt von einem bestimmten Testpod zu allen anderen Testpods, einschließlich der IP-Adresse net1.

Quellpodname	Befehl
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

Hinweis: In diesem Beispiel verwenden wir testpod1, um alle anderen IP-Adressen der Testpods net1 zu pingen.

Führen Sie den Befehl kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 aus, um von testpod1 in testpod1 zu pingen.

Beachten Sie, dass der Ping 4 packets transmitted, 4 received, 0% packet loss enthält. Der Ping ist erfolgreich.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

Führen Sie den Befehl kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 aus, um von testpod1 in testpod2 zu pingen.

Beachten Sie, dass der Ping 4 packets transmitted, 4 received, 0% packet loss enthält. Der Ping ist erfolgreich.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

Führen Sie den Befehl kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 aus, um von testpod1 in testpod3 zu pingen.

Beachten Sie, dass der Ping 4 packets transmitted, 4 received, 0% packet loss enthält. Der Ping ist erfolgreich.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

Führen Sie den Befehl kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 aus, um von testpod1 in testpod4 zu pingen.

Beachten Sie, dass der Ping 4 packets transmitted, 4 received, 0% packet loss enthält. Der Ping ist erfolgreich.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

Hinweis: Wir haben nicht alle anderen Ping-Ausgaben für alle anderen Testpods enthalten, aber Sie erhalten die Idee.

Die folgende Abbildung zeigt einen visuellen Überblick darüber, was wir bisher konfiguriert haben.

Aufgabe 9: (Optional) Pods mit mehreren Schnittstellen bereitstellen

Bis jetzt haben wir nur eine VNIC vorbereitet (die SR-IOV unterstützt) und diese VNIC in einen Pod verschoben. Wir haben dies für vier verschiedene Testpods getan.

Was nun, wenn wir weitere VNICs zu einem bestimmten Pod hinzufügen oder verschieben möchten? Sie müssen die folgenden Schritte ausführen:

Neues OCI-Subnetz erstellen.
Erstellen Sie eine neue VNIC, und weisen Sie sie zu.
Erstellen Sie eine neue NetworkAttachmentDefinitions.
Aktualisieren Sie die YAML-Datei des Testpods, indem Sie neue Anmerkungen hinzufügen.

In dieser Aufgabe finden Sie ein Beispiel, in dem wir ein zusätzliches Subnetz (VNIC) erstellen, die IP-Adresse (NetworkAttachmentDefinition) zuweisen und diese der YAML-Datei für die Poderstellung für testpod1 hinzufügen.

Dies ist die NetworkAttachmentDefinition für eine neue Schnittstelle ens6 mit der IP-Adresse 10.0.4.29/27 im Netzwerk 10.0.4.0/27.

Beachten Sie, dass dies eine weitere NetworkAttachmentDefinition als bisher für die Schnittstelle ens5 mit der IP-Adresse 10.0.3.30/27 im Netzwerk 10.0.3.0/27 ist.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

Dies ist die (aktualisierte) YAML-Datei für testpod1.

Beachten Sie die zusätzliche Zeile in der annotations, in der die neue NetworkAttachmentDefinition; sriov-vnic-2-new referenziert wird.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Aufgabe 10: Alle Pod-Deployments entfernen und `NetworkAttachmentDefinitions`

Wenn Sie neu beginnen oder die Container mit NetworkAttachmentDefinitions bereinigen möchten, führen Sie die folgenden Schritte aus:

Rufen Sie alle Pods mit dem Befehl kubectl get pod ab.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

Löschen Sie die Testpods mit den folgenden Befehlen.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

Rufen Sie die gesamte NetworkAttachmentDefinitions mit dem Befehl kubectl get network-attachment-definitions.k8s.cni.cncf.io ab.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

Löschen Sie NetworkAttachmentDefinitions mit den folgenden Befehlen.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

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

Bestätigungen

Autor - Iwan Hoogendoorn (OCI Network Specialist)

Weitere Lernressourcen

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

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28053-02

Container-Apps für SR-IOV-fähige Netzwerkschnittstellen in OKE mit Multus CNI-Plug-in bereitstellen

Einführung

Ziele

Aufgabe 1: OKE mit Bastion, Operator, drei VM-Worker-Knoten und dem Flannel-CNI-Plug-in bereitstellen

Aufgabe 2: SR-IOV-(Hardware-Assisted-)Netzwerk auf jedem Worker-Knoten aktivieren

Aufgabe 3: Neues Subnetz für die SR-IOV-fähigen VNICs erstellen

Aufgabe 3.1: Sicherheitsliste erstellen

Aufgabe 3.2: Subnetz erstellen

Aufgabe 4: Zweiten VNIC-Anhang hinzufügen

Aufgabe 4.1: Netzwerksicherheitsgruppe (NSG) erstellen

Aufgabe 4.2: VNIC hinzufügen

Aufgabe 5: IP-Adresse der neuen zweiten VNIC mit einem Standardgateway zuweisen

Aufgabe 5.1: Alle Knoten in Knotenpool 1 prüfen (np1)

Aufgabe 5.2: Alle Knoten in Knotenpool 2 prüfen (np2)

Aufgabe 6: Meta-Plugin-CNI (Multus CNI) auf Worker-Knoten installieren

Aufgabe 6.1: Multus CNI mit der Thin-Installationsmethode installieren

Aufgabe 6.2: Multus-Installation validieren

Aufgabe 7: Netzwerkschnittstellen an Pods anhängen

Aufgabe 7.1: Netzwerkanhangsdefinition erstellen

Aufgabe 7.2: Pods mit angehängtem NetworkDefinitionAttachment erstellen

Aufgabe 7.3: Pods mit Knotenaffinität erstellen

Aufgabe 7.4: IP-Adresse in den Testpods prüfen

Aufgabe 7.5: IP-Adresse auf den Worker-Knoten prüfen

Aufgabe 8: Pingtests zwischen mehreren Pods ausführen

Aufgabe 9: (Optional) Pods mit mehreren Schnittstellen bereitstellen

Aufgabe 10: Alle Pod-Deployments entfernen und NetworkAttachmentDefinitions

Verwandte Links

Bestätigungen

Weitere Lernressourcen

Aufgabe 5.1: Alle Knoten in Knotenpool 1 prüfen (`np1`)

Aufgabe 5.2: Alle Knoten in Knotenpool 2 prüfen (`np2`)

Aufgabe 7.2: Pods mit angehängtem `NetworkDefinitionAttachment` erstellen

Aufgabe 10: Alle Pod-Deployments entfernen und `NetworkAttachmentDefinitions`