Betreiber der Netzwerkfunktion

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

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 mit Distributed Cloud verbundenen Arbeitslasten so konfigurieren, dass sie diese virtuellen Netzwerkschnittstellen verwenden.

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

Betreiberprofile für Netzwerkfunktionen

Distributed Cloud Connected bietet die folgenden Funktionsprofile für Netzwerkfunktionen auf jedem Distributed Cloud Connected-Formfaktor:

  • Distributed Cloud-Racks mit Verbindung unterstützen das vollständige Funktionsprofil für Netzwerkfunktionen mit den folgenden Funktionen:

    • Mit Netzwerkautomatisierungsfunktionen können Sie die Konfiguration des Pod-Netzwerks Ihrer Arbeitslast automatisieren. Beispielsweise BGP-Peering und sekundäre Netzwerkschnittstellen konfigurieren.

    • Mit Funktionen zum Exportieren des Status können Sie Hostnetzwerkstatus für den Nutzer exportieren, einschließlich der Konfiguration und des Status der Netzwerkschnittstelle.

    • Mit Knotenkonfigurationsfunktionen können Sie die Leistung eines Knotens an Ihre geschäftlichen Anforderungen anpassen, einschließlich CPU-Isolation, Huge Pages, Echtzeitkernel, kubelet-Parametern und sysctl.

    • Mit den Energieverwaltungsfunktionen können Sie den Stromverbrauch auf einem Knoten verwalten, einschließlich der P- und C-Zustände isolierter CPUs.

    • Mit Webhook-Funktionen können Sie Nutzereingaben validieren.

    • Zu den verschiedenen Funktionen gehört der SR-IOV-Automator, der den SR-IOV-Operator automatisch konfiguriert.

  • Mit Distributed Cloud verbundene Server unterstützen das leistungsoptimierte Funktionsprofil für Netzwerkfunktionen mit den folgenden Funktionen:

    • Mit Netzwerkautomatisierungsfunktionen können Sie die Konfiguration des Pod-Netzwerks Ihrer Arbeitslast automatisieren. Beispielsweise BGP-Peering und sekundäre Netzwerkschnittstellen konfigurieren.

    • Mit Funktionen zum Exportieren des Status können Sie Hostnetzwerkstatus für den Nutzer exportieren, einschließlich der Konfiguration und des Status der Netzwerkschnittstelle.

    • Mit Webhook-Funktionen können Sie Nutzereingaben validieren.

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 ZONE_PROJECT_ID \
  --role roles/edgenetwork.viewer \
  --member "serviceAccount:CLUSTER_PROJECT_ID.svc.id.goog[nf-operator/nf-angautomator-sa]"

Ersetzen Sie Folgendes:

  • ZONE_PROJECT_ID durch die ID des Google Cloud Projekts, das die Distributed Cloud Edge Network API-Ressourcen enthält.
  • CLUSTER_PROJECT_ID durch die ID des Google Cloud Projekts, das den verbundenen Zielcluster von Distributed Cloud enthält.

Ressourcen für den Betrieb von Netzwerkfunktionen

Der Operator für verbundene 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 Subnetzwerk 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 mit Distributed Cloud verbundenen 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 Subnetzwerk 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 mit Distributed Cloud verbundenen Rack definiert, das Pods in Ihrem mit Distributed Cloud verbundenen 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 Connected, 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.
  • annotations.networking.gke.io/gdce-per-node-ipam-size: gibt die Größe der Subnetzmaske für einen einzelnen Knoten an. Wenn diese Angabe fehlt, wird die Größe der Subnetzmaske auf den Wert des Felds cluster-cidr-config-per-node-mask-size in der ConfigMap nf-operator-defaults im Namespace nf-operator festgelegt.
  • annotations.networking.gke.io/gdce-vlan-id: Gibt die VLAN-ID für dieses Netzwerk an.
  • annotations.networking.gke.io/gdce-vlan-mtu: (optional) Gibt den MTU-Wert für dieses Netzwerk an. Wird kein Wert angegeben, wird der MTU-Wert von der übergeordneten Schnittstelle übernommen.
  • annotations.networking.gke.io/gdce-lb-service-vip-cidr: Gibt den Bereich der virtuellen IP-Adressen für den Load-Balancing-Dienst an. Der Wert kann ein CIDR-Block oder ein expliziter Adressbereich sein. Diese Anmerkung ist für Layer 3-Load-Balancing obligatorisch und für Layer 2-Load-Balancing optional.

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
    networking.gke.io/gdce-lb-service-vip-cidrs: "10.1.1.0/24"
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.200
  gateway4: 10.53.0.1

Wenn Sie mehrere Bereiche virtueller IP-Adressen für den Load-Balancing-Dienst angeben möchten, verwenden Sie die Annotation networking.gke.io/gdce-lb-service-vip-cidrs. Sie können die Werte für diese Annotation entweder als durch Kommas getrennte Liste oder als JSON-Nutzlast angeben. Beispiel:

[
  {
    "name": "test-oam-3",
    "addresses": ["10.235.128.133-10.235.128.133"],
    "autoAssign": false
  }
  ,
  {
    "name": "test-oam-4",
    "addresses": ["10.235.128.134-10.235.128.134"],
    "autoAssign": false
  },
  {
    "name": "test-oam-5",
    "addresses": ["10.235.128.135-10.235.128.135"],
    "autoAssign": false
  }
]

Wenn Sie eine JSON-Nutzlast verwenden, empfehlen wir das komprimierte JSON-Format. Beispiel:

apiVersion: networking.gke.io/v1
  kind: Network
  metadata:
    annotations:
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"test-oam-3","addresses":["10.235.128.133-10.235.128.133"],"autoAssign":false},{"name":"test-oam-4","addresses":["10.235.128.134-10.235.128.134"],"autoAssign":false},{"name":"test-oam-5","addresses":["10.235.128.135-10.235.128.135"],"autoAssign":false}]'
      networking.gke.io/gdce-vlan-id: "81"
    name: test-network-vlan81
  spec:
    IPAMMode: Internal
    dnsConfig:
      nameservers:
      - 8.8.8.8
    gateway4: 192.168.81.1
    l2NetworkConfig:
      prefixLength4: 24
    nodeInterfaceMatcher:
      interfaceName: gdcenet0.81
    type: L2

Wenn das Feld autoAssign weggelassen wird, wird standardmäßig false verwendet.

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. Diese Ressource ist nicht für Bereitstellungen von verbundenen Servern in Distributed Cloud verfügbar.

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 Connected 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 mit Distributed Cloud verbundenen 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).

  • 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.cgroupConfig.noKernelMemory: schließt den Kernel-Speicher aus der Berechnung der Pod-Speichernutzung aus. Gültige Werte sind true und false.

  • 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. Die KernelOptimized-Richtlinie kennzeichnet die CPUs als isolcpus und legt die Flags rcu_nocb und rcu_nocb_poll für jede CPU fest, nicht aber das Flag nohz_full.

  • 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 mithilfe des tuning-CNI-Plug-ins (Container Networking Interface) 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 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 Ressource SriovNetworkNodePolicy können Sie eine Gruppe von SR-IOV-VFs (Virtual Functions) auf einer mit Distributed Cloud verbundenen physischen Maschine zuweisen und diese Gruppe als Kubernetes-Ressource instanziieren. Anschließend können Sie diese Ressource in einer NetworkAttachmentDefinition-Ressource verwenden. Diese Ressource ist nicht für die Bereitstellung von Distributed Cloud Connected-Servern verfügbar.

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 verbundenen 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 Knotenlabel edgecontainer.googleapis.com/network-sriov.capable, das auf allen mit Distributed Cloud verbundenen 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 mit Distributed Cloud verbundenen 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. Diese Ressource ist nicht für Bereitstellungen von verbundenen Servern in Distributed Cloud verfügbar.

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 mit Distributed Cloud verbundenen Knoten anhängen. Es nutzt das Multus-CNI-Framework und die folgenden Plug-ins:

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.

Verwenden Sie die Annotation networking.gke.io/gdce-vlan-id, um die VLAN-ID für das Zielnetzwerk anzugeben. Diese Anmerkung ist obligatorisch.

Die folgenden Beispiele veranschaulichen die Struktur der Ressource. Für IPv4-Netzwerke.

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
    networking.gke.io/gdce-vlan-id: 225

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"
  }
}'

Für IPv6-Netzwerke:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-210-den102
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p0_sriov_en
    networking.gke.io/gdce-vlan-id: 225
spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-210-den102",
  "vlan": 210,
  
  "ipam": {
    "type": "host-local",
    "rangeStart": "2001:4860:1025:102:ffff:0220::2",
    "rangeEnd": "2001:4860:1025:102:ffff:0220::F",
    "subnet": "2001:4860:1025:102:ffff:0220::/96",
    "routes": [{
      "dst": "::/0"
    }],
    "gateway": "2001:4860:1025:102:ffff:0220::1"
  }
}'

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 Pod-Definition für Distributed Cloud 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 Connected 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 in den folgenden Beispielen gezeigt. Für IPv4-Netzwerke:

     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"
       }
     ]
   ...
   }
 }'

    Für IPv6-Netzwerke:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-bond0-210-den402
   annotations:
       networking.gke.io/gdce-vlan-id
 spec:
   config: '{
   "type": "macvlan",
   "cniVersion": "0.3.1",
   "name": "bond0-210",
   "master": "bond0.210",

   "ipam": {
     "type": "host-local",
     "rangeStart": "2001:4860:1025:102:0001:0210::2",
     "rangeEnd": "2001:4860:1025:102:0001:0210::F",
     "subnet": "2001:4860:1025:102:0001:0210::/96",
     "routes": [{
       "dst": "::/0"
     }],
     "gateway": "2001:4860:1025:102:0001:0210::1"
   }
 }'

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

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

    Für IPv6-Netzwerke:

     apiVersion: v1
 kind: Pod
 metadata:
   name: vlan210-1
   namespace: default
   annotations:
     k8s.v1.cni.cncf.io/networks: default/macvlan-bond0-210-den402

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

Distributed Cloud Connected 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: my-network-410
  annotations:
      networking.gke.io/gdce-vlan-id: "410"
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"myPool","addresses":["10.100.63.130-10.100.63.135"],"avoidBuggyIPs":false,"autoAssign":true}]'
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.410
  gateway4: 10.100.63.129
  l2NetworkConfig:
    prefixLength4: 27

    Die Annotation networking.gke.io/gdce-lb-service-vip-cidrs gibt einen oder mehrere IP-Adresspools für dieses virtuelle Netzwerk an. Die erste Hälfte des hier angegebenen CIDR muss virtuelle Dienst-IP-Adressen (Service Virtual IP, SVIP) enthalten. Distributed Cloud Connected erzwingt diese Anforderung durch Webhook-Prüfungen:

    • Der SVIP-Adressbereich muss sich im entsprechenden VLAN-CIDR-Bereich befinden.
    • Der SVIP-Adressbereich kann nur bis zur ersten Hälfte des VLAN-CIDR-Bereichs reichen.

  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":"eth0","network":"pod-network"}, {"interfaceName":"eth1","network":"my-network-410"}]'
    networking.gke.io/default-interface: eth1

    Mit dieser Annotation wird die eth0-Schnittstelle als primäre und die eth1-Schnittstelle als sekundäre Schnittstelle mit Layer 2-Load-Balancing mit MetalLB konfiguriert.

Wenn Sie Ihre sekundäre Schnittstelle wie in diesem Abschnitt beschrieben konfigurieren, werden die folgenden benutzerdefinierten Ressourcen automatisch erstellt:

  • Eine IPAddressPool-Ressource, die die automatische Zuweisung von SVIP-Adressen zu Pods ermöglicht. Beispiel:
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: test-410-pool
  namespace: kube-system
  annotations:
    networking.gke.io/network:my-network-410
    …
  spec:
  addresses:
  - 10.100.63.130-10.100.63.135
  autoAssign: true
  • Eine L2Advertisement-Ressource, die die Werbung für die angegebenen SVIP-Adressen ermöglicht. Beispiel:
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertise-410
  namespace: kube-system
spec:
  ipAddressPools:
  - test-410-pool
  interfaces:
  - gdcenet0.410

## Weitere Informationen