容器编排系统K8s之flannel网络模型

　　前文我们聊到了k8s上webui的安装和相关用户授权，回顾请参考：https://www.cnblogs.com/qiuhom-1874/p/14222930.html；今天我们来聊一聊k8s上的网络相关话题；

　　在说k8s网络之前，我们先来回顾下docker中的网络是怎么实现的，在docker中，容器有4种类型，第一种是closed container类型，这种容器类型，容器内部只有一个lo接口，它无法实现和外部网络通信；第二种是bridged container，这种类型容器就是默认的容器类型，它是通过桥接的形式将容器中的虚拟网卡直接桥接到docker0桥上，让其容器内部的虚拟网卡和docker0桥直接位于同一网络名称空间中，使得容器可以同外部网络通信；第三种容器就是joined container，这种容器是共享式网络容器，所谓共享式网络容器是指在运行一个容器时，直接指定我们要把该容器同那个容器共享为同一网络名称空间，这种网络模型本质上也桥接的一种，不同于bridage contaier的是，joined container它可以共享多个容器的网络名称空间；比如容器a要和容器b通信，容器a就可以直接加入到容器b的网络名称空间中，实现两个容器在同一网络名称空间中；第四种容器是open container，这种容器网络是直接共享宿主机网络名称空间；如下图所示

　　提示：从上述描述不难发现docker中的容器网络模型都是通过桥接的模式实现的不同类别的网络模型；

　　在docker中跨主机容器通信是怎么做的呢？

　　从上面的描述，docker中的容器要想和外部通信，首先要把对应的容器桥接到能够和外部通信的桥上，默认情况docker运行的容器，它会把容器内部的虚拟网卡桥接到docker0桥，对应docker0桥是宿主机上的一个虚拟网桥，它是一个nat桥，它能够和外部网络通信的原因是它借助了宿主机上的iptables规则中的SNAT实现的源地址转换，从而实现和外部网络主机通信；同样的道理如果对应docker0桥上桥接的容器要能够被外部网络所访问，它也需要借助宿主机上的iptables中的DNAT，让其外部网络访问对应宿主机上的ip地址，对应流量通过DNAT将用户请求送达至容器内部进行响应；如下图所示

容器编排系统K8s之flannel网络模型

　　提示：同一宿主机上的容器通信直接可以通过docker0桥直接通信，跨主机容器间通信，必须借助宿主机上的iptables规则，将docker0桥上桥接的容器通过SNAT或DNAT把对应请求路由出去或将外部请求转发到对应容器内部进行响应；

　　k8s上的网络

　　我们知道在k8s上有三种网络，第一种是宿主机网络，这种网络没有列入容器编排的范畴内，是集群管理员自行维护；第二种网络上service网络，service网络也叫cluster网络，该网络本质上不会在任何网卡上存在，它是借助每个节点上的kube-proxy生成的iptables或ipvs规则，主要用来实现对pod访问的负载均衡，也是各服务间访问的网络；第三种网络就是pod网络，pod网络主要用来pod和pod间通信；如下图所示

容器编排系统K8s之flannel网络模型

　　提示：在k8s上pod和pod通信，它不是靠iptables中的SANT或DNAT实现的，它也不走docker0桥，而是借助外部网络插件实现的，对于k8s的网络插件来说，实现的软件有很多，最为著名的有flannel或calico这两种；这两种插件都能实现pod与pod间通信不依赖iptables中的SNAT或DANT；不同的是flannel不支持网络策略，对应calico支持网络策略；

　　flannel是怎么实现的pod与pod间通信的呢？

　　我们知道在k8s上pod的ip地址，取决于我们使用的网络插件，使用flannel网络插件我们在初始化集群时就要指定对应的pod网络（10.244.0.0/16），如果使用calico网络插件，初始化集群我们要指定pod网络为192.168.0.0/16；我们指定对应的pod网络地址，使用对应的插件，k8s集群就能正常工作，这其中的原因是默认flannel网络插件使用的地址就是10.244.0.0/16的地址，calico使用的192.168.0.0/16；当然这个默认的配置我们是可以更改的；以flannel为例，它是怎么实现pod和pod直接通信的呢？我们知道在docker环境中跨节点通信，两个容器的地址可能是相同的地址，为此跨节点容器通信就必须借助SNAT或DNAT方式进行通信；对于在k8s上网络插件要想实现pod和pod直接通信，首先要解决podip和podip不能互相冲突；对于flannel这个网络插件来说，它解决pod地址冲突是依赖网络虚拟化中的vxlan机制实现的；vxlan能够将10.244.0.0/16这个网络划分为多个子网，每个节点的pod使用对应节点上的子网地址，这样一来不同节点上的podip就一定不会发生两个podip地址相同的情况；比如vxlan把10.244.0.0/16的网络划分为256个子网，第一个节点上运行的pod就是用10.244.0.0/24这个子网中的地址，第二个节点上的pod就使用10.244.1.0/24子网中的地址；第三个节点，第四个节点依次类推；IP地址冲突问题解决，pod和pod怎么直接通信呢？方案一：按照docker网络中的思想，我们可以将容器内部的虚拟网卡直接桥接到宿主机上的网卡上，这样一来对应每个pod就可以通过宿主机网卡来实现通信；但是这种方式有一个缺点，如果对应pod增多，对于宿主机网络中的arp广播报文可能因为数量多而导致arp泛洪；从而导致网络拥塞而不可用；为此我们需要借助其他机制来解决；比如把每个节点的子网划分一个vlan，节点与节点通信，通过vlan去交换数据；这样一来我们就需要手动去管理vlan，很显然这种方式不是我们想要的方式；方式二：我们不把容器的虚拟网卡桥接到宿主机网卡上，而是把它桥接的一个虚拟的网桥上；然后把宿主机和宿主机通过某种机制打通一个隧道，然后生成对应的路由信息，这样一来在同一节点上的pod通信直接通过虚拟网桥通信即可；如果要和其他节点上的pod通信对应报文会通路由信息把对应虚拟网桥上的流量发送到隧道接口，进行隧道协议报文的封装，然后把封装好的报文通过自己所在节点上的物理网卡发送出去，对应主机收到此报文后，通过层层解封装，最后到达对应pod内部，从而实现pod和pod直接通信；对此pod是无所感知的，因为最终到达pod的报文一定是源ip和目标ip都是对应的podip；那么问题来了，对应接口怎么知道是对端虚拟网桥的ip地址呢？它怎么知道对应报文该发往那个主机呢？这个就跟我们使用的网络插件有关系了；在flannel网络插件中，对应的网络信息是存储在一个存储系统中的，比如使用etcd存储；在k8s上安装好flannel插件以后，对应的它会在每个宿主机上运行一个守护进程，并且在每个节点上创建一个cni0的接口，这个接口就是我们上面说的虚拟网桥；除了这个网桥，它还会创建一个flannel.1的接口，这个接口就是隧道接口；随后flannel会借助vxlan把10.244.0.0/16这个网络进行子网划分，并把对应划分的子网信息同对应节点上的物理网卡上的ip地址，mac地址，进行一一对应；比如节点1的子网为10.244.0.0/24，对应物理网卡上的ip地址为192.168.0.41，mac地址xxx；把节点2的子网信息以及对应节点ip地址，mac地址等信息一一对应起来，并把这些信息保存在etcd中；当节点1上的pod需要和节点2上的pod通信时，此时vxlan控制器会到etcd中检索对应的信息，然后封装报文；其实说这么多就一句话，在k8s上flannel网络插件是通过vxlan机制，实现对每个节点上pod网络进行子网划分解决了podip地址冲突问题，同时也基于vxlan机制实现节点与节点间的隧道通信；从而实现k8s上的pod与pod间可以直接通信；如下图所示

容器编排系统K8s之flannel网络模型

　　k8s上借助flannel网络插件，实现跨节点pod通信报文走向示意图

容器编排系统K8s之flannel网络模型

　　提示：简单讲vxlan就是借助物理网卡来承载pod网络，而实现的二层隧道；从而各pod可以直接使用该隧道通信，中间无需做任何nat转换；其实vxlan这种技术运用还是很广泛的，比如openstack中的自服务网络，docker swarm中的容器和容器间通信；

　　测试：在k8s上运行pod，然后在pod内部ping跨节点pod，看看他们之间具体是怎么通信过程

[root@master01 ~]# kubectl get pods -o wide

NAME                         READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES

myapp-dep-5bc4d8cc74-2kjf5   1/1     Running   0          20h   10.244.2.9   node02.k8s.org   <none>           <none>

myapp-dep-5bc4d8cc74-5k8rc   1/1     Running   0          20h   10.244.1.3   node01.k8s.org   <none>           <none>

myapp-dep-5bc4d8cc74-w6gdz   1/1     Running   0          20h   10.244.3.9   node03.k8s.org   <none>           <none>

[root@master01 ~]#

　　提示：以上k8s上在default名称空间中跑了3个pod，分别被调度到3个节点之上，各自运行了一个pod；

　　进入其中一个pod，在其内部ping另外一个pod

[root@master01 ~]# kubectl get pods -o wide

NAME                         READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES

myapp-dep-5bc4d8cc74-2kjf5   1/1     Running   0          20h   10.244.2.9   node02.k8s.org   <none>           <none>

myapp-dep-5bc4d8cc74-5k8rc   1/1     Running   0          20h   10.244.1.3   node01.k8s.org   <none>           <none>

myapp-dep-5bc4d8cc74-w6gdz   1/1     Running   0          20h   10.244.3.9   node03.k8s.org   <none>           <none>

[root@master01 ~]# kubectl exec -it myapp-dep-5bc4d8cc74-2kjf5 -- /bin/sh

/ # ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

3: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP

    link/ether 5a:2a:ca:ec:83:65 brd ff:ff:ff:ff:ff:ff

    inet 10.244.2.9/24 brd 10.244.2.255 scope global eth0

       valid_lft forever preferred_lft forever

/ # ping 10.244.1.3

PING 10.244.1.3 (10.244.1.3): 56 data bytes

64 bytes from 10.244.1.3: seq=0 ttl=62 time=9.944 ms

64 bytes from 10.244.1.3: seq=1 ttl=62 time=1.974 ms

64 bytes from 10.244.1.3: seq=2 ttl=62 time=2.115 ms

　　登录到node01节点，查看网络接口

[root@node01 ~]# ip a l

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000

    link/ether 00:0c:29:01:21:41 brd ff:ff:ff:ff:ff:ff

    inet 172.16.11.4/24 brd 172.16.11.255 scope global eth0

       valid_lft forever preferred_lft forever

    inet6 fe80::20c:29ff:fe01:2141/64 scope link

       valid_lft forever preferred_lft forever

3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN

    link/ether 02:42:e1:a6:d7:1a brd ff:ff:ff:ff:ff:ff

    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

       valid_lft forever preferred_lft forever

4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN

    link/ether 76:12:1a:11:62:86 brd ff:ff:ff:ff:ff:ff

    inet 10.244.1.0/32 brd 10.244.1.0 scope global flannel.1

       valid_lft forever preferred_lft forever

    inet6 fe80::7412:1aff:fe11:6286/64 scope link

       valid_lft forever preferred_lft forever

5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP qlen 1000

    link/ether 52:6f:30:31:77:86 brd ff:ff:ff:ff:ff:ff

    inet 10.244.1.1/24 brd 10.244.1.255 scope global cni0

       valid_lft forever preferred_lft forever

    inet6 fe80::506f:30ff:fe31:7786/64 scope link

       valid_lft forever preferred_lft forever

7: vethce8e4bf2@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP

    link/ether 9a:22:8e:d7:78:33 brd ff:ff:ff:ff:ff:ff link-netnsid 0

    inet6 fe80::9822:8eff:fed7:7833/64 scope link

       valid_lft forever preferred_lft forever

[root@node01 ~]#

　　提示：可以看到对应节点有cni0接口，也有flannel.1接口；

　　在node01节点上抓cni0上的包

[root@node01 ~]# tcpdump -i cni0 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes

18:55:18.469861 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 225, length 64

18:55:18.470073 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 225, length 64

18:55:19.471439 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 226, length 64

18:55:19.471575 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 226, length 64

18:55:20.472470 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 227, length 64

18:55:20.472608 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 227, length 64

18:55:21.473084 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 228, length 64

18:55:21.473223 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 228, length 64

18:55:22.474856 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 229, length 64

18:55:22.474922 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 229, length 64

18:55:23.475499 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 230, length 64

18:55:23.475685 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 230, length 64

18:55:24.476694 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 231, length 64

18:55:24.476854 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 231, length 64

^C

14 packets captured

14 packets received by filter

0 packets dropped by kernel

[root@node01 ~]#

　　提示：可以看到在cni0上能够看到10.244.2.9在ping10.244.1.3；说明pod和pod通信首先会通过cni0这个接口；

　　在node01上抓flainnel.1接口上的icmp包

[root@node01 ~]# tcpdump -i flannel.1 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes

18:57:03.607093 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 330, length 64

18:57:03.607273 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 330, length 64

18:57:04.607604 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 331, length 64

18:57:04.607819 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 331, length 64

18:57:05.608172 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 332, length 64

18:57:05.608369 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 332, length 64

18:57:06.609825 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 333, length 64

18:57:06.610106 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 333, length 64

18:57:07.610310 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 334, length 64

18:57:07.612417 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 334, length 64

^C

10 packets captured

10 packets received by filter

0 packets dropped by kernel

[root@node01 ~]#

　　提示：在node01上的flannel.1接口上抓icmp包，能够正常看到10.244.2.9在ping10.244.1.3；说明对应报文来到了flannel.1接口；

　　在node01上的物理接口上抓icmp包，看看是否能抓到对应的icmp包呢？

[root@node01 ~]# tcpdump -i eth0 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

　　提示：可以看到在node01上的物理接口上抓icmp类型的包，一个都没有抓到，其原因是对应报文通过隧道接口封装后，在物理接口上不是icmp类型的包了；

　　在node01的物理接口上抓node02的ip地址的包，看看会抓到什么？

[root@node01 ~]# tcpdump -i eth0 -nn host 172.16.11.5

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

19:02:36.139552 IP 172.16.11.5.46521 > 172.16.11.4.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 662, length 64

19:02:36.139935 IP 172.16.11.4.57232 > 172.16.11.5.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 662, length 64

19:02:37.143339 IP 172.16.11.5.46521 > 172.16.11.4.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 663, length 64

19:02:37.143587 IP 172.16.11.4.57232 > 172.16.11.5.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 663, length 64

19:02:38.144569 IP 172.16.11.5.46521 > 172.16.11.4.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 664, length 64

19:02:38.145276 IP 172.16.11.4.57232 > 172.16.11.5.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 664, length 64

19:02:39.144889 IP 172.16.11.5.46521 > 172.16.11.4.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 665, length 64

19:02:39.145126 IP 172.16.11.4.57232 > 172.16.11.5.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 665, length 64

19:02:40.145727 IP 172.16.11.5.46521 > 172.16.11.4.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 13568, seq 666, length 64

19:02:40.145976 IP 172.16.11.4.57232 > 172.16.11.5.8472: OTV, flags [I] (0x08), overlay 0, instance 1

IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 13568, seq 666, length 64

^C

10 packets captured

10 packets received by filter

0 packets dropped by kernel

[root@node01 ~]#

　　提示：从上面的抓包信息可以看到，在node01节点物理接口上收到来自node02物理节点上的包，外层是两个节点ip地址通信，里面承载了对应的podip；通过上述验证，可以发现在k8s上pod和pod通信，的确没有做任何nat，而是借助vxlan隧道实现的pod和pod直接通信；

　　更改flannel工作为直接路由模式，使pod与pod网络通信不经由flannel.1接口，直接将流量发送给物理接口

容器编排系统K8s之flannel网络模型

　　提示：在flannel的配置文件中的backend配置段中，加上“DirectRouting”： true配置信息，这里需要注意加了此配置，上面的type后面要有逗号分隔；修改完成以后，保存退出即可；

　　删除原有的flannel pod，让其自动重新新建flannel pod，应用新配置

　　删除前查看节点的路由信息

[root@master01 ~]# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         172.16.11.2     0.0.0.0         UG    0      0        0 eth0

0.0.0.0         172.16.11.2     0.0.0.0         UG    100    0        0 eth0

10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0

10.244.1.0      10.244.1.0      255.255.255.0   UG    0      0        0 flannel.1

10.244.2.0      10.244.2.0      255.255.255.0   UG    0      0        0 flannel.1

10.244.3.0      10.244.3.0      255.255.255.0   UG    0      0        0 flannel.1

169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

172.16.11.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

[root@master01 ~]#

　　提示：可以看到删除原有flannel pod前，对应节点路由信息中，对应10.244.1.0/24、10.244.2.0/24和3.0/24的网络都是指向flannel.1这个接口；

　　删除原有的flannel pod

[root@master01 ~]# kubectl get pods -n kube-system --show-labels

NAME                                       READY   STATUS    RESTARTS   AGE   LABELS

coredns-7f89b7bc75-9s8wr                   1/1     Running   0          11d   k8s-app=kube-dns,pod-template-hash=7f89b7bc75

coredns-7f89b7bc75-ck8gl                   1/1     Running   0          11d   k8s-app=kube-dns,pod-template-hash=7f89b7bc75

etcd-master01.k8s.org                      1/1     Running   1          11d   component=etcd,tier=control-plane

kube-apiserver-master01.k8s.org            1/1     Running   1          11d   component=kube-apiserver,tier=control-plane

kube-controller-manager-master01.k8s.org   1/1     Running   3          11d   component=kube-controller-manager,tier=control-plane

kube-flannel-ds-2z7sk                      1/1     Running   2          11d   app=flannel,controller-revision-hash=64465d999,pod-template-generation=1,tier=node

kube-flannel-ds-57fng                      1/1     Running   0          11d   app=flannel,controller-revision-hash=64465d999,pod-template-generation=1,tier=node

kube-flannel-ds-vt2jv                      1/1     Running   0          11d   app=flannel,controller-revision-hash=64465d999,pod-template-generation=1,tier=node

kube-flannel-ds-wk52c                      1/1     Running   2          11d   app=flannel,controller-revision-hash=64465d999,pod-template-generation=1,tier=node

kube-proxy-2hcd9                           1/1     Running   0          11d   controller-revision-hash=c449f5b75,k8s-app=kube-proxy,pod-template-generation=1

kube-proxy-m9s45                           1/1     Running   0          11d   controller-revision-hash=c449f5b75,k8s-app=kube-proxy,pod-template-generation=1

kube-proxy-mh9nx                           1/1     Running   0          11d   controller-revision-hash=c449f5b75,k8s-app=kube-proxy,pod-template-generation=1

kube-proxy-t57x8                           1/1     Running   0          11d   controller-revision-hash=c449f5b75,k8s-app=kube-proxy,pod-template-generation=1

kube-scheduler-master01.k8s.org            1/1     Running   3          11d   component=kube-scheduler,tier=control-plane

[root@master01 ~]# kubectl delete pod -l app=flannel -n kube-system

pod "kube-flannel-ds-2z7sk" deleted

pod "kube-flannel-ds-57fng" deleted

pod "kube-flannel-ds-vt2jv" deleted

pod "kube-flannel-ds-wk52c" deleted

[root@master01 ~]# kubectl get pods -n kube-system

NAME                                       READY   STATUS    RESTARTS   AGE

coredns-7f89b7bc75-9s8wr                   1/1     Running   0          11d

coredns-7f89b7bc75-ck8gl                   1/1     Running   0          11d

etcd-master01.k8s.org                      1/1     Running   1          11d

kube-apiserver-master01.k8s.org            1/1     Running   1          11d

kube-controller-manager-master01.k8s.org   1/1     Running   3          11d

kube-flannel-ds-9ww8d                      1/1     Running   0          39s

kube-flannel-ds-gd45l                      1/1     Running   0          79s

kube-flannel-ds-ps6c5                      1/1     Running   0          27s

kube-flannel-ds-x642z                      1/1     Running   0          70s

kube-proxy-2hcd9                           1/1     Running   0          11d

kube-proxy-m9s45                           1/1     Running   0          11d

kube-proxy-mh9nx                           1/1     Running   0          11d

kube-proxy-t57x8                           1/1     Running   0          11d

kube-scheduler-master01.k8s.org            1/1     Running   3          11d

[root@master01 ~]# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         172.16.11.2     0.0.0.0         UG    0      0        0 eth0

0.0.0.0         172.16.11.2     0.0.0.0         UG    100    0        0 eth0

10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0

10.244.1.0      172.16.11.4     255.255.255.0   UG    0      0        0 eth0

10.244.2.0      172.16.11.5     255.255.255.0   UG    0      0        0 eth0

10.244.3.0      172.16.11.6     255.255.255.0   UG    0      0        0 eth0

169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

172.16.11.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

[root@master01 ~]#

　　提示：可以看到，新建flannel pod后对应的路由信息就发生变了；现在就没有任何路由会通过flannel.1接口；

　　验证：进入一个pod内部ping 另一个pod ip，看看对应报文走向

容器编排系统K8s之flannel网络模型

　　在节点1抓包

[root@node01 ~]# tcpdump -i cni0 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on cni0, link-type EN10MB (Ethernet), capture size 262144 bytes

19:45:55.693118 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 32, length 64

19:45:55.693285 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 32, length 64

19:45:56.693771 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 33, length 64

19:45:56.693941 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 33, length 64

19:45:57.695549 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 34, length 64

19:45:57.695905 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 34, length 64

19:45:58.696517 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 35, length 64

19:45:58.697035 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 35, length 64

^C

8 packets captured

8 packets received by filter

0 packets dropped by kernel

[root@node01 ~]# tcpdump -i flannel.1 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on flannel.1, link-type EN10MB (Ethernet), capture size 262144 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

[root@node01 ~]# tcpdump -i eth0 -nn icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

19:46:24.737002 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 61, length 64

19:46:24.737350 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 61, length 64

19:46:25.737664 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 62, length 64

19:46:25.737987 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 62, length 64

19:46:26.739459 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 63, length 64

19:46:26.739705 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 63, length 64

19:46:27.739800 IP 10.244.2.9 > 10.244.1.3: ICMP echo request, id 18944, seq 64, length 64

19:46:27.740026 IP 10.244.1.3 > 10.244.2.9: ICMP echo reply, id 18944, seq 64, length 64

^C

8 packets captured

8 packets received by filter

0 packets dropped by kernel

[root@node01 ~]#

　　提示：可以看到在node01的flannel.1接口上就抓不到icmp类型的包，在对应物理接口上能够抓到icmp类型的包，并且从抓包信息中也能看到对应是10.244.2.9在ping 10.244.1.3；

容器编排系统K8s之flannel网络模型的更多相关文章

容器编排系统K8s之ConfigMap、Secret资源
前文我们了解了k8s上的pv/pvc/sc资源的使用和相关说明,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14188621.html:今天我们主要来聊一下 ...
容器编排系统K8s之NetworkPolicy资源
前文我们了解了k8s的网络插件flannel的基础工作逻辑,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14225657.html:今天我们来聊一下k8s上 ...
容器编排系统k8s之Service资源
前文我们了解了k8s上的DemonSet.Job和CronJob控制器的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14157306.html:今 ...
容器编排系统K8s之Volume的基础使用
前文我们聊到了k8s上的ingress资源相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14167581.html:今天们来聊一下k8s上volum ...
容器编排系统K8s之访问控制--用户认证
前文我们聊到了k8s的statefulset控制器相关使用说明,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14201103.html:今天我们来聊一下k8 ...
容器编排系统K8s之访问控制--RBAC授权
前文我们了解了k8s上的访问控制机制,主要对访问控制中的第一关用户认证做了相关说明以及常规用户的配置文件的制作,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/ ...
容器编排系统K8s之访问控制--准入控制
前文我们聊到了k8s的访问控制第二关RBAC授权插件的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14216634.html:今天我们来聊一下k8 ...
容器编排系统K8s之Prometheus监控系统+Grafana部署
前文我们聊到了k8s的apiservice资源结合自定义apiserver扩展原生apiserver功能的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/ ...
容器编排系统k8s之Ingress资源
前文我们了解了k8s上的service资源的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14161950.html:今天我们来了解下k8s上的In ...

随机推荐

教你分分钟学会用python爬虫框架Scrapy爬取心目中的女神
本博文将带领你从入门到精通爬虫框架Scrapy,最终具备爬取任何网页的数据的能力.本文以校花网为例进行爬取,校花网:http://www.xiaohuar.com/,让你体验爬取校花的成就感. Scr ...
【主席树】【bzoj2161】[hdu4348]
#include<cstdio> #include<algorithm> #include<cstring> #define N 400000 using name ...
jquery - 通过点击切换文字内容
今天要写一个简单的显示/隐藏效果,本以为是挺简单的事儿,没想到还真因为基本功不扎实遇到了问题,这里跟大家分享一下. 百度了很多方法,精简能用的干货实在太少,最后还是通过去查jq的官方api才找到了解决 ...
比较好的自学IT的网站
其实这是我在知乎的一个回答,由于收藏人数众多,我想也许对有些初学者有用,故同步到Blog.此文章和知乎答案将不定期同步更新(知乎答案传送门). 入门与进阶: 学堂在线-最大的中文慕课(MOOC)平台学 ...
nginx和apache的特点优点和使用场景
Apache Apache是世界使用排名第一的Web服务器软件.它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的Web服务器端软件之一. Apache源于 ...
CDialog类中OnCancel()、OnInitDialog（）作用
1.void CCOMDDlg::OnCancel() { // TODO: Add extra cleanup here CDialog::OnCancel();} 如果把CDialog::OnCa ...
poj 2762 Going from u to v or from v to u&quest; (推断它是否是一个薄弱环节图)
意甲冠军:给定一个有向图有m单向边缘.免费推断是否两点起来(a可以b要么b可以a或最多彼此),该请求弱联通重量. 算法: 缩点求强连通分量.然后又一次建图.推断新图是否是一条单链,即不能分叉,假设分 ...
python demo整理
1 变量作用域 #!/usr/bin/python # coding=utf-8 name = "whole global name" class Person: name = & ...
从零开始制作 Hexo 主题
原文地址:从零开始制作 Hexo 主题 · Ahonn 写在前面本文将会从零开始开发一个简单的博客主题.样式主要参考 Hexo theme 中的 Noise 主题. 开始之前你需要了解: 模板引擎 ...
Python统计词频的几种方式
语料 text = """My fellow citizens: I stand here today humbled by the task before us, gr ...