Mehrere sekundäre VNICs für Podnetzwerke anhängen

Schritt 1: Erweiterte Ressourcennamen und Kapazität auf einem Knoten prüfen

Nachdem der Knotenpool Worker-Knoten enthält, prüfen Sie die Namen und Kapazität der erweiterten Ressourcen auf einem Knoten.

1. Prüfen Sie die angekündigten erweiterten Ressourcen des Knotens:

   kubectl describe node <node-name>

2. Identifizieren Sie im Abschnitt Capacity der Ausgabe die erweiterten Ressourcen, die Anwendungsressourcen entsprechen (z.B. oke-application-resource.oci.oraclecloud.com/frontend), und bestätigen Sie, dass sie eine Kapazität ungleich null haben.

Knoten, die Anwendungsressourcen bereitstellen, werden mit oci.oraclecloud.com/application-resource-only:NoSchedule verfälscht, um zu verhindern, dass Pods ohne explizite Anwendungsressourcenanforderungen auf ihnen landen.

Fügen Sie der Podspezifikation eine entsprechende Toleranz hinzu (unter spec.tolerations für einen Pod oder unter spec.template.spec.tolerations in einem Deployment):

tolerations:
  - key: "oci.oraclecloud.com/application-resource-only"
    operator: "Exists"
    effect: "NoSchedule"

Ohne diese Toleranz lehnt der Scheduler die Platzierung ab, selbst wenn Ressourcenkapazität vorhanden ist.

Fordern Sie in der Podspezifikation die erweiterte Ressource an, die dem sekundären VNIC-Profil entspricht, das der Pod verwenden muss (z.B. in einem Deployment unter spec.template.spec.containers[].resources). Fordern Sie genau eine Einheit an, und begrenzen Sie sie, damit der Scheduler die Kapazität konsistent reserviert.

Beispiel:

containers:
  - name: myapp
    image: <image>
    resources:
      requests:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"
      limits:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"

Schritt 4: (Optional) Richtige Knotenpools als Ziel festlegen

Wenn Ihre Organisation eine Konvention für Knotenlabels/Selektoren für diese Knoten verwendet (z.B. gva_vnic: "yes"), nehmen Sie sie auf, damit Pods nicht auf Knotenpools landen, die nicht über die erforderlichen Ressourcen verfügen:

nodeSelector:
  gva_vnic: "yes"

Ein nodeSelector ist optional, wenn Anforderungen und Toleranzen von Anwendungsressourcen die Planung bereits einschränken. Verwenden Sie nur einen nodeSelector, wenn Sie die Zielknoten beschriftet haben (z.B. über Knotenpool-Kubernetes-Labels).

Nach dem Deployment:

1. Eingeben:

   kubectl get pods -o wide

2. Geben Sie für einen relevanten Pod Folgendes ein:

   kubectl describe pod <pod-name>

3. Stellen Sie sicher, dass der Pod ausgeführt wird und keine Planungsfehler vorliegen (z.B. unzureichende Kapazität für die angeforderte Ressource).

Installieren Sie Multus, bevor Sie NADs erstellen oder Pods mit mehreren Schnittstellen bereitstellen. Informationen zur Installation von Multus finden Sie in der Dokumentation zu Multus-CNI auf GitHub.

Befolgen Sie den Standardprozess Ihres Unternehmens für das Deployment von Multus, und prüfen Sie, ob der Prozess fehlerfrei ist:

kubectl get pod -l app=multus -n kube-system

In den Beispielen in diesem Abschnitt wird das CNI-Plug-in ipvlan für die zusätzliche Podschnittstelle verwendet. Stellen Sie sicher, dass die Binärdatei ipvlan in /opt/cni/bin/ipvlan auf jedem Worker-Knoten vorhanden ist, der Multi-Schnittstellen-Pods ausführen kann.

Oracle empfiehlt, das Plug-in ipvlan mit einem Cloud-Init-Skript für Knotenpools zu installieren, damit das Plug-in installiert wird, wenn Knoten erstellt, ersetzt oder vertikal skaliert werden. Pinnen Sie das Plug-in an ein validiertes Release für die Zielumgebung, anstatt einem unverankerten Downloadpfad zu folgen. Im folgenden Beispiel wird die Version v1.9.0 verwendet.

Beispiel:

#!/bin/bash

CNI_VERSION="v1.9.0"
CNI_ARCH="amd64"
CNI_TARBALL="cni-plugins-linux-${CNI_ARCH}-${CNI_VERSION}.tgz"
CNI_URL="https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/${CNI_TARBALL}"
CNI_BIN_DIR="/opt/cni/bin"

wget --fail -O "/tmp/${CNI_TARBALL}" "${CNI_URL}" && \
  tar xvzf "/tmp/${CNI_TARBALL}" -C "${CNI_BIN_DIR}" && \
  rm -f "/tmp/${CNI_TARBALL}"

curl --fail -H "Authorization: Bearer Oracle" -L0 \
  http://169.254.169.254/opc/v2/instance/metadata/oke_init_script \
  | base64 --decode > /var/run/oke-init.sh

bash /var/run/oke-init.sh

Wenn Worker-Knoten nicht auf GitHub zugreifen können, stellen Sie das erforderliche CNI-Plug-in-Archiv in OCI Object Storage oder einem anderen genehmigten internen Speicherort bereit, und aktualisieren Sie die Download-URL im Cloud-Init-Skript.

NADs müssen die tatsächlichen Hostschnittstellennamen als Ziel festlegen, die von den angehängten VNICs erstellt wurden (z.B. enp1s0, enp2s0). Prüfen Sie sie auf einem Mitarbeiterknoten mit der Standardzugriffsmethode Ihrer Organisation.

Erstellen:

• ein NAD für das Standardpodnetzwerk (um zu steuern, welche Hostschnittstelle eth0 unterstützt)
• einen oder mehrere NADs für zusätzliche Schnittstellen (z.B. net1).

Ihre NAD-Konfiguration kann ein Gerät mit einem deviceSelector auswählen (z.B. nach interfaceName oder nach Anwendungsressourcenname mit appResource, wenn dies in Ihrer Umgebung unterstützt wird).

Die folgenden NAD-Beispiele verwenden absichtlich verschiedene Namespaces. oci-vcn-native-network ist in kube-system definiert, während ipvlan-network in default definiert ist. Wenn die Workload in einem anderen Namespace ausgeführt wird, erstellen Sie ipvlan-network in diesem Namespace, oder aktualisieren Sie die Podannotation, um den vollqualifizierten NAD-Namen zu referenzieren.

Standard-Netzwerk-NAD an enp1s0 gepinnt:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: oci-vcn-native-network
  namespace: kube-system
spec:
  config: |
    {
      "name": "oci",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "cniVersion": "0.3.1",
          "type": "oci-ipvlan",
          "mode": "l2",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp1s0"
            }
          }
        },
        {
          "cniVersion": "0.3.1",
          "type": "oci-ptp",
          "containerInterface": "ptp-veth0",
          "mtu": 9000
        }
      ]
    }

NAD des sekundären Netzwerks an enp2s0 gepinnt:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-network
  namespace: default
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "ipvlan",
          "mode": "l2",
          "master": "enp2s0",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp2s0"
            }
          }
        }
      ]
    }

Der Standard-NAD verwendet die OCI-spezifischen Plug-ins oci-ipvlan und oci-ptp, da diese Schnittstelle am Pfad des nativen OKE-VCN-Standardnetzwerks teilnimmt. Der zusätzliche NAD verwendet das standardmäßige ipvlan-Plug-in, da Multus eine zusätzliche Schnittstelle an eine bestimmte Host-NIC anhängt, während OCI IPAM weiterhin die Subnetz-bezogene IP-Zuweisung bereitstellt.

deviceSelector kann Schnittstellen mit Feldern wie:

{
  "appResource": "blue",
  "interfaceName": "enp2s0",
  "interfaceNamePrefix": "enp",
  "macAddress": "02:00:17:08:E3:07"
}

Mit dem Block deviceSelector kann OCI IPAM die Zielschnittstelle oder VNIC auswählen, die für die Pod-IP-Zuweisung verwendet wird. Es kann ein Gerät mithilfe eines oder mehrerer dieser Felder auswählen:

• appResource: Wählt das GVA-VNIC-Profil nach Anwendungsressourcenname.

• interfaceName: Wählt eine bestimmte Hostschnittstelle, wie enp1s0.

• interfaceNamePrefix: Wählt eine Schnittstelle nach Präfix, wie enp.

• macAddress: Wählt eine Schnittstelle nach MAC-Adresse.

Wenn appResource im NAD-Geräteselektor festgelegt ist, verwendet das OCI-IPAM-Plug-in diese Anwendungsressource, um zu entscheiden, welches GVA-VNIC-Profil die Pod-IP-Adresse angeben und als übergeordnetes Gerät für diese Schnittstelle fungieren soll. Dadurch können verschiedene NADs im selben Pod unterschiedlichen VNIC-Profilen zugeordnet werden. Beispiel:

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

Wenn ein Pod alle drei NADs verwendet, kann jede Schnittstelle über das entsprechende VNIC-Profil angehängt werden.

In den in diesem Dokument gezeigten Beispielen für Schnittstellennamen:

• Der oci-vcn-native-network-NAD verwendet interfaceName: enp1s0, sodass OCI IPAM die Standardnetzwerk-IP des Pods von der enp1s0-Schnittstelle des Hosts zuweist.

• Der ipvlan-network-NAD verwendet interfaceName: enp2s0, sodass OCI IPAM die zusätzliche Schnittstellen-IP aus der enp2s0-Schnittstelle des Hosts zuweist.

Deshalb setzt das Pod-Beispiel:

annotations:
  v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
  k8s.v1.cni.cncf.io/networks: default/ipvlan-network

Die Annotation v1.multus-cni.io/default-network stellt sicher, dass eth0 den NAD oci-vcn-native-network verwendet. Ohne explizite Auswahl dieses Standardnetzwerks kann OCI IPAM von jeder berechtigten Hostschnittstelle zugewiesen werden, wodurch die primäre Podschnittstelle weniger vorhersehbar ist. Wenn der Standard-NAD festgelegt wird, wird sichergestellt, dass eth0 die beabsichtigte Schnittstelle verwendet und vom zusätzlichen Netzwerkanhang isoliert bleibt.

Kombinieren Sie diese Multus-Pod-Annotationen nicht mit Anwendungsressourcenanforderungen auf Pod-Ebene in derselben Podspezifikation. Wenn für einen Pod mit mehreren Schnittstellen eine GVA-VNIC-Auswahl erforderlich ist, definieren Sie diese Auswahl in der NAD-Konfiguration deviceSelector.appResource für jede Schnittstelle, anstatt eine Anwendungsressourcenanforderung auf Pod-Ebene zu verwenden.

NADs anwenden:

kubectl apply -f oci-vcn-native-network-nad.yaml

kubectl apply -f ipvlan-network.yaml

Kommentieren Sie den Pod, um den Standardnetzwerk-NAD auszuwählen, und hängen Sie zusätzliche Netzwerk-NADs an. Beispiel:

metadata:
  annotations:
    v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
    k8s.v1.cni.cncf.io/networks: default/ipvlan-network

1. Beschreiben Sie den Pod, und prüfen Sie die Multus-Netzwerkstatusannotationen (falls vorhanden):

   kubectl describe pod <pod-name>

2. Wenn in Ihrer Umgebung zulässig, führen Sie eine Ausführung im Pod aus, und prüfen Sie die Schnittstellen (z.B. ifconfig oder ip addr), um zu bestätigen, dass der Pod die erwarteten Schnittstellen (eth0, net1, …) und IP-Adressen aufweist.