Bonds in OpenShift Pods
Networks can have more bandwidth and availability thanks to Linux bonding. Aggregating many network interfaces into a single logical interface does this. Interface bonding is introduced to OpenShift by the bond-CNI for use inside pods. Pod bonding is mostly used to supplement SRIOV virtual features in Openshift Pods.
Installing bond-cni:
Bond-CNI is a supported feature beginning with OpenShift 4.12 and is currently available as a tech preview in OpenShift 4.10. To use it, no additional steps are needed.
Configuring a bond network
A NetworkAttachmentDefinition resource is used to define a bond interface.
Below is a sample arrangement.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: bond-network
namespace: bond-namespace
spec:
config: '{
"type": "bond",
"cniVersion": "0.3.1",
"name": "bond-net1",
"mode": "active-backup",
"failOverMac": 1,
"linksInContainer": true,
"miimon": "100",
"mtu": 1500,
"links": [
{"name": "net1"}, {"name": "net2"}
],
"ipam": {}
}'
The specific attributes of the configuration section are described below:
type – cni type, must always be ‘bond’
mode – the bonding mode, the following values are supported: “balance-rr”, “active-backup” ,”balance-xor”
failOverMac – only valid for the “active-backup” mode, must be set to 1
linksInContainer – denotes the bond cni’s use of interfaces inside the pod network namespace. “True” is the sole supported value.
miimon – defines the millisecond-based MII link monitoring frequency.
mtu – the bond interface’s mtu
Links – a list of recommended network interfaces. Before the bond interface is built, these interfaces need to be present in the pod.
Multiple current interfaces are combined through bonding into a single logical bonded interface. Create the interfaces that will be aggregated. These interfaces will then be used to form the bond interface.
Configuring a pod with a bond interface
A bond interface is set up using the k8s.v1.cni.cncf.io/networks annotation just like any other secondary interface. Below is an illustration of a pod definition with a bond network interface:
apiVersion: v1 kind: Pod metadata: name: example-pod namespace: default annotations: k8s.v1.cni.cncf.io/networks: sriov/sriov-network, sriov/sriov-network, bond-namespace/bond-network, spec: …
It should be noted that a list of network attachment definitions is contained in the “k8s.v1.cni.cncf.io/networks” annotation. The “bond-namespace/bond-network” part specifies the bond interface.
Multiple current interfaces are combined through bonding into a single logical bonded interface. The interfaces that will be aggregated must be built before the bond interface. These interfaces will then be used to form the bond interface. The aggregated interfaces must be defined in the list of “links” attributes before the creation of the bond network attachment in order to guarantee that they are formed before the bond interface. Note that there are two elements defined before the bond in the example above’s list:
annotations: k8s.v1.cni.cncf.io/networks: sriov/sriov-network, sriov/sriov-network, bond-namespace/bond-network
The “sriov/sriov-network” secondary network has two components. In the order specified in the annotation, OpenShift will create each interface one at a time. As a result, before the bond interface is processed, 2 interfaces defined by the “sriov-network” network attachment definition will be formed.
The interface names in a pod are automatically assigned as “netn>” if nothing else has been set, with n starting at 1. The interfaces in the aforementioned pod example would have the names “net1” and “net2,” with “net3” designating the bond interface. This is represented in the “links” element of the bond network attachment declaration, which names the “net1” and “net2” interfaces:
"links": [{"name": "net1"}, {"name": "net2"}]
The “@name” suffix can be added to the “k8s.v1.cni.cncf.io/networks” annotation of the pod to force the interfaces to use a certain name:
annotations: k8s.v1.cni.cncf.io/networks: sriov/sriov-network@ifc1, sriov/sriov-network@ifc2, bond-namespace/bond-network@bond
The “links” list has to be changed to read:
"links": [{"name": "ifc1"}, {"name": "ifc2"}]
and the name “bond” given to the bond.
Configuring SRIOV Interfaces
The “trust” attribute for SRIOV virtual functions must be set to “on” in the SriovNetwork when they are utilized in bonds in the “balance-rr” or “balance-xor” modes.
