Create Network Attachment Definitions

Network attachment definition specifications must be created in order to reference / request an SR-IOV interface in a container specification.

About this task

The sample network attachments shown in this procedure can be used in a container as shown in Using Network Attachment Definitions in a Container.

Prerequisites

You must have configured at least one SR-IOV interface on a host with the target datanetwork (datanet-a or datanet-b in the example below) assigned to it before creating a NetworkAttachmentDefinition referencing this data network.

Note

The configuration for this SR-IOV interface with either a netdevice or vfio vf-driver determines whether the NetworkAttachmentDefinition will be a kernel network device or a userspace network device.

Only netdevice is supported for Mellanox NICs.

Procedure

  1. Create a simple SR-IOV network attachment definition file called net1.yaml associated with the data network datanet-a.

    ~(keystone_admin)]$ cat <<EOF > net1.yaml
    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: net1
      annotations:
        k8s.v1.cni.cncf.io/resourceName: intel.com/pci_sriov_net_datanet_a
    spec:
      config: '{
          "cniVersion": "0.3.0",
          "type": "sriov"
        }'
    EOF
    

    This NetworkAttachmentDefinition is valid for both a kernel-based and a DPDK (vfio) based device.

  2. Create an SR-IOV network attachment.

    • The following example creates an SR-IOV network attachment definition configured for a VLAN with an ID of 2000.

      ~(keystone_admin)]$ cat <<EOF > net2.yaml
      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: net2
        annotations:
          k8s.v1.cni.cncf.io/resourceName: intel.com/pci_sriov_net_datanet_b
      spec:
        config: '{
            "cniVersion": "0.3.0",
            "type": "sriov",
            "vlan": 2000
          }'
      EOF
      
    • The following example creates an SR-IOV network attachment definition configured with IP Address information.

      ~(keystone_admin)]$ cat <<EOF > net3.yaml
      apiVersion: crd.projectcalico.org/v1
      kind: IPPool
      metadata:
        name: mypool
      spec:
        cidr: "10.56.219.0/24"
        ipipMode: "Never"
        natOutgoing: True
      ---
      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: net3
        annotations:
          k8s.v1.cni.cncf.io/resourceName: intel.com/pci_sriov_net_datanet_b
      spec:
        config: '{
            "cniVersion": "0.3.0",
            "type": "sriov",
            "ipam": {
              "type": "calico-ipam",
              "assign_ipv4": "true",
              "ipv4_pools": ["mypool"]
            },
            "kubernetes": {
              "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
            },
            "datastore_type": "kubernetes"
          }'
      EOF
      
    • The following example creates an SR-IOV network attachment definition configured with a static IP address and MTU of 1950.

      ~(keystone_admin)]$ cat <<EOF > net4.yaml
      apiVersion: k8s.cni.cncf.io/v1
      kind: NetworkAttachmentDefinition
      metadata:
        name: net4
        annotations:
          k8s.v1.cni.cncf.io/resourceName: intel.com/pci_sriov_net_datanet_b
      spec:
        config: '{
             "cniVersion": "0.3.0",
             "plugins":
             [
                {
                  "type": "sriov",
                  "ipam": {
                    "type": "static",
                    "addresses": [
                      {
                        "address": "192.168.1.2/16"
                      }
                    ]
                  }
                },
                {
                 "type": "tuning",
                 "mtu": 1950
                }
            ]
        }'
      EOF
      

Results

After SR-IOV interfaces have been provisioned and the hosts labeled and unlocked, available SR-IOV VF resources are automatically advertised.

They can be referenced in subsequent StarlingX operations using the appropriate NetworkAttachmentDefinition name and the following extended resource name:

intel.com/pci_sriov_net_${DATANETWORK_NAME}

For example, with a network called datanet-a the extended resource name would be:

intel.com/pci_sriov_net_datanet_a
  • The extended resource name will convert all dashes (‘-’) in the data network name into underscores (’_’).

  • SR-IOV enabled interfaces using the netdevice VF driver must be administratively and operationally up to be advertised by the SR-IOV device plugin.

  • If multiple data networks are assigned to an interface, the VFs resources will be shared between pools.