從零開始入門 K8s | Kubernetes 網絡概念及策略控制

做者 | 阿里巴巴高級技術專家  葉磊

1、Kubernetes 基本網絡模型

本文來介紹一下 Kubernetes 對網絡模型的一些想法。你們知道 Kubernetes 對於網絡具體實現方案，沒有什麼限制，也沒有給出特別好的參考案例。Kubernetes 對一個容器網絡是否合格作出了限制，也就是 Kubernetes 的容器網絡模型。能夠把它歸結爲約法三章和四大目標。

• 約法三章的意思是：在評價一個容器網絡或者設計容器網絡的時候，它的准入條件。它須要知足哪三條？ 才能認爲它是一個合格的網絡方案。
• 四大目標意思是在設計這個網絡的拓撲，設計網絡的具體功能的實現的時候，要去想清楚，能不能達成連通性等這幾大指標。

約法三章

先來看下約法三章：

• 第一條：任意兩個 pod 之間實際上是能夠直接通訊的，無需通過顯式地使用 NAT 來接收數據和地址的轉換；
• 第二條：node 與 pod 之間是能夠直接通訊的，無需使用明顯的地址轉換；
• 第三條：pod 看到本身的 IP 跟別人看見它所用的IP是同樣的，中間不能通過轉換。

後文中會講一下我我的的理解，爲何 Kubernetes 對容器網絡會有一些看起來武斷的模型和要求。

四大目標

四大目標實際上是在設計一個 K8s 的系統爲外部世界提供服務的時候，從網絡的角度要想清楚，外部世界如何一步一步鏈接到容器內部的應用？

• **外部世界和 service 之間是怎麼通訊的？**就是有一個互聯網或者是公司外部的一個用戶，怎麼用到 service？service 特指 K8s 裏面的服務概念。
• service 如何與它後端的 pod 通信？
• pod 和 pod 之間調用是怎麼作到通訊的？
• 最後就是 pod 內部容器與容器之間的通訊？

最終要達到目標，就是外部世界能夠鏈接到最裏面，對容器提供服務。

對基本約束的解釋

對基本約束，能夠作出這樣一些解讀：由於容器的網絡發展複雜性就在於它實際上是寄生在 Host 網絡之上的。從這個角度講，能夠把容器網絡方案大致分爲 **Underlay/Overlay **兩大派別：

• Underlay 的標準是它與 Host 網絡是同層的，從外在可見的一個特徵就是它是否是使用了 Host 網絡一樣的網段、輸入輸出基礎設備、容器的 IP 地址是否是須要與 Host 網絡取得協同（來自同一個中心分配或統一劃分）。這就是 Underlay；
• Overlay 不同的地方就在於它並不須要從 Host 網絡的 IPM 的管理的組件去申請 IP，通常來講，它只須要跟 Host 網絡不衝突，這個 IP 能夠自由分配的。

爲何社區會提出 perPodperIP 這種簡單武斷的模型呢？我我的是以爲這樣爲後面的 service 管理一些服務的跟蹤性能監控，帶來了很是多的好處。由於一個 IP 一向到底，對 case 或者各類不大的事情都會有很大的好處。

2、Netns 探祕

Netns 究竟實現了什麼

下面簡單講一下，Network Namespace 裏面能網絡實現的內核基礎。狹義上來講 runC 容器技術是不依賴於任何硬件的，它的執行基礎就是它的內核裏面，進程的內核表明就是 task，它若是不須要隔離，那麼用的是主機的空間（ namespace），並不須要特別設置的空間隔離數據結構（ nsproxy-namespace proxy）。

相反，若是一個獨立的網絡 proxy，或者 mount proxy，裏面就要填上真正的私有數據。它能夠看到的數據結構如上圖所示。

從感官上來看一個隔離的網絡空間，它會擁有本身的網卡或者說是網絡設備。網卡多是虛擬的，也多是物理網卡，它會擁有本身的 IP 地址、IP 表和路由表、擁有本身的協議棧狀態。這裏面特指就是 TCP/Ip協議棧，它會有本身的status，會有本身的 iptables、ipvs。

從整個感官上來說，這就至關於擁有了一個徹底獨立的網絡，它與主機網絡是隔離的。固然協議棧的代碼仍是公用的，只是數據結構不相同。

Pod 與 Netns 的關係

這張圖能夠清晰代表 pod 裏 Netns 的關係，每一個 pod 都有着獨立的網絡空間，pod net container 會共享這個網絡空間。通常 K8s 會推薦選用 Loopback 接口，在 pod net container 之間進行通訊，而全部的 container 經過 pod 的 IP 對外提供服務。另外對於宿主機上的 Root Netns，能夠把它看作一個特殊的網絡空間，只不過它的 Pid 是1。

3、主流網絡方案簡介

典型的容器網絡實現方案

接下來簡單介紹一下典型的容器網絡實現方案。容器網絡方案多是 K8s 裏最爲百花齊放的一個領域，它有着各類各樣的實現。容器網絡的複雜性，其實在於它須要跟底層 Iass 層的網絡作協調、須要在性能跟 IP 分配的靈活性上作一些選擇，這個方案是多種多樣的。

下面簡單介紹幾個比較主要的方案：分別是 Flannel、Calico、Canal ，最後是 WeaveNet，中間的大多數方案都是採用了跟 Calico 相似的策略路由的方法。

• **Flannel **是一個比較大一統的方案，它提供了多種的網絡 backend。不一樣的 backend 實現了不一樣的拓撲，它能夠覆蓋多種場景；
• **Calico **主要是採用了策略路由，節點之間採用 BGP 的協議，去進行路由的同步。它的特色是功能比較豐富，尤爲是對 Network Point 支持比較好，你們都知道 Calico 對底層網絡的要求，通常是須要 mac 地址可以直通，不能跨二層域；
• 固然也有一些社區的同窗會把 Flannel 的優勢和 Calico 的優勢作一些集成。咱們稱之爲嫁接型的創新項目 Cilium；
• 最後講一下 WeaveNet，若是你們在使用中須要對數據作一些加密，能夠選擇用 WeaveNet，它的動態方案能夠實現比較好的加密。

Flannel 方案

Flannel 方案是目前使用最爲廣泛的。如上圖所示，能夠看到一個典型的容器網方案。它首先要解決的是 container 的包如何到達 Host，這裏採用的是加一個 Bridge 的方式。它的 backend 實際上是獨立的，也就是說這個包如何離開 Host，是採用哪一種封裝方式，仍是不須要封裝，都是可選擇的。

如今來介紹三種主要的 backend：

• 一種是用戶態的 udp，這種是最先期的實現；
• 而後是內核的 Vxlan，這兩種都算是 overlay 的方案。Vxlan 的性能會比較好一點，可是它對內核的版本是有要求的，須要內核支持 Vxlan 的特性功能；
• 若是你的集羣規模不夠大，又處於同一個二層域，也能夠選擇採用 host-gw 的方式。這種方式的 backend 基本上是由一段廣播路由規則來啓動的，性能比較高。

4、Network Policy 的用處

Network Policy 基本概念

下面介紹一下 Network Policy 的概念。

剛纔提到了 Kubernetes 網絡的基本模型是須要 pod 之間全互聯，這個將帶來一些問題：可能在一個 K8s 集羣裏，有一些調用鏈之間是不會直接調用的。好比說兩個部門之間，那麼我但願 A 部門不要去探視到 B 部門的服務，這個時候就能夠用到策略的概念。

基本上它的想法是這樣的：它採用各類選擇器（標籤或 namespace），找到一組 pod，或者找到至關於通信的兩端，而後經過流的特徵描述來決定它們之間是否是能夠聯通，能夠理解爲一個白名單的機制。

在使用 Network Policy 以前，如上圖所示要注意 apiserver 須要打開一下這幾個開關。另外一個更重要的是咱們選用的網絡插件須要支持 Network Policy 的落地。你們要知道，Network Policy 只是 K8s 提供的一種對象，並無內置組件作落地實施，須要取決於你選擇的容器網絡方案對這個標準的支持與否及完備程度，若是你選擇 Flannel 之類，它並無真正去落地這個 Policy，那麼你試了這個也沒有什麼用。

配置實例

接下來說一個配置的實例，或者說在設計一個 Network Policy 的時候要作哪些事情？我我的以爲須要決定三件事：

• 第一件事是控制對象，就像這個實例裏面 spec 的部分。spec 裏面經過 podSelector 或者 namespace 的 selector，能夠選擇作特定的一組 pod 來接受咱們的控制；
• 第二個就是對流向考慮清楚，須要控制入方向仍是出方向？仍是兩個方向都要控制？
• 最重要的就是第三部分，若是要對選擇出來的方向加上控制對象來對它流進行描述，具體哪一些 stream 能夠放進來，或者放出去？類比這個流特徵的五元組，能夠經過一些選擇器來決定哪一些能夠做爲個人遠端，這是對象的選擇；也能夠經過 IPBlock 這種機制來獲得對哪些 IP 是能夠放行的；最後就是哪些協議或哪些端口。其實流特徵綜合起來就是一個五元組，會把特定的可以接受的流選擇出來 。

本文總結

本文內容到這裏就結束了，咱們簡單總結一下：

• 在 pod 的容器網絡中核心概念就是 IP，IP 就是每一個 pod 對外通信的地址基礎，必須內外一致，符合 K8s 的模型特徵；

• 那麼在介紹網絡方案的時候，影響容器網絡性能最關鍵的就是拓撲。要可以理解你的包端到端是怎麼聯通的，中間怎麼從 container 到達 Host，Host 出了 container 是要封裝仍是解封裝？仍是經過策略路由？最終到達對端是怎麼解出來的？

• 容器網絡選擇和設計選擇。若是你並不清楚你的外部網絡，或者你須要一個普適性最強的方案，假設說你對 mac 是否直連不太清楚、對外部路由器的路由表可否控制也不太清楚，那麼你能夠選擇 Flannel 利用 Vxlan 做爲 backend 的這種方案。若是你確信你的網絡是 2 層可直連的，你能夠進行選用 Calico 或者 Flannel-Hostgw 做爲一個 backend；

• 最後就是對 Network Policy，在運維和使用的時候，它是一個很強大的工具，能夠實現對進出流的精確控制。實現的方法咱們也介紹了，要想清楚你要控制誰，而後你的流要怎麼去定義。

5、思考時間

最後留一些思考，你們能夠想想：

1. 爲何接口標準化 CNI 化了，可是容器網絡卻沒有一個很標準的實現，內置在 K8s 裏面？

2. Network Policy 爲何沒有一個標準的 controller 或者一個標準的實現，而是交給這個容器網絡的 owner 來提供？

3. 有沒有可能徹底不用網絡設備來實現容器網絡呢？考慮到如今有 RDMA 等有別於 TCP/IP 的這種方案。

4. 在運維過程當中網絡問題比較多、也比較難排查，那麼值不值得作一個開源工具，讓它能夠友好的展現從 container 到 Host 之間、Host 到 Host 之間，或者說封裝及解封裝之間，各個階段的網絡狀況，有沒有出現問題，可以快速的定位。據我所知應該如今是沒有這樣的工具的。

以上就是我對 K8s 容器網絡的基本概念、以及 Network Policy 的一些介紹。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」