Skip to content

Commit 1f17543

Browse files
tmulqueetmulquee
committed
TELCODOCS-365: new content on pod level bonding with link fix
1 parent ca3d121 commit 1f17543

File tree

3 files changed

+135
-0
lines changed

3 files changed

+135
-0
lines changed

‎_topic_maps/_topic_map.yml‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -981,6 +981,8 @@ Topics:
981981
File: using-sriov-multicast
982982
- Name: Using DPDK and RDMA
983983
File: using-dpdk-and-rdma
984+
- Name: Using pod-level bonding for secondary networks
985+
File: using-pod-level-bonding
984986
- Name: OpenShift SDN default CNI network provider
985987
Dir: openshift_sdn
986988
Topics:

‎modules/nw-sriov-cfg-bond-interface-with-virtual-functions.adoc‎

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/hardware_networks/configuring-sriov-operator.adoc
4+
:_content-type: PROCEDURE
5+
[id="nw-sriov-cfg-bond-interface-with-virtual-functions_{context}"]
6+
= Configuring a bond interface from two SR-IOV interfaces
7+
8+
Bonding enables multiple network interfaces to be aggregated into a single logical "bonded" interface. Bond-CNI brings bond capability into containers.
9+
10+
Bond-CNI can be created using SR-IOV virtual functions and placing them in the container network namespace.
11+
12+
{product-title} only supports Bond-CNI using SR-IOV virtual functions. Physical interfaces are not supported.
13+
14+
.Prerequisites
15+
16+
* The SR-IOV operator must be installed and configured to obtain virtual functions in a container.
17+
* To configure SR-IOV interfaces, an SR-IOV network and policy must be created for each interface.
18+
* The SR-IOV operator creates a network attachment definition for each SR-IOV interface, based on the SR-IOV network and policy defined.
19+
20+
[id="nw-sriov-cfg-creating-bond-network-attachment-definition_{context}"]
21+
== Creating a bond network attachment definition
22+
23+
Now that the SR-IOV virtual functions are available, you can create a bond network attachment definition.
24+
25+
[source,yaml]
26+
----
27+
apiVersion: "k8s.cni.cncf.io/v1"
28+
kind: NetworkAttachmentDefinition
29+
metadata:
30+
name: bond-net1
31+
namespace: demo
32+
spec:
33+
config: '{
34+
"type": "bond", <1>
35+
"cniVersion": "0.3.1",
36+
"name": "bond-net1",
37+
"ifname: "bond0" <2>
38+
"mode": "active-backup",
39+
"failOverMac": 1, <3>
40+
"linksInContainer": true, <4>
41+
"miimon": "100",
42+
"mtu": 1500,
43+
"links": [ <5>
44+
{"name": "net1"},
45+
{"name": "net2"}
46+
],
47+
"ipam": {
48+
"type": "host-local"
49+
"subnet": "10.56.217.0/24"
50+
"routes": [{
51+
"dst": "0.0.0.0/0"
52+
}],
53+
"gateway": "10.56.217.1"
54+
}
55+
}'
56+
----
57+
<1> The type is `bond`.
58+
<2> The `ifname` attribute specifies the name of the bond interface.
59+
<3> The `failover` attribute is mandatory for active-backup mode.
60+
<4> The `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.
61+
<5> The `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.
62+
63+
[id="nw-sriov-cfg-creating-pod-using-interface_{context}"]
64+
== Creating a pod using a bond interface
65+
66+
You can now test the setup by creating a pod using a bond interface.
67+
68+
[source,yaml]
69+
----
70+
apiVersion: v1
71+
kind: Pod
72+
metadata:
73+
name: bondpod1
74+
namespace: demo
75+
annotations:
76+
k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 <1>
77+
spec:
78+
containers:
79+
- name: podexample
80+
image: quay.io/openshift/origin-network-interface-bond-cni:4.9.0
81+
command: ["/bin/bash", "-c", "sleep INF"]
82+
----
83+
<1> Note 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 bond slaves.
84+
85+
You can inspect the pod interfaces with the following command:
86+
[source,yaml]
87+
----
88+
$ oc rsh -n demo bondpod1
89+
sh-4.4#
90+
sh-4.4# ip a
91+
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
92+
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
93+
inet 127.0.0.1/8 scope host lo
94+
valid_lft forever preferred_lft forever
95+
3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
96+
link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
97+
inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
98+
valid_lft forever preferred_lft forever
99+
4: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
100+
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff
101+
inet 10.56.217.66/24 scope global bond0
102+
valid_lft forever preferred_lft forever
103+
43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
104+
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff <1>
105+
44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
106+
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff <2>
107+
----
108+
<1> The `net1` interface is based on an SR-IOV virtual function.
109+
<2> The `net2` interface is based on an SR-IOV virtual function.

‎networking/hardware_networks/using-pod-level-bonding.adoc‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
:_content-type: ASSEMBLY
2+
[id="using-pod-level-bonding"]
3+
= Using pod-level bonding
4+
include::modules/common-attributes.adoc[]
5+
:context: using-pod-level-bonding
6+
7+
toc::[]
8+
9+
10+
:FeatureName: Bond Container Network Interface (CNI)
11+
include::snippets/technology-preview.adoc[leveloffset=+1]
12+
13+
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.
14+
15+
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.
16+
17+
[NOTE]
18+
====
19+
The current functionality of Bond CNI is available only in active-backup mode - for further details, see link:https://bugzilla.redhat.com/show_bug.cgi?id=2037214[*BZ#2037214*].
20+
====
21+
22+
For guidance on tasks such as creating a SR-IOV network, network policies, network attachment definitions and pods, see xref:../../networking/hardware_networks/configuring-sriov-device.adoc#configuring-sriov-device[Configuring an SR-IOV network device].
23+
24+
include::modules/nw-sriov-cfg-bond-interface-with-virtual-functions.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)