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), mit denen Distributed Cloud leistungsstarke Arbeitslasten ausführen kann.

Der Operator für Netzwerkfunktionen und die SR-IOV-Funktionalität sind auf Distributed Cloud-Servern nicht verfügbar.

Mit dem Operator für Netzwerkfunktionen können Sie Folgendes tun:

  • Vorhandene Netzwerkgeräte auf einem Knoten abfragen.
  • Den IP-Adress- und physischen Verbindungsstatus für jedes Netzwerkgerät auf einem Knoten abfragen.
  • Zusätzliche Netzwerkschnittstellen auf einem Knoten bereitstellen.
  • Systemfunktionen auf niedriger Ebene auf der physischen Maschine des Knotens konfigurieren, die zur Unterstützung leistungsstarker Arbeitslasten erforderlich sind.
  • Die Single-Root I/O Virtualization (SR-IOV) auf PCI Express-Netzwerkschnittstellen verwenden, 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 Operator für Netzwerkfunktionen ruft die Netzwerkkonfiguration von der Distributed Cloud Edge Network API ab. Dazu müssen Sie dem Dienstkonto des Operators für Netzwerkfunktionen 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 Ziel Google Cloud projekts.

Ressourcen des Operators für Netzwerkfunktionen

Der Operator für Netzwerkfunktionen von Distributed Cloud 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 Verbindungsstatus und der IP-Adresse.
  • NodeSystemConfigUpdate. Ermöglicht die Konfiguration von Systemfunktionen auf niedriger Ebene wie Kerneloptionen 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. Ermöglicht das Abfragen des Bereitstellungsstatus der SriovNetworkNodePolicy-Ressource auf einem Distributed Cloud-Knoten.
  • NetworkAttachmentDefinition. Ermöglicht das Anhängen von Distributed Cloud-Pods an ein oder mehrere logische oder physische Netzwerke auf Ihrem Distributed Cloud-Knoten. 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 Operator für Netzwerkfunktionen können Sie auch sekundäre Netzwerkschnittstellen definieren, die keine virtuellen SR-IOV-Funktionen verwenden.

Network-Ressource

Die Network-Ressource definiert ein virtuelles Netzwerk im Distributed Cloud-Rack, 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 Wert für nodeInterfaceMatcher.interfaceName 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 eine schreibgeschützte Ressource, mit der Sie physische Netzwerkschnittstellen auf dem Knoten ermitteln und Laufzeitstatistiken zum Netzwerktraffic erfassen können, 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 gebundene Netzwerkschnittstelle auf der Rack Select Network Daughter Card (rNDC) mit dem Namen gdcenet0. Diese Schnittstelle bindet die Netzwerkschnittstellen eno1np0 und eno2np1. Jede davon ist mit einem Distributed Cloud-ToR-Switch verbunden.

Die NetworkInterfaceState-Ressource bietet die folgenden Kategorien von Netzwerkschnittstelleninformationen, 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 Zielschnittstelle.

Informationen zur IP-Adresskonfiguration:

  • status.interfaces.interfaceinfo.address: die der Zielschnittstelle zugewiesene IP-Adresse.
  • status.interfaces.interfaceinfo.dns: die IP-Adresse des DNS-Servers, der der Zielschnittstelle 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 Zielschnittstelle.
  • 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 Zielschnittstelle.
  • status.interfaces.linkinfo.mtu: der MTU-Wert für die Zielschnittstelle.

Empfangsstatistiken:

  • status.interfaces.statistics.rx.bytes: die Gesamtzahl der von der Zielschnittstelle empfangenen Byte.
  • status.interfaces.statistics.rx.dropped: die Gesamtzahl der von der Zielschnittstelle verworfenen Pakete.
  • status.interfaces.statistics.rx.errors: die Gesamtzahl der Paketempfangsfehler für die Zielschnittstelle.
  • status.interfaces.statistics.rx.multicast: die Gesamtzahl der von der Zielschnittstelle empfangenen Multicast-Pakete.
  • status.interfaces.statistics.rx.overErrors: die Gesamtzahl der Paketempfangsfehler für die Zielschnittstelle.
  • status.interfaces.statistics.rx.packets: die Gesamtzahl der von der Zielschnittstelle empfangenen Pakete.

Übertragungsstatistiken:

  • status.interfaces.statistics.tx.bytes: die Gesamtzahl der von der Zielschnittstelle übertragenen Byte.
  • status.interfaces.statistics.tx.carrierErrors: die Gesamtzahl der von der Zielschnittstelle aufgetretenen Carrier-Fehler.
  • status.interfaces.statistics.tx.collisions: die Gesamtzahl der von der Zielschnittstelle aufgetretenen Paketkollisionen.
  • status.interfaces.statistics.tx.dropped: die Gesamtzahl der von der Zielschnittstelle verworfenen Pakete.
  • status.interfaces.statistics.tx.errors: die Gesamtzahl der Übertragungsfehler für die Zielschnittstelle.
  • status.interfaces.statistics.tx.packets: die Gesamtzahl der von der Zielschnittstelle ü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 NodeSystemConfigUpdate-Ressource können Sie Änderungen an der Betriebssystemkonfiguration des Knotens vornehmen und Kubelet-Flags ändern. Andere Änderungen als sysctl-Änderungen 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 einzeln aktualisiert.

ACHTUNG: Das Feld nodeName wurde eingestellt. Wenn Sie es verwenden, werden die Zielknoten sofort neu gestartet, einschließlich der lokalen Steuerungsebenenknoten, was zu einem Stillstand kritischer Arbeitslasten führen kann.

Die NodeSystemConfigUpdate-Ressource bietet die folgenden Konfigurationsfelder, die spezifisch für Distributed Cloud sind:

  • spec.containerRuntimeDNSConfig.ip: gibt eine Liste von IP-Adressen für private Image-Registries an.

  • spec.containerRuntimeDNSConfig: gibt eine Liste benutzerdefinierter DNS-Einträge an, die von der Container Runtime Environment 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 ist: CustomNetworkInterfaceConfig, Network (per Annotation), NetworkAttachmentDefinition, (per 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 Hugepages wird gleichmäßig auf beide NUMA-Knoten im System verteilt. Wenn Sie beispielsweise 16 Hugepages mit jeweils 1 GB zuweisen, erhält jeder Knoten eine Vorabzuweisung von 8 GB.

  • spec.osConfig.isolatedCpusPerSocket: gibt die Anzahl der isolierten CPUs pro Socket an. Erforderlich, wenn cpuManagerPolicy auf Static gesetzt ist. Die maximale Anzahl der isolierten CPUs muss weniger als 80% der Gesamtzahl der CPUs im Knoten betragen.

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

  • spec.sysctls.NodeLevel: gibt die sysctls-Parameter an, die Sie mit dem Operator für Netzwerkfunktionen 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

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

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

  • status.lastReportTime: der Zeitpunkt, zu dem der Status zuletzt für die Zielschnittstelle gemeldet wurde.
  • status.conditions.lastTransitionTime: der Zeitpunkt, zu dem sich der Status der Schnittstelle zuletzt geändert hat.
  • status.conditions.observedGeneration: gibt den Wert .metadata.generation an, auf dem die ursprüngliche Bedingung basiert.
  • status.conditions.message: eine informative Nachricht, die die Änderung des Status 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 virtuellen SR-IOV-Funktionen (VFs) 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 jede Ziel-VF anhand des PCIe-Anbieters und der Geräte-ID, der PCIe-Geräteadressen oder des Linux-aufgezählten Gerätenamens auswählen. Der SR-IOV Network Operator konfiguriert jede physische Netzwerkschnittstelle, um die Ziel-VFs bereitzustellen. Dazu gehört das Aktualisieren der Firmware der Netzwerkschnittstelle, das Konfigurieren des Linux-Kerneltreibers und gegebenenfalls das Neustarten der Distributed Cloud-Maschine.

Um die auf Ihrem Knoten verfügbaren Netzwerkschnittstellen zu ermitteln, können Sie die NetworkInterfaceState Ressourcen auf diesem Knoten im nf-operator Namespace suchen.

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 vorherigen Beispiel werden maximal 31 VFs vom zweiten Port auf der Netzwerkschnittstelle mit dem Namen enp134s0f1np1 mit einem MTU-Wert von 9000 (dem maximal zulässigen Wert) erstellt. Verwenden Sie das Knoten-Selector-Label 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 SriovNetworkNodeState-Ressource können Sie den Bereitstellungsstatus der SriovNetworkNodePolicy-Ressource auf einem Distributed Cloud-Knoten abfragen. Sie gibt die vollständige Konfiguration der SriovNetworkNodePolicy-Ressource auf dem Knoten sowie eine Liste der aktiven VFs auf dem Knoten zurück. Das Feld status.syncStatus gibt an, ob alle für den Knoten definierten SriovNetworkNodePolicy-Ressourcen ordnungsgemäß 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. Dabei werden das Multus-CNI-Framework und das SRIOV-CNI-Plug-in verwendet.

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

  • Verwenden Sie den Schlüssel k8s.v1.cni.cncf.io/resourceName.
  • Verwenden Sie das Präfix gke.io/ im Wert, gefolgt vom Namen der Ziel-SriovNetworkNodePolicy-Ressource.

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 Schnittstelle bond0 durch eine neue Schnittstelle mit dem Namen gdcenet0 ersetzt. Mit der Schnittstelle gdcenet0 können Sie die Host-Management-Netzwerkschnittstellenkarte (NIC) auf jeder Distributed Cloud-Maschine in Ihrem Rack für Ihre Arbeitslasten verwenden, während der Distributed Cloud-Management- und Steuerungsebenen-Netzwerktraffic vollständig getrennt bleibt. 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 Subnetze 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 mit virtuellen SR-IOV-Funktionen konfigurieren.

Fügen Sie dazu der Distributed Cloud-Pod-Definition 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 Schnittstelle gdcenet0 unterstützt diese Konfiguration und nur auf Pods, die containerisierte Arbeitslasten ausführen.

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

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

     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 Distributed Cloud-Pod-Definition eine Annotation hinzu:

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

Sekundäre Schnittstelle auf einem Pod mit Distributed Cloud-Multi-Netzwerk konfigurieren

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

  1. Konfigurieren Sie eine Network-Ressource. 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 Distributed Cloud-Pod-Definition eine Annotation 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