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
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.
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.