主頁 > 作業系統 > 容器編排系統K8s之flannel網路模型

容器編排系統K8s之flannel網路模型

2021-01-04 06:05:09 作業系統

　　前文我們聊到了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將用戶請求送達至容器內部進行回應；如下圖所示

　　提示：同一宿主機上的容器通信直接可以通過docker0橋直接通信，跨主機容器間通信，必須借助宿主機上的iptables規則，將docker0橋上橋接的容器通過SNAT或DNAT把對應請求路由出去或將外部請求轉發到對應容器內部進行回應；

　　k8s上的網路

　　我們知道在k8s上有三種網路，第一種是宿主機網路，這種網路沒有列入容器編排的范疇內，是集群管理員自行維護；第二種網路上service網路，service網路也叫cluster網路，該網路本質上不會在任何網卡上存在，它是借助每個節點上的kube-proxy生成的iptables或ipvs規則，主要用來實作對pod訪問的負載均衡，也是各服務間訪問的網路；第三種網路就是pod網路，pod網路主要用來pod和pod間通信；如下圖所示

　　提示：在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網路插件，實作跨節點pod通信報文走向示意圖

 

　　提示：簡單講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介面，直接將流量發送給物理介面

　　提示：在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，看看對應報文走向

　　在節點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；

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/244108.html

標籤：其他

上一篇：Netplan on Ubuntu 用于網路管理

下一篇：systemd-resolved and resolvctl on ubuntu; 127.0.0.53 nameserver;

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • CA和證書

    1、在 CentOS7 中使用 gpg 創建 RSA 非對稱密鑰對 gpg --gen-key #Centos上生成公鑰/密鑰對（存放在家目錄.gnupg/） 2、將 CentOS7 匯出的公鑰，拷貝到 CentOS8 中，在 CentOS8 中使用 CentOS7 的公鑰加密一個檔案 gpg -a ......

    uj5u.com 2020-09-10 00:09:53 more
  • Kubernetes K8S之資源控制器Job和CronJob詳解

    Kubernetes的資源控制器Job和CronJob詳解與示例 ......

    uj5u.com 2020-09-10 00:10:45 more
  • VMware下安裝CentOS

    VMware下安裝CentOS 一、軟硬體準備 1 Centos鏡像準備 1.1 CentOS鏡像下載地址 下載地址 1.2 CentOS鏡像下載程序 點擊下載地址進入如下圖的網站，選擇需要下載的版本，這里選擇的是Centos8，點擊如圖所示。 決定選擇Centos8后，選擇想要的鏡像源進行下載，此 ......

    uj5u.com 2020-09-10 00:12:10 more
  • 如何使用Grep命令查找多個字串

    如何使用Grep 命令查找多個字串 大家好，我是良許！ 今天向大家介紹一個非常有用的技巧，那就是使用 grep 命令查找多個字串。 簡單介紹一下，grep 命令可以理解為是一個功能強大的命令列工具，可以用它在一個或多個輸入檔案中搜索與正則運算式相匹配的文本，然后再將每個匹配的文本用標準輸出的格式 ......

    uj5u.com 2020-09-10 00:12:28 more
  • git配置http代理

    git配置http代理 經常遇到克隆 github 慢的問題，這里記錄一下幾種配置 git 代理的方法，解決 clone github 過慢。 目錄 git配置代理 git單獨配置github代理 git配置全域代理 配置終端環境變數 git配置代理 主要使用 git config 命令 git單獨 ......

    uj5u.com 2020-09-10 00:12:33 more
  • Linux npm install 裝包時提示Error EACCES permission denied解

    npm install 裝包時提示Error EACCES permission denied解決辦法 ......

    uj5u.com 2020-09-10 00:12:53 more
  • Centos 7下安裝nginx，使用yum install nginx，提示沒有可用的軟體包

    Centos 7下安裝nginx，使用yum install nginx，提示沒有可用的軟體包。 18 (flaskApi) [root@67 flaskDemo]# yum -y install nginx 19 已加載插件：fastestmirror, langpacks 20 Loading ......

    uj5u.com 2020-09-10 00:13:13 more
  • Linux查看服務器暴力破解ssh IP

    在公網的服務器上經常遇到別人爆破你服務器的22埠，用來挖礦或者干其他嘿嘿嘿的事情~ 這種情況下正確的做法是： 修改默認ssh的22埠 使用設定密鑰登錄或者白名單ip登錄 建議服務器密碼為復雜密碼 創建普通用戶登錄服務器（root權限過大） 建立堡壘機，實作統一管理服務器 統計爆破IP [root ......

    uj5u.com 2020-09-10 00:13:17 more
  • CentOS 7系統常見快捷鍵操作方式

    Linux系統中一些常見的快捷方式，可有效提高操作效率，在某些時刻也能避免操作失誤帶來的問題。 ......

    uj5u.com 2020-09-10 00:13:31 more
  • CentOS 7作業系統目錄結構介紹

    作業系統存在著大量的資料檔案資訊，相應檔案資訊會存在于系統相應目錄中，為了更好的管理資料資訊，會將系統進行一些目錄規劃，不同目錄存放不同的資源。 ......

    uj5u.com 2020-09-10 00:13:35 more
最新发布
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中，用的編輯器命令，比如移動游標，洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反（大多數編輯器默認模式為插入模式）。 2. 插入模式在這個模式中，大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:43:21 more
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中，用的編輯器命令，比如移動游標，洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反（大多數編輯器默認模式為插入模式）。 2. 插入模式在這個模式中，大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:42:36 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜，傳統發布專案一個只需要一個jar包，運行環境需要單獨部署。而通過Docker可將jar包和相關環境（如jdk，redis，Hadoop...）等打包到docker鏡像里，將鏡像發布到Docker倉庫，部署時下載發布的鏡像，直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:26:53 more
  • 設定Windows主機的瀏覽器為wls2的默認瀏覽器

    這里以Chrome為例。 1. 準備作業 wsl是可以使用Windows主機上安裝的exe程式，出于安全考慮，默認情況下改功能是無法使用。要使用的話，終端需要以管理員權限啟動。 我這里以Windows Terminal為例，介紹如何默認使用管理員權限打開終端，具體操作如下圖所示： 2. 操作 wsl ......

    uj5u.com 2023-04-19 09:25:49 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜，傳統發布專案一個只需要一個jar包，運行環境需要單獨部署。而通過Docker可將jar包和相關環境（如jdk，redis，Hadoop...）等打包到docker鏡像里，將鏡像發布到Docker倉庫，部署時下載發布的鏡像，直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:19:04 more
  • Linux學習筆記

    IP地址和主機名 IP地址 ifconfig可以用來查詢本機的IP地址，如果不能使用，可以通過install net-tools安裝。 Centos系統下ens33表示主網卡；inet后表示IP地址；lo表示本地回環網卡； 127.0.0.1表示代指本機；0.0.0.0可以用于代指本機，同時在放行設 ......

    uj5u.com 2023-04-18 06:52:01 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題：專案麒麟系統服務器的kdump服務無法啟動，沒有相關日志無法定位問題。 1、查看服務狀態是關閉的，重啟系統也無法啟動 systemctl status kdump 2、修改grub引數，修改“crashkernel”為“512M（有的機器數值太大太小都會導致報錯，建議從128M開始試，或者加個 ......

    uj5u.com 2023-04-12 09:59:50 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題：專案麒麟系統服務器的kdump服務無法啟動，沒有相關日志無法定位問題。 1、查看服務狀態是關閉的，重啟系統也無法啟動 systemctl status kdump 2、修改grub引數，修改“crashkernel”為“512M（有的機器數值太大太小都會導致報錯，建議從128M開始試，或者加個 ......

    uj5u.com 2023-04-12 09:59:01 more
  • 你是不是暴露了？

    作者：袁首京 原創文章，轉載時請保留此宣告，并給出原文連接。 如果您是計算機相關從業人員，那么應該經歷不止一次網路安全專項檢查了，你肯定是收到過資訊系統技術檢測報告，要求你加強風險監測，確保你提供的系統服務堅實可靠了。 沒檢測到問題還好，檢測到問題的話，有些處理起來還是挺麻煩的，尤其是線上正在運行的 ......

    uj5u.com 2023-04-05 16:52:56 more
  • 細節拉滿，80 張圖帶你一步一步推演 slab 記憶體池的設計與實作

    1. 前文回顧 在之前的幾篇記憶體管理系列文章中，筆者帶大家從宏觀角度完整地梳理了一遍 Linux 記憶體分配的整個鏈路，本文的主題依然是記憶體分配，這一次我們會從微觀的角度來探秘一下 Linux 內核中用于零散小記憶體塊分配的記憶體池 —— slab 分配器。 在本小節中，筆者還是按照以往的風格先帶大家簡單 ......

    uj5u.com 2023-04-05 16:44:11 more

Copyright © 2010-2020 有解無憂