虛擬雲網路

網路虛擬化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:

Server1 — Pod-A: 192.168.101.13               
Server2 — Pod-B: 192.168.101.22               
Server3 — Pod-C: 192.168.102.17               
Server4 — Pod-D: 192.168.102.36

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

To 192.168.101.0/24 Network — GW: 10.100.1.101
To 192.168.102.0/24 Network — GW: 10.100.1.102          

特別再次強調,上面這個路由表,是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間連線的網路架構。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注