成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

一文明白calico的IPIP網絡模式

作者：小姜
網絡 網絡管理
本文主要分析k8s中網絡組件calico的 IPIP網絡模式。旨在理解IPIP網絡模式下產生的calixxxx，tunl0等設備以及跨節(jié)點網絡通信方式。

[[397426]]

前言

本文主要分析k8s中網絡組件calico的 IPIP網絡模式。旨在理解IPIP網絡模式下產生的calixxxx，tunl0等設備以及跨節(jié)點網絡通信方式。可能看著有點枯燥，但是請花幾分鐘時間堅持看完，如果看到后面忘了前面，請反復看兩遍，這幾分鐘時間一定你會花的很值。

一、calico介紹

Calico是Kubernetes生態(tài)系統(tǒng)中另一種流行的網絡選擇。雖然Flannel被公認為是最簡單的選擇，但Calico以其性能、靈活性而聞名。Calico的功能更為全面，不僅提供主機和pod之間的網絡連接，還涉及網絡安全和管理。Calico CNI插件在CNI框架內封裝了Calico的功能。

Calico是一個基于BGP的純三層的網絡方案，與OpenStack、Kubernetes、AWS、GCE等云平臺都能夠良好地集成。Calico在每個計算節(jié)點都利用Linux Kernel實現(xiàn)了一個高效的虛擬路由器vRouter來負責數據轉發(fā)。每個vRouter都通過BGP1協(xié)議把在本節(jié)點上運行的容器的路由信息向整個Calico網絡廣播，并自動設置到達其他節(jié)點的路由轉發(fā)規(guī)則。Calico保證所有容器之間的數據流量都是通過IP路由的方式完成互聯(lián)互通的。Calico節(jié)點組網時可以直接利用數據中心的網絡結構(L2或者L3)，不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節(jié)約CPU運算，提高網絡效率。

此外，Calico基于iptables還提供了豐富的網絡策略，實現(xiàn)了Kubernetes的Network Policy策略，提供容器間網絡可達性限制的功能。

calico官網：https://www.projectcalico.org/

二、calico架構及核心組件

架構圖如下：

calico核心組件：

  • Felix：運行在每個需要運行workload的節(jié)點上的agent進程。主要負責配置路由及 ACLs(訪問控制列表) 等信息來確保 endpoint 的連通狀態(tài)，保證跨主機容器的網絡互通;
  • etcd：強一致性、高可用的鍵值存儲，持久存儲calico數據的存儲管理系統(tǒng)。主要負責網絡元數據一致性，確保Calico網絡狀態(tài)的準確性;
  • BGP Client(BIRD)：讀取Felix設置的內核路由狀態(tài)，在數據中心分發(fā)狀態(tài)。
  • BGP Route Reflector(BIRD)：BGP路由反射器，在較大規(guī)模部署時使用。如果僅使用BGP Client形成mesh全網互聯(lián)就會導致規(guī)模限制，因為所有BGP client節(jié)點之間兩兩互聯(lián)，需要建立N^2個連接，拓撲也會變得復雜。因此使用reflector來負責client之間的連接，防止節(jié)點兩兩相連。

三、calico工作原理

Calico把每個操作系統(tǒng)的協(xié)議棧認為是一個路由器，然后把所有的容器認為是連在這個路由器上的網絡終端，在路由器之間跑標準的路由協(xié)議——BGP的協(xié)議，然后讓它們自己去學習這個網絡拓撲該如何轉發(fā)。所以Calico方案其實是一個純三層的方案，也就是說讓每臺機器的協(xié)議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。

四、calico的兩種網絡方式

1)IPIP

把 IP 層封裝到 IP 層的一個 tunnel。它的作用其實基本上就相當于一個基于IP層的網橋!一般來說，普通的網橋是基于mac層的，根本不需 IP，而這個 ipip 則是通過兩端的路由做一個 tunnel，把兩個本來不通的網絡通過點對點連接起來。ipip 的源代碼在內核 net/ipv4/ipip.c 中可以找到。

2)BGP

邊界網關協(xié)議(Border Gateway Protocol, BGP)是互聯(lián)網上一個核心的去中心化自治路由協(xié)議。它通過維護IP路由表或‘前綴’表來實現(xiàn)自治系統(tǒng)(AS)之間的可達性，屬于矢量路由協(xié)議。BGP不使用傳統(tǒng)的內部網關協(xié)議(IGP)的指標，而使用基于路徑、網絡策略或規(guī)則集來決定路由。因此，它更適合被稱為矢量性協(xié)議，而不是路由協(xié)議。

五、IPIP網絡模式分析

由于個人環(huán)境中使用的是IPIP模式，因此接下來這里分析一下這種模式。

  1. # kubectl get po -o wide -n paas | grep hello 
  2. demo-hello-perf-d84bffcb8-7fxqj   1/1     Running   0          9d      10.20.105.215   node2.perf  <none>           <none> 
  3. demo-hello-sit-6d5c9f44bc-ncpql   1/1     Running   0          9d      10.20.42.31     node1.sit   <none>           <none> 

進行ping測試

這里在demo-hello-perf這個pod中ping demo-hello-sit這個pod。

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# ping 10.20.42.31 
  2. PING 10.20.42.31 (10.20.42.31) 56(84) bytes of data. 
  3. 64 bytes from 10.20.42.31: icmp_seq=1 ttl=62 time=5.60 ms 
  4. 64 bytes from 10.20.42.31: icmp_seq=2 ttl=62 time=1.66 ms 
  5. 64 bytes from 10.20.42.31: icmp_seq=3 ttl=62 time=1.79 ms 
  6. ^C 
  7. --- 10.20.42.31 ping statistics --- 
  8. 3 packets transmitted, 3 received, 0% packet loss, time 6ms 
  9. rtt min/avg/max/mdev = 1.662/3.015/5.595/1.825 ms 

進入pod demo-hello-perf中查看這個pod中的路由信息

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 eth0 
  5. 169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth0 

根據路由信息，ping 10.20.42.31，會匹配到第一條。

第一條路由的意思是：去往任何網段的數據包都發(fā)往網關169.254.1.1，然后從eth0網卡發(fā)送出去。

demo-hello-perf所在的node node2.perf 宿主機上路由信息如下：

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         172.16.36.1     0.0.0.0         UG    100    0        0 eth0 
  5. 10.20.42.0      172.16.35.4     255.255.255.192 UG    0      0        0 tunl0 
  6. 10.20.105.196   0.0.0.0         255.255.255.255 UH    0      0        0 cali4bb1efe70a2 
  7. 169.254.169.254 172.16.36.2     255.255.255.255 UGH   100    0        0 eth0 
  8. 172.16.36.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0 
  9. 172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0 

可以看到一條Destination為 10.20.42.0的路由。

意思是：當ping包來到master節(jié)點上，會匹配到路由tunl0。該路由的意思是：去往10.20.42.0/26的網段的數據包都發(fā)往網關172.16.35.4。因為demo-hello-perf的pod在172.16.36.5上，demo-hello-sit的pod在172.16.35.4上。所以數據包就通過設備tunl0發(fā)往到node節(jié)點上。

demo-hello-sit所在的node node1.sit 宿主機上路由信息如下：

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. 0.0.0.0         172.16.35.1     0.0.0.0         UG    100    0        0 eth0 
  5. 10.20.15.64     172.16.36.4     255.255.255.192 UG    0      0        0 tunl0 
  6. 10.20.42.31     0.0.0.0         255.255.255.255 UH    0      0        0 cali04736ec14ce 
  7. 10.20.105.192   172.16.36.5     255.255.255.192 UG    0      0        0 tunl0 

當node節(jié)點網卡收到數據包之后，發(fā)現(xiàn)發(fā)往的目的ip為10.20.42.31，于是匹配到Destination為10.20.42.31的路由。

該路由的意思是：10.20.42.31是本機直連設備，去往設備的數據包發(fā)往cali04736ec14ce

為什么這么奇怪會有一個名為cali04736ec14ce的設備呢?這是個啥玩意兒呢?

其實這個設備就是veth pair的一端。在創(chuàng)建demo-hello-sit 時calico會給demo-hello-sit創(chuàng)建一個veth pair設備。一端是demo-hello-sit 的網卡，另一端就是我們看到的cali04736ec14ce

接著驗證一下。我們進入demo-hello-sit 的pod，查看到 4 號設備后面的編號是：122964

  1. root@demo-hello-sit--6d5c9f44bc-ncpql:/# ip a 
  2. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 
  3.     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
  4.     inet 127.0.0.1/8 scope host lo 
  5.        valid_lft forever preferred_lft forever 
  6. 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 
  7.     link/ipip 0.0.0.0 brd 0.0.0.0 
  8. 4: eth0@if122964: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  9.     link/ether 9a:7d:b2:26:9b:17 brd ff:ff:ff:ff:ff:ff link-netnsid 0 
  10.     inet 10.20.42.31/32 brd 10.20.42.31 scope global eth0 
  11.        valid_lft forever preferred_lft forever 

然后我們登錄到demo-hello-sit這個pod所在的宿主機查看

  1. # ip a | grep -A 5 "cali04736ec14ce" 
  2. 122964: cali04736ec14ce@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  3.     link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 16 
  4.     inet6 fe80::ecee:eeff:feee:eeee/64 scope link  
  5.        valid_lft forever preferred_lft forever 
  6. 120918: calidd1cafcd275@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1380 qdisc noqueue state UP group default  
  7.     link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 2 

發(fā)現(xiàn)pod demo-hello-sit中 的另一端設備編號和這里在node上看到的cali04736ec14ce編號122964是一樣的

所以，node上的路由，發(fā)送cali04736ec14ce網卡設備的數據其實就是發(fā)送到了demo-hello-sit的這個pod中去了。到這里ping包就到了目的地。

注意看 demo-hello-sit這個pod所在的宿主機的路由，有一條 Destination為10.20.105.192的路由

  1. # route -n 
  2. Kernel IP routing table 
  3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
  4. ... 
  5. 0.0.0.0         172.16.35.1     0.0.0.0         UG    100    0        0 eth0 
  6. 10.20.105.192   172.16.36.5     255.255.255.192 UG    0      0        0 tunl0 
  7. ... 

再查看一下demo-hello-sit的pod中路由信息，和demo-hello-perf的pod中是一樣的。

所以綜合上述例子來看，IPIP的網絡模式就是將IP網絡封裝了一層。特點就是所有pod的數據流量都從隧道tunl0發(fā)送，并且tunl0這里增加了一層傳輸層的封包操作。

六、抓包分析

在demo-hello-perf這個pod中ping demo-hello-sit這個pod，接著在demo-hello-sit這個pod所在的宿主機進行tcpdump

  1. # tcpdump  -i eth0 -nn -w icmp_ping.cap 
  2. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 

在demo-hello-perf這個pod中進行ping demo-hello-sit的操作

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# ping 10.20.42.31 
  2. PING 10.20.42.31 (10.20.42.31) 56(84) bytes of data. 
  3. 64 bytes from 10.20.42.31: icmp_seq=1 ttl=62 time=5.66 ms 
  4. 64 bytes from 10.20.42.31: icmp_seq=2 ttl=62 time=1.68 ms 
  5. 64 bytes from 10.20.42.31: icmp_seq=3 ttl=62 time=1.61 ms 
  6. ^C 
  7. --- 10.20.42.31 ping statistics --- 
  8. 3 packets transmitted, 3 received, 0% packet loss, time 6ms 
  9. rtt min/avg/max/mdev = 1.608/2.983/5.659/1.892 ms 

結束抓包后下載icmp_ping.cap到本地windows進行抓包分析

能看到該數據包一共5層，其中IP(Internet Protocol)所在的網絡層有兩個，分別是pod之間的網絡和主機之間的網絡封裝。

紅色框選的是兩個pod所在的宿主機，藍色框選的是兩個pod的ip，src表示發(fā)起ping操作的pod所在的宿主機ip以及發(fā)起ping操作的pod的ip，dst表示被ping的pod所在的宿主機ip及被ping的pod的ip

根據數據包的封裝順序，應該是在demo-hello-perf ping demo-hello-sit的ICMP包外面多封裝了一層主機之間的數據包。

可以看到每個數據報文共有兩個IP網絡層,內層是Pod容器之間的IP網絡報文,外層是宿主機節(jié)點的網絡報文(2個node節(jié)點)。之所以要這樣做是因為tunl0是一個隧道端點設備，在數據到達時要加上一層封裝，便于發(fā)送到對端隧道設備中。

兩層封包的具體內容如下：

Pod間的通信經由IPIP的三層隧道轉發(fā),相比較VxLAN的二層隧道來說，IPIP隧道的開銷較小，但其安全性也更差一些。

七、pod到svc的訪問

查看service

  1. # kubectl get svc -o wide -n paas | grep hello 
  2. demo-hello-perf              ClusterIP   10.10.255.18    <none>        8080/TCP              10d    appEnv=perf,appName=demo-hello 
  3. demo-hello-sit               ClusterIP   10.10.48.254    <none>        8080/TCP              10d    appEnv=sit,appName=demo-hello 

在pod demo-hello-sit 的宿主機上抓包

  1. # tcpdump -i eth0 -nn -w svc.cap 
  2. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 

測試訪問，在demo-hello-sit中curl demo-hello-perf的svc的地址和端口

  1. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  2. HTTP/1.1 200 
  3. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  4. Transfer-Encoding: chunked 
  5. Date: Fri, 30 Apr 2021 01:42:56 GMT 
  6.  
  7. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  8. HTTP/1.1 200 
  9. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  10. Transfer-Encoding: chunked 
  11. Date: Fri, 30 Apr 2021 01:42:58 GMT 
  12.  
  13. root@demo-hello-perf-d84bffcb8-7fxqj:/# curl -I http://10.10.48.254:8080/actuator/health 
  14. HTTP/1.1 200 
  15. Content-Type: application/vnd.spring-boot.actuator.v3+json 
  16. Transfer-Encoding: chunked 
  17. Date: Fri, 30 Apr 2021 01:42:58 GMT 

結束抓包，下載svc.cap文件放到wireshark中打開查看


可以看到wireshark中Src和Dst的結果。任然是和上面pod中訪問pod的ip地址一樣。這里Src和Dst任然是兩個pod的宿主機的內網ip和兩個pod自己的ip地址。是用ipip的方式進行通信的。

通過以上例子演示，應該就看明白了IPIP網絡模式的通信方式了吧！

 

責任編輯：姜華 來源： 運維開發(fā)故事
IPIP網絡模式calicok8s
相關推薦

2024-05-09 09:09:19

組合模式對象

2024-05-13 10:45:25

中介模式面向對象數量

2024-05-10 08:43:04

外觀模式接口系統(tǒng)

2024-05-11 14:18:44

迭代器模式業(yè)務

2024-05-17 10:08:59

享元模式分類方式

2024-05-15 17:41:37

備忘錄模式多線程

2022-05-05 16:47:24

Docker網絡空間容器

2020-07-10 08:03:35

DNS網絡ARPAne

2019-08-27 14:46:59

ElasticSearES數據庫

2023-05-29 08:45:45

Java注解數據形式

2024-02-26 11:52:38

代理模式設計

2024-02-19 13:11:38

門面模式系統(tǒng)

2024-01-29 12:22:07

設計模式策略模式

2016-08-18 00:21:12

網絡爬蟲抓取網絡

2022-07-05 06:30:54

云網絡網絡云原生

2021-12-29 18:00:19

無損網絡網絡通信網絡

2023-05-22 13:27:17

2024-01-30 13:15:00

設計模式責任鏈瑣

2024-02-21 12:24:33

模板設計模式框架

2024-02-23 12:11:53

裝飾器模式對象
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 午夜在线免费观看视频 | aaa级片| 欧美成视频 | 视频在线亚洲 | 2018国产精品| 亚洲手机视频在线 | 在线中文一区 | 亚洲免费在线视频 | 久久精品视频免费看 | 一级片片 | 国产福利在线 | 在线观看视频你懂得 | 伊人在线| 免费看片在线播放 | 无码一区二区三区视频 | 盗摄精品av一区二区三区 | av福利网 | 色综合一区二区三区 | 国产人成精品一区二区三 | 看片地址 | 成人欧美一区二区三区黑人孕妇 | 国产欧美日韩一区二区三区在线观看 | 日本不卡免费新一二三区 | 在线观看视频一区二区三区 | 国产日批| 99国产精品99久久久久久粉嫩 | 国产免费a视频 | 精品国产一区二区国模嫣然 | 成人免费观看男女羞羞视频 | 中文在线一区二区 | 国产精品中文字幕在线 | 国产精品久久久久久久久免费樱桃 | 久久精品亚洲精品国产欧美 | 一区二区三区四区在线视频 | 久久最新 | 男女在线免费观看 | 草久久免费视频 | 亚洲精品久久久久久下一站 | 亚洲天堂中文字幕 | 欧美精品一区二区在线观看 | 亚洲成人精品在线观看 |