kubernetes网络通信
- 容器间的通信 pod内的容器通信（lo）
- Pod之间的通信 pod IP <-----> pod IP
- Pod与Service之间的通信 podIP <-----> ClusterIP
- Service与集群外部的通信 ClusterIP <-----> 集群外部
CNI插件：
- flannel
- calico
- canel
- kube-route
解决方案：
- 虚拟网桥
- 多路复用 MacVLAN
- 硬件交换 SR-IOV
Flannel
Flannel本身是一个框架，真正提供网络功能是他的后端实现。目前支持三种后端实现：
- VXLAN
- host-gw
- UDP
UDP
UDP模式是Flannel早期支持的一种方式，却也是性能最差的一种方式。所以现在基本都弃用了。但是这种模式是最直接最容易理解的一种方式。
Node1的容器访问Node2的容器，Node1容器访问的目的地址不是在容器的路由规则里，所以会走默认路由到达宿主机的docker0 网桥上，从而出现在宿主机上，这个时候这个IP的下一步取决于这台宿主机的路由规则，这时候这条会使用flannel0的设备上，flannel是一个TUN设备，在Linux中，TUN设备是一种工作在三层的虚拟网络设备，TUN设备的功能是在操作系统内核和应用程序之间传递IP包。
当操作系统将一个IP包发送给flannel0设备后，flannel0 就会把IP包交给创建这个设备的应用程序，也就是flannel进行。这就是从内核态（Linux操作系统）到用户态（Flannel进程）的流动方向。
反之，如果flannel进程向flannel0设备发送一个IP包，那么这个IP包就会出现在宿主机网络栈，然后根据宿主机路由表进行下一步处理，这是用户态向内核态流动方向。
所以，当IP包从容器经过docker0出现在宿主机上，然后又根据宿主机路由表进入flannel0设备后，宿主机上的flannel进程就会收到这个IP包。然后，flannel看到了这个IP包的目的地址，就可以把他发送到Node2宿主机上。
flannel是如何知道目的IP地址对应的容器是运行在Node2上
源于flannel里的一个重要概念子网（Subnet）。事实上，在由Flannel管理的容器网络里，一台宿主机上的所有容器都属于该宿主机被分配的一个“子网”，所以flannel会根据目的IP地址找到对应的子网，从而在etcd里找到对应的宿主机。只要node1 和node2 互通，flannel进程一定会到达node2。
UDP模式的缺点
相比两台宿主机之间的直接通信，基于flannel UDP模式的容器通信网络多个一个额外的步骤，那就是flannel的处理过程，这个过程由于使用到了flannel0这个TUN设备，仅仅是发送IP包的时候，就需要三次用户态和内核态的数据拷贝。如图：
- 用户态容器进程发起IP包进过docker0网桥进入内核态
- IP包根据路由表进入TUN（flannel0）设备,从而回到用户态的flanneld进程
- flanneld 进行UDP封包之后重新进入内核态，将UDP包通过宿主机的eth0发出去
VXLAN
VXLAN全称虚拟可扩展局域网，是Linux内核本身就支持的一种网络虚拟化技术。所以说，VXLAN可以完全在内核态实现上述封装和解封工作，从而通过前面相似的“隧道机制”，构建出覆盖网络。
VXLAN覆盖网络的设计思想：在现有的三层网络之上，“覆盖”一层虚拟的，由内核VXLAN模块负责维护的二层网络，使得连接在这个VXLAN二层网络上的“主机”（可以是虚拟机也可以是容器）之间，可以像一个局域网里那样自由通信，当然，实际上，这些“主机”可能分布在不同的宿主机上，甚至可以分布在不同的物理机房里。
而为了能够在二层网络上打通“隧道”，VXLAN会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备叫VTEP，既：虚拟隧道端点。而这个VTEP设备的作用，其实跟前面的flanneld进程非常相似。只不过，它进行封装和解封装的对象是二层数据帧。而且这个工作的执行流程全部是在内核里完成的（因为VXLAN本身就是内核模块）。如图：
从图里看每个宿主机都有一个flannel1的设备，就是VXLAN所需的VTEP设备，它既有IP地址也有MAC地址。现在我们是container1 访问 container2,相对UDP比较来看，当container1发出请求后，这个目的的地址是10.244.1.3的IP包，会先出现在docker0网桥，然后被路由到本机flanner1设备上处理，也就是说，来到了“隧道”的出口。既目的宿主机的VTEP设备。而这个设备信息正是每台宿主机上的flanneld进程负责维护的。
当所有Node启动后，我们可以在Node1 上可以看到多个flannel1 网卡的路由信息，是因为flanneld启动后创建的。
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
10.244.1.0 10.244.1.0 255.255.255.0 UG flannel.
....
从上图看到10.244.1.0就是Node2的VTEP设备（就是flannel1 设备）的IP地址，而这些VTEP设备之间就需要想办法组成一个虚拟的二层网络，既：通过二层数据帧进行通信，而Node1上的VTEP设备收到原始IP包后,就要想办法把原始IP包加一个目的MAC地址，封装成二层数据帧，然后发送给目的VTEP设备。这里需要解决一个问题目的VTEP设备的MAC地址是什么？
根据路由表信息我们知道了目的VTEP设备的IP地址，而根据三层IP地址查询二层MAC地址正是ARP表的功能。而这里用ARP表的记录，也就是flanneld进程在Node2节点启动时，自动添加到Node1上的。如下：
$ ip neigh show dev flannel.
10.244.1.0 lladdr b2:ba:aa:a5::1a PERMANENT
有了这个MAC地址linux内核就可以开始二层封包了，上面提到的MAC地址，对宿主机的二层网络没有任何意义，所以上述封装的数据帧不能在宿主机的二层网络里传输，为了方便概述，我们把上述数据帧称为内部数据帧。所以Linux内核还要把内部数据帧进一步封装成宿主机网络的一个普通数据帧，好让他载着内部数据帧，通过eth0网卡进行传输。这次封装我们称为外部数据帧，为了实现这个搭便车的机制，Linux内核在封装内部数据帧前面，加上特殊的VXLAN头，用来表示这个乘客实际上是VXLAN使用的数据帧。而这个VXLAN头里有一个重要的标志VNI，它是识别某个数据帧是不是应该归属自己处理的标志。而flannel中，VNI的值是1，这也是为什么宿主机的VTEP设备都叫做flannel1的原因。这个时候linux内核会把这数据帧封装一个UDP包里发出去。虽然node1的flannel1知道node2的flannel2的MAC地址，但是不知道node2MAC的地址，也就是UDP该发往那台主机，实际上flannel1还要扮演一个网桥的角色，在二层网络进行UDP转发，而在Linux内核里面，网桥设备进行转发的依据来自FDB的转发数据库。这个flannel网桥对应的FDB信息，就是flannel进程维护的，他的内容如下：
$ bridge fdb show flannel. | grep b2:ba:aa:a5::1a
b2:ba:aa:a5::1a dev flannel. dst 172.16.138.41 self permanent
我们可以看到发往的IP地址是172.16.138.41的主机，显然这台主机就是 Node2,UDP要转发的目的也找到了。接下来就是宿主机网络封包的过程了。
Flannel 在kubernetes上的应用
其实上述过程也是kubernetes的主要处理方法，只不过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作为容器网络方案。
CNI配置文件内容如下：
cat /etc/cni/net.d/-flannel.conflist
{
"name": "cbr0",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
需要注意的是Kubernetes 目前不支持多个CNI混用，如果在/etc/cni/net.d/里放置多个CNI配置文件的话，只会加载字母排序第一个配置文件。但另一方面，CNI允许你在一个CNI配置文件里，通过plugins字段，定义多个插件协作。假如我们定义了flannel和protmap这两个插件，这个时候dockershim会把这个CNI配置文件加载起来，并把列表第一个插件，就是flannel插件设置为默认插件，然后执行过程中flannel和portmap会按照定义顺序被调用，从而一次完成“配置容器网络”和“配置端口映射”。
CNI插件工作原理
当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插件。
将Flannel插件的后端改成VXLAN+DriectRouting
以下操作不适合在生产环境操作，kubernetes的网络环境需要根据未来的业务环境选择。所以要集群配置前做好规划。
VXLAN+DriectRouting是首先采用直接路由的方式，如果不可以就使用VXLAN的方式。
Flannel的默认配置是VXLAN，但是我们可以配置多个插件协作，接下来我们就使用VXLAN+DriectRouting这两个插件协作。
下载Flannel配置文件
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-legacy.yml
修改kube-flannel-legacy.yml，在net-conf.json里的增加一个type。
$ vim kube-flannel-legacy.yml
.......
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"Type": "DriectRouting"
}
}
.....
删除flannel插件，重新生成配置文件。
$ kubectl delete ds kube-flannel-ds -n kube-system
$ kubectl apply -f kube-flannel-legacy.yml
这样就修改完成了，切忌生成不可以直接操作。