容器网络之Kubernetes CNI

系统管理员 2022-12-12 02:22 435阅读 0赞

### 文章目录 ###

*  容器网络之Kubernetes CNI
 *   *  前言
     *  1、Flannel
     *   *  1.1、Flannel 在 K8S 中运行的整体过程
         *  1.2、数据传递过程
         *  1.3、实操通信链路抓包确认(未完成)
     *  2、Calico
     *  3、Weave Net
     *  4、Contiv
     *  5、CNI-Genie
     *  6、Cilium
     *  7、Contrail
     *  8、Multus

# 容器网络之Kubernetes CNI #

## 前言 ##

容器网络发展到现在，形成了Docker的CNM以及由Google、CoreOS、Kuberenetes主导的CNI两大阵营。需要明确的是，CNM和CNI只是容器网络的规范，并不是网络实现，它们只是容器网络的规范，从开发者的角度看，就是一堆接口，底层用Flannel也好，用Calico也罢，他们并不关心。

Kubernetes作为容器的编排框架，在网络层面，并没有进入更底层的具体容器互通互联的网络解决方案的设计中，而是将网络功能一分为二，主要关注Kubernetes服务在网络中的暴露以及Pod自身网络的配置，至于Pod具体需要配置的网络参数以及Service、Pod之间的互通互联，则交给CNI来解决。这样Kubernetes本身不用具有太复杂的网络功能，从而能够将更多的精力放在Kubernetes服务和容器的管理上，最终能够对外呈现一个易于管理、可用性高的应用服务集群。

CNI于2015年4月由CoreOS公司推出，优势是兼容其他容器技术及上层编排系统，如Kubernetes与Mesos。CNI的目的在于定义一个标准的接口规范，使得Kubernetes在增删Pod的时候，能够按照规范向CNI实例提供标准的输入并获取标准的输出，再将输出作为Kubernetes管理Pod网络的参考。在满足输入输出以及调用标准的CNI规范下，Kubernetes委托CNI实例管理Pod的网络资源并为Pod建立互通能力。

CNI本身实现了一些基本的插件，比如Bridge、IPvlan、MACvlan、Loopback、vlan等网络接口管理插件，还有dhcp、host-local等IP管理插件，并且主流的容器网络解决方案都有对应CNI的支持能力，比如Flannel、Calico、Weave、Contiv、SR-IOV、Amazon ECS CNI Plugins等。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center][]

CNI的接口主要包括以下几种方法：添加网络、删除网络、添加网络列表和删除网络列表。每个CNI插件只需要实现两类方法，一类是配置网络，用于创建容器时调用，一类是清理网络，用于删除容器时调用（以及一个可选的VERSION查看版本操作）。所以，CNI的实现确实非常简单，把复杂的逻辑交给具体的Network Plugin实现。CNI插件必须实现为一个可执行文件，这个文件被容器编排管理系统（例如Kubernetes）调用。CNI插件负责将网络接口插入容器网络命名空间（例如veth pair的一端），并在主机上进行任何必要的改变（例如将veth的另一端连接到网桥），然后将IP分配给接口，并通过调用适当的IPAM（IP Address Management）插件来设置路由。

用户通过使用参数`--network-plugin=cni`来运行kubelet，从而运行对应的CNI插件。kubelet会从参数`--cni-conf-dir`确定的目录（默认值为`/etc/cni/net.d`）读取文件，并使用该文件中的CNI配置来设置每个Pod的网络。CNI配置文件必须与CNI规范相匹配，并且配置中所引用的任何所需的CNI插件必须存在于`--cni-bin-dir`参数确定的目录中（默认值为`/opt/cni/bin`）。如果目录中存在多个CNI配置文件，则按照文件名的词典顺序排序并选取顺序排第一的CNI配置文件。除CNI配置文件指定的CNI插件外，Kubernetes还需要标准的CNI lo插件，并且最低版本为0.2.0。

[root@master ~]# ll /etc/cni/net.d/
    总用量 4
    -rw-r--r-- 1 root root 94 9月  12 18:04 00-galaxy.conf
    [root@master ~]#
    [root@master ~]# cat /etc/cni/net.d/00-galaxy.conf
    { 
      "type": "galaxy-sdn",
      "capabilities": { "portMappings": true},
      "cniVersion": "0.2.0"
    }
    [root@master ~]# ll /opt/cni/bin/
    总用量 77964
    -rwxr-xr-x 1 root root  4159253 1月  23 2020 bandwidth
    -rwxr-xr-x 1 root root  4671350 1月  23 2020 bridge
    -rwxr-xr-x 1 root root 12116044 1月  23 2020 dhcp
    -rwxr-xr-x 1 root root  5945760 1月  23 2020 firewall
    -rwxr-xr-x 1 root root  3069556 1月  23 2020 flannel
    -rwxr-xr-x 1 root root  7861170 5月  21 19:39 galaxy-sdn
    -rwxr-xr-x 1 root root  4153025 1月  23 2020 host-device
    -rwxr-xr-x 1 root root  3614305 1月  23 2020 host-local
    -rwxr-xr-x 1 root root  4314508 1月  23 2020 ipvlan
    -rwxr-xr-x 1 root root  3026388 8月  18 2017 loopback
    -rwxr-xr-x 1 root root  4389532 1月  23 2020 macvlan
    -rwxr-xr-x 1 root root  3939867 1月  23 2020 portmap
    -rwxr-xr-x 1 root root  4590104 1月  23 2020 ptp
    -rwxr-xr-x 1 root root  3392736 1月  23 2020 sbr
    -rwxr-xr-x 1 root root  2885430 1月  23 2020 static
    -rwxr-xr-x 1 root root  3356497 1月  23 2020 tuning
    -rwxr-xr-x 1 root root  4314356 1月  23 2020 vlan
    [root@master ~]# ps -efww | grep kubelet | grep -v grep
    root     33734     1 31 7月09 ?       26-14:29:25 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet
    .conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --hostname-override=10.25.0.10 --network-plugin=cni --pod-infra-container-image=registry.tce.com
    /library/pause:3.1
    root     73234 73216  0 9月12 ?       00:00:04 /csi-node-driver-registrar --v=5 --csi-address=/csi/csi.sock --kubelet-registration-path=/var/lib/kubelet/plugins/loop
    device.csi.infra.tce.io/csi.sock
    [root@master ~]# kubectl get pod --all-namespaces | grep galaxy
    kube-system         galaxy-daemonset-6br6w                                            1/1     Running             0          64d
    kube-system         galaxy-daemonset-7dqhd                                            1/1     Running             4          100d
    kube-system         galaxy-daemonset-7zk92                                            1/1     Running             0          100d
    kube-system         galaxy-daemonset-8qnbk                                            1/1     Running             0          100d
    kube-system         galaxy-daemonset-9z7lh                                            1/1     Running             2          65d
    kube-system         galaxy-daemonset-bnjr5                                            1/1     Running             2          37d
    [root@master ~]# kubectl -n kube-system get pod flannel-6sr6r -o yaml
    [root@master ~]# kubectl get configmap/kube-flannel-cfg -n kube-system -o yaml | grep -i type
              "type": "flannel",
              "type": "portmap",
            "Type": "vxlan"
    [root@master ~]# kubectl get configmap/kube-flannel-cfg -n kube-system -o yaml
    apiVersion: v1
    data:
      cni-conf.json: |
        { 
          "name": "cbr0",
          "plugins": [
            { 
              "type": "flannel",
              "delegate": { 
                "hairpinMode": true,
                "isDefaultGateway": true
              }
            },
            { 
              "type": "portmap",
              "capabilities": { 
                "portMappings": true
              }
            }
          ]
        }
      net-conf.json: |
        { 
          "Network": "192.168.0.0/16",
          "Backend": { 
            "Type": "vxlan"
          }
        }
    kind: ConfigMap
    metadata:
      creationTimestamp: "2020-04-16T11:25:30Z"
      labels:
        app: flannel
        tier: node
      name: kube-flannel-cfg
      namespace: kube-system
      resourceVersion: "406"
      selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
      uid: dd954170-1e7e-459c-b5b0-441be1d7b3b0
    [root@master ~]#

以下是一些常见的CNI插件。

## 1、Flannel ##

https://github.com/coreos/flannel/blob/master/Documentation/backends.md

Flannel是CoreOS开源的网络方案，负责为Kubernetes集群中的多个Node间提供层3的IPv4网络。容器如何与主机联网不在Flannel的考虑范围，Flannel只控制如何在主机之间传输流量。Flannel为Kubernetes提供了一个CNI插件，并提供了与Docker集成的指导。

Flannel在集群的每个主机上运行一个名为flanneld的小型代理，负责从一个预先配置的地址空间中向每个主机分配子网；使用Kubernetes API或etcd来存储网络配置、分配的子网和任何辅助数据（如主机的公共IP）；数据包则通过VXLAN、UDP或host-gw这些类型的后端机制进行转发。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 1][]

Flannel的底层通信协议可以有很多选择，比如UDP、VxLAN、AWS VPC等，不同协议实现下的网络通信效率相差较多，默认为使用UDP协议，部署和管理相对简单。

*  UDP封包使用了Flannel自定义的一种包头协议，数据是在Linux的用户态进行封包和解包的，因此当数据进入主机后，需要经历两次内核态到用户态的切换。网络通信效率低且存在不可靠的因素。-
 *  VxLAN封包采用的是内置在Linux内核里的标准协议，因此虽然它的封包结构比UDP模式复杂，但由于所有数据封装、解包过程均在内核中完成，实际的传输速度要比UDP模式快许多。VxLAN方案在做大规模应用时复杂度会提升，故障定位分析复杂。

### 1.1、Flannel 在 K8S 中运行的整体过程 ###

1）设置集群网络

flannel默认使用etcd作为配置和协调中心，首先使用etcd设置集群的整体网络。通过如下的命令能够查询网络配置信息：

$ etcdctl ls /coreos.com/network/config

2）设置 Node 节点上的子网

基于在 etcd 中设置的网络，flannel 为每一个 Node 分配 IP 子网。

获取子网列表

$ etcdctl ls /coreos.com/network/subnets

获取子网信息

$ etcdctl ls /coreos.com/network/subnets/{IP网段}

3）在每个 Node 上启动 flanneld

flannel 在每个 Node 上启动了一个 flanneld 的服务，在flanneld启动后，将从etcd中读取配置信息，并请求获取子网的租约。

所有 Node 上的 flanneld 都依赖 etcd cluster 来做集中配置服务，etcd 保证了所有node 上 flanned 所看到的配置是一致的。同时每个 node 上的 flanned 监听etcd上的数据变化，实时感知集群中node的变化。flanneld一旦获取子网租约、配置后端后，会将一些信息写入/run/flannel/subnet.env文件。

$ cat /var/run/flannel/subnet.env

![20201005143624716.png_pic_center][]

4）创建虚拟网卡

在Node节点上，会创建一个名为flannel.1的虚拟网卡。

$ ip addr show flannel.1

![20201005143638814.png_pic_center][]

5）创建Docker网桥

并为容器配置名为docker0的网桥，实际是通过修改Docker的启动参数–bip来实现的。通过这种方式，为每个节点的Docker0网桥设置在整个集群范围内唯一的网段，从保证创建出来的Pod的IP地址是唯一。

$ ip addr show docker0

![2020100514365947.png_pic_center][]

6）修改路由表

flannel会对路由表进行修改，从而能够实现容器跨主机的通信。

$ route -n

![2020100514371259.png_pic_center][]

### 1.2、数据传递过程 ###

在源容器宿主机中的数据传递过程：

**1）源容器向目标容器发送数据，数据首先发送给 docker0 网桥**

在源容器内容查看路由信息：

$ kubectl exec -it -p {Podid} -c {ContainerId} -- ip route

**2）docker0 网桥接受到数据后，将其转交给 flannel.1 虚拟网卡处理**

docker0 收到数据包后，docker0的内核栈处理程序会读取这个数据包的目标地址，根据目标地址将数据包发送给下一个路由节点：

查看源容器所在Node的路由信息：

$ ip route

**3）flannel.1 接受到数据后，对数据进行封装，并发给宿主机的 eth0**

flannel.1收到数据后，flannelid会将数据包封装成二层以太包。

Ethernet Header的信息：

*  From:\{源容器flannel.1虚拟网卡的MAC地址\}
 *  To:\{目录容器flannel.1虚拟网卡的MAC地址\}

**4）对在flannel路由节点封装后的数据，进行再封装后，转发给目标容器 Node 的 eth0**

由于目前的数据包只是vxlan tunnel上的数据包，因此还不能在物理网络上进行传输。因此，需要将上述数据包再次进行封装，才能源容器节点传输到目标容器节点，这项工作在由linux内核来完成。

Ethernet Header 的信息：

*  From: \{源容器 Node 节点网卡的 MAC 地址\}
 *  To: \{目录容器 Node 节点网卡的 MAC 地址\}

IP Header的信息：

*  From:\{源容器Node节点网卡的IP地址\}
 *  To:\{目录容器Node节点网卡的IP地址\}

通过此次封装，就可以通过物理网络发送数据包。

在目标容器宿主机中的数据传递过程：

**5）目标容器宿主机的eth0接收到数据后，对数据包进行拆封，并转发给flannel.1虚拟网卡；**

**6）flannel.1 虚拟网卡接受到数据，将数据发送给docker0网桥；**

**7）最后，数据到达目标容器，完成容器之间的数据通信。**

### 1.3、实操通信链路抓包确认(未完成) ###

## 2、Calico ##

Calico是一个基于BGP的纯三层的数据中心网络方案，与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。

如下图所示为Calico架构，Calico在每一个计算节点基于Linux内核实现了一个高效的vRouter来负责数据转发，基于iptables创建了相应的路由规则，并通过这些规则来处理进出各个容器、虚拟机和主机的流量。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 2][]

*  calicoctl:Calico提供的命令行工具。
 *  orchestrator插件：提供与Kubernetes等的紧密集成和同步。
 *  key/value store：用于存储Calico的策略和网络配置状态。
 *  calico/node：运行在每个主机上，从key/value store读取相关的策略和网络配置信息，并在Linux内核中进行实现。
 *  Dikastes/Envoy：可选的Kubernetes sidecar，通过相互TLS身份验证保护工作负载到工作负载的通信，并实施应用层策略。

## 3、Weave Net ##

Weave Net能够简化用户对Kubernetes网络的配置。它可以作为CNI插件运行或独立运行。在这两种模式下，运行Weave Net均不需要任何额外的配置或代码。同时，两种模式都遵循了标准的“IP-per-Pod”模型。

## 4、Contiv ##

Contiv由思科开源，兼容CNI模型及CNM模型，能够为多种不同用例提供可配置的网络（比如原生L3网络使用BGP,overlay网络使用VxLAN）。Contiv带来的方便是用户可以根据容器实例IP地址直接进行访问。

## 5、CNI-Genie ##

如图所示，CNI-Genie使Kubernetes能够在运行时同时访问Kubernetes网络模型的不同实现，例如Flannel、Calico、Romana和Weave-net等。CNI-Genie还支持为一个Pod分配多个IP地址，每个IP地址由不同的CNI插件来提供。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 3][]

## 6、Cilium ##

https://sourcegraph.com/github.com/cilium/cilium@v1.6.4/-/blob/api/v1/server/restapi/cilium\_api.go\#L593:21

https://sourcegraph.com/github.com/torvalds/linux@v4.16/-/blob/include/uapi/linux/bpf.h\#L289

Cilium是一款开源软件，它以一种不干涉运行在容器中的应用程序的方式，提供了安全的网络连接和负载均衡。Cilium在层3和层4运行，提供传统的网络和安全服务；同时，Cilium也在层7运行，以保护HTTP、gRPC和Kafka等应用协议的使用。

Cilium架构如图所示。Cilium已经集成到Kubernetes和Mesos等编排框架之中。一种名为BPF（Berkeley Packet Filter，伯克利包过滤器，于4.9内核开始支持）的Linux内核技术是Cilium的基础。它支持在各种集成点（如网络I/O、应用程序套接字和跟踪点）将BPF字节码动态地插入Linux内核，以实现安全性、网络和可见性逻辑。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 4][]

## 7、Contrail ##

基于OpenContrail的Contrail是一个真正开放的多云网络虚拟化和策略管理平台。Contrail和OpenContrail已经与各种编排系统集成，如Kubernetes、OpenShift、OpenStack和Mesos，并为容器或Pod、虚拟机和裸机的工作负载提供了不同的隔离模式。

## 8、Multus ##

在生产环境下，为了保证安全和性能，不同功能的网络进行隔离是一个必要的措施，如管理网络、控制网络和数据网络的隔离。这种隔离对于物理机和虚拟机来说很容易实现。但是在Pod里面，如果使用Kubernetes，则会面临一些限制，尤其是现Kubernetes的Pod默认还不支持多网卡设置。

在这种背景下，Intel的multuscni借助CNI在一定程度上满足了这个需求。如图所示，Multus可以为运行在Kubernetes的Pod提供多个网络接口，它可以将多个CNI插件组合在一起为Pod配置不同类型的网络。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 5][]

Multus能够支持几乎所有的CNI插件，包括Flannel、DHCP和Macvlan，以及Calico、Weave、Cilium和Contiv等第三方插件。Multus使用“delegates”的概念将多个CNI插件组合起来，并且指定一个master plugin作为Pod的主网络并且被Kubernetes感知。

Multus自己不会进行任何网络设置，而是调用其他插件（如Flannel、Calico）来完成真正的网络配置。它重用了Flannel中调用代理的方式，通过将多个插件分组，再按照CNI配置文件的顺序来调用它们。默认的网络接口名称为“eth0”，而Pod中的网络接口名称为net0、net1、……、netX。Multus也支持自动的网络接口名称。如图所示为Multus网络的工作流程

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 6][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/3a5930a946ff4d3ca4ebf503ae6f62b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/c6c05b90259c48299c121aaa02eb3086.png
[20201005143624716.png_pic_center]: /images/20221123/5da2203e50ad4bb497b92f3d20159ce3.png
[20201005143638814.png_pic_center]: /images/20221123/6a56e9824c924df48f5588882367878d.png
[2020100514365947.png_pic_center]: /images/20221123/09e8e75c1760449286bbf140518995bf.png
[2020100514371259.png_pic_center]: /images/20221123/5806c806c9f5467bbc9cb36d1108d002.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/499e4b49f18d4fcca45c04380b2e8573.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/0e760d59251b4fd9be57e6190d038011.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/256f1779a666479684824f77ed9ee3ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/83207ed423b84247b0fd3d5e149a21ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/d0ea0c2b952d4b7aa02f488ff5fe1f9d.png