Kubernetes網絡模型理論深刻剖析(一)-Kubernetes商業環境實戰

專一於大數據及容器雲核心技術解密，可提供全棧的大數據+雲原平生臺諮詢方案，請持續關注本套博客。若有任何學術交流，可隨時聯繫。更多內容請關注《數據雲技術社區》公衆號，或請轉發郵件至1120746959@qq.com。 node

1 Docker通訊模型

1.1 Docker Host 網絡模型

1.2 Docker Briage 網絡模型

2 Kubernetes通訊模型

在每一個Kubernetes節點（本場景指的是Linux機器）上，都有一個根（root）命名空間（root是做爲基準，而不是超級用戶）--root netns，最主要的網絡接口 eth0 就是在這個root netns下。
相似的，每一個Pod都有其自身的netns，經過一個虛擬的以太網對鏈接到root netns。這基本上就是一個管道對，一端在root netns內，另外一端在Pod的nens內。
節點上的全部Pod都會完成這個過程。這些Pod要相互通訊，就要用到linux的以太網橋 cbr0 了。Docker使用了相似的網橋，稱爲docker0。

2.1 節點內通訊原理

假設一個網絡數據包要由pod1到pod2。

它由pod1中netns的eth0網口離開，經過vethxxx進入root netns。
而後被傳到cbr0，cbr0使用ARP請求，說「誰擁有這個IP」，從而發現目標地址。
vethyyy說它有這個IP，所以網橋就知道了往哪裏轉發這個包。
數據包到達vethyyy，跨過管道對，到達pod2的netns。

2.2 節點間通訊原理

Pod也須要跨節點可達。Kubernetes不關心如何實現。咱們可使用L2（ARP跨節點），L3（IP路由跨節點，就像雲提供商的路由表），Overlay網絡，或者甚至信鴿。無所謂，只要流量能到達另外一個節點的指望Pod就好。每一個節點都爲Pod IPs分配了惟一的CIDR塊（一段IP地址範圍），所以每一個Pod都擁有惟一的IP，不會和其它節點上的Pod衝突。

假設一個數據包要從pod1到達pod4（在不一樣的節點上）。
它由pod1中netns的eth0網口離開，經過vethxxx進入root netns。
而後被傳到cbr0，cbr0經過發送ARP請求來找到目標地址。
本節點上沒有Pod擁有pod4的IP地址，所以數據包由cbr0 傳到主網絡接口 eth0。
數據包的源地址爲pod1，目標地址爲pod4，它以這種方式離開node1進入電纜。
路由表有每一個節點的CIDR塊的路由設定，它把數據包路由到CIDR塊包含pod4的IP的節點。
所以數據包到達了node2的主網絡接口eth0。如今即便pod4不是eth0的IP，數據包也仍然能轉發到cbr0，由於節點配置了IP forwarding enabled。節點的路由表尋找任意能匹配pod4 IP的路由。它發現了 cbr0 是這個節點的CIDR塊的目標地址。你能夠用route -n命令列出該節點的路由表，它會顯示cbr0的路由，類型以下：
網橋接收了數據包，發送ARP請求，發現目標IP屬於vethyyy。
數據包跨過管道對到達pod4。

2.3 Overlay 網絡-VXLAN端口（一般是8472）

Overlay網絡不是默認必須的，可是它們在特定場景下很是有用。好比當咱們沒有足夠的IP空間，或者網絡沒法處理額外路由，抑或當咱們須要Overlay提供的某些額外管理特性。一個常見的場景是當雲提供商的路由表能處理的路由數是有限制時。例如，AWS路由表最多支持50條路由纔不至於影響網絡性能。所以若是咱們有超過50個Kubernetes節點，AWS路由表將不夠。這種狀況下，使用Overlay網絡將幫到咱們。
儘管這個映射發生在用戶空間，真實的封裝以及數據的流動發生在內核空間，所以仍然是很快的。

從pod1到pod4（在不一樣節點）的數據包的流向相似以下：
一、它由pod1中netns的eth0網口離開，經過vethxxx進入root netns。
二、而後被傳到cbr0，cbr0經過發送ARP請求來找到目標地址。
3a、因爲本節點上沒有Pod擁有pod4的IP地址，所以網橋把數據包發送給了flannel0，由於節點的路由表上flannel0被配成了Pod網段的目標地址。
3b、flanneld daemon和Kubernetes apiserver或者底層的etcd通訊，它知道全部的Pod IP，而且知道它們在哪一個節點上。所以Flannel建立了Pod IP和Node IP之間的映射（在用戶空間）。 flannel0取到這個包，並在其上再用一個UDP包封裝起來，該UDP包頭部的源和目的IP分別被改爲了對應節點的IP，而後發送這個新包到特定的VXLAN端口（一般是8472）。
3c、封裝後的包經過eth0發送出去，由於它涉及了節點間的路由流量。
四、包帶着節點IP信息做爲源和目的地址離開本節點。
五、雲提供商的路由表已經知道了如何在節點間發送報文，所以該報文被髮送到目標地址node2。
6a、包到達node2的eth0網卡，因爲目標端口是特定的VXLAN端口，內核將報文發送給了 flannel0。
6b、flannel0解封報文，並將其發送到 root 命名空間下。從這裏開始，報文的路徑和咱們以前在Part 1 中看到的非Overlay網絡就是一致的了。
6c、因爲IP forwarding開啓着，內核按照路由表將報文轉發給了cbr0。
七、網橋獲取到了包，發送ARP請求，發現目標IP屬於vethyyy。
八、包跨過管道對到達pod4。

3 網絡模型架構圖

3.1 Flannel UDP 模式

3.2 Flannel VXLAN 模式

3.3 Flannel Host-gw 模式

3.4 Calico模式

3.4.1 Calico基礎理論

Calico是一個簡單、可擴展和安全的三層數據中心網絡架構，無需依託overlay網絡。 Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責數據轉發，而每一個vRouter經過BGP協議負責把本身上運行的workload的路由信息向整個Calico網絡內傳播，小規模部署能夠直接互聯，大規模部署可經過指定的BGP route reflector來完成。Calico基於iptables還提供了豐富而靈活的網絡Policy，保證經過各個節點上的ACLs來提供workload的多租戶隔離、安全組以及其餘可達性限制等功能。 linux