kubernetes 叢集内端口_淺談 Kubernetes 網絡模型（CNI）

來源：https://morven.life/notes/networking-6-k8s-summary/

Kubernetes通過整合規模龐大的容器執行個體形成叢集，這些容器執行個體可能運作在異構的底層網絡環境中，如何保證這些容器間的互通是實際生産環境中首要考慮的問題之一。

Kubernetes網絡基本要求

Kubernetes對容器技術做了更多的抽象，其中最重要的一點是提出pod的概念，pod是Kubernetes資源排程的基本單元，我們可以簡單地認為pod是容器的一種延伸擴充，從網絡的角度來看，pod必須滿足以下條件：

1. 每一個Pod都有一個獨特的IP位址，所有pod都在一個可以直接連通的、扁平的網絡空間中
2. 同一個pod内的所有容器共享同一個netns網絡命名空間

基于這樣的基本要求，我們可以知道：

1. 同一個pod内的所有容器之間共享端口，可直接通過

   localhost

   +

   端口

   來通路
2. 由于每個pod有單獨的IP，是以不需要考慮容器端口與主機端口映射以及端口沖突問題

事實上，Kubernetes進一步确定了對一個合格叢集網絡的基本要求：

1. 任意兩個pod之間其實是可以直接通信的，無需顯式地使用NAT進行位址的轉換；
2. 任意叢集節點node與任意pod之間是可以直接通信的，無需使用明顯的位址轉換，反之亦然；
3. 任意pod看到自己的IP跟别人看見它所用的IP是一樣的，中間不能經過位址轉換；

也就是說，必須同時滿足以上三點的網絡模型才能适用于kubernetes，事實上，在早期的Kubernetes中，并沒有什麼網絡标準，隻是提出了以上基本要求，隻有滿足這些要求的網絡才可以部署Kubernetes，基于這樣的底層網絡假設，Kubernetes設計了

pod-deployment-service

的經典三層服務通路機制。直到1.1釋出，Kubernetes才開始采用全新的CNI(Container Network Interface)網絡标準。

CNI

其實，我們在前面介紹容器網絡的時候，就提到了CNI網絡規範，CNI相對于CNM(Container Network Model)對開發者的限制更少，更開放，不依賴于Docker。事實上，CNI規範确實非常簡單，詳見：https://github.com/containernetworking/cni/blob/master/SPEC.md

實作一個CNI網絡插件隻需要一個配置檔案和一個可執行的檔案：

• 配置檔案描述插件的版本、名稱、描述等基本資訊
• 可執行檔案會被上層的容器管理平台調用，一個CNI可執行檔案自需要實作将容器加入到網絡的ADD操作以及将容器從網絡中删除的DEL操作(以及一個可選的VERSION檢視版本操作)

Kubernetes使用CNI網絡插件的基本工作流程：

1. kubelet先建立

   pause

   容器生成對應的netns網絡命名空間
2. 根據配置調用具體的CNI插件，可以配置成CNI插件鍊來進行鍊式調用
3. 當CNI插件被調用時，它根據環境變量以及指令行參數來獲得網絡命名空間netns、容器的網絡裝置等必要資訊，然後執行ADD操作
4. CNI插件給pause容器配置正确的網絡，pod中其他的容器都是用pause容器的網絡

如果不清楚什麼是

pause

容器，它在pod中處于什麼樣的位置，請檢視之前的筆記：https://morven.life/notes/from-container-to-pod/

pod網絡模型

要了解kubernetes網絡模型的實作原理，我們就要從單個pod入手，事實上，一旦熟悉了單個pod的網絡模型，就會發現kubernetes網絡模型基本遵循和容器網絡模型一樣的原理。

通過前面的筆記從docker容器到pod，我們知道pod啟動的時候先建立

pause

容器生成對應的netns網絡命名空間，然後其他容器共享

pause

容器建立的網絡命名空間。而對于單個容器的網絡模型我們之前也介紹過，主要就是通過

docker0

網橋裝置與veth裝置對連接配接不同的容器網絡命名空間，由此，我們可以得到如下圖所示的單個pod網絡模型的建立過程：

可以看到，同一個pod裡面的其他容器共享

pause

容器建立的網絡命名空間，也就是說，所有的容器共享相同的網絡裝置，路由表設定，服務端口等資訊，仿佛是在同一台機器上運作的不同程序，是以這些容器之間可以直接通過

localhost

與對應的端口通信；對于叢集外部的請求，則通過

docker0

網橋裝置充當的網關，同時通過iptables做位址轉換。我們會發現，這其實就是對當個容器的bridge網絡模型的擴充。

主流kubernetes網絡方案

上一小節我們知道單個pod的網絡模型是容器網絡模型的擴充，但是pod與pod之間的是怎麼互相通信的呢？這其實與容器之間互相通信非常類似，也分為同一個主機上的pod之間與跨主機的pod之間兩種。

如容器網絡模型一樣，對于統一主機上的pod之間，通過

docker0

網橋裝置直接二層(資料鍊路層)網絡上通過MAC位址直接通信：

而跨主機的pod之間的互相通信也主要有以下兩個思路：

1. 修改底層網絡裝置配置，加入容器網絡IP位址的管理，修改路由器網關等，該方式主要和SDN(Software define networking)結合。
2. 完全不修改底層網絡裝置配置，複用原有的underlay平面網絡，解決容器跨主機通信，主要有如下兩種方式:

• 隧道傳輸(Overlay)：将容器的資料包封裝到原主機網絡的三層或者四層資料包中，然後使用主機網絡的IP或者TCP/UDP傳輸到目标主機，目标主機拆包後再轉發給目标容器。Overlay隧道傳輸常見方案包括Vxlan、ipip等，目前使用Overlay隧道傳輸技術的主流容器網絡有Flannel等；

• 修改主機路由：把容器網絡加到主機路由表中，把主機網絡裝置當作容器網關，通過路由規則轉發到指定的主機，實作容器的三層互通。目前通過路由技術實作容器跨主機通信的網絡如Flannel host-gw、Calico等；

下面簡單介紹幾種主流的方案：

• Flannel是目前使用最為普遍的方案，提供了多種網絡backend，它支援多種資料路徑，也适合于overlay/underlay等多種場景。對于overlay的資料包封裝，可以使用使用者态的UDP，核心态的Vxlan(性能相對較好)，甚至在叢集規模不大，且處于同一個二層域時可以采用host-gw的方式修改主機路由表；
• Weave工作模式與Flannel很相似的，它最早隻提供了UDP(稱為sleeve模式)的網絡方式，後來又加上了fastpass方式(基于VxLAN)，不過Weave消除了Flannel中用來存儲網絡位址的額外元件，自己內建了高可用的資料存儲功能；
• Calico主要是采用了修改主機路由，節點之間采用BGP的協定去進行路由的同步。但是現實中的網絡并不總是支援BGP路由的，是以Calico也支援核心中的IPIP模式，使用overlay的方式來傳輸資料；

政策控制(Network Policy)

Network Policy)是Kubernetes提供的基于政策的網絡控制，用于隔離應用并提高安全性。它使用Kubernetes中常用的标簽選擇器模拟傳統的分段網絡，并通過政策控制它們之間的東西流量以及與外部交流的南北流量。

Note: 確定使用的網絡插件支援政策控制(Network Policy)，比如Flannel就沒有實作Network Policy；

下面的例子是配置一個典型的Network Policy的執行個體：

它使用标簽選擇器

namespaceSelector

與

posSelector

控制pod之間的流量，流量的行為模式主要由以下三個對象決定：

1. 控制對象：通過

   spec.podSelector

   篩選
2. 流量方向：

   ingress

   控制入pod流量，

   egress

   控制出pod流量
3. 流量特征：對端-IP-協定-端口

通過使用Network Policy可以實作對進出流的精确控制，它采用各種選擇器(标簽或namespace)，找到一組滿足條件的pod，或者找到相當于通信的兩端，然後通過流量的特征描述來決定它們之間是不是可以連通，可以了解為一個白名單的機制。

- END -

 推薦閱讀 
           

小團隊如何從零搭建一個自動化運維體系？為什麼 HTTPS 是安全的？面試管：用了HTTPS就安全了嗎？HTTPS 會被抓包嗎？支付寶架構師眼中的高并發架構
           

SpringCloud微服務項目運維必知必會Java 應用最常見的3個問題排查思路一篇漫畫帶你了解 Linux 核心長啥樣！

點亮，伺服器三年不當機