一篇文章讲明白k8s网络插件flannel模式剖析：vxlan、host

跨节点通讯，需要通过NAT，即需要做源地址转换。

k8s网络通信：

　　1） 容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；

2） pod之间的通信，pod ip pod ip，pod和pod之间要不经过任何转换即可通信；

3） pod和service通信:pod ip cluster ip（即service ip）pod ip，他们通过iptables或ipvs实现通信，另外大家要注意ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换；

4） Service与集群外部客户端的通信

【root@master pki】# kubectl get configmap -n kube-system

NAME DATA AGE

coredns 1 22d

extension-apiserver-authentication 6 22d

kube-flannel-cfg 2 22d

kube-proxy 2 22d

kubeadm-config 1 22d

kubelet-config-1.11 1 22d

kubernetes-dashboard-settings 1 9h

【root@master pki】# kubectl get configmap kube-proxy -o yaml -n kube-system|grep mode

mode: ""

看到mode是空的，我们把它改为ipvs就可以了。

k8s要靠CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，callco，canel，kube-router。

这些插件使用的解决方案都如下：

1）虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信；

2）多路复用：MacVLAN，多个容器共用一个物理网卡进行通信；

3）硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

CNI插件存放位置

【root@master ~】# cat /etc/cni/net.d/10-flannel.conflist

{

"name": "cbr0",

"plugins": 【

{

"type": "flannel",

"delegate": {

"hairpinMode": true,

"isDefaultGateway": true

}

},

{

"type": "portmap",

"capabilities": {

"portMappings": true

}

}

】

}

flanel只支持网络通讯，但是不支持网络策略。

callco网络通讯和网络策略都支持。

canel：flanel+callco合起来的功能。

我们可以部署flanel提供网络通讯，再部署一个callco只提供网络策略。而不用canel。

mtu：是指一种通信协议的某一层上面所能通过的最大数据包大小。

【root@master ~】# ifconfig

cni0: flags=4163 mtu 1450

inet 10.244.0.1 netmask 255.255.255.0 broadcast 0.0.0.0

inet6 fe80::4097:d5ff:fe28:6b64 prefixlen 64 scopeid 0x20

ether 0a:58:0a:f4:00:01 txqueuelen 1000 (Ethernet)

RX packets 1609844 bytes 116093191 (110.7 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 1632952 bytes 577989701 (551.2 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

docker0: flags=4099 mtu 1500

inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255

ether 02:42:83:f8:b8:ff txqueuelen 0 (Ethernet)

RX packets 0 bytes 0 (0.0 B)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 0 bytes 0 (0.0 B)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens192: flags=4163 mtu 1500

inet 172.16.1.100 netmask 255.255.255.0 broadcast 172.16.1.255

inet6 fe80::9cf3:d9de:59f:c320 prefixlen 64 scopeid 0x20

inet6 fe80::5707:6115:267b:bff5 prefixlen 64 scopeid 0x20

inet6 fe80::e34:f952:2859:4c69 prefixlen 64 scopeid 0x20

ether 00:50:56:a2:4e:cb txqueuelen 1000 (Ethernet)

RX packets 5250378 bytes 704067861 (671.4 MiB)

RX errors 139 dropped 190 overruns 0 frame 0

TX packets 4988169 bytes 4151179300 (3.8 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

flannel.1: flags=4163 mtu 1450

inet 10.244.0.0 netmask 255.255.255.255 broadcast 0.0.0.0

inet6 fe80::a82c:bcff:fef8:895c prefixlen 64 scopeid 0x20

ether aa:2c:bc:f8:89:5c txqueuelen 0 (Ethernet)

RX packets 51 bytes 3491 (3.4 KiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 53 bytes 5378 (5.2 KiB)

TX errors 0 dropped 10 overruns 0 carrier 0 collisions 0

lo: flags=73 mtu 65536

inet 127.0.0.1 netmask 255.0.0.0

inet6 ::1 prefixlen 128 scopeid 0x10

loop txqueuelen 1 (Local Loopback)

RX packets 59118846 bytes 15473986573 (14.4 GiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 59118846 bytes 15473986573 (14.4 GiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth6ec94aab: flags=4163 mtu 1450

inet6 fe80::487d:5bff:fef7:484d prefixlen 64 scopeid 0x20

ether 4a:7d:5b:f7:48:4d txqueuelen 0 (Ethernet)

RX packets 88112 bytes 19831802 (18.9 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 105718 bytes 13343894 (12.7 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vethf703483a: flags=4163 mtu 1450

inet6 fe80::b06a:eaff:fec3:33a8 prefixlen 64 scopeid 0x20

ether b2:6a:ea:c3:33:a8 txqueuelen 0 (Ethernet)

RX packets 760882 bytes 59400960 (56.6 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 763263 bytes 282299805 (269.2 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vethff579703: flags=4163 mtu 1450

inet6 fe80::d82f:37ff:fe9a:b6d0 prefixlen 64 scopeid 0x20

ether da:2f:37:9a:b6:d0 txqueuelen 0 (Ethernet)

RX packets 760850 bytes 59398245 (56.6 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 764016 bytes 282349248 (269.2 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

通过ifconfig命令，我们可以看到flannel.1的地址是10.244.0.0，子网掩码是255.255.255.255，mtu是1450，mtu要留出一部分做封装叠加，额外开销使用。

cni0只有在pod运行时才会出现。

两个节点上的pod可以借助flannel隧道进行通信。默认使用的VxLAN协议，因为它有额外开销，所以性能有点低。

flannel第二种协议叫host-gw(host gateway)，即Node节点把自己的网络接口当做pod的网关使用，从而使不同节点上的node进行通信，这个性能比VxLAN高，因为它没有额外开销。不过他有个缺点， 就是各node节点必须在同一个网段中 。

另外，如果两个pod所在节点在同一个网段中 ，可以让VxLAN也支持host-gw的功能， 即直接通过物理网卡的网关路由转发，而不用隧道flannel叠加，从而提高了VxLAN的性能，这种flannel的功能叫directrouting。

【root@master ~】# kubectl get daemonset -n kube-system

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE

kube-flannel-ds-amd64 3 3 3 3 3 beta.kubernetes.io/arch=amd64 22d

【root@master ~】# kubectl get pods -n kube-system -o wide

NAME READY STATUS RESTARTS AGE IP //代码效果参考：http://www.zidongmutanji.com/bxxx/451004.html

kube-flannel-ds-amd64-6zqzr 1/1 Running 8 22d 172.16.1.100 master

kube-flannel-ds-amd64-7qtcl 1/1 Running 7 22d 172.16.1.101 node1

kube-flannel-ds-amd64-kpctn 1/1 Running 6 22d 172.16.1.102 node2

看到flannel是以pod的daemonset控制器形式运行的（其实flannel还可以以守护进程的方式运行）。

【root@master ~】# kubectl get configmap -n kube-system

NAME DATA AGE

kube-flannel-cfg 2 22d

【root@master ~】#kubectl get configmap -n kube-system kube-flannel-cfg -o json -n kube-system|grep Backend

\\"10.244.0.0/16\\",\n \\"Backend\\": {\n \\"Type\\": \\"vxlan\

flannel的配置参数：

1、network ：flannel使用的CIDR格式的网络地址，用于为pod配置网络功能。

1)10.244.0.0/16--->

master: 10.244.0.0./24

//代码效果参考：http://www.zidongmutanji.com/zsjx/16955.html

....

node255: 10.244.255.0/24

可以支持255个节点

2)10.0.0.0/8

10.0.0.0/24

...

10.255.255.0/24

可以支持6万多个节点

2、SubnetLen ：把network切分为子网供各节点使用时，使用多长的掩码进行切分，默认为24位；

3、SubnetMin ：指明子网中的地址段最小多少可以分给子网使用，比如可以限制10.244.10.0/24，这样0~9就不让用；

4、SubnetMax ：表示最多使用多少个，比如10.244.100.0/24

5、Backend: Vxlan，host-gw，udp（最慢）

flannel支持多种后端：

1.Vxlan

1.1 vxlan

1.2 Dirextrouting

2.host-gw：Host Gateway #不推荐，只能在二层网络中，不支持跨网络，如果有成千上万的Pod，容易产生广播风暴

3.UDP：性能差

【root@master ~】# kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE

myapp-deploy-69b47bc96d-79fqh 1/1 Running 4 7//代码效果参考：http://www.zidongmutanji.com/bxxx/242734.html

myapp-deploy-69b47bc96d-tc54k 1/1 Running 4 7d 10.244.2.88 node2

【root@master ~】# kubectl exec -it myapp-deploy-69b47bc96d-79fqh -- /bin/sh

/ # ping 10.244.2.88 #ping对方Node上容器的ip

PING 10.244.2.88 (10.244.2.88): 56 data bytes

64 bytes from 10.244.2.88: seq=0 ttl=62 time=0.459 ms

64 bytes from 10.244.2.88: seq=0 ttl=62 time=0.377 ms

64 bytes from 10.244.2.88: seq=1 ttl=62 time=0.252 ms

64 bytes from 10.244.2.88: seq=2 ttl=62 time=0.261 ms

在其他节点上抓包，发现根本就在ens192上抓不到包。

【root@master ~】# tcpdump -i ens192 -nn icmp

【root@master ~】# yum install bridge-utils -y

【root@master ~】# brctl show docker0

bridge namebridge idSTP enabledinterfaces

docker08000.024283f8b8ffno

【root@master ~】# brctl show cni0

bridge namebridge idSTP enabledinterfaces

cni08000.0a580af40001noveth6ec94aab

vethf703483a

vethff579703

可以看到veth这些接口都是桥接到cni0上的。

brctl show表示查看已有网桥。