Flannel 在 k8s 中的使用
在处理过的 k8s 集群的众多问题中数据链路的问题往往是最复杂，最难排查的。这需要我们对 k8s 集群的网络通信的过程有着清晰的认识。Docker 通过 veth 虚拟网络设备以及 Linux bridge 实现了同一台主机上的容器网络通信，再通过 iptables 进行 NAT 实现了容器和外部网络的通信。而 k8s 作为容器编排平台，集群中有众多节点，并且每个节点上也部署了众多 pod, 要实现 pod 跨节点通信，就没有这么简单了。
k8s 网络模型
为了解决 k8s 当中网络通信的问题，K8s 作为一个容器编排平台提出了 k8s 网络模型，但是并没有自己去实现，具体网络通信方案通过网络插件来实现。
其实 K8s 网络模型当中总共只作了三点要求：
- 运行在一个节点当中的 Pod 能在不经过NAT的情况下跟集群中所有的 Pod 进行通信
- 节点当中的客户端（system daemon、kubelet）能跟该节点当中的所有 Pod 进行通信
- 以 host network 模式运行在一个节点上的Pod能跟集群中所有的 Pod 进行通信 从 k8s 的网络模型我们可以看出来，在 k8s 当中希望做到的是每一个 Pod 都有一个在集群当中独一无二的IP，并且可以通过这个 IP 直接跟集群当中的其他 Pod 以及节点自身的网络进行通信，一句话概括就是 k8s 当中希望网络是扁平化的。 所以只要再符合 k8s 网络模型的要求，就可以以插件的方式在 k8s 集群中作为跨节点网络通信实现。目前比较流行的实现有 flannel, calico, weave, canal等。 这里结合我们自己在阿里云中的 k8s 集群的 CNI flannel 来解释 pod 之间的通信过程。
Flannel 介绍
Flannel 是由 CoreOS 团队针对 k8s 设计的一个 Overlay Network(也就是将TCP数据包装在另一种网络包里面进行路由转发和通信) 实现，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式，实现集群间网络通讯。
在 k8s 各个节点上通过DaemonSet的方式运行了一个 flannel 的Pod
kubectl get ds -n kube-system app=flannel
|
|
每一个 flannel 的 Pod 当中都运行了一个 flanneld 进程，且 flanneld 的配置文件以 ConfigMap 的形式挂载到容器内的 /etc/kube-flannel/目录供 flanneld 使用。
flannel 通过在每一个节点上启动一个叫 flanneld 的进程，负责每一个节点上的子网划分，并将相关的配置信息如各个节点的子网网段、外部IP等保存到 etcd 当中，而具体的网络包转发交给具体的 Backend 来实现。
flanneld 可以在启动的时候通过配置文件来指定不同的 Backend 来进行网络通信，目前比较成熟的 Backend 有 VXLAN、host-gw以及UDP三种方式，也已经有诸如AWS，GCE and AliVPC这些还在实验阶段的 Backend。VXLAN 是目前官方最推崇的一种 Backend 实现方式，host-gw 一般用于对网络性能要求比较高的场景，但需要基础架构本身的支持，UDP 则一般用于 Debu g和一些比较老的不支持 VXLAN 的 Linux 内核。
flannel 默认使用 UDP 作为集群间通讯实现，如上图所示，flannel 通过 etcd 管理整个集群中所有节点与子网的映射关系，如上图所示，flannel分别为节点A和B划分了两个子网：10.1.15.0/16和10.1.20.0/16。同时通过修改docker启动参数，确保Docker启动的容器能够特定的网段中如10.1.15.1/24。
- 同一 Pod 实例容器间通信：对于 Pod 而言，其可以包含1~n个容器实例，这些容器实例共享 Pod 的存储以及网络资源，Pod 直接可以直接通过127.0.0.1进行通讯。其通过 Linux 的 Network Namespace 为这组容器实现了一个隔离网络。
- 相同主机上 Pod 间通信：对于 Pod 而言，每一个 Pod 实例都有一个独立的 Pod IP，该 IP 是挂载到虚拟网卡（VETH）上，并且 bridge 到docker0 的网卡上。以节点A为例，其节点上运行的 Pod 均在10.1.15.1/24的网段中，其属于相同网络，因此直接通过 docker0 进行通信。
- 对于跨节点间的 Pod 通信：以节点A和节点B通讯而言，由于不同节点 docker0 网卡的网段并不相同，因此 flannel 通过主机路由表的方式，将对节点B POD IP网段地址的访问路由到 flannel0 的网卡上。 而 flannel0 网卡的背后运行的则是 flannel 在每个节点上运行的进程 flanneld。由于 flannel通过 ETCD 维护了节点间所有网络的路由关系，原本容器将的数据报文，被 flanneld 封装成 UDP 协议，发送到了目标节点的 flanneld 进程，再对 udp 报文进行解包，后将数据发送到 docker0，从而实现跨主机的 Pod 通讯。
公有云中的 flannel
上面我们解释了 flannel backend 为 UDP的通信过程。由于 UDP 作为backend存在明显的性能问题，一般生产环境不会使用这种方式，而在像 AWS 阿里云这样的公有云厂商提供的 k8s 集群服务中的 flannel 优先选择 vpc 作为backend, 这种方式其实类似 host-gw(Host Gateway)。 就像上面我们所说，flannel 通过 etcd 会统一为每个节点分配相应的网段， 下面为一个特定节点的网段
|
|
如上所示，flannel 建立了一个 172.20.0.0/16 的大网段，而这个节点则分配了 一个172.20.1.1/25的小网段。所以该节点上所有Pod的IP地址一定是在该网段中（172.20.1.1 ~ 172.20.1.126). 节点的网卡信息如下
|
|
其中 veth177b8616 是每个 Pod 的虚拟网卡，并且连接到网桥 cni0：
|
|
-
数据包出 该点上的 pod 内的数据包通过网桥方式发送到 cni0.
cni0怎么转发数据包呢？这里是使用的就是在 vpc 中建立的路由规则
例如数据包的目标 pod ip 是 172.20.1.43 则会匹配到图中的路由规则，然后转发到 pod 所在的节点。 -
数据包入 此时，数据包已经到达节点，那么怎么发送到目标 pod 呢？ 查看接收流量主机的路由规则：
例如数据包的目标 pod ip 是 172.20.1.43 则会匹配到图中的路由规则，然后转发到 pod 所在的节点。
|
|
根据主机路由表规则，发送到 pod 172.16.1.43 的请求会落到路由表
172.20.1.0 0.0.0.0 255.255.255.128 U 0 0 0 cni0
然后数据包被发给网桥 cni0 然后经 veth 虚拟网卡 发送到 pod.
上述过程我们用下面这张示意图来总结
像开始我们说的那样一个主机中的容器通过 bridge 模式就能实现容器与容器，容器与主机的通信。flannel 更像是这种模式的扩展，集群的主机如果都在一个子网内，就配置路由转发过去；若是不在一个子网内，就通过隧道转发过去。