作者 | 溪恆 阿里巴巴高階技術專家

本文整理自《CNCF x Alibaba 雲原生技術公開課》第 26 講，[點選直達課程頁面](https://edu.aliyun.com/roadmap/cloudnative)。

關注“阿里巴巴雲原生”公眾號，回覆關鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。

**導讀**：網路架構是 K8s 中較為複雜的方面之一。K8s 網路模型本身對某些特定的網路功能有著一定的要求，因此，業界已經有了不少的網路方案來滿足特定的環境和要求。CNI 意為容器網路的 API 介面，為了讓使用者在容器建立或銷燬時都能夠更容易地配置容器網路。在本文中，作者將帶領大家理解典型網路外掛地工作原理、掌握 CNI 外掛的使用。

# 一、CNI 是什麼
首先我們介紹一下什麼是 CNI，它的全稱是 Container Network Interface，即容器網路的 API 介面。

它是 K8s 中標準的一個呼叫網路實現的介面。Kubelet 透過這個標準的 API 來呼叫不同的網路外掛以實現不同的網路配置方式，實現了這個介面的就是 CNI 外掛，它實現了一系列的 CNI API 介面。常見的 CNI 外掛包括 Calico、flannel、Terway、Weave Net 以及 Contiv。

# 二、Kubernetes 中如何使用 CNI
K8s 透過 CNI 配置檔案來決定使用什麼 CNI。

基本的使用方法為：

1. 首先在每個結點上配置 CNI 配置檔案(/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一個網路配置檔案的名稱；
1. 安裝 CNI 配置檔案中所對應的二進位制外掛；
1. 在這個節點上建立 Pod 之後，Kubelet 就會根據 CNI 配置檔案執行前兩步所安裝的 CNI 外掛；
1. 上步執行完之後，Pod 的網路就配置完成了。

具體的流程如下圖所示：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/eb89cb969a514b2e9b2bdcf6273f31f9.png)

在叢集裡面建立一個 Pod 的時候，首先會透過 apiserver 將 Pod 的配置寫入。apiserver 的一些管控元件（比如 Scheduler）會排程到某個具體的節點上去。Kubelet 監聽到這個 Pod 的建立之後，會在本地進行一些建立的操作。當執行到建立網路這一步驟時，它首先會讀取剛才我們所說的配置目錄中的配置檔案，配置檔案裡面會宣告所使用的是哪一個外掛，然後去執行具體的 CNI 外掛的二進位制檔案，再由 CNI 外掛進入 Pod 的網路空間去配置 Pod 的網路。配置完成之後，Kuberlet 也就完成了整個 Pod 的建立過程，這個 Pod 就線上了。

大家可能會覺得上述流程有很多步（比如要對 CNI 配置檔案進行配置、安裝二進位制外掛等等），看起來比較複雜。

但如果我們只是作為一個使用者去使用 CNI 外掛的話就比較簡單，因為很多 CNI 外掛都已提供了一鍵安裝的能力。以我們常用的 Flannel 為例，如下圖所示：只需要我們使用 kubectl apply Flannel 的一個 Deploying 模板，它就能自動地將配置、二進位制檔案安裝到每一個節點上去。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/a912b7e3aff44f9a854251ae72443c69.png)

安裝完之後，整個叢集的 CNI 外掛就安裝完成了。

因此，如果我們只是去使用 CNI 外掛的話，那麼其實很多 CNI 外掛已經提供了一鍵安裝的指令碼，無需大家關心 Kubernetes 內部是如何配置的以及如何呼叫 API 的。

# 三、哪個 CNI 外掛適合我

社群有很多的 CNI 外掛，比如 Calico, flannel, Terway 等等。那麼在一個真正具體的生產環境中，我們要選擇哪一個 CNI 外掛呢？<br> <br>這就要從 CNI 的幾種實現模式說起。我們需要根據不同的場景選擇不同的實現模式，再去選擇對應的具體某一個外掛。

通常來說，CNI 外掛可以分為三種：Overlay、路由及 Underlay。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/1c0c5c4562e7476588c0cf2fbe1a453d.png)

- **Overlay 模式**的典型特徵是容器獨立於主機的 IP 段，這個 IP 段進行跨主機網路通訊時是透過在主機之間建立隧道的方式，將整個容器網段的包全都封裝成底層的物理網路中主機之間的包。該方式的好處在於它不依賴於底層網路；

- **路由模式**中主機和容器也分屬不同的網段，它與 Overlay 模式的主要區別在於它的跨主機通訊是透過路由打通，無需在不同主機之間做一個隧道封包。但路由打通就需要部分依賴於底層網路，比如說要求底層網路有二層可達的一個能力；

- **Underlay 模式**中容器和宿主機位於同一層網路，兩者擁有相同的地位。容器之間網路的打通主要依靠於底層網路。因此該模式是強依賴於底層能力的。

瞭解了以上三種常用的實現模式之後，再根據自己的環境、需求判斷可由哪一種模式進行實現，再在對應的模式中去找 CNI 外掛。不過社群中有那麼多外掛，它們又都屬於哪種模式？如何進行選擇呢？怎麼挑選適合自己的呢？我們可以從以下 3 個方面來考慮。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/f0fd6f3f4887478ebeebff31ea5d327c.png)

## 1. 環境限制

不同環境中所支援的底層能力是不同的。
- **虛擬化環境**（例如 OpenStack）中的網路限制較多，比如不允許機器之間直接透過二層協議訪問，必須要帶有 IP 地址這種三層的才能去做轉發，限制某一個機器只能使用某些 IP 等。在這種被做了強限制的底層網路中，只能去選擇 Overlay 的外掛，常見的有 Flannel-vxlan, Calico-ipip, Weave 等等；

- **物理機環境**中底層網路的限制較少，比如說我們在同一個交換機下面直接做一個二層的通訊。對於這種叢集環境，我們可以選擇 Underlay 或者路由模式的外掛。Underlay 意味著我們可以直接在一個物理機上插多個網路卡或者是在一些網路卡上做硬體虛擬化；路由模式就是依賴於 Linux 的路由協議做一個打通。這樣就避免了像 vxlan 的封包方式導致的效能降低。這種環境下我們可選的外掛包括 clico-bgp, flannel-hostgw, sriov 等等；

- **公有云環境**也是虛擬化，因此底層限制也會較多。但每個公有云都會考慮適配容器，提升容器的效能，因此每家公有云可能都提供了一些 API 去配置一些額外的網路卡或者路由這種能力。在公有云上，我們要儘量選擇公有云廠商提供的 CNI 外掛以達到相容性和效能上的最優。比如 Aliyun 就提供了一個高效能的 Terway 外掛。

環境限制考慮完之後，我們心中應該都有一些選擇了，知道哪些能用、哪些不能用。在這個基礎上，我們再去考慮功能上的需求。

## 2. 功能需求

- 首先是**安全需求；**

K8s 支援 NetworkPolicy，就是說我們可以透過 NetworkPolicy 的一些規則去支援“Pod 之間是否可以訪問”這類策略。但不是每個 CNI 外掛都支援 NetworkPolicy 的宣告，如果大家有這個需求，可以選擇支援 NetworkPolicy 的一些外掛，比如 Calico, Weave 等等。

- 第二個是**是否需要叢集外的資源與叢集內的資源互聯互通；**

大家的應用最初都是在虛擬機器或者物理機上，容器化之後，應用無法一下就完成遷移，因此就需要傳統的虛擬機器或者物理機能跟容器的 IP 地址互通。為了實現這種互通，就需要兩者之間有一些打通的方式或者直接位於同一層。此時可以選擇 Underlay 的網路，比如 sriov 這種就是 Pod 和以前的虛擬機器或者物理機在同一層。我們也可以使用 calico-bgp，此時它們雖然不在同一網段，但可以透過它去跟原有的路由器做一些 BGP 路由的一個釋出，這樣也可以打通虛擬機器與容器。

- 最後考慮的就是 **K8s 的服務發現與負載均衡的能力**。

K8s 的服務發現與負載均衡就是我們前面所介紹的 [K8s 的 Service](https://developer.aliyun.com/article/728115)，但並不是所有的 CNI 外掛都能實現這兩種能力。比如很多 Underlay 模式的外掛，在 Pod 中的網路卡是直接用的 Underlay 的硬體，或者透過硬體虛擬化插到容器中的，這個時候它的流量無法走到宿主機所在的名稱空間，因此也無法應用 kube-proxy 在宿主機配置的規則。

這種情況下，外掛就無法訪問到 K8s 的服務發現。因此大家如果需要服務發現與負載均衡，在選擇 Underlay 的外掛時就需要注意它們是否支援這兩種能力。

經過功能需求的過濾之後，能選的外掛就很少了。經過環境限制和功能需求的過濾之後，如果還剩下 3、4 種外掛，可以再來考慮效能需求。

## 3. 效能需求

我們可以從 Pod 的建立速度和 Pod 的網路效能來衡量不同外掛的效能。

- **Pod 的建立速度**

當我們建立一組 Pod 時，比如業務高峰來了，需要緊急擴容，這時比如說我們擴容了 1000 個 Pod，就需要 CNI 外掛建立並配置 1000 個網路資源。Overlay 和路由模式在這種情況下的建立速度是很快的，因為它是在機器裡面又做了虛擬化，所以只需要呼叫核心介面就可以完成這些操作。但對於 Underlay 模式，由於需要建立一些底層的網路資源，所以整個 Pod 的建立速度相對會慢一些。因此對於經常需要緊急擴容或者建立大批次的 Pod 這些場景，我們應該儘量選擇 Overlay 或者路由模式的網路外掛。

- **Pod 的網路效能**

主要表現在兩個 Pod 之間的網路轉發、網路頻寬、PPS 延遲等這些效能指標上。Overlay 模式的效能較差，因為它在節點上又做了一層虛擬化，還需要去封包，封包又會帶來一些包頭的損失、CPU 的消耗等，如果大家對網路效能的要求比較高，比如說機器學習、大資料這些場景就不適合使用 Overlay 模式。這種情形下我們通常選擇 Underlay 或者路由模式的 CNI 外掛。

相信大家透過這三步的挑選之後都能找到適合自己的網路外掛。

# 四、如何開發自己的 CNI 外掛

有時社群的外掛無法滿足自己的需求，比如在阿里雲上只能使用 vxlan 這種 Overlay 的外掛，而 Overlay 外掛的效能相對較差，無法滿足阿里雲上的一些業務需求，所以阿里雲上開發了一個 Terway 的外掛。

如果我們自己的環境比較特殊，在社群裡面又找不到合適的網路外掛，此時可以開發一個自己的 CNI 外掛。

CNI 外掛的實現通常包含兩個部分：

1. 一個二進位制的 CNI 外掛去配置 Pod 網路卡和 IP 地址。這一步配置完成之後相當於給 Pod 上插上了一條網線，就是說它已經有自己的 IP、有自己的網路卡了；

2. 一個 Daemon 程式去管理 Pod 之間的網路打通。這一步相當於說將 Pod 真正連上網路，讓 Pod 之間能夠互相通訊。

## 給 Pod 插上網線

那麼如何實現第一步，給 Pod 插上網線呢？通常是這樣一個步驟：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/14b9ba2a61f84c4e801eb01d4e19254d.png)

### 1. 給 Pod 準備一個網路卡

通常我們會用一個 "veth" 這種虛擬網路卡，一端放到 Pod 的網路空間，一端放到主機的網路空間，這樣就實現了 Pod 與主機這兩個名稱空間的打通。

### 2. 給 Pod 分配 IP 地址

這個 IP 地址有一個要求，我們在之前介紹網路的時候也有提到，就是說這個 IP 地址在叢集裡需要是唯一的。如何保障叢集裡面給 Pod 分配的是個唯一的 IP 地址呢？

一般來說我們在建立整個叢集的時候會指定 Pod 的一個大網段，按照每個節點去分配一個 Node 網段。比如說上圖右側建立的是一個 172.16 的網段，我們再按照每個節點去分配一個 /24 的段，這樣就能保障每個節點上的地址是互不衝突的。然後每個 Pod 再從一個具體的節點上的網段中再去順序分配具體的 IP 地址，比如 Pod1 分配到了 172.16.0.1，Pod2 分配到了 172.16.0.2，這樣就實現了在節點裡面 IP 地址分配的不衝突，並且不同的 Node 又分屬不同的網段，因此不會衝突。

這樣就給 Pod 分配了叢集裡面一個唯一的 IP 地址。

### 3. 配置 Pod 的 IP 和路由

- 第一步，將分配到的 IP 地址配置給 Pod 的虛擬網路卡；
- 第二步，在 Pod 的網路卡上配置叢集網段的路由，令訪問的流量都走到對應的 Pod 網路卡上去，並且也會配置預設路由的網段到這個網路卡上，也就是說走公網的流量也會走到這個網路卡上進行路由；
- 最後在宿主機上配置到 Pod 的 IP 地址的路由，指向到宿主機對端 veth1 這個虛擬網路卡上。這樣實現的是從 Pod 能夠到宿主機上進行路由出去的，同時也實現了在宿主機上訪問到 Pod 的 IP 地址也能路由到對應的 Pod 的網路卡所對應的對端上去。

## 給 Pod 連上網路

剛才我們是給 Pod 插上網線，也就是給它配了 IP 地址以及路由表。那怎麼打通 Pod 之間的通訊呢？也就是讓每一個 Pod 的 IP 地址在叢集裡面都能被訪問到。

一般我們是在 CNI Daemon 程式中去做這些網路打通的事情。通常來說是這樣一個步驟：

- 首先 CNI 在每個節點上執行的 Daemon 程式會學習到叢集所有 Pod 的 IP 地址及其所在節點資訊。學習的方式通常是透過監聽 K8s APIServer，拿到現有 Pod 的 IP 地址以及節點，並且新的節點和新的 Pod 的建立的時候也能通知到每個 Daemon；

- 拿到 Pod 以及 Node 的相關資訊之後，再去配置網路進行打通。

- 首先 Daemon 會建立到整個叢集所有節點的通道。這裡的通道是個抽象概念，具體實現一般是透過 Overlay 隧道、阿里雲上的 VPC 路由表、或者是自己機房裡的 BGP 路由完成的；

- 第二步是將所有 Pod 的 IP 地址跟上一步建立的通道關聯起來。關聯也是個抽象概念，具體的實現通常是透過 Linux 路由、fdb 轉發表或者OVS 流表等完成的。Linux 路由可以設定某一個 IP 地址路由到哪個節點上去。fdb 轉發表是 forwarding database 的縮寫，就是把某個 Pod 的 IP 轉發到某一個節點的隧道端點上去（Overlay 網路）。OVS 流表是由 Open vSwitch 實現的，它可以把 Pod 的 IP 轉發到對應的節點上。

# 六、本文總結
本文的主要內容就到此為止了，這裡為大家簡單總結一下：

1. 在我們自己的環境中搭建一個 K8s 叢集，應當如何選擇最適合自己的網路外掛？
1. 當社群網路外掛不能滿足時，如何開發自己的網路外掛？

![2群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/ac48163928d241c7800400be301848f8.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

從零開始入門 K8s | 理解 CNI 和 CNI 外掛

相關文章