K8S CNI

OCI概念

OCI，Open Container Initiative，开放容器标准，是一个轻量级，开放的治理结构（项目），在 Linux 基金会的支持下成立，致力于围绕容器格式和运行时创建开放的行业标准。

OCI 项目由 Docker，CoreOS（后来被 Red Hat 收购了，相应的席位被 Red Hat 继承）和容器行业中的其他领导者在 2015 年 6 月的时候启动。

runc: OCI默认实现,在资源效率和标准通用方面最强，但是在安全隔离方面却最弱
kata：更加强调安全
gvisor: gVisor 通过拦截所有从应用到主机内核的系统调用，并使用用户空间中 gVisor 的内核实现来处理这些调用
rkt: 弃用
crun：Redhat 领导的 OCI 实现，它是由 C 开发的，性能好且轻量级

Open Container Initiative - Open Container Initiative

Runtime spec: GitHub - opencontainers/runtime-spec: OCI Runtime Specification

Image spec: GitHub - opencontainers/image-spec: OCI Image Format

Distribution spec: GitHub - opencontainers/distribution-spec: OCI Distribution Specification

Tools implemented OCI

opencontainers/runc

kata-containers/runtime

google/gvisor

github.com/rkt/rkt

github.com/containers/crun

OCI运行时环境

runc: 容器的低级运行时，OCI的默认实现，

CONTAINER_ID=$(docker create busybox:latest)
docker export -o busybox.tar ${CONTAINER_ID}
mkdir rootfs
tar -xf busybox.tar -C rootfs
runc spec
sudo runc run test
# top

containerd: 容器的高级运行时，runc的封装，

显然 runc 是只是一个命令行工具，containerd_是一个长期居住守护进程。containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性，containerd 可以负责干下面这些事情：

• 管理容器的生命周期（从创建容器到销毁容器）

• 拉取 / 推送容器镜像

• 存储管理（管理镜像及容器数据的存储）

• 调用 runc 运行容器（与 runc 等容器运行时交互）

• 管理容器网络接口及网络

sudo ctr images list
sudo ctr images pull docker.io/library/busybox:latest
sudo ctr containers list
sudo ctr run -t --net-host docker.io/library/busybox:latest test
# ping 10.67.126.18
sudo ctr container delete test

Runc和OCI在整个K8S体系架构中的位置，

早期: kubelet --> docker-manager --> docker

中期: kubelet -CRI-> docker-shim --> docker --> containerd --> runc

中期: kubelet -CRI-> cri-containerd --> containerd --> runc

当前: kubelet -CRI-> containerd(CRI plugin) --> runc

当前: kubelet -CRI-> cri-o --> runc

CNI介绍

CNI (Container Network Interface), a Cloud Native Computing Foundation project, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins.

As well as the specification , the CNI repository contains the Go source code of a library for integrating CNI into applications and an example command-line tool for executing CNI plugins. A separate repository contains reference plugins and a template for making new plugins.

CNI Responsibilities

Pod IP address management

Pod-2-pod communication within a node

Pod-2-pod communication cross nodes

CNI SPEC

A configuration file (/etc/cni/net.d/)

CRI invokes CNI plugin binary file (/opt/cni/bin/)

Plugin do some operations and return an IP for container

创建一个Pod的流程

其中，在 “Invoke CNI plugin”阶段，会进入到下面的程序调用，

github.com/containerd/containerd
sandbox_run.go
func (c *criService) RunPodSandbox......if err := c.setupPodNetwork(ctx, &sandbox); err != nil { ->func (c *criService) setupPodNetwork......result, err = netPlugin.SetupSerially(ctx, id, path, opts...) ->cni.go
func (c *libcni) SetupSerially(ctx context.Context, id string......result, err := c.attachNetworksSerially(ctx, ns) ->func (c *libcni) attachNetworksSerially...r, err := network.Attach(ctx, ns) ->namespace.go
func (n *Network) Attach(ctx context.Context, ns *Namespace) (*types100.Result, error) {r, err := n.cni.AddNetworkList(ctx, n.config, ns.config(n.ifName)) ->api.go
func (c *CNIConfig) AddNetworkList…result, err = c.addNetwork(ctx, list.Name, list.CNIVersion, net, result, rt) ->func (c *CNIConfig) addNetwork(ctx context.Context, name, cniVersion return invoke.ExecPluginWithResult(ctx, pluginPath, newConf.Bytes, c.args("ADD", rt), c.exec) ->exec.go
func ExecPluginWithResult(ctx context.Context... ->...stdoutBytes, err := exec.ExecPlugin(ctx, pluginPath, netconf, args.AsEnv()) ->raw_exec.go
func (e *RawExec) ExecPlugin(ctx context.Context,...c := exec.CommandContext(ctx, pluginPath)

Sandbox

K8S在创建任何一个Pod的时候都会先创建一个sandbox容器，或者pause容器，起到一个占位的目的，这个Pod中的其它容器会共享pause容器中的网络和存储资源，

config_unix.go -> "sandboxImage": "registry.k8s.io/pause:3.8“

https://github.com/kubernetes/kubernetes/blob/master/build/pause/linux/pause.c

Cnitool

Cnitool是一个用于CNI开发和测试的工具，

https://github.com/containernetworking/cni/blob/main/cnitool/cnitool.go

sudo su –
mkdir cnitool && cd cnitool
go install github.com/containernetworking/cni/cnitool@latest
git clone https://github.com/containernetworking/plugins.git
cd plugins
./build_linux.sh
echo '{"cniVersion":"0.4.0","name":"myptp","type":"ptp","ipMasq":true,"ipam":{"type":"host-local","subnet":"172.16.29.0/24","routes":[{"dst":"0.0.0.0/0"}]}}' | sudo tee /etc/cni/net.d/10-myptp.confip netns add testing
ip netns add testing2
CNI_PATH=./bin cnitool add myptp /var/run/netns/testing
CNI_PATH=./bin cnitool add myptp /var/run/netns/testing2
ip -n testing addr
ip -n testing2 addr
ip netns exec testing ping <testing2 IP>
ip netns exec testing2 ping <testing IP>CNI_PATH=./bin cnitool del myptp /var/run/netns/testing
CNI_PATH=./bin cnitool del myptp /var/run/netns/testing2
ip netns del testing
ip netns del testing2

常见CNI插件

Flannel: The basic CNI, high performance, but not support security related features

Calico: High performance, support security features

Weave: Mesh overlay between all nodes, fast datapath, support security features

Cilium: Use eBPF to support advanced network features, support security features, resource usage is high

The Ultimate Guide To Using Calico, Flannel, Weave and Cilium - Platform9

https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49

Flannel

Flannel 在 Kubernetes 集群的所有节点上运行一个简单的覆盖网络。它在第 3 层（ OSI 网络模型的网络层）提供网络。

Flannel 支持 VXLAN 作为其默认后端，但你也可以将其配置为使用 UDP 和 host-gw。**AWS VPC、AliVPC、IPIP 和 IPSec 等一些实验性后端也可用，但目前尚未得到官方支持。

Flannel 的缺点之一是缺乏高级功能，例如配置网络策略和防火墙的能力。因此 Flannel 是 Kubernetes 集群网络的一个很好的入门级选择，但是，如果你正在寻找高级网络功能，你可能需要考虑其他 CNI 选项，例如 Calico。

Calico

与 Flannel 一样，Calico 在 OSI 模型的第 3 层上运行，并使用 BGP 协议在其默认配置中的节点之间移动网络数据包，并使用 IP in IP 进行封装。使用 BGP，Calico 可以本地定向数据包，而无需将它们包装在额外的封装层中。

Calico 最有价值的特性是它对网络策略的支持。通过定义和执行网络策略，你可以规定哪些 pod 可以发送和接收流量并管理网络内的安全性。

Weave

Weave 在 Kubernetes 集群的所有节点之间创建一个网格覆盖，并将其与每个节点上的路由组件结合使用，以在整个集群中动态路由流量。默认情况下，Weave 使用快速数据路径方法路由数据包，该方法尝试沿最短路径在节点之间发送流量。该网络不断分析交通流量并优化路线。如果快速数据路径发生故障，则称为***sleeve***数据包转发的较慢网络方法是备用方法。

Cilium

Cilium 可以为大规模部署提供优势，并利用 eBPF 来提高可观察性和网络管理效率。Cilium 仍然是一个年轻的项目，在下面引用的基准测试中，它似乎确实更耗费资源。

网桥/veth-pair

网桥可以理解为Linux上的一个虚拟交换机，可以连接不用的veth-pair，起到转发数据包的作用。

Veth-pair类似一根网线，可以连接不同的network space，让不同的ns通信。

Veth-pair的一端可以连接到kernel ns，但在kernel ns中需要一个路由才能进入到veth-pair的另一端。

下面演示不同的ns通过网桥可以相互ping通对方，

brctl addbr br0
ip link set br0 up
ip netns add ns1
ip netns add ns2
ip link add veth1-ns type veth peer name veth1-br
ip link add veth2-ns type veth peer name veth2-br
ip link set veth1-ns netns ns1
ip link set veth2-ns netns ns2
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip link set veth1-ns up
ip netns exec ns1 ip addr add 10.0.0.2/24 dev veth1-ns
ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set veth2-ns up
ip netns exec ns2 ip addr add 10.0.0.3/24 dev veth2-ns
ip link set veth1-br up
ip link set veth2-br up
brctl addif br0 veth1-br
brctl addif br0 veth2-brbrctl show
ip netns list
ip netns exec ns1 ifconfig
ip netns exec ns2 ifconfigip netns exec ns1 ping 10.0.0.3
ip netns exec ns2 ping 10.0.0.2ifconfig br0 down
brctl delbr br0
ip link delete veth1-br
ip link delete veth2-br
ip netns del ns1
ip netns del ns2

如何实现一个CNI

CNI要解决的问题有，

IP地址管理
Node内不同Pod的通信
不同Node上Pod的通信

IP地址管理需要考虑的事情是如何保证不同Node上为Pod分配的IP地址不会冲突，以及如何全局统一来协调。通常这里需要用到etcd数据库，保存全局的IP地址分配的配置。

Node内不同的Pod通信，可以考虑使用网桥+ethpair。

不同的Node上Pod的通信比较复杂，如果Node在同一子网，可以考虑最简单的静态路由的方案，也就是underlay网络，或者基于静态路由的BGP方案。如果Node不在同一子网，需要考虑overlay的网络方案，例如IPIP，vxlan等。

按照CNI规范，实现一个CNI需要创建一个配置文件用以描述CNI plugin，以及一个二进制的plugin可执行文件。这里我们实现一个基于静态路由的SimpleCNI，

CNI plugin配置文件参考下面：

root@rxxxx:/etc/cni/net.d# cat simplecni.conf
{"cniVersion": "0.3.0","name": "simplecni","type": "simplecni","bridge": "simplecni0","subnet": "10.244.0.0/16"
}

Plugin可执行文件参考以下模板，编译好simplecni以后，需要将binary放到以下位置：/opt/cni/bin/simplecni,

https://github.com/containernetworking/plugins/blob/main/plugins/main/bridge/bridge.go

为了简化IPAM的管理，这里没有使用etcd数据库，而是在每个node上创建了一个配置文件，ipam.config，用于IP地址的管理和分配，

root@xxx:/etc/cni# cat ipam.config
{"Subnet":"10.244.1.0","SubnetPrefix":"10.244.1.","Gateway":"10.244.1.1","IPIndex":“1"}

由于SimpleCNI基于静态路由，所以需要手动在不同的Node上配置类似下面的路由规则以实现不同Node上的Pos间的相互通信，

# On node1
ip route add 10.244.2.0/24 via 192.168.2.1 dev eth1# On node2
ip route add 10.244.1.0/24 via 192.168.1.1 dev eth1

SimpleCNI代码参考：K8S-Related/SimpleCNI at main · wangxiaohui2015/K8S-Related (github.com)

IPIP

IP in IP可用于跨子网的Node上Pod与Pod的通信，基本原理是将Pod与Pod通信的IP层数据包封装到Node上IP数据包的payload部分，通过Node的IP层进行通信。使用IPIP后，会在OS上创建一个tunl0的设备，用于IPIP协议的解析，数据包的封装和解封，OS Kernel本身支持IPIP协议。参考：

一文明白calico的IPIP网络模式 - 知乎