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

Antrea Egress這個功能最早於社群版本1.2開始推出為Alpha階段，於1.6版至今（寫作當時為社群版本1.8版）進入Beta階段，已經是一個廣為測試的功能。Egress主要解決的問題就是前篇內提到，在Kubernetes Pod要連接到企業外部系統時，不要採用預設的以NAT將來源位置轉換為K8S Node IP，而可以基於管理者需求，by Namespace甚至by Pod指定來源地址。這個需求幾乎我們在每個企業用戶的容器專案都會聽到。

但開始介紹前先補充說明一下前段的Alpha / Beta階段，Antrea本身的每個Feature在推出時，會有三個階段：

  • Alpha階段：功能已經推出，但預設會關閉。管理者如果要使用，可以修改相關的配置檔已啟用
  • Beta階段：功能已近穩定，預設即會打開。但管理者如果不要此功能，可以修改相關的配置檔來關閉。
  • GA階段：功能穩定，預設就會打開而且無法關閉。

上述的定義與Kubernetes內各個功能階段定義是相同的。如果大家想要知道Antrea的各個功能，如接下來要介紹的Egress / IPAM等，目前是在哪個階段，可以到下列網址查詢：https://antrea.io/docs/main/docs/feature-gates/

回頭來討論Antrea Egress功能。當一個Pod有啟用Antrea Egress功能，且要往外部連線時，這個Pod的網路封包

  • 不是由所在K8S Node的介面IP做SNAT，而是先透過Overlay機制，將封包送往指定提供Egress功能的K8S Node，再以管理者指定的Egress IP做SNAT後對外傳出
  • 可以基於Namespace / Pod 來指定不同的Egress IP。

用下面這張圖來做說明：

  • K8S叢集內有兩個Namespace: lab 以及 yelb-app。每個Namespace內有多個Pod，分佈在不同的K8S Worker Node內。
  • 各個Pod的IP定址與標準Kubernetes定址方式一樣，只要是在Node 1上的Pod，IP都是配置於10.203.1.0/24網段。只要是在Node 2上的Pod，IP都是配置在10.203.2.0/24網段。因此，在每個Namespace內的Pod，IP地址是混雜在各個不同網段內的，無法用來源IP來進行判斷這個Pod是屬於哪個Namespace / 應用
  • 但我們啟用Antrea Egress功能，並指定所有lab namespace內的Pod（紫色），都要改由Node 1為出口。且從這個Node出去時，來源IP不是採用介面地址 (172.16.18.121)，而是管理者指定的172.16.18.131這個Egress IP地址。此時所有在紫色Namespace Lab裡面的Pod的連外網路流，都會先透過Overlay機制被送到Node 1上，再做SNAT把來源IP改為172.16.18.131，再往外傳送。
  • 同樣地，yelb-app的出口Node在Node 2，且SNAT轉換之來源IP地址會是172.16.18.132這個Egress IP。所有在橘色Namespace Lab裡面的Pod的連外網路流，都會先透過Overlay機制被送到Node 2上，再做SNAT把來源IP改為172.16.18.132，再往外傳送。

這時候在外部環境的防火牆或資訊設備，如上圖內的資料庫，如果看到的是來自172.16.18.131這個IP的網路流，代表是來自lab這個namespace（或應用）內的pod的網路連接。而如果是來自172.16.18.132這個IP的網路流，就是來自yelb-app這個namespace / project / application的應用了。此時無論我們是要進行防火牆阻擋，或在應用內要進行日誌記錄來源IP，就都能夠基於企業應用的方式來進行管理了。

對應到前篇內我們提到，在企業Kubernetes專案內常碰到的IP管理相關問題，Antrea Egress機制解決了最主要的那一項：位於不同Namespace，或具備不同K8S Label的Pod，可以用管理者指定的對外IP地址往企業網路進行連接，達成需求的安全政策阻擋與稽核管理，如下圖。但另外三項，包括需要外部可以路由直接連線，Pod IP固定等，就不是Egress機制能做到的了。

本篇內我們討論了Antrea Egress的基礎運作機制及解決的問題。下篇我想實際地更進一步說明Egress功能的配置，以及相關的議題討論。