Configuring SriovNetwork in application namespaces

An introduction to namespaced SriovNetwork resources
- Configuring SriovNetwork in application namespaces

Namespaced SriovNetwork Resources allow application owners to create and manage their own SriovNetwork resources directly within their namespaces, rather than relying on a cluster administrator to do it in a shared operator namespace. This method simplifies permissions, improves security, and provides better separation between applications.

An introduction to namespaced SriovNetwork resources

SR-IOV networks can be created and managed directly within application namespaces. This capability provides application owners with fine-grained control over network configurations, simplifying their workflow.

This approach offers several key advantages that enhance the user experience:

Increased Autonomy and Control: Application owners gain direct control over their network configurations, eliminating the need for a cluster administrator to create SriovNetwork objects on their behalf.
Enhanced Security: By allowing users to manage resources within their own namespaces, the feature improves security and provides better separation between applications. This also helps avoid the unintentional misconfiguration of other applications' NetworkAttachmentDefinition objects.
Simplified Permissions: Managing SriovNetwork resources directly in their own namespaces simplifies user permissions. This streamlines the workflow and reduces the operational overhead for developers.

When an SriovNetwork custom resource (CR) is deployed in an application namespace, do not define or populate the spec.networkNamespace field. In this scenario, the NetworkAttachmentDefinition will be created in the same namespace as the SriovNetwork CR.

The SR-IOV Network Operator webhook rejects the creation of an SriovNetwork resource in an application namespace if the spec.networkNamespace field is defined.

Follow this procedure to create an SriovNetwork resource in an application namespace and attach a pod to the additional network.

Prerequisites

The following steps must be completed by a cluster administrator before an application owner can configure a namespaced SriovNetwork resource:

The SR-IOV Network Operator is installed in the openshift-sriov-network-operator namespace.
Nodes with SR-IOV hardware are labeled for the operator to identify the nodes.

As an application owner you need to have administrator privileges on the application namespace.

Procedure

Specify the SR-IOV network device configuration for a node by creating an SR-IOV network node policy. The SriovNetworkNodePolicy object is created in the openshift-sriov-network-operator namespace to define the SR-IOV network device configuration for nodes. Example configuration for Intel DPK is as follows:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: 10
  numVfs: 4
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: [""]
  deviceType: netdevice

Create an application namespace. For example, create a namespace named sriov-app by running the following command:
```
$ cat <<EOF | oc create -f -
apiVersion: v1
kind: Namespace
metadata:
    name: sriov-app
EOF
```
Create a YAML file, for example, sriovnetwork.yaml, to define the SriovNetwork object in the application namespace.
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: test-network
  namespace: sriov-app
spec:
  resourceName: intelnics
  ipam:
    type: host-local
    subnet: "10.0.0.0/24"
    routes:
      - dst: "0.0.0.0/0"
        gw: "10.0.0.1"
  vlan: 10
```
- namespace: The value must match the name of the application namespace, for example, sriov-app.
- resourceName: This value must match the spec.resourceName defined in the SriovNetworkNodePolicy created by the cluster administrator, which in the example is intelnics.
Apply the YAML file to create the SriovNetwork object in the application namespace.
```
$ oc create -f sriovnetwork.yaml
```
After an application owner has created the SriovNetwork resource, they can create a pod that uses the newly defined network. You attach a pod to the additional network by adding a specific annotation to the pod’s YAML manifest.
Create a YAML file, for example, test-pod.yaml, to define a pod that uses the new network attachment:
```
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: sriov-app
  annotations:
    k8s.v1.cni.cncf.io/networks: test-network
spec:
  containers:
  - name: test-pod-container
    image: centos/tools
    command: ["/bin/bash", "-c", "sleep 3600"]
```
- namespace: The namespace where the pod is created. This must be the same namespace where the SriovNetwork object is created.
- annotations: k8s.v1.cni.cncf.io/networks specifies the additional network that the pod connects to. The value must match the metadata.name of the SriovNetwork object.
Apply the YAML file to create the pod in the application namespace by running the following command:
```
$ oc create -f test-pod.yaml
```

Verification

Verify that the NetworkAttachmentDefinition has been created in the same namespace by running the following command:
```
$ oc get net-attach-def -n sriov-app
```
Where sriov-app is the application namespace where the SriovNetwork object is created.
Example output
```
NAME           AGE
test-network   2m
```
Verify the pod is running and get its network status by describing the pod with the following command:
```
$ oc describe pod test-pod -n sriov-app
```
Where sriov-app is the application namespace where the pod is created.

In the output, look for the k8s.v1.cni.cncf.io/network-status annotation. This shows the name of the network and the IP assigned to the pod on that interface.
Check that the pod has the additional network interface by running the following command:
```
$ oc exec -it test-pod -n sriov-app -- ip a
```
Look for a secondary network interface, for example net1 or eth1, in addition to the default eth0 interface. The net1 interface should have an IP address from the subnet you defined in the SriovNetwork object, for example 10.0.0.0/24. This confirms the pod is using the new network attachment definition.

Configuring namespaced SR-IOV resources

An introduction to namespaced SriovNetwork resources

Configuring SriovNetwork in application namespaces