> **導讀：**前文 [Kubernetes 中的 ClusterIP、NodePort、LoadBalancer、Ingress 服務訪問方式比較](https://www.atatech.org/articles/156810)中總結了服務接入訪問的主要方式，以及它們之間隱含關係。有了這些概念基礎後，K8s 應用開發和服務部署就容易很多了，但 Under the hood 服務訪問究竟是如何實現的呢？這篇內容就 Kubernetes 的網路模型和典型的容器網路實現，特別是阿里雲自己的容器網路外掛（Terway）的方案做了一個較詳細的總結。

# Pod 之間 Container-to-Container networking

Linux networking namespace 為程式通訊提供了一個邏輯網路棧，包括 network devices、routes、firewall rules。Network namespace（NS）管理實際是為其中的所有程式提供了一個獨立的邏輯網路 Stack。

預設情況下，Linux 將每個程式掛載在 Root NS 下，這些程式透過 eth0 通往外面的世界。

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

在 Pod 世界裡所有其中的容器共享一個 NS，這些容器都有相同的 IP 和 Port 空間，透過 localhost 訪問也是互通的。Shared storage 也是可以訪問的，透過 SharedVolume 掛載到容器中。如下一個 NS per pod 圖例：

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

# 同 Node 中 Pod-to-Pod networking

先看同一個 Node 下 Pod 之間的 networking 如何實現？答案是透過`Virtual Ethernet Device (or veth pair)`的兩塊 Virtual interfaces，每塊 veth 掛載在一個 NS 上，來實現跨 NS 的連線。比如，一塊掛在 Root NS（host）上，另一塊掛在 Pod NS 上，好比一根網線把兩個在不同網路空間的 traffic 連線起來了，如圖：

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

有了`veth pair`這條*網線*，Pods 網路可以連通到 Root NS 了，但在 Root NS 上如何實現對來自不同 Pod 的 packet 通訊呢？答案是透過`Linux Ethernet Bridge`，一個虛擬的 Layer2 網路裝置來實現不同 network segments 之間的 Ethernet packet switching。不得不提這個 old-school 協議：ARP，實現了 MAC 地址到 IP 地址的發現協議。Bridge 廣播 ethframe 到所有連線的裝置（除傳送者外），收到 ARP 回覆後將 packet forward 到對應 veth 裝置上。如圖：

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

# 跨 Node 之間 Pod-to-Pod networking

進入這部分之前，先提及 K8s 在其（Pod）networking 設計上的 3 個 fundamental requirements，任何 networking 部分的實現都必須遵循這三個需求。

- 在不使用 NAT 下，所有 Pods 都能和其它任何 Pods 通訊
- 在不使用 NAT 下，所有 Nodes 都能和所有 Pods 通訊
- Pod 所看到自己的 IP 和其它 Pods 看到它的 IP 一定是相同的

簡要來看，K8s 網路模型要求 Pod IP 在整個網路中都能通達。具體實現方案有三方面：

- Layer2（Switching）Solution
- Layer3（Routing）Solution，如,Calico, Terway
- Overlay Solution，如Flannel

這部分下文介紹，目前且認為 Pod IP 的網路通達性是確保的。

在 Pod 獲得 IP 之前，kubelet 為每個 Node 分配一個 CIDR 地址段（Classless inter-domain routing），每個 Pod 在其中獲取唯一 IP，CIDR 地址塊的大小對應於每個 Node 的最大 Pod 數量（預設 110 個）。在 Pod IP 和跨 Node 網路層部署成功後，從源 Pod1 到目的 Pod4 的通訊如圖：

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

# Pod-to-Service networking

K8s Service 管理服務的 Pods 狀態，在 Pod 有變化下管理對應 IP 的變化，並管理對外提供服務的 Virtual IP 到 Pod IPs 路由訪問，實現外部對服務 Virtual IP 的訪問路由到 Pod IP，以此遮蔽外部對服務後端的實現形態。所以在服務建立時，會對應生成一個 Virtual IP（也即是 Cluster IP），任何對該 Virtual IP 的訪問將打散路由到服務所屬的 Pods 上。

K8s 的服務是如何實現對 Virtual IP 的訪問負載均衡呢？答案是 netfilter 和 iptables。netfilters 是 Linux built-in networking framework，為 Linux 提供網路包過濾、NAT 和 Port translation 等豐富的自定義 handler 實現。iptables 是執行在 Linux user-space 的規則管理系統，為 netfilter 框架提供豐富的包轉發規則管理。

在 K8s 實現中 kube-proxy（node deamon）透過 watch apiserver 來獲得服務配置的變化，比如，服務的 Virtual IP 變化、Pod IP 變化（ie, pod up/down）。iptables 規則隨之變化並將請求路由到服務對應的 Pod 上，Pod IP 選取是隨機的，這樣看 iptables 起到了 Pod 負載均衡作用。在訪問請求 Return path 上，iptables 會做一次 SNAT 以替換 IP header 的 Pod IP 為服務 Virtual IP，這樣使得 Client 看起來請求僅在服務 Virtual IP 上進行通訊。

從 K8S v1.11 中 IPVS（IP Virtual Server）被引入成為第二種叢集內負載均衡方式。IPVS 同樣也是構建基於 netfilter 之上，在建立服務定義時可指定使用 iptables 或 IPVS。IPVS 是特定適合於服務負載均衡的解決方案，提供了非常豐富的均衡演算法應用場景。

# 使用 DNS

每個服務會設定一個 DNS 域名，`kubelets`為每個容器進行配置`--cluster-dns=<dns-service-ip>`，用以解析服務所對應 DNS 域名到對應的 Cluster IP 或 Pod IP。1.12 後 CoreDNS 成為預設 DNS 方式。服務支援 3 種型別 DNS records（A record、CNAME、SRV records）。其中常用的是 A Records，比如，在`cluster.local`的 DNS name 下，A record 格式如`pod-ip-address.my-namespace.pod.cluster.local`，其中 Pod hostname和subdomain 欄位可以設定為標準的 FQDN 格式，比如，`custom-host.custom-subdomain.my-namespace.svc.cluster.local`

# CNI

容器網路模型在實現上是由 K8s 的節點 Pod 資源管控（kubelet）和遵從 Container Networking Interface（CNI）標準的外掛共同協作完成的。CNI 外掛程式在其中充當了"膠水"作用：各種容器網路實現能在一致的操作介面下由 kubelet 統一管控排程。另外，多個容器網路也能共存於一個叢集內，為不同 Pod 的網路需求提供服務，都是在 kubelet 的統一管控下完成。

## Overlay networking: Flannel

Flannel 是 CoreOS 為 K8s networking 開發的解決方案，也是阿里雲 [ACK](https://cn.aliyun.com/product/kubernetes) 產品支援的容器網路解決方案。Flannel 的設計原理很簡潔，在 host 網路之上建立另一個扁平網路（所謂的 overlay），在其上地址空間中給每個 pod 容器設定一個 IP 地址，並用此實現路由和通訊。

主機內容器網路在 docker bridge `docker0`上完成通訊，不再贅述。主機間通訊使用核心路由表和 IP-over-UDP 封裝進行實現。容器 IP 包流經 docker bridge 會轉發到`flannel0`網路卡（TUN）裝置上，進而流入到`flanneld`程式中。`flanneld`會對 packet 目標 IP 地址所屬的網段資訊查詢其對應的`下一跳`主機 IP，容器子網 CIDR 和所屬主機 IP 的對映(key-value)儲存在 etcd 中，`flanneld`查詢得到 packet 目標 IP 所屬的主機 IP 地址後，會將 IP packet 封裝到一個 UDP payload 中並設定 UDP packet 目標地址為所得到的目標主機 IP，最後在 host 網路中傳送出 UDP packet。到達目標主機後，UDP packet 會流經`flanneld`並在這裡解封出 IP packet，再傳送至`flannel0`、`docker0`最後到達目標容器 IP 地址上。下圖示意流程：

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

值得一提是，容器 CIDR 和下一跳主機 IP 的對映條目容量沒有特殊限制。在阿里雲 ACK 產品上該條目容量需要在 VPC/vSwitch 控制面中進行分發，考慮到整體效能因素，在數量上做了一定數量限制（預設 48 個）。但在自建主機網路部署中，該數量限制就不會明顯了，因為主機下一跳主機網路在一個大二層平面上。

Flannel 新版本 backend 不建議採用 UDP 封裝方式，因為 traffic 存在 3 次使用者空間與核心空間的資料複製，（如下圖）效能上存在比較大的損耗。新版本推薦用 VxLan 和雲服務商版本的 [backends](https://github.com/coreos/flannel/blob/master/Documentation/backends.md) 進行最佳化。

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

## L3 networking: Calico

[Calico](https://www.projectcalico.org/) 是 L3 Routing 上非常流行容器網路架構方案。主要元件是 [Felix](https://github.com/projectcalico/felix)，BIRD 和 BGP Route Reflector。Felix 和 BIRD 均是執行在 Node 上的 deamon 程式。架構簡要：

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

Felix 完成網路卡的管理和配置，包括 Routes programming 和 ACLs。實現路由資訊對 [Linux kernel FIB](https://vincent.bernat.ch/en/blog/2017-ipv4-route-lookup-linux) 的操作和 ACLs 的管理操作。由於 Felix 功能完整性和執行獨立性非常好，其功能作為 Off-the-shelf 被整合到阿里雲 Terway 網路外掛中，實現其網路策略功能。

BIRD（BGP client）完成核心路由 FIB 條目向叢集網路側分發，使其路由條目對所有網路節點中可見，並實現 BGP 路由協議功能。每一個 BGP client 會連線到網路中其它 BGP client，這對規模較大的部署會是明顯的瓶頸（due to the N^2 increase nature）。鑑於該限制引入了 BGP Route Reflector 元件，實現 BGP clients 路由資訊在匯聚層上再進行分發（propagation）。在叢集網站中 Reflector 元件可以部署多個，完全能於部署規模大小來決定。Reflector 元件僅僅執行路由信令和條目的分發，其中不涉及任何資料面流量。路由匯聚層分發：

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

## L3 networking：Terway

Terway 是阿里雲自研 CNI 外掛，提供了阿里雲 VPC 互通和方便對接阿里雲產品的基礎設施，沒有 overlay 網路帶來的效能損耗，同時提供了簡單易用的 backend 功能。

Terway 功能上可分為三部分：1. CNI 外掛，一個獨立的 binary 執行程式；2. Backend Server（也稱為daemon），程式以獨立 daemonSet 方式執行在每個 Node 上；3. Network Policy，完全整合了 Calico Felix 實現。

CNI 外掛 binary 是透過 daemonSet 部署中 initContainer 安裝到所有節點上，實現了`ADD`、`DEL`、`CHECK`三個介面供 kubelet 呼叫。這裡以一個 Pod 在建立過程中的網路 setup 步驟來說明：

- 當一個 Pod 被排程到節點上時，kubelet 監聽到 Pod 建立在自己節點上，透過 runtime(docker...)建立 sandbox 容器來打通所需 namespace。
- kubelet 呼叫外掛 binary 的`cmdAdd`介面，外掛程式對介面引數設定檢查後，向 backendServer 發起`AllocIP`呼叫。
- backendServer 程式的`networkService`根據 Pod 的網路型別進行相應的 Pod IP 申請，支援三種網路型別`ENIMultiIP`、`VPCENI`、`VPCIP`：
   - `ENIMultiIP`是 eni 網路卡帶多 IP 型別，由`networkService`中的`ResourceManager`在自己的 IP 地址池中進行 IP 地址分配
   - `VPCENI`是為 Pod 建立和掛載一個 eni，由`networkService`中的`allocateENI`向阿里雲 Openapi 發起對所屬 ecs 例項的 eni 建立、掛載，並獲得對應 eni IP 地址
   - `VPCIP`是為 Pod 在 VPC 網路平面上分配一個 IP 地址，這是在外掛程式中透過呼叫`ipam`介面從 vpc 管控面獲取的 IP 地址
- 在 backendServer 返回`AllocIP`呼叫（IP 地址）結果後，外掛呼叫不同網路型別下的`NetnsDriver``Setup`介面實現來完成從容器網路卡通往主機網路卡的鏈路設定，其中：
   - `ENIMultiIP`和`VPCIP`均是採用`vethDriver`的鏈路模式，步驟包括：
      - Create veth pair
      - Add IP addr for container interface
      - Add routes
      - Host side namespace config
      - Add host routes and rules
   - `VPCENI`稍有不同是為每個 Pod 在 VPC 平面上繫結一個 eni，其中包括兩次`NetnsDriver`介面呼叫：
      - `vethDriver`
      - `rawNicDriver`（主要實現 VPC 平面網路路由設定，包括預設路由和閘道器等配置）

綜上圖示：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/83c9e17aaad342b3b05b3ba696aa474c.png)

為什麼需要支援上述三種網路型別？根本上是由阿里雲 vpc 網路基礎設施所決定，同時覆蓋阿里雲主流應用對 vpc 網路資源的使用場景需求。另一方面是對標 Amazon AWS 的容器網路解決方案，在基於 VPC 和 ENI 的網路設施上能支援同等功能。

ENI 多 IP、VPC ENI 和 VPC IP 的主要區別在於前兩者下的 Pod 網段和 VPC 網段是相同的，而 VPC IP 的網段和節點的宿主機網段不同。這樣使得在 ENI 網路環境下的 IP 路由完全在 VPC 的 L2 網路平面上進行，而 VPC IP 網路需要在 VPC 路由表中進行配置 Pod 網段的下一跳主機，和 Flannel 的路由模式類似。可以看出，ENI 網路能帶來更靈活的路由選擇和更好的路由效能。如下兩個截圖反映其不同路由特點：

VPC ENI 網路：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/942e283749ba49389e1fb86d835c9bfb.png)

VPC IP 網路：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/813bf6d8ea1840ca931696c16787c3df.png)

ENI 多 IP（1 個主 IP/多個輔助 IP）網路下有 2 種路由模式：`veth策略路由`和`ipvlan`。兩者本質區別在於使用不同的路由模式，前者使用`veth pair`的策略路由，後者使用`ipvlan`網路路由。策略路由需要在節點上配置策略路由條目來保證輔助 IP 的流量經過它所屬的彈性網路卡。`ipvlan`實現了一個網路卡虛擬出多個子網路卡和不同的 IP 地址，eni 將其輔助 IP 繫結到這些虛擬出來的子網路卡上形成一個與 vpc 平面打通的 L3 網路。這種模式使 ENI 多 IP 的網路結構比較簡單，效能相對`veth策略路由`網路也更好。兩種網路模式切換透過配置即可完成（預設是`vethpair`）：

值得一提的是 Terway 還實現了 ENI 多 IP 地址資源池的管理和分配機制。`networkService`中的`eniIPFactory`為每個 eni 網路卡建立一個 goroutine，該 eni 網路卡上的 eniIP 的分配釋放都在這個 goroutine 中完成。在建立一個 eniIP 時掃描已經存在的 eni 網路卡，如該 eni 還存在空閒的 eniIP，該 goroutine 會透過`ipResultChan`返回給`eniIPFactory`一個分配的 IP。如果所有的 eni 網路卡的 eniIP 都分配完畢，會先建立一個新的 eni 網路卡和對應的 goroutine，首次建立 eni 網路卡時無需做 IP 分配，直接返回 eni 網路卡主 IP 即可。eniIP 釋放是逆向的，在 eni 網路卡的最後一個 eniIP 釋放時，整個 eni 網路卡資源會釋放掉。

另外，有一個`startCheckIdleTicker`goroutine 會定期掃描地址池的`MaxPoolSize`和`MinPoolSize`水位，在低於和高出水位閥值時會對地址池 eniIP 資源進行進行建立和釋放，使得地址池 IP 資源處於一個可控水位範圍中。為了保證資源狀態一致性，有一個`startGarbageCollectionLoop`goroutine會定期掃描 IP 地址是否在用或過期狀態，如檢測到會進行資源 GC 操作。最後，Pod 資源狀態資料都持久化在本地的一個`boltDB`檔案中`/var/lib/cni/terway/pod.db`，即使 Pod 已經在 apiServer 中刪除，`GetPod`會從本地`boltDB`中讀取副本資料。在 Pod 已經刪除但副本還存在 DB 的情況下，GC goroutine檢 測到會執行清理。截圖簡述：

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

總結下，從這些 backend 功能可以看到 Terway 為阿里雲 vpc 網路資源設施連通性做了很好的封裝，讓基於阿里雲 Kubernetes 的應用開發和部署帶來更加簡便和高效的優點。</dns-service-ip>

Kubernetes 容器網路模型和典型實現

相關文章