Betreiber der Netzwerkfunktion

Auf dieser Seite wird der spezielle Kubernetes-Operator für Netzwerkfunktionen beschrieben, der in Google Distributed Cloud enthalten ist. Dieser Operator implementiert eine Reihe von CustomResourceDefinitions (CRDs), die es Distributed Cloud ermöglichen, leistungsstarke Arbeitslasten auszuführen.

Die Funktionen für Netzwerkfunktionen und SR-IOV sind auf Distributed Cloud-Servern nicht verfügbar.

Mit dem Network Function-Operator haben Sie folgende Möglichkeiten:

  • Vorhandene Netzwerkgeräte auf einem Knoten abfragen.
  • Fragen Sie den Status der IP-Adresse und der physischen Verbindung für jedes Netzwerkgerät auf einem Knoten ab.
  • Stellen Sie zusätzliche Netzwerkschnittstellen auf einem Knoten bereit.
  • Konfigurieren Sie die erforderlichen Systemfunktionen auf niedriger Ebene auf der physischen Maschine des Knotens, um Hochleistungs-Arbeitslasten zu unterstützen.
  • Verwenden Sie SR-IOV (Single-Root Input/Output Virtualization) auf PCI Express-Netzwerkschnittstellen, um sie in mehrere virtuelle Schnittstellen zu virtualisieren. Anschließend können Sie Ihre Distributed Cloud-Arbeitslasten so konfigurieren, dass sie diese virtuellen Netzwerkschnittstellen verwenden.

Die Unterstützung von SR-IOV in Distributed Cloud basiert auf den folgenden Open-Source-Projekten:

Vorbereitung

Der Network Function-Operator ruft die Netzwerkkonfiguration über die Distributed Cloud Edge Network API ab. Dazu müssen Sie dem Dienstkonto des Netzwerkfunktionsoperators mit dem folgenden Befehl die Rolle „Edge Network Viewer“ (roles/edgenetwork.viewer) zuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/edgenetwork.viewer \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[nf-operator/nf-angautomator-sa]"

Ersetzen Sie PROJECT_ID durch die ID des Zielprojekts Google Cloud .

Ressourcen für den Betrieb von Netzwerkfunktionen

Der Distributed Cloud Network Function-Operator implementiert die folgenden Kubernetes-CRDs:

  • Network: Definiert ein virtuelles Netzwerk, das Pods für die Kommunikation mit internen und externen Ressourcen verwenden können. Sie müssen das entsprechende VLAN mit der Distributed Cloud Edge Network API erstellen, bevor Sie es in dieser Ressource angeben. Eine Anleitung finden Sie unter Netzwerk erstellen.
  • NetworkInterfaceState: Ermöglicht die Ermittlung von Netzwerkschnittstellenstatus und das Abfragen einer Netzwerkschnittstelle nach dem Linkstatus und der IP-Adresse.
  • NodeSystemConfigUpdate: Ermöglicht die Konfiguration von Low-Level-Systemfunktionen wie Kernel-Optionen und Kubelet-Flags.
  • SriovNetworkNodePolicy: Wählt eine Gruppe von SR-IOV-virtualisierten Netzwerkschnittstellen aus und instanziiert die Gruppe als Kubernetes-Ressource. Sie können diese Ressource in einer NetworkAttachmentDefinition-Ressource verwenden.
  • SriovNetworkNodeState: Hiermit können Sie den Bereitstellungsstatus der SriovNetworkNodePolicy-Ressource auf einem Distributed Cloud-Knoten abfragen.
  • NetworkAttachmentDefinition: Hiermit können Sie Distributed Cloud-Pods an ein oder mehrere logische oder physische Netzwerke auf Ihrem Distributed Cloud-Knoten anhängen. Sie müssen das entsprechende VLAN mit der Distributed Cloud Edge Network API erstellen, bevor Sie es in dieser Ressource angeben. Eine Anleitung finden Sie unter Netzwerk erstellen.

Mit dem Network Function-Operator können Sie auch sekundäre Netzwerkschnittstellen definieren, die keine SR-IOV-Virtual Functions verwenden.

Network-Ressource

Mit der Network-Ressource wird ein virtuelles Netzwerk im Distributed Cloud-Rack definiert, das Pods in Ihrem Distributed Cloud-Cluster für die Kommunikation mit internen und externen Ressourcen verwenden können.

Die Network-Ressource bietet die folgenden konfigurierbaren Parameter für die Netzwerkschnittstelle, die als beschreibbare Felder verfügbar sind:

  • spec.type: Gibt die Netzwerktransportschicht für dieses Netzwerk an. Der einzige gültige Wert ist L2. Sie müssen auch einen nodeInterfaceMatcher.interfaceName-Wert angeben.
  • spec.nodeInterfaceMatcher.interfaceName: Der Name der physischen Netzwerkschnittstelle auf dem Zielknoten von Distributed Cloud, die mit diesem Netzwerk verwendet werden soll.
  • spec.gateway4: die IP-Adresse des Netzwerk-Gateways für dieses Netzwerk.
  • spec.l2NetworkConfig.prefixLength4: Gibt den CIDR-Bereich für dieses Netzwerk an.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vlan200-network
  annotations:
    networking.gke.io/gdce-vlan-id: 200
    networking.gke.io/gdce-vlan-mtu: 1500
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.200
  gateway4: 10.53.0.1

NetworkInterfaceState-Ressource

Die NetworkInterfaceState-Ressource ist schreibgeschützt. Mit ihr können Sie physische Netzwerkschnittstellen auf dem Knoten ermitteln und Laufzeitstatistiken zum Netzwerkverkehr erfassen, der über diese Schnittstellen fließt. Distributed Cloud erstellt für jeden Knoten in einem Cluster eine NetworkInterfaceState-Ressource.

Die Standardkonfiguration von Distributed Cloud-Maschinen umfasst eine gebündelte Netzwerkschnittstelle auf der Rack Select Network Daughter Card (rNDC) mit dem Namen gdcenet0. Diese Schnittstelle fasst die Netzwerkschnittstellen eno1np0 und eno2np1 zusammen. Jeder ist mit einem Distributed Cloud-ToR-Switch verbunden.

Die NetworkInterfaceState-Ressource enthält die folgenden Kategorien von Informationen zur Netzwerkschnittstelle, die als schreibgeschützte Statusfelder verfügbar sind.

Allgemeine Informationen:

  • status.interfaces.ifname: Der Name der Zielnetzwerkschnittstelle.
  • status.lastReportTime: Die Uhrzeit und das Datum des letzten Statusberichts für die Ziel-Schnittstelle.

Informationen zur Konfiguration von IP-Adressen:

  • status.interfaces.interfaceinfo.address: die IP-Adresse, die der Ziel-Schnittstelle zugewiesen ist.
  • status.interfaces.interfaceinfo.dns: die IP-Adresse des DNS-Servers, der der Ziel-Schnittstelle zugewiesen ist.
  • status.interfaces.interfaceinfo.gateway: die IP-Adresse des Netzwerk-Gateways, das die Zielschnittstelle bedient.
  • status.interfaces.interfaceinfo.prefixlen: die Länge des IP-Präfixes.

Hardwareinformationen:

  • status.interfaces.linkinfo.broadcast: die Broadcast-MAC-Adresse der Ziel-Schnittstelle.
  • status.interfaces.linkinfo.businfo: Der PCIe-Gerätepfad im Format bus:slot.function.
  • status.interfaces.linkinfo.flags: die Schnittstellen-Flags, z. B. BROADCAST.
  • status.interfaces.linkinfo.macAddress: die Unicast-MAC-Adresse der Ziel-Schnittstelle.
  • status.interfaces.linkinfo.mtu: Der MTU-Wert für die Ziel-Schnittstelle.

Statistiken zu erhaltenen Präsentationen:

  • status.interfaces.statistics.rx.bytes: Die Gesamtzahl der Byte, die von der Ziel-Schnittstelle empfangen wurden.
  • status.interfaces.statistics.rx.dropped: Die Gesamtzahl der Pakete, die von der Ziel-Schnittstelle verworfen wurden.
  • status.interfaces.statistics.rx.errors: Die Gesamtzahl der Paketempfangsfehler für die Ziel-Schnittstelle.
  • status.interfaces.statistics.rx.multicast: die Gesamtzahl der Multicast-Pakete, die von der Ziel-Schnittstelle empfangen wurden.
  • status.interfaces.statistics.rx.overErrors: Die Gesamtzahl der empfangenen Pakete über Fehler für die Ziel-Schnittstelle.
  • status.interfaces.statistics.rx.packets: Die Gesamtzahl der Pakete, die von der Ziel-Schnittstelle empfangen wurden.

Übertragungsstatistiken:

  • status.interfaces.statistics.tx.bytes: Die Gesamtzahl der von der Ziel-Schnittstelle übertragenen Byte.
  • status.interfaces.statistics.tx.carrierErrors: die Gesamtzahl der von der Zielschnittstelle erkannten Carrier-Fehler.
  • status.interfaces.statistics.tx.collisions: Die Gesamtzahl der Paketkollisionen, die an der Ziel-Schnittstelle aufgetreten sind.
  • status.interfaces.statistics.tx.dropped: Die Gesamtzahl der Pakete, die von der Ziel-Schnittstelle verworfen wurden.
  • status.interfaces.statistics.tx.errors: Die Gesamtzahl der Übertragungsfehler für die Ziel-Schnittstelle.
  • status.interfaces.statistics.tx.packets: Die Gesamtzahl der vom Zielinterface übertragenen Pakete.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: networking.gke.io/v1
kind: NetworkInterfaceState
metadata:
  name: MyNode1
nodeName: MyNode1
status:
  interfaces:
  - ifname: eno1np0
    linkinfo:
      businfo: 0000:1a:00.0
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 1098522811
        errors: 2
        multicast: 190926
        packets: 4988200
      tx:
        bytes: 62157709961
        packets: 169847139
  - ifname: eno2np1
    linkinfo:
      businfo: 0000:1a:00.1
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 33061895405
        multicast: 110203
        packets: 110447356
      tx:
        bytes: 2370516278
        packets: 11324730
  - ifname: enp95s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf4
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f4
      mtu: 9000
    statistics:
      rx:
        bytes: 37858381
        multicast: 205645
        packets: 205645
      tx:
        bytes: 1207334
        packets: 6542
  - ifname: enp95s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf5
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f5
      mtu: 9000
    statistics:
      rx:
        bytes: 37852406
        multicast: 205607
        packets: 205607
      tx:
        bytes: 1207872
        packets: 6545
  - ifname: enp134s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6c
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6c
      mtu: 9000
    statistics:
      rx:
        bytes: 37988773
        multicast: 205584
        packets: 205584
      tx:
        bytes: 1212385
        packets: 6546
  - ifname: enp134s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6d
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6d
      mtu: 9000
    statistics:
      rx:
        bytes: 37980702
        multicast: 205548
        packets: 205548
      tx:
        bytes: 1212297
        packets: 6548
  - ifname: gdcenet0
    interfaceinfo:
    - address: 208.117.254.36
      prefixlen: 28
    - address: fe80::b816:3ff:fe9e:9c87
      prefixlen: 64
    linkinfo:
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 34160422968
        errors: 2
        multicast: 301129
        packets: 115435591
      tx:
        bytes: 64528301111
        packets: 181171964
     .. <remaining interfaces omitted>
   lastReportTime: "2022-03-30T07:35:44Z"

NodeSystemConfigUpdate-Ressource

Mit der Ressource NodeSystemConfigUpdate können Sie Änderungen an der Betriebssystemkonfiguration des Knotens vornehmen und Kubelet-Flags ändern. Änderungen, die nicht sysctl betreffen, erfordern einen Neustart des Knotens.

Beim Instanziieren dieser Ressource müssen Sie die Zielknoten im Feld nodeSelector angeben. Sie müssen alle Schlüssel/Wert-Paare für jeden Zielknoten im Feld nodeSelector angeben. Wenn Sie in diesem Feld mehr als einen Zielknoten angeben, werden die Zielknoten nacheinander aktualisiert.

ACHTUNG: Das Feld nodeName wurde eingestellt. Wenn Sie den Befehl sofort verwenden, werden die Zielknoten, einschließlich der lokalen Steuerungsebenenknoten, neu gestartet. Dadurch können kritische Arbeitslasten angehalten werden.

Die NodeSystemConfigUpdate-Ressource bietet die folgenden Konfigurationsfelder, die speziell für Distributed Cloud gelten:

  • spec.containerRuntimeDNSConfig.ip: Gibt eine Liste von IP-Adressen für private Bildregistrierungen an.

  • spec.containerRuntimeDNSConfig: Gibt eine Liste benutzerdefinierter DNS-Einträge an, die von der Container-Laufzeitumgebung auf jedem Distributed Cloud-Knoten verwendet werden. Jeder Eintrag besteht aus den folgenden Feldern:

    • ip: gibt die Ziel-IPv4-Adresse an.
    • domain: Gibt die entsprechende Domain an.
    • interface: Gibt die Netzwerkausgangsschnittstelle an, über die die im Feld ip angegebene IP-Adresse erreichbar ist. Sie können eine Schnittstelle angeben, die über die folgenden Ressourcen definiert wird: CustomNetworkInterfaceConfig, Network (über Annotation), NetworkAttachmentDefinition (über Annotation). Dies ist eine Funktion auf Vorschau-Ebene.

  • spec.kubeletConfig.cpuManagerPolicy: Gibt die Kubernetes-CPUManager-Richtlinie an. Gültige Werte sind None und Static.

  • spec.kubeletConfig.topologyManagerPolicy: Gibt die Kubernetes-TopologyManager-Richtlinie an. Gültige Werte sind None, BestEffort, Restricted und SingleNumaMode.

  • spec.osConfig.hugePagesConfig: Gibt die Hugepage-Konfiguration pro NUMA-Knoten an. Gültige Werte sind 2MB und 1GB. Die Anzahl der angeforderten Huge Pages wird gleichmäßig auf beide NUMA-Knoten im System verteilt. Wenn Sie beispielsweise 16 Huge Pages mit jeweils 1 GB zuweisen, erhält jeder Knoten eine Vorabzuweisung von 8 GB.

  • spec.osConfig.isolatedCpusPerSocket: Gibt die Anzahl der isolierten CPUs pro Sockel an. Erforderlich, wenn cpuManagerPolicy auf Static gesetzt ist. Die maximale Anzahl isolierter CPUs darf nicht mehr als 80% der Gesamtzahl der CPUs im Knoten betragen.

  • spec.osConfig.cpuIsolationPolicy: Gibt die Richtlinie zur CPU-Isolation an. Die Default-Richtlinie isoliert nur systemd-Aufgaben von CPUs, die für Arbeitslasten reserviert sind. Die Kernel-Richtlinie kennzeichnet die CPUs als isolcpus und legt die Flags rcu_nocb, nohz_full und rcu_nocb_poll für jede CPU fest.

  • spec.sysctls.NodeLevel: Gibt die sysctls-Parameter an, die Sie mithilfe des Network Function-Operators global auf einem Knoten konfigurieren können. Die konfigurierbaren Parameter sind:

    • fs.inotify.max_user_instances
    • fs.inotify.max_user_watches
    • kernel.sched_rt_runtime_us
    • kernel.core_pattern
    • net.ipv4.tcp_wmem
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_slow_start_after_idle
    • net.ipv4.udp_rmem_min
    • net.ipv4.udp_wmem_min
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_wmem
    • net.core.rmem_max
    • net.core.wmem_max
    • net.core.rmem_default
    • net.core.wmem_default
    • net.netfilter.nf_conntrack_tcp_timeout_unacknowledged
    • net.netfilter.nf_conntrack_tcp_timeout_max_retrans
    • net.sctp.auth_enable
    • net.sctp.sctp_mem
    • net.ipv4.udp_mem
    • net.ipv4.tcp_mem
    • net.ipv4.tcp_slow_start_after_idle
    • net.sctp.auth_enable
    • vm.max_map_count

    Sie können sowohl sichere als auch unsichere sysctls-Parameter auf einen bestimmten Pod oder Namespace beschränken, indem Sie das tuning-CNI-Plug-in (Container Networking Interface) verwenden.

Die NodeSystemConfigUpdate-Ressource bietet die folgenden schreibgeschützten allgemeinen Statusfelder:

  • status.lastReportTime: Der Zeitpunkt, zu dem der Status für die Ziel-Schnittstelle zuletzt gemeldet wurde.
  • status.conditions.lastTransitionTime: Der Zeitpunkt, zu dem sich der Zustand der Schnittstelle zuletzt geändert hat.
  • status.conditions.observedGeneration: Der .metadata.generation-Wert, auf dem die Ausgangsbedingung basiert.
  • status.conditions.message: Eine informative Nachricht, die die Änderung des Zustands der Schnittstelle beschreibt.
  • status.conditions.reason: eine programmatische Kennung, die den Grund für die letzte Änderung des Status der Schnittstelle angibt.
  • status.conditions.status: Der Statusdeskriptor der Bedingung. Gültige Werte sind True, False und Unknown.
  • status.conditions.type: Der Bedingungstyp im Binnenmajuskelformat.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
  name: node-pool-1-config
  namespace: default
spec:
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
    networking.gke.io/worker-network-sriov.capable: true
  sysctls:
    nodeLevel:
      "net.ipv4.udp_mem" : "12348035 16464042 24696060"
  kubeletConfig:
    topologyManagerPolicy: BestEffort
    cpuManagerPolicy: Static
  osConfig:
    hugePagesConfig:
      "TWO_MB": 0
      "ONE_GB": 16
    isolatedCpusPerSocket:
      "0": 10
      "1": 10

SriovNetworkNodePolicy-Ressource

Mit der SriovNetworkNodePolicy-Ressource können Sie eine Gruppe von SR-IOV-VFs (Virtual Functions) auf einer physischen Distributed Cloud-Maschine zuweisen und diese Gruppe als Kubernetes-Ressource instanziieren. Anschließend können Sie diese Ressource in einer NetworkAttachmentDefinition-Ressource verwenden.

Sie können jedes Ziel-VF anhand seiner PCIe-Anbieter- und Geräte-ID, seiner PCIe-Geräteadressen oder seines in Linux aufgezählten Gerätenamens auswählen. Der SR-IOV Network Operator konfiguriert jede physische Netzwerkschnittstelle, um die Ziel-VFs bereitzustellen. Dazu gehören das Aktualisieren der Firmware der Netzwerkschnittstelle, das Konfigurieren des Linux-Kernel-Treibers und das Neustarten des Distributed Cloud-Computers, falls erforderlich.

Wenn Sie die auf Ihrem Knoten verfügbaren Netzwerkschnittstellen ermitteln möchten, können Sie die NetworkInterfaceState-Ressourcen auf diesem Knoten im Namespace nf-operator aufrufen.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlnx6-p2-sriov-en2
  namespace: sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  mtu: 9000
  nicSelector:
    pfNames:
    - enp134s0f1np1
  nodeSelector:
    edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_p2_sriov_en2

Im obigen Beispiel werden maximal 31 VFs über den zweiten Port auf der Netzwerkschnittstelle mit dem Namen enp134s0f1np1 mit einem MTU-Wert von 9000 (dem maximal zulässigen Wert) erstellt. Verwenden Sie das Knotenselektorlabel edgecontainer.googleapis.com/network-sriov.capable, das auf allen Distributed Cloud-Knoten vorhanden ist, die SR-IOV unterstützen.

Informationen zur Verwendung dieser Ressource finden Sie unter SriovNetworkNodeState.

SriovNetworkNodeState-Ressource

Mit der schreibgeschützten Ressource SriovNetworkNodeState können Sie den Bereitstellungsstatus der Ressource SriovNetworkNodePolicy auf einem Distributed Cloud-Knoten abfragen. Es wird die vollständige Konfiguration der SriovNetworkNodePolicy-Ressource auf dem Knoten sowie eine Liste der aktiven VFs auf dem Knoten zurückgegeben. Das Feld status.syncStatus gibt an, ob alle für den Knoten definierten SriovNetworkNodePolicy-Ressourcen richtig angewendet wurden.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
  name: MyNode1
  namespace: sriov-network-operator
spec:
  dpConfigVersion: "1969684"
  interfaces:
  - mtu: 9000
    name: enp134s0f1np1
    numVfs: 31
    pciAddress: 0000:86:00.1
    vfGroups:
    - deviceType: netdevice
      mtu: 9000
      policyName: mlnx6-p2-sriov-en2
      resourceName: mlnx6_p2_sriov_en2
      vfRange: 0-30
status:

Status:
  Interfaces:
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno1np0
    Pci Address:  0000:1a:00.0
    Vendor:       15b3
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno2np1
    Pci Address:  0000:1a:00.1
    Vendor:       15b3
    Vfs:
  - Vfs:
    - deviceID: 101e
      driver: mlx5_core
      mac: c2:80:29:b5:63:55
      mtu: 9000
      name: enp134s0f1v0
      pciAddress: 0000:86:04.1
      vendor: 15b3
      vfID: 0
    - deviceID: 101e
      driver: mlx5_core
      mac: 7e:36:0c:82:d4:20
      mtu: 9000
      name: enp134s0f1v1
      pciAddress: 0000:86:04.2
      vendor: 15b3
      vfID: 1
      .. <omitted 29 other VFs here>
  syncStatus: Succeeded

Informationen zur Verwendung dieser Ressource finden Sie unter SriovNetworkNodeState.

NetworkAttachmentDefinition-Ressource

Mit der NetworkAttachmentDefinition-Ressource können Sie Distributed Cloud-Pods an ein oder mehrere logische oder physische Netzwerke auf Ihrem Distributed Cloud-Knoten anhängen. Es nutzt das Multus-CNI-Framework und das SRIOV-CNI-Plug-in.

Verwenden Sie eine Annotation, um auf den Namen der entsprechenden SriovNetworkNodePolicy-Ressource zu verweisen. Gehen Sie beim Erstellen dieser Anmerkung so vor:

  • Verwenden Sie die Taste k8s.v1.cni.cncf.io/resourceName.
  • Verwenden Sie das Präfix gke.io/ in seinem Wert, gefolgt vom Namen der Zielressource SriovNetworkNodePolicy.

Das folgende Beispiel veranschaulicht die Struktur der Ressource:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net1
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p2_sriov_en2

spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-network",
  "ipam": {
    "type": "host-local",
    "subnet": "10.56.217.0/24",
    "routes": [{
      "dst": "0.0.0.0/0"
    }],
    "gateway": "10.56.217.1"
  }
}'

NetworkAttachmentDefinition-Ressourcen auf Distributed Cloud 1.4.0 aktualisieren

In Distributed Cloud-Version 1.4.0 wird die bond0-Schnittstelle durch eine neue Schnittstelle mit dem Namen gdcenet0 ersetzt. Über die gdcenet0-Schnittstelle können Sie die Host-Verwaltungs-NIC (Network Interface Card) in jeder Distributed Cloud-Maschine in Ihrem Rack für Ihre Arbeitslasten verwenden und gleichzeitig den Netzwerk-Traffic der Distributed Cloud-Verwaltungs- und Steuerungsebene vollständig trennen. Wenn Sie diese Funktion nutzen möchten, führen Sie die Schritte in diesem Abschnitt aus, um Ihre NetworkAttachmentDefinition-Ressourcen neu zu konfigurieren. Folgen Sie dann der Anleitung unter Distributed Cloud-Netzwerk konfigurieren, um die entsprechenden Netzwerke und Subnetzwerke bereitzustellen.

Für jeden Distributed Cloud-Cluster, in dem Sie eine oder mehrere NetworkAttachmentDefinition-Ressourcen bereitgestellt haben, gelten die folgenden Migrationsregeln:

  • Verwenden Sie für jede neue NetworkAttachmentDefinition-Ressource gdcenet0 anstelle von bond0 als Wert des Felds master. Wenn Sie eine Ressource anwenden, die bond0 oder einen leeren Wert für dieses Feld verwendet, ersetzt Distributed Cloud den Wert durch gdcenet0 und speichert und wendet die Ressource dann auf den Cluster an.
  • Ersetzen Sie für jede vorhandene NetworkAttachmentDefinition-Ressource bond0 durch gdcenet0 als Wert des Felds master und wenden Sie die Ressource dann noch einmal auf den Cluster an, um die vollständige Netzwerkverbindung zu den betroffenen Pods wiederherzustellen.

Informationen zur Verwendung dieser Ressource finden Sie unter NetworkAttachmentDefinition.

Sekundäre Schnittstelle auf einem Pod mit SR-IOV-VFs konfigurieren

Nachdem Sie eine SriovNetworkNodePolicy-Ressource und eine entsprechende NetworkAttachmentDefinition-Ressource konfiguriert haben, können Sie eine sekundäre Netzwerkschnittstelle auf einem Distributed Cloud-Pod mithilfe von SR-IOV-Virtual Functions konfigurieren.

Fügen Sie dazu der Definition des Distributed Cloud-Pods eine Annotation hinzu:

  • Schlüssel: k8s.v1.cni.cncf.io/networks
  • Wert: nameSpace/<NetworkAttachmentDefinition1,nameSpace/NetworkAttachmentDefinition2...

Das folgende Beispiel veranschaulicht diese Annotation:

apiVersion: v1
kind: Pod
metadata:
  name: sriovpod
  annotations:
    k8s.v1.cni.cncf.io/networks: mynamespace/sriov-net1
spec:
  containers:
  - name: sleeppodsriov
    command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine
    securityContext:
      capabilities:
        add:
          - NET_ADMIN

Sekundäre Schnittstelle auf einem Pod mit dem MacVLAN-Treiber konfigurieren

Distributed Cloud unterstützt auch das Erstellen einer sekundären Netzwerkschnittstelle auf einem Pod mit dem MacVLAN-Treiber. Nur die gdcenet0-Schnittstelle unterstützt diese Konfiguration und nur für Pods, in denen containerisierte Arbeitslasten ausgeführt werden.

So konfigurieren Sie eine Schnittstelle für die Verwendung des MacVLAN-Treibers:

  1. Konfigurieren Sie eine NetworkAttachmentDefinition-Ressource wie im folgenden Beispiel:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-b400-1
   annotations:
     networking.gke.io/gdce-vlan-id: 400
 spec:
   config: '{
   "type": "macvlan",
   "master": "gdcenet0.400",
   "ipam": {
     "type": "static",
     "addresses": [
       {
         "address": "192.168.100.20/27",
         "gateway": "192.168.100.1"
       }
     ]
   ...
   }
 }'

  2. Fügen Sie der Pod-Definition für Distributed Cloud eine Annotation wie folgt hinzu:

     apiVersion: v1
 kind: Pod
 metadata:
   name: macvlan-testpod1
   annotations:
     k8s.v1.cni.cncf.io/networks: macvlan-b400-1

Sekundäre Schnittstelle für einen Pod mit Distributed Cloud Multi-Networking konfigurieren

Distributed Cloud unterstützt das Erstellen einer sekundären Netzwerkschnittstelle auf einem Pod mithilfe der Multi-Netzwerk-Funktion. Führen Sie dazu die folgenden Schritte aus:

  1. Network-Ressource konfigurieren Beispiel:

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vlan200-network
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: vlan200-interface
  gateway4: 10.53.0.1

  2. Fügen Sie der Pod-Definition für Distributed Cloud eine Annotation wie folgt hinzu:

    apiVersion: v1
kind: Pod
metadata:
  name: myPod
  annotations:
    networking.gke.io/interfaces: [{"interfaceName":"eth1","network":"vlan200-network"}]
    networking.gke.io/default-interface: eth1
...

    Nächste Schritte