k8s的网络插件Flannel和Calico(the hard way)

背景：最近在以高塔老师的the hard way进行二进制方式搭建K8S，按照第9步部署worker节点和第11步设置pod网络路由，pod与pod之间可以通信，pod和宿主机之间可以通信，pod和服务之间也可以通信。

 高塔老师在第9步进行cni配置的时候，高塔老师使用了网桥bridge且ip分配使用了host-local，通过将地址写死在每个worker节点的cni配置文件和kubelet的配置文件里面来实现，都是文档中的${POD_CIDR}这个变量，例如worker0的pod_cidr 为10.200.0.0/24，worker1的pod_cidr为10.200.1.0/24，worker2的pod_cidr为10.200.2.0/24

https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/1.21.0/docs/09-bootstrapping-kubernetes-workers.md

在第11步，高塔老师使用的是谷歌cloud服务器，所以命令都是以gcloud为开头，但是我所处的服务器环境就是6台虚拟机，3台为控制平面(192.168.1.2/192.168.1.3/192.168.1.4)，3台为工作节点(192.168.1.5/192.168.1.6/192.168.1.7)。所以无法使用高塔老师的教程，只能自己添加路由表。

给worker0新增路由:
ip route add 10.200.1.0/24 via 192.168.1.6 dev eth0
ip route add 10.200.2.0/24 via 192.168.1.7 dev eth0
 
给worker1新增路由：
ip route add 10.200.0.0/24 via 192.168.1.5 dev eth0
ip route add 10.200.2.0/24 via 192.168.1.7 dev eth0
 
给worker2新增路由：
ip route add 10.200.0.0/24 via 192.168.1.5 dev eth0
ip route add 10.200.1.0/24 via 192.168.1.6 dev eth0

执行完通过ip route 查看路由，并通过kubectl run busybox来测试网络，发现没有任何问题，pod和pod之间的通信正常。

但是在第11步完成后，有两个问题：

第一个问题是：当worker节点重启，节点上的所有静态路由表将会被清除，也就是说你需要再次重新写静态路由表。

第二个问题是：当worker节点很多时候，给每个worker节点新增静态路由表是一个巨大且繁重的工作。例如你有3个worker节点，那么你需要给每个节点新增两条路由信息，整个集群新增6条路由信息。即 n * (n-1) ，即3*2=6

为了解决这两个问题，k8s的各类开源网络插件腾空而出，例如Flannel、Weave和Calico，我们在本篇文章中只关注Flannel和Calico。网络插件真正要做的事情，则是通过某种方法，把不同宿主机上的特殊设备连通，从而达到容器跨主机通信的目的

每遇到网络知识就有点懵，于是重新找到了大学的经典课程《计算机网络》谢希仁，重新复习了一遍基础知识，再看k8s的网络就感觉是小儿科了，并且又看了一下RFC文献，关于这些请大家自省学习，这里有一张Calico的图非常好理解，如下所示。

 一、Flannel

关于Flannel的推荐的通信方式有三种，一种是UDP(已被遗弃)，另外一种是VXLAN，最后一种是host-gw，所以这里只讲解VXLAN和host-gw，还有就是Flannel需要kubernetesAPI或etcd来存储网络配置和子网信息。可参考flannel/backends.md at master · flannel-io/flannel · GitHub

Flannel does not control how containers are networked to the host, only how the traffic is transported between hosts. However, flannel does provide a CNI plugin for Kubernetes and a guidance on integrating with Docker.

Flannel is focused on networking. For network policy, other projects such as Calico can be used.

上述英文是从Flannel项目地址上复制的，意思是Flannel不会控制宿主机上的容器网络，而是负责在多台宿主机之间的网络流量传输。并且Flannel也为kubernetes提供cni插件,为docker提供了集成。Flannel着重于网络，对于网络策略，其他项目像Calico可以使用。

VXLAN，即 Virtual Extensible LAN（虚拟可扩展局域网），它是一个网络虚拟技术，是 Linux 内核本身就支持的一种网络虚似化技术。用于在三层网络(物理层、数据链路层、网络层)之上再虚拟一个二层(物理层、数据链路层)的网络，其实就是将二层数据(MAC frame)作为顶层应用的数据，然后在传输层使用UDP报文(UDP datagram)封装和传输，然后向下面三层(网络层IP)进行传输，可以用于创建一个覆盖网络和隧道。

特别适用于容器之间的通信，即overlay覆盖网络，也就是通过技术手段将底层的差异全部屏蔽掉，创造一个假象让容器认为他们在一个二层网络中，让容器认为自己是一个普通的虚拟机节点。

VXLAN 会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备就叫作 VTEP，即：VXLAN Tunnel End Point（虚拟隧道端点），这个设备有ip和mac地址。

请注意：VXLAN和VLAN的区别和不同，差别只有一个字母

VXLAN的缺点就是 网络传输效率不高，并且涉及封包和解包的操作，会有一定的计算量。

然后是host-gw，这种方式没有使用overlay的覆盖网络进行传输，采用了纯三层传输的方式，

这种方式实质上就是高塔老师新增路由表的方式，通过对子网的下一条进行设置来进行路由，只不过这个过程变成了自动，而不是手动。这种方式要求是各个宿主机是二层互联的，在一个子网内才能实现，这种方式减少了额外的封包和解包带来的性能损失。

 二、Calico

其实Calico和Flannel的host-gw是一致的，也是新增路由信息，而是使用了现实网络中的BGP(Border Gateway Protocol)边界网关协议来进行网络互通，它的部署也分为两种方式：operator和manifest，还有一个非人类选项是 Calico the hard way

当使用manifest的部署方式时候，要注意是否超过了50个节点，如下图所示：

 而关于什么是BGP，BGP的原理是什么，请大家自行百度或谷歌。

当处于不同的子网中，Calico使用了IPIP模式，这种模式使用了封包和解包的操作来完成不同子网之间的通信，这种方式与Flannel的VXLAN模式的性能相当。

还有一个最有意思的是Calico也有一个the hard way的方式进行手动部署，也是从高塔老师的the hard way受到了启发，我们再下一篇文章中会说明详细的步骤来以the hard way的方式来安装Calico，以及如何在高塔老师的the hard way教程中切入这个Calico的the hard way，将两个the hard way结合起来，来实现一个完整的集群搭建，敬请期待。

参考文献：

1.VXLAN：https://datatracker.ietf.org/doc/html/rfc7348

https://en.wikipedia.org/wiki/Virtual_Extensible_LAN

2.k8s网络模型： https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/

3.k8s kubelet : 

https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/

4.Flannel： https://github.com/flannel-io/flannel

5.Flannel backend：https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md

6.Calico install: Install Calico networking and network policy for on-premises deployments

7.Calico the hard way: https://projectcalico.docs.tigera.io/getting-started/kubernetes/hardway/