Using pod-level bonding

Bond Container Network Interface (CNI) is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Bonding at the pod level is vital to enable workloads inside pods that require high availability and more throughput. With pod-level bonding, you can create a bond interface from multiple single root I/O virtualization (SR-IOV) virtual function interfaces in a kernel mode interface. The SR-IOV virtual functions are passed into the pod and attached to a kernel driver.

One scenario where pod level bonding is required is creating a bond interface from multiple SR-IOV virtual functions on different physical functions. Creating a bond interface from two different physical functions on the host can be used to achieve high availability and throughput at pod level.

The current functionality of Bond CNI is available only in active-backup mode - for further details, see BZ#2037214.

For guidance on tasks such as creating a SR-IOV network, network policies, network attachment definitions and pods, see Configuring an SR-IOV network device.

Configuring a bond interface from two SR-IOV interfaces

Bonding enables multiple network interfaces to be aggregated into a single logical “bonded” interface. Bond-CNI brings bond capability into containers.

Bond-CNI can be created using SR-IOV virtual functions and placing them in the container network namespace.

OKD only supports Bond-CNI using SR-IOV virtual functions. Physical interfaces are not supported.

Prerequisites

  • The SR-IOV operator must be installed and configured to obtain virtual functions in a container.

  • To configure SR-IOV interfaces, an SR-IOV network and policy must be created for each interface.

  • The SR-IOV operator creates a network attachment definition for each SR-IOV interface, based on the SR-IOV network and policy defined.

Creating a bond network attachment definition

Now that the SR-IOV virtual functions are available, you can create a bond network attachment definition.

  1. apiVersion: "k8s.cni.cncf.io/v1"
  2.     kind: NetworkAttachmentDefinition
  3.     metadata:
  4.       name: bond-net1
  5.       namespace: demo
  6.     spec:
  7.       config: '{
  8.       "type": "bond", (1)
  9.       "cniVersion": "0.3.1",
  10.       "name": "bond-net1",
  11.       "ifname: "bond0" (2)
  12.       "mode": "active-backup",
  13.       "failOverMac": 1, (3)
  14.       "linksInContainer": true, (4)
  15.       "miimon": "100",
  16.       "mtu": 1500,
  17.       "links": [ (5)
  18.             {"name": "net1"},
  19.             {"name": "net2"}
  20.         ],
  21.       "ipam": {
  22.             "type": "host-local"
  23.             "subnet": "10.56.217.0/24"
  24.             "routes": [{
  25.             "dst": "0.0.0.0/0"
  26.             }],
  27.             "gateway": "10.56.217.1"
  28.         }
  29.       }'
1The type is bond.
2The ifname attribute specifies the name of the bond interface.
3The failover attribute is mandatory for active-backup mode.
4The linksInContainer=true flag tells the Bond CNI that the interfaces required are to be found inside the container. By default Bond CNI looks for these interfaces on the host which does not work for integration with SRIOV/Multus.
5The links section defines which interfaces will be used to create the bond. By default, Multus names the attached interfaces as: “net”, plus a consecutive number, starting with one.

Creating a pod using a bond interface

You can now test the setup by creating a pod using a bond interface.

  1. apiVersion: v1
  2.     kind: Pod
  3.     metadata:
  4.       name: bondpod1
  5.       namespace: demo
  6.       annotations:
  7.         k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 (1)
  8.     spec:
  9.       containers:
  10.       - name: podexample
  11.         image: quay.io/openshift/origin-network-interface-bond-cni:4.10.0
  12.         command: ["/bin/bash", "-c", "sleep INF"]
1Note the network annotation: it contains two SR-IOV network attachments, and one bond network attachment. The bond attachment uses the two SR-IOV interfaces as bonded port interfaces.

You can inspect the pod interfaces with the following command:

  1. $ oc rsh -n demo bondpod1
  2. sh-4.4#
  3. sh-4.4# ip a
  4. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
  5. link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  6. inet 127.0.0.1/8 scope host lo
  7. valid_lft forever preferred_lft forever
  8. 3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
  9. link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
  10. inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
  11. valid_lft forever preferred_lft forever
  12. 4: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
  13. link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff
  14. inet 10.56.217.66/24 scope global bond0
  15. valid_lft forever preferred_lft forever
  16. 43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
  17. link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff (1)
  18. 44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
  19. link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff (2)
1The net1 interface is based on an SR-IOV virtual function.
2The net2 interface is based on an SR-IOV virtual function.