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

前兩篇內我們說明了Antrea Egress的效益，並以實際展示說明其運作機制。本篇內我想繼續討論Antrea Egress的幾個相關議題，包含High Availability機制，使用限制，以及於VMware Tanzu內的支援。

Antrea Egress High Availability機制

大家理解了前兩篇討論的Antrea運作架構後應該會有一個疑問，如果Egress機制將指定的Pod（在同一個Namespace內或有同一個Label）要往外連線時，都先送到某一個Kubernetes Node上再往外送，那如果這個Kubernetes Node失效了怎麼辦？是不是這些Pod就不能連外了？Antrea Egress設計時當然有考慮到這樣的狀況，因此預設就有High Availability的功能。

下圖是與前兩篇網誌相同的展示架構圖：

在之前的配置內，yelb-app這個namespace（橘色）內的所有Pod要連外時，會先都送到Node 2上，再將來源IP以SNAT轉換為管理者指定的172.16.18.132後送出去。而如果Node 2失效了呢？

此時Antrea會自動將這個Egress配置到其他可以運作的Kubernetes Node上，於這個範例就是Node 1。而出口IP不變，同樣是管理者指定的172.16.18.132。此時，所有橘色Pod要連外時，就會改用Node 1作為出口了。

同時上圖也可看到，轉換後，兩個namespace對應的Egress此時都在Node 1上。Antrea Egress運作時預設會儘量分散，但沒有規定不同的Egress不能在同一個Node上。但當時，此時這兩個Egress就會同樣吃同一個Node網卡的進出流量了。

下圖是一個簡單的測試，我從上圖的10.203.1.4這個Pod持續去ping 外部的172.29.161.22，然後手動直接把Node 2的虛機用Power-Off的方式強制關掉。下圖內可以看到，中間掉了六個ping，但就自動恢復了。不是非常完美的無感移轉，但是也算是秒級恢復了。

Antrea Egress內的High-Availability是預設機制，不需要任何額外配置。只要在External IP Pool內指定的nodeSelector不是只有一個，在某個Kubernetes Node失效下仍然有其他的Node可以運作，就能自動進行轉換。

Antrea Egress 的配置限制

首先以社群版本來說，Antrea要運作Egress機制有兩個主要限制：

  • 目前僅能在Linux Node上運作，無法在基於Windows的Kubernetes Node上運行。
  • Antrea啟用時，必須採用”encap”封裝模式

第二點多做一些說明。encap模式的意思是兩個不同Kubernetes Node上的Pod之間，或是一個Pod要對外，先送到Egress所在的Node，有上面這樣『跨Node』的Kubernetes叢集內部網路傳輸需求時，Antrea會透過OVS將要傳輸的Traffic先進行封裝（預設與NSX一樣是採用Geneve協議），再由底層實體網路進行傳輸。Antrea在絕大部分的環境安裝都是採用encap模式，所以這個問題不太大。但在某些特殊情況下，Antrea安裝時可能會改為採用不要封裝”NoEncap”模式，或是混合式的”Hybrid”模式：

  • 在底層網路上手動或整合SDN，以路由模式來傳輸各個Node內部網路間的封包。
  • 在公有雲建立的Kubernetes上，讓底層網路傳輸由預設CNI進行，Antrea僅作安全政策控制
  • 啟用Antrea本身的IPAM (IP Address Management) 機制

Antrea IPAM後面會繼續討論，前兩個場景算是較特殊架構，就只先簡單說明。這邊主要強調的是Antrea Egress機制必須要運作於encap模式，因此如果由於某些特定理由，Antrea部署時得使用”NoEncap”或”Hybrid”模式時，就不能運作Egress功能。

Antrea Egress在Tanzu上的運用

更直接大家關心的應該是，看起來這個Egress機制很不錯，可以解決部分企業關心的Kubernetes網路相關問題。目前已經要部署一個Tanzu的Kubernetes專案，是不是Egress機制就能開始啟用了呢？

首先要說明，在前篇我們有討論，只要版本有支援，要啟用Egress功能可以直接改Antrea的ConfigMap，將Egress功能設定改為True。而在社群版本1.6之後，Egress功能進入Beta階段，甚至預設就打開了呀？

但是，

  • Tanzu部署的TKC底層用的是Antrea企業版本 (VMware Container Networking with Antrea)，著重於穩定，沒有社群版本更新的那麼快。
  • 在Tanzu內的企業版本Antrea，不能直接去改ConfigMap更動設定。詳細一點說，即使管理者手動改了ConfigMap，Tanzu的控制器會定期（五分鐘）檢查相關配置，並把手動配置部分移除，重新變回Tanzu允許的預設配置。

所以呢，不能用社群版本的方式手動改。在本文寫作的時間點，狀況是這樣：

  • Tanzu Kubernetes Grid 1.6版後已經支持Egress功能，可以正常使用。Egress相關配置可以透過FeatureGate來開關。
  • vSphere with Tanzu最新的1.23版TKC內也開始支持Egress功能了，大家可參考https://blogs.vmware.com/networkvirtualization/2022/11/antrea-egress-vsphere8-with-tanzu.html/ 這篇官方部落格文章內描述的流程。只要在建立TKC前，先配置一個AntreaConfig，並於featureGates內將Egress功能開啟即可，如下圖：

好的，這三篇我們就Antrea Egress的相關架構、效益、功能進行了詳盡討論，應該是在多數Kubernetes部署環境內對企業客戶具有好處的機制。但如同前幾篇網誌內說明，除了Egress機制解決的來源IP指定轉址效益外，客戶在轉換到容器環境時，可能還會要求比如說Pod IP不能異動甚至需要指定，外部設備不要透過任何NAT機制（像LoadBalancer / Nodeport）就要直接連到這些Pod等等的網路需求，而這些不是Egress能夠做到的。Antrea對於上述要求的回應是IPAM功能，在後續網誌會繼續與大家討論。