flanneld,flannel和cni逐步深入

这个问题，现在慢慢搞定。

把这两者的关系搞清楚了。

还有kubeadm join和手工安装Node的故事，

也没那么玄乎~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

https://www.cnblogs.com/xzkzzz/p/9936467.html
https://segmentfault.com/a/1190000017182169
https://segmentfault.com/a/1190000017182169

Flannel本身是一个框架，真正提供网络功能是他的后端实现。目前支持三种后端实现：

VXLAN
host-gw
UDP

kubernetes是通过一个叫CNI接口维护一个单独网桥来代替docker0，这个网桥CNI网桥，默认叫做cni0.
过程也是和VXLAN是一样的。需要注意的是，CNI网桥只是接管所有CNI插件负责的，既只是kubernetes创建的容器。

kubernetes之所以要设置这样一个与docker0网桥功能一样的CNI网桥，主要原因有两点：

kubernetes项目并没有使用Docker的网络模型，所以它不希望，也不具备配置docker0的能力。
还与kubernetes如何配置Pod,也就是infra容器Network Namespace相关。
我们在部署kubernetes的时候，有一个步骤是安装kubernetes-cni包，他的目的就是宿主机上安装CNI插件所需要的基础可执行文件。

ls /opt/cni/bin/
bridge dhcp flannel host-local ipvlan loopback macvlan portmap ptp sample tuning vlan
CNI的基础可执行文件，按照功能分三类：

Main插件 他是用来创建具体网络设备的二进制文件。例如：birdge(网桥设备)、ipvlan、lookback(lo 设备)、ptp(Veth Pair设备)、macvlan、vlan
IPAM插件 他是负责分配IP地址的二进制文件。例如：dhcp,这个文件会向dhcp服务器发起请求；host-local,则会使用预先配置的IP地址来进行分配。
CNI社区维护的内置CNI插件。例如 flannel,就是专门为Flannel项目提供的CNI插件。
从二进制文件来看，如果实现一个kubernetes用的容器网络方案，其实需要两部分工作，以Flannel下项目为例。

首先实现这个网络本身，其实就是flanneld进程里主要逻辑，例如：创建和配置flannel.1设备，配置宿主机路由、配置ARP和FDB表。
实现该网络方案对应的CNI插件，就是配置infra容器里的网络栈，并把他连接在CNI网桥上。
接下来进行第一步，在宿主机上安装flannel。而这个过程中，flanneld启动后会在每台宿主机上生成他对应的CNI配置文件（就是configmap）,从而告诉kubernetes,这个集群要使用Flannel作为容器网络方案。

当kubelet组件需要创建pod时，他一个创建的一定是infra容器，所以这一步，dockershim 就会先调用Docker API创建并启动infra容器，紧着执行一个叫做SetUpPod的方法，这个方法的作用是：为CNI插件准备构建参数，然后调用CNI插件为infra容器配置网络。这里要调用CNI插件是/opt/cni/bin/flannel;而调用它所需的参数，分两部分：

第一部分，是由dockershim设置的一组CNI环境变量。其中，最重要的环境变量参数叫做：CNI_COMMAND。他的取值只有两种ADD和DEL。这个ADD和DEL操作，就是CNI插件唯一实现的两种方法。

ADD 把容器添加CNI网络里
DEL 把容器从CNI网络里移除
在网桥类型的CNI里，这两个操作说明把容器以“Veth Pair”方式插在CNI网桥上，或者从网桥上拔掉。

第二部分，是dockershim从CNI配置文件里加载到的默认插件的配置信息。这个配置信息在CNI中被叫作Network Configuration,dockershim会把Network Configuration 通过JSON数据的方式，通过标准输入的方式传递给Flannel CNI插件。

创建容器网络的流程就是：kubelet ——> flannel ——> flanneld。

工作原理
很容易混淆几个东西。我们通常说的Flannel（coreos/flannel），其实说的是flanneld。大家都知道Kubernetes是通过CNI标准对接网络插件的，但是当你去看Flannel（coreos/flannel）的代码时，并没有发现它实现了CNI的接口。如果你玩过其他CNI插件，你会知道还有一个二进制文件用来供kubele调用，并且会调用后端的网络插件。对于Flannel（coreos/flannel）来说，这个二进制文件是什么呢？git repo在哪里呢？

这个二进制文件就对应宿主机的/etc/cni/net.d/flannel，它的代码地址是https://github.com/containernetworking/plugins，最可恨的它的名字就叫做flannel，为啥不类似contiv netplugin对应的contivk8s一样，取名flannelk8s之类的。

上面的Flannel Pod中还有一个容器叫做install-cni，它对应的脚本在https://github.com/coreos/flannel-cni。

/opt/bin/flanneld --> https://github.com/coreos/flannel
/etc/cni/net.d/flannel --> https://github.com/containernetworking/plugins
/install-cni.sh --> https://github.com/coreos/flannel-cni

flannel for kubernetes
flannel在对kubernets进行支持时，flanneld启动参数中会增加--kube-subnet-mgr参数，flanneld会初始化一个kubernetes client，获取本地node的pod-cidr，这个pod-cidr将会作为flannel为node本地容器规划的ip网段。记录到/run/flannel/subnet.env。（flannel_cni组件会读取这个文件并写入到net-conf.json中，供cni使用）。

如果说flanneld为Pod打通了一张跨node的大网，那么CNI就是将各个终端Pod挂载到这张大网上的安装工人。
因此，现在我们可以将整个流程连起来了：flannel CNI插件首先读取netconf配置和subnet.env信息，生成适用于bridge CNI插件的netconf文件和ipam（host-local）配置，并设置其delegate为bridge CNI插件。然后调用走bridge CNI插件挂载容器到bridge的流程。由于各个Pod的IP地址分配是基于host-local的Ipam，因此整个流程完全是分布式的，不会对API-Server造成太大的负担。