網路虛擬化NSX 技術文章系列二百二十九: NSX Advanced Load Balancer容器方案支持（七）：網路部署方式討論

作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

前面多篇對於NSX Advanced Load Balancer (Avi Networks) 內的Kubernetes支持方案AKO的基礎架構及效益進行介紹。接下來我想就技術面的幾個常見架構問題與需求進行更深入的討論。首先本篇內我們要談一個介紹AKO時，常會需要與網路團隊進行互動說明的課題：既然Avi將Kubernetes的LB Service / Ingress等功能放到外部服務引擎上，以Virtual Service的方式運作，但真正的工作負載是位於Kubernetes Cluster內各台Worker Node上的Pod。那麼，『前端的應用遞送引擎，要怎麼把用戶連線轉送到後端的Pod呢』？

乍看起來很單純，但如果大家熟悉Kubernetes的網路架構，就會發現，問題很不簡單，因為

• 不同的CNI (Container Network Interface) 對於Pod IP的處理方式不一樣

• 不同的公有雲方案內建置Kubernetes環境時，對於Pod IP配置的機制也不一樣

而AKO在設計上是要能夠在不同雲、不同Kubernetes方案內都能夠提供應用遞送支持的。因此要如何在不同架構內都能夠連通網路達成應用遞送的能力，當然是方案設計時的必要考慮。下面我們列出數種不同環境內常見到的Pod網路部署方式，並說明AKO方案解決網路連線的方法。

1. Pod放置的網段與企業網路間沒有外部路由：採用靜態路由 - ClusterIP機制

Kubernetes內一個極為常見的標準網路部署機制是各個Pod會放在Worker Node的內部網路內，這個內部網路 (下圖的Pod Network，或稱Pod CIDR) 與外部是沒有路由連通的。當我們自建Kubernetes，採用像Calico / Flannel / Weave / Antrea這些開源方案，預設模式幾乎都是這樣。下圖內，

• Pod A / Pod B位於Worker Node 1內，取得的IP是Worker Node 1內部Pod網路的192.168.101.0/24網段。同樣的Pod C / Pod D位於Worker Node 2內，取得的IP是Worker Node 2內部Pod網路的192.168.102.0/24網段

• 實體企業網路 (下圖的10.100.1.0/24) 與Pod Network沒有路由連接。

此時當我們前端配置一個對應B Service / Ingress的Virtual Service，要由後端的Pod A~D來提供服務，服務引擎必須要能夠建立與這些藏在內部網路Pod間的網路連結。AKO在這邊有兩種處理方式，第一種是當服務引擎可以與各台Worker Node的實體網路介面在同一個實體網路內時，如上圖，Service Engine與Worker Node的介面都在10.100.1.0/24網路內。此時最簡單的模式在AKO內叫做Static Routing，或在一些文件內叫做ClusterIP。

以上圖為例，當AKO設置為ClusterIP模式時，此時在這個Virtual Service對應的Server Pool內，會顯示各個Pod內部的IP：

但同時，AKO會monitor目前每個Pod是在哪台Worker Node上，並通知Avi Controller要自動建立下列的靜態路由配置：

特別再次強調，上面這個路由表，是AKO告知Avi Controller『自動配置』的。管理者無需手動自行建置。

透過上述的靜態路由自動配置機制，當服務引擎上要將用戶封包遞送到後端比如說Pod C (192.168.102.17)，此時參照靜態路由，服務引擎知道封包要往Worker Node 2: 10.100.1.102這邊送。當Worker Node 2收到此封包，因為192.168.102.17是位於其自己的內部網路，當然就能將封包正確遞送到Pod C上。

這邊的Static Routing / ClusterIP 是AKO架構內最常使用到，來建立服務引擎與內部Pod間連線的機制。但實際上還有各種不同的狀況，比如說在有些客戶，Worker Node所在的網段，與Avi Service Engine可以連接的網段間是不能二層連通，必須走路由的，此時上面的做法就會出問題。在下篇我們要繼續介紹另外兩種機制：利用NodePort / NodePortLocal來建立服務引擎與Pod間連線的網路架構。