一、前言
1、Docker的网络模型
Bridge Joined Open None（具体参见：https://www.cnblogs.com/cmxu/p/11624699.html）
跨节点之间通信时都需要NAT，需要经过两次地址转换。效率低，并且很难构建需要的网络。
2、Kubernetes网络通信
（1） 容器间通信：同一个Pod内的多个容器间的通信，通过lo；
（2） Pod通信：Pod IP < -- > Pod IP；
（3） Pod与Service通信：Pod IP< -- > Cluster IP；
（4）Service与集群外部客户端的通信；
3、CNI（Container Network Interface）
容器虚拟化网络方案：
基于隧道：flannel vxlan模式，calico的IPIP模式
基于路由：flannel的host-gw模式，calico的bgp模式
Flannel的host-gw模式只能用于二层直接可达的网络，由于广播的问题，这种网络规模都比较小（但目前规模小的解决方案有：“大二层”网络）
K8S自身不提供网络解决方案，但支持任何第三方的网络解决方案（CNI）。常见的CNI：flannel，calico，canel，kube-router等等
解决方案：
虚拟网桥
多路复用：MacVLAN
硬件交换：SR-IOV（Single-root I/O virtualization，单根I/O虚拟化）
K8S自动去此目录下找配置，只要把配置文件放在此目录下，k8s自动加载使用此网络插件。
[root@master ~]# ll /etc/cni/net.d/
4、白话flannel和calico
参见：https://www.lbbniu.com/6548.html
二、Flannel
Flannel不支持网络策略（Pod之间的网络访问控制），只支持地址分配。
Calico既支持地址分配也支持网络策略。
Flannel是被kubelet调用，但凡运行kubelet运行的节点都应该部署网络插件，所以作为Pod运行时应该部署为DaemonSet，也可以直接部署为操作系统的守护进程。
[root@master ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
1、flannel支持的后端
VxLAN：
（1）原生vxlan
（2）Directrouting（源节点和目标节点在同一个网络，则使用host-gw方式直接通信，不用隧道叠加，不在同一个网络，则降级为vxlan模式）
host-gw：Host Gateway 各节点都要工作在同一个二层网络中；维护路由表。可能会出现广播风暴。
UDP：使用普通的UDP报文转发，性能最差，最好不要用。
Flannel默认使用VxLAN的模式：
flannel.1网卡用于隧道创建。性能会降低，因为隧道会封装几层首部。
2、Flannel的配置参数
[root@master ~]# kubectl get configmap kube-flannel-cfg -o yaml -n kube-system Network： flannel使用的CIDR格式的网络地址，用于为Pod配置网络功能； 10.244.0.0/16 --> Master：10.244.0.0/24 Node1：10.244.1.0/24 Node2：10.244.2.0/24 集群最多能有256个网络，也就意味着至多只能有256个节点。 SubnetLen：把Network切分为子网供各节点使用时，使用多长的掩码进行切分，默认为24位；则每个子网最多有256个Pod。 SubnetMin：指定用于分配给节点子网使用的起始子网；10.244.10.0/24 SubnetMin：指定用于分配给节点子网使用的最大子网；10.244.100.0/24 Backend：vxlan，host-gw，udp
3、默认VxLAN的数据包流向分析
跨节点的Pod间通信。在node1上的Pod Ping node2上的Pod，在物理网卡上抓ICMP的包是抓不到的，因为到达ens33时，ICMP的包已经被封装为UDP的包了。
报文从cni0进来，从flannel.1出去，在flannel.1就被封装成VxLAN的包了。
在到达cni0网络接口时报文还没有封装，并且报文的源地址和目的地址还是Pod IP.
[root@node1 ~]# tcpdump -i flannel.1 -nn -p icmp
[root@node1 ~]# tcpdump -i cni0 -nn -p icmp
[root@node1 ~]# tcpdump -i flannel.1 -nn -p icmp
[root@node1 ~]# tcpdump -i ens33 -nn host 192.168.42.130
在物理网卡能看到封装后的报文。
4、修改Flannel的后端为directrouting的VxLAN
未修改前，路由表如下，出口都是flannel.1网卡。
[root@master flannel]# ip route show
[root@master flannel]# kubectl edit configmap kube-flannel-cfg -n kube-system #直接编辑，在 net-conf.json处添加字段Directrouting，不建议直接使用edit，不生效。记得加逗号。
Flannel会自动重读配置。本节点走cni，其他节点走物理接口。
通过edit修改configmap修改后端后，不会生效，路由表不会更新，目前只能删除flannel，修改kube-flannel.yml，重新apply才会生效。
事实上，我们应该在前期集群部署时就规划好网络相关，中途修改会引发很多问题。
5、Directrouting VxLAN的数据包流向分析
在node1上的Pod Ping node2上的Pod，（Pod间的桥接网络）直接在物理网卡上抓包，结果如下：
三、Tips：
更改Service通信模式为ipvs：
Modeprobe加载ipvs需要的内核模块
[kubelet@master dashboard]$ kubectl get configmap kube-proxy -n kube-system -o yaml
修改mode为ipvs之后，重载一下kube-proxy应用即可。