A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/distributed-cloud/edge/latest/docs/network-function below:

Network Function operator | Distributed Cloud connected

This page describes the specialized Network Function Kubernetes operator that Google Distributed Cloud connected ships with. This operator implements a set of CustomResourceDefinitions (CRDs) that allow Distributed Cloud connected to execute high-performance workloads.

The Network Function operator lets you do the following:

Distributed Cloud connected support for SR-IOV is based on the following open source projects:

Network Function operator profiles

Distributed Cloud connected provides the following Network Function operator functionality profiles on each Distributed Cloud connected form factor:

Prerequisites

The Network Function operator fetches network configuration from the Distributed Cloud Edge Network API. To allow this, you must grant the Network Function operator service account the Edge Network Viewer role (roles/edgenetwork.viewer) using the following command:

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]"

Replace the following:

Network Function operator resources

The Distributed Cloud connected Network Function operator implements the following Kubernetes CRDs:

The Network Function operator also lets you define secondary network interfaces that do not use SR-IOV virtual functions.

Network resource

The Network resource defines a virtual network within the Distributed Cloud connected rack that pods within your Distributed Cloud connected cluster can use to communicate with internal and external resources.

The Network resource provides the following configurable parameters for the network interface exposed as writable fields:

The following example illustrates the structure of the resource:

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

To specify multiple virtual IP address ranges for the load balancing service, use the networking.gke.io/gdce-lb-service-vip-cidrs annotation. You can provide the values for this annotation as either a comma-separated list or as a JSON payload. For example:

[
  {
    "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
  }
]

If you choose to use a JSON payload, we recommend that you use the condensed JSON format. For example:

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

Keep in mind that the autoAssign field defaults to false if omitted.

NetworkInterfaceState resource

The NetworkInterfaceState resource is a read-only resource that lets you discover physical network interfaces on the node and collect runtime statistics on the network traffic flowing through those interfaces. Distributed Cloud creates a NetworkInterfaceState resource for each node in a cluster.

The default configuration of Distributed Cloud connected machines includes a bonded network interface on the Rack Select Network Daughter Card (rNDC) named gdcenet0. This interface bonds the eno1np0 and eno2np1 network interfaces. Each of those is connected to one Distributed Cloud ToR switch, respectively.

The NetworkInterfaceState resource provides the following categories of network interface information exposed as read-only status fields.

General information:

IP address configuration information:

Hardware information:

Reception statistics:

Transmission statistics:

The following example illustrates the structure of the resource:

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 resource

The NodeSystemConfigUpdate resource lets you make changes to the node's operating system configuration as well as modify Kubelet flags. Changes other than sysctl changes require a node reboot. This resource is not available on Distributed Cloud connected servers deployments.

When instantiating this resource, you must specify the target nodes in the nodeSelector field. You must include all key-value pairs for each target node in the nodeSelector field. When you specify more than one target node in this field, the target nodes are updated one node at a time.

CAUTION: The nodeName field has been deprecated. Using it immediately reboots the target nodes, including local control plane nodes, which can halt critical workloads.

The NodeSystemConfigUpdate resource provides the following configuration fields specific to Distributed Cloud connected:

The NodeSystemConfigUpdate resource provides the following read-only general status fields:

The following example illustrates the structure of the resource:

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 resource

The SriovNetworkNodePolicy resource lets you allocate a group of SR-IOV virtual functions (VFs) on a Distributed Cloud connected physical machine and instantiate that group as a Kubernetes resource. You can then use this resource in a NetworkAttachmentDefinition resource. This resource is not available on Distributed Cloud connected servers deployments

You can select each target VF by its PCIe vendor and device ID, its PCIe device addresses, or by its Linux enumerated device name. The SR-IOV Network Operator configures each physical network interface to provision the target VFs. This includes updating the network interface firmware, configuring the Linux kernel driver, and rebooting the Distributed Cloud connected machine, if necessary.

To discover the network interfaces available on your node, you can look up the NetworkInterfaceState resources on that node in the nf-operator namespace.

The following example illustrates the structure of the resource:

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

The preceding example creates a maximum of 31 VFs from the second port on the network interface named enp134s0f1np1 with an MTU value of 9000 (the maximum allowed value). Use the node selector label edgecontainer.googleapis.com/network-sriov.capable, which is present on all Distributed Cloud connected nodes capable of SR-IOV.

For information about using this resource, see SriovNetworkNodeState.

SriovNetworkNodeState resource

The SriovNetworkNodeState read-only resource lets you query the provisioning state of the SriovNetworkNodePolicy resource on a Distributed Cloud connected node. It returns the complete configuration of the SriovNetworkNodePolicy resource on the node as well as a list of active VFs on the node. The status.syncStatus field indicates whether all SriovNetworkNodePolicy resources defined for the node have been properly applied. This resource is not available on Distributed Cloud connected servers deployments

The following example illustrates the structure of the resource:

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

For information about using this resource, see SriovNetworkNodeState.

NetworkAttachmentDefinition resource

The NetworkAttachmentDefinition resource lets you attach Distributed Cloud pods to one or more logical or physical networks on your Distributed Cloud connected node. It leverages the Multus-CNI framework and the following plugins:

Use an annotation to reference the name of the appropriate SriovNetworkNodePolicy resource. When you create this annotation, do the following:

Use the networking.gke.io/gdce-vlan-id annotation to specify the VLAN ID for the target network. This annotation is mandatory.

The following examples illustrate the structure of the resource. For IPv4 networking.

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

For IPv6 networking:

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"
  }
}'
Configure a secondary interface on a pod using SR-IOV VFs

After you configure a SriovNetworkNodePolicy resource and a corresponding NetworkAttachmentDefinition resource, you can configure a secondary network interface on a Distributed Cloud pod by using SR-IOV virtual functions.

To do so, add an annotation to your Distributed Cloud pod definition as follows:

The following example illustrates this 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
Configure a secondary interface on a pod using the MacVLAN driver

Distributed Cloud connected also supports creating a secondary network interface on a pod by using the MacVLAN driver. Only the gdcenet0 interface supports this configuration and only on pods that run containerized workloads.

To configure an interface to use the MacVLAN driver:

  1. Configure a NetworkAttachmentDefinition resource as shown in the following examples. For IPv4 networking:

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

    For IPv6 networking:

     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. Add an annotation to your Distributed Cloud pod definition as follows. For IPv4 networking:

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

    For IPv6 networking:

     apiVersion: v1
 kind: Pod
 metadata:
   name: vlan210-1
   namespace: default
   annotations:
     k8s.v1.cni.cncf.io/networks: default/macvlan-bond0-210-den402
Configure a secondary interface on a pod using Distributed Cloud multi-networking

Distributed Cloud connected supports creating a secondary network interface on a pod by using its multi-network feature. To do so, complete the following steps:

  1. Configure a Network resource. For example:

    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

    The networking.gke.io/gdce-lb-service-vip-cidrs annotation specifies one or more IP address pools for this virtual network. The first half of the CIDR you specify here must include Service Virtual IP (SVIP) addresses. Distributed Cloud connected enforces this requirement through webhook checks as follows:

  2. Add an annotation to your Distributed Cloud pod definition as follows:

    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

    This annotation configures the eth0 interface as primary and the eth1 interface as secondary with Layer2 load balancing with MetalLB.

Configuring your secondary interface as described in this section results in the automatic creation of the following custom resources:

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

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertise-410
  namespace: kube-system
spec:
  ipAddressPools:
  - test-410-pool
  interfaces:
  - gdcenet0.410

## What's next

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4