Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/k8snetworkplumbingwg/bond-cni

Bond-cni is for fail-over and high availability of networking in cloudnative orchestration
https://github.com/k8snetworkplumbingwg/bond-cni

active-backup alb bonding-cni cni failover fault-tolerance high-availability interface-bonding link-aggregator load-balancing networking tlb

Last synced: 21 days ago
JSON representation

Bond-cni is for fail-over and high availability of networking in cloudnative orchestration

Host: GitHub
URL: https://github.com/k8snetworkplumbingwg/bond-cni
Owner: k8snetworkplumbingwg
License: apache-2.0
Created: 2017-12-15T12:11:35.000Z (almost 7 years ago)
Default Branch: master
Last Pushed: 2024-08-01T10:24:41.000Z (4 months ago)
Last Synced: 2024-08-04T17:05:41.097Z (4 months ago)
Topics: active-backup, alb, bonding-cni, cni, failover, fault-tolerance, high-availability, interface-bonding, link-aggregator, load-balancing, networking, tlb
Language: Go
Homepage: https://networkbuilders.intel.com/network-technologies/container-experience-kits
Size: 5.86 MB
Stars: 61
Watchers: 10
Forks: 26
Open Issues: 3
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE

Awesome Lists containing this project

awesome-cloud-native - bond-cni - ail-over and high availability of networking in cloudnative orchestration. (NetWork)

README

# Bond CNI plugin

[![Coverage Status](https://coveralls.io/repos/github/k8snetworkplumbingwg/bond-cni/badge.svg?branch=master)](https://coveralls.io/github/k8snetworkplumbingwg/bond-cni?branch=master)

- Bonding provides a method for aggregating multiple network interfaces into a single logical "bonded" interface.
- According to the 802.3ad specification, Linux Bonding drivers provides various flavours of bonded interfaces depending on the mode (bonding policies), such as round robin, active aggregation
- When Bond CNI is configured as a standalone plugin, interfaces are obtained from the host network namespace. With these physical interfaces a bonded interface is created in the container network namespace.
- When used with [Multus](https://github.com/intel/multus-cni) users can bond two interfaces that have previously been passed into the container.
- A major use case for bonding in containers is network redundancy of an application in the case of network device or path failure and unavailability. For more information - refer to [network redundancy using interface bonding](https://www.howtoforge.com/tutorial/how-to-configure-high-availability-and-network-bonding-on-linux/)
- And for more information on the bonding driver please refer to [kernel doc](https://www.kernel.org/doc/Documentation/networking/bonding.txt)

## Build

It is recommended that Bond CNI be built with Go 1.12+ with dependencies managed using Go modules.

- Build the source code to binary:

```
make build-bin
```

- Copy the binary to the CNI folder for the testing:

```
cp ./bin/bond /opt/cni/bin/
```

The binary should be placed at /opt/cni/bin on all nodes on which bonding will take place. That is all nodes to which a container with a bonded interface can be deployed.

## Network configuration reference

- name (string, required): the name of the network
- type (string, required): "bond"
- miimon (int, required): specifies the arp link monitoring frequency in milliseconds
- mtu (int, optional): the mtu of the bond. Default is 1500.
- failOverMac (int, optional): specifies the failOverMac setting for the bond. Should be set to 1 for active-backup bond modes. Default is 0.
- linksInContainer(boolean, optional): specifies if slave links are in container to start. Default is false i.e. look for interfaces on host before bonding.
- links (dictionary, required): master interface names
- ipam (dictionary, required): IPAM configuration to be used for this network

## Usage

### Standalone operation

Given the following network configuration:
```json
# cat > /etc/cni/net.d/00-flannel-bonding.conf <"]

}
},
{
"resourceName": "intel_sriov_PF_2",
"selectors": {
"vendors": ["8086"],
"devices": ["154c", "10ed"],
"drivers": ["i40evf", "ixgbevf"],
"pfNames": [""]
}
}
]
}

```
In the above specific PF names will have to be entered - based on available PFs in the cluster - in order to make the selectors pick up the correct VFs. The other selectors in the above configuration are identical.
Note that SRIOV device plugin only picks up new configuration at startup - so if the daemonset was previously running the pods will have to be killed and redeployed before this is advertised again.

## Steps for deployment
1) Deploy Network Attach Definiton for SRIOV

```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
k8s.v1.cni.cncf.io/resourceName: intel.com/intel_sriov_PF_1
spec:
config: '{
"type": "sriov",
"name": "sriov-network",
"spoofchk":"off"
}'
```

We will create a separate - but equivalent except for naming - SRIOV network attach definition. This allows us to keep our definitions seperate for our two Physical Function pools as definited above.
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net2
annotations:
k8s.v1.cni.cncf.io/resourceName: intel.com/intel_sriov_PF_2
spec:
config: '{
"type": "sriov",
"name": "sriov-network",
"spoofchk":"off"
}'
```
2) Deploy Network Attach Definition for Bond CNI:
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: bond-net1
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": {
"type": "host-local",
"subnet": "10.56.217.0/24",
"routes": [{
"dst": "0.0.0.0/0"
}],
"gateway": "10.56.217.1"
}
}'
```
Note above the `"linksInContainer": true` flag. This tells the Bond CNI that the interfaces we're looking for are to be found inside the container. By default it will look for these interfaces on the host which does not work for integration with SRIOV/Multus.

3) Deploy a pod which requests two SRIOV networks, one from each PF, and one bonded network.

```
apiVersion: v1
kind: Pod
metadata:
name: test-pod
annotations:
k8s.v1.cni.cncf.io/networks: '[
{"name": "sriov-net1",
"interface": "net1"
},
{"name": "sriov-net2",
"interface": "net2"
},
{"name": "bond-net",
"interface": "bond0"
}]'
spec:
restartPolicy: Never
containers:
- name: bond-test
image: alpine:latest
command:
- /bin/sh
- "-c"
- "sleep 60m"
imagePullPolicy: IfNotPresent
resources:
requests:
intel.com/intel_sriov_PF_1: '1'
intel.com/intel_sriov_PF_2: '1'
limits:
intel.com/intel_sriov_PF_1: '1'
intel.com/intel_sriov_PF_2: '1'
```

The order in the request annotation `k8s.v1.cni.cncf.io/networks: sriov-net1, sriov-net2, bond-net1` is important as it is the same order in which networks will be added. In the above spec we add one SRIOV network, then we add another identically configured SRIOV network from our second SRIOV VF pool. Multus will give these networks the names net1 and net2 respectively.

Next the bond-net1 network is created - using interfaces net1 and net2. If bond is created before the SRIOV networks the CNI will not be able to find the interfaces in the container.

The name of each interface can be set manually in the annotation according to the [CRD Spec](https://docs.google.com/document/d/1TW3P4c8auWwYy-w_5afIPDcGNLK3LZf0m14943eVfVg/edithttps://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_RNydhVE1Kx54kFQ/edit#heading=h.hylsbqoj5fxd). Changing the names applied in the annotation configuration requires matching changes to be made in the bond network attachment definition.

After deploying the above pod spec on Kubernetes running the following command:

```kubectl exec -it test-pod -- ip a```

Will result in output like:

```
1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth0@if150: mtu 1450 qdisc noqueue state UP
link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: bond0: mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff
inet 10.56.217.66/24 scope global bond0
valid_lft forever preferred_lft forever
43: net1: mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff
44: net2: mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff
```

We have three new interfaces added to our pod - net1 and net2 are SRIOV interfaces while bond0 is the bond over the two of them. Net1 and Net2 don't require IP addresses - and this can be changed in their CRD.