kubernetes之Flannel网络插件部署Kubernetes系统上Pod网络的实现依赖于第三方插件，而Flannel是由CoreOS
主推的目前比较主流的容器网络解决方案，CNI插件有两种功能：网络配置和网络策略，由于flannel比较简单，并不支持网络策略，fl
annel项目自身只是一个框架，真正提供网络功能的是它的后端实现，目前，Flannel支持三种不同后端实现，分别是：UDPVXLA
Nhost-gwUDP是Flannel项目最早支持的一种方式，是性能最差的方式，目前已被废弃。用的最多的是VXLAN和host-g
w模式的部署FlannelVXLAN模式配置Flannel部署在刚好安装完k8s集群之上部署flannel。直接应用官方的yam
l文件：root@k8s-master:~#kubectlapply-fhttps://raw.githubusercon
tent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/
Documentation/kube-flannel.ymlclusterrole.rbac.authorization.k8s.
io/flannelcreatedclusterrolebinding.rbac.authorization.k8s.io/fl
annelcreatedserviceaccount/flannelcreatedconfigmap/kube-flannel
-cfgcreateddaemonset.extensions/kube-flannel-ds-amd64createddae
monset.extensions/kube-flannel-ds-arm64createddaemonset.extensio
ns/kube-flannel-ds-armcreateddaemonset.extensions/kube-flannel-d
s-ppc64lecreateddaemonset.extensions/kube-flannel-ds-s390xcreat
ed输出如下结果表示运行正常：root@k8s-master:~#kubectlgetds-nkube-systemNA
MEDESIREDCURRENTREADYUP-TO-DATE
AVAILABLENODESELECTORAGEkube-flannel-ds-
amd6422222be
ta.kubernetes.io/arch=amd6498skube-flannel-ds-arm0
0000beta.kubernetes.
io/arch=arm98skube-flannel-ds-arm6400
000beta.kubernetes.io/arch=arm64
98skube-flannel-ds-ppc64le0000
0beta.kubernetes.io/arch=ppc64le98skube-fl
annel-ds-s390x00000
beta.kubernetes.io/arch=s390x98s运行正常后，flanneld会在宿主机的/
etc/cni/net.d目录下生成自已的配置文件，kubelet将会调用它。网络插件运行成功后，Node状态才Readyroot
@k8s-master:~#kubectlgetnodeNAMESTATUSROLESAGE
VERSIONk8s-masterReadymaster18mv1.13.1k8s-node01R
eady16mv1.13.1flannel运行后，在各Node宿主机多了一个网络接口：root@k8s-mas
ter:~#ifconfigflannel.1Linkencap:EthernetHWaddr6a:43:8c:e4
:2a:77inetaddr:10.244.0.0Bcast:0.0.0.0Mask:255.255.255.255i
net6addr:fe80::6843:8cff:fee4:2a77/64Scope:LinkUPBROADCASTR
UNNINGMULTICASTMTU:1450Metric:1root@k8s-node01:~#ifconfigfla
nnel.1Linkencap:EthernetHWaddr7a:a1:2e:85:a9:1cinetaddr:
10.244.1.0Bcast:0.0.0.0Mask:255.255.255.255inet6addr:fe80::7
8a1:2eff:fe85:a91c/64Scope:LinkUPBROADCASTRUNNINGMULTICAST
MTU:1450Metric:1从上面的结果可以知道：flannel默认就是VXLAN模式，即OverlayNetwork。f
lanneld创建了一个flannel.1接口，它是专门用来封装隧道协议的，默认分给集群的Pod网段为10.244.0.0/16。
flannel给k8s-master节点配置的Pod网络为10.244.0.0段，给k8s-node01节点配置的Pod网络为10
.244.1.0段，如果有更多的节点，以此类推。启动一个副本为3的nginx容器：root@k8s-master:~#kubec
tlrunnginx--image=nginx:1.10--port=80--replicas=3查看pod：root
@k8s-master:~#kubectlgetpod-owideNAMEREA
DYSTATUSRESTARTSAGEIPNODENOMINAT
EDNODEREADINESSGATESnginx-6b647cb88-24j291/1Running
023m10.244.0.3k8s-masternginx-6b64
7cb88-ft8wc1/1Running023m10.244.0.2k8s
-masternginx-6b647cb88-g4mqt1/1Running0
33m10.244.1.4k8s-node01其中，两个Pod运行在节点k8
s-master上，其中一个Pod配置的IP为10.244.0.2，现在，在此node查看网络接口root@k8s-master:
~#ifconfigcni0Linkencap:EthernetHWaddr0a:58:0a:f4:01:01i
netaddr:10.244.0.1Bcast:0.0.0.0Mask:255.255.255.0inet6addr:
fe80::c048:c9ff:fe09:f54e/64Scope:LinkUPBROADCASTRUNNINGMULT
ICASTMTU:1450Metric:1RXpackets:3316errors:0dropped:0overr
uns:0frame:0TXpackets:3387errors:0dropped:0overruns:0carri
er:0collisions:0txqueuelen:1000当有容器运行后，节点之上多了个虚拟接口cni0，其IP为10.
244.0.1，它是由flanneld创建的一个虚拟网桥叫cni0，在Pod本地通信使用。flanneld为每个Pod创建一对ve
th虚拟设备，一端放在容器接口上，一端放在cni0桥上。使用brctl查看该网桥：root@k8s-master:~#brctl
showcni0bridgenamebridgeidSTPenabledinterfacescni08
000.0a580af40001noveth0fda9673veth6388ea61#刚好有两个容器的网络接口挂在了cni0网
桥之上。测试正常访问：#在宿主机上测试root@k8s-master:~#ping10.244.0.2PING10.244.
1.4(10.244.1.4)56(84)bytesofdata.64bytesfrom10.244.1.4:i
cmp_seq=1ttl=63time=2.01ms在现有的flannelVXLAN网络中，两台主机上的pod间通信，肯定
是可以的，如下两pod：#进入Pod测试root@k8s-master:~#kubectlexec-itnginx-6b6
47cb88-ft8wc--/bin/sh#ping10.244.1.4http://www.gw638.cnPING
10.244.1.4(10.244.1.4):56databytes64bytesfrom10.244.1.4:i
cmp_seq=0ttl=62time=2.587ms64bytesfrom10.244.1.4:icmp_seq=
1ttl=62time=3.880ms那么容器跨主机是如何通信的呢，查看路由信息：root@k8s-master:~#ip
route10.244.1.0/24via10.244.1.0devflannel.1onlink去往10.244
.1.0/24网络的数据包发给本机的flannel.1接口，即进入二层隧道，然后封装VXLAN包，到达目标Node后，由目标Nod
e上的flannel.1解封装。一旦Node启动并加入Flannel网络之后，其它Node上的flanneld就会添加一条类似这样
的路由规则，这就是默认的VXLAN网络。因为是在k8s-master上ping别人的，所以k8s-master是封装过VXLAN
包的，抓包：#k8s-master抓物理网卡的包tcpdump-iens33-nnhost10.3.1.2016:46
:09.302335IP10.3.1.20.53051>10.3.1.21.8472:OTV,flags[I](0
x08),overlay0,instance1IP10.244.0.2>10.244.1.4:ICMPecho
request,id20,seq360,length6416:46:09.302395IP10.3.1.20.59
519>10.3.1.21.8472:OTV,flags[I](0x08),overlay0,instance
1IP10.244.1.4>10.244.0.2:ICMPechoreply,id20,seq360,len
gth64可以看到，在overlay里面是一个是上面ping的ICMP包。VXLAN是Linux内核本身支持的一种网络虚拟化技术
，是内核的一个模块，在内核态实现封装解封装，构建出覆盖网络，其实就是一个由各宿主机上的Flannel.1设备组成的虚拟二层网络。由
于VXLAN由于额外的封包解包，导致其性能较差，所以Flannel就有了host-gw模式，即把宿主机当作网关，除了本地路由之外没
有额外开销，性能和calico差不多，由于没有叠加来实现报文转发，这样会导致路由表庞大。因为一个节点对应一个网络，也就对应一条路由
条目。host-gw虽然VXLAN网络性能要强很多。，但是种方式有个缺陷：要求各物理节点必须在同一个二层网络中。物理节点必须在同一
网段中。这样会使得一个网段中的主机量会非常多，万一发一个广播报文就会产生干扰。在私有云场景下，宿主机不在同一网段是很常见的状态，所
以就不能使用host-gw了。VXLAN还有另外一种功能，VXLAN也支持类似host-gw的玩法，如果两个节点在同一网段时使用h
ost-gw通信，如果不在同一网段中，即当前pod所在节点与目标pod所在节点中间有路由器，就使用VXLAN这种方式，使用叠加网
络。结合了Host-gw和VXLAN，这就是VXLAN的Directrouting模式因此Flnnel的VXLAN模式有两种：VX
LAN：原生的VXLAN，即扩展的虚拟LANDirectrouting：直接路由型FlannelVXLAN之Directrou
ting模式配置修改下载的kube-flannel.yml，将flannel的configmap对象改为：net-conf.jso
n:|{"Network":"10.244.0.0/16",#默认网段"Backend":{"Type":"V
XLAN","Directrouting":true#增加http://www.f-1.cc}}然后把原来的flanne
l删除，再重新apply：root@k8s-master:~#kubectlapply-fkube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannelcreatedclusterrole
binding.rbac.authorization.k8s.io/flannelcreatedserviceaccount/f
lannelcreatedconfigmap/kube-flannel-cfgcreateddaemonset.extensi
ons/kube-flannel-ds-amd64createddaemonset.extensions/kube-flanne
l-ds-arm64createddaemonset.extensions/kube-flannel-ds-armcreate
ddaemonset.extensions/kube-flannel-ds-ppc64lecreateddaemonset.ex
tensions/kube-flannel-ds-s390xcreated删除重新部署需要删除原来的Flannel，所以应该在一
开始就把Flannel规划好。再来查看路由：root@k8s-master:~#iprouteshowdefaultvia10.3.1.1devens33onlink10.244.0.0/24devcni0protokernelscopelinksrc10.244.0.110.244.1.0/24via10.3.1.21devens33去往10.244.1.0/24网络的下一跳是10.3.1.21，从本机的物理接口ens33出去。这就是Directrouting。如果两个节点跨网段，则flannel自动降级为VXLAN模式。Flannelhost-gw配置与Directrouting类似，将flannel的configmap对象改为：net-conf.json:|{"Network":"10.244.0.0/16","Backend":{"Type":"host-gw"#修改}}其路由信息显示和Directrouting是相同的。这就是flannel的配置方式。 |
|
