接續本系列文章對於VMware支援之容器網路方案Antrea的介紹，接下來開始另一個話題，想與大家討論的是Antrea本身在客戶端應用的一個常用功能：Antrea Egress。但在開始說明此機制前，先得討論在原生Kubernetes方案內基礎的網路與定址設計，通常在企業環境內使用時有什麼缺陷，才進而能探討為什麼需要新的機制？有哪些效益？因此本篇第一個重點就先著重在「現行的問題是什麼」。
K8s網路傳統做法的局限性
圖1是用來舉例，但很典型顯示常見企業客戶Kubernetes環境的示意圖。在此環境內有一個Kubernetes叢集，上面放了多個生產應用，包括Portal、ERP、CRM、Vote。每個生產應用為了資源區隔等考量，放在各自對應的Namespace裡面。
請大家回憶一下原生Kubernetes最基本的定址機制，或是叫做Node-IPAM：
‧每一個Kubernetes Node內會被分配一個子網段。圖1中最左邊Node的內部網段是10.10.1.0/24，最右邊Node的內部網段是10.10.7.0/24。這裡的內部網段，當手動安裝Kubernetes用kubeadm init啟用時，可以用--pod-network-cidr參數給一個大範圍（例如10.10.0.0/16），然後每個新的Kubernetes Node加進來時，就從上面的範圍內拿一段走，做為自己的子網段。
圖1 常見的企業客戶Kubernetes環境示意圖。
‧當一個Pod被分派在某台Node內啟用運作時，會從這個Node的內部子網段中分派一個IP地址填入。在圖1左邊Node，裡面有來自Portal、ERP、Vote不同Namespace內建立的Pod，每個Pod拿到的都是10.10.1.0/24內的IP地址。相同地，最右邊的Node裡面有Portal、ERP、CRM三個不同Namespace內建立的Pod，每個Pod拿到的都是10.10.7.0/24內的IP地址。
‧在同一個Namespace（同一個Project、應用）內，各個Pod拿到的IP地址是混亂的，例如ERP Namespace內的Pod，拿到的IP來自不同網段，包括10.10.1.12、10.10.7.11、10.10.9.82、10.10.10.2。
接著看圖2，客戶的現狀是應用資料庫目前還在外部沒有轉成容器，因此K8s內的Pod要能夠連到外部資料庫進行存取。
圖2 K8s內Pod連到外部資料庫進行存取。
在標準Kubernetes的Pod基礎連外機制（Egress）做法是什麼呢？
‧每個Pod連外時，預設都會用所在K8s Node的Interface IP做Source-NAT。圖2中，在左邊Node裡面，所有不同Namespace的Pod往外連線時，來源地址都會改為172.16.11.11的Interface IP；同樣地，右邊Node裡面的所有Pod連到外面世界時，都會帶172.16.11.17的Interface IP。
‧在外部的防火牆或是資料庫設備，看到這些連線時，只會看到來源地址是來自各台K8s Node的介面IP，無法區分這個連線是來自哪個Namespace、Project、應用。舉個需求請大家想一下，如果外部的ERP資料庫要限制只有「屬於ERP應用的Pod」可以連線到它身上，此時要怎麼做呢？
傳統K8s網路機制對客戶轉型造成困擾
用圖1、圖2兩張圖來討論了近年幾乎在每個客戶Kubernetes生產環境都有碰到的網路問題，簡單做個整理。如圖3所示，這些問題尤其常出現在金融與政府客戶要進行應用轉型過程當中：
圖3 傳統Kubernetes網路機制對客戶轉型過程中的困擾。
1. 外部防火牆或業務系統只看得到K8s Node IP，看不到真實的應用網路連線來源，無法對應是哪個業務系統，此時在資安政策要求的防火牆控管、應用連線稽核紀錄都無法進行。
2. 也不單純是連外才有這個問題，即使都在Kubernetes內部連接不用NAT，但當應用仍然要求記錄連線資訊時，看到的IP是雜亂的。例如前面的案例，如果AP日誌紀錄了有10.10.1.5的Pod來連接它，只會知道這是一個在Node 1號上面運作的Pod，其他什麼資訊都沒有。況且Pod如果重啟，IP就換掉了，這個IP資訊根本沒有意義。
3. 對於外對內的連線，很多客戶也希望不要有NAT像是Nodeport、LB、Ingress等機制，而可以直接用標準路由的方式讓外部系統連到這些Pod。在基礎標準CNI運作方式是不容易滿足的。
4. 很多客戶希望Pod產生時IP可以固定不要變動。當然，通常也是稽核的考量。甚至有些是應用不想改，程式碼內就把IP寫死了。
在近幾年與客戶的互動過程中，上面的2、3、4點都是可以討論的。客戶通常在互動溝通後能夠理解在轉型到雲原生方案的過程中，需要逐步將IP對應用的影響與綁定移除掉。IP地址只是最底層要連接時的構件，但上層應用構件互聯時，就僅用構件的服務名稱、FQDN即可。應用層構件的識別應該採用像是公私鑰而非IP地址，而構件間的安全保護，也應該改由Label、Service這些來定義而不會是IP或網段。如果客戶整個應用從上層往下都採用雲原生的概念來考慮，構件都改為容器，上述2到4點的需求可以緩解。
但第1點的要求是硬需求，客戶在重要防火牆前肯定會採用安全設備限制只有哪些應用可以連過來，而如果K8s內的Pod在對外連線時，都只能依據「目前在哪個Node」上來做NAT連接，此時外部防火牆根本無法區分這個連線是來自哪個Namespace、Project及應用，並據此進行連線控制。因此，在接下來的文章將更詳細地說明在Antrea內的Egress功能會如何解決這個問題。
改用Antrea Egress機制
當一個Pod有啟用Antrea Egress功能，且要往外部連線時，這個Pod的網路封包：
‧不是由所在K8s Node的介面IP做SNAT，而是先透過Overlay機制，將封包送往指定提供Egress功能的K8s Node，再以管理者指定的Egress IP做SNAT後對外傳出。
‧可以基於Namespace/Pod來指定不同的Egress IP。
接著，就用圖4來做說明：
圖4 Antrea Egress機制示意圖。
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（圖4左上部分），都要改由Node 1為出口。且從這個Node出去時，來源IP不是採用介面地址（172.16.18.121），而是管理者指定的172.16.18.131這個Egress IP地址。此時所有在圖4左上部分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。所有在圖4右下部分Namespace lab裡面的Pod的連外網路流，都會先透過Overlay機制被送到Node 2上，再做SNAT把來源IP改為172.16.18.132，再往外傳送。
這時候在外部環境的防火牆或資訊設備，如圖4中的資料庫，如果看到的是來自172.16.18.131這個IP的網路流，代表是來自lab這個Namespace（或應用）內的Pod的網路連接。而如果是來自172.16.18.132這個IP的網路流，就是來自yelb-app這個Namespace、Project、Application的應用了。
此時，無論是要進行防火牆阻擋，或在應用內要進行日誌記錄來源IP，就都能夠基於企業應用的方式來進行管理了。
結語
本篇文章討論了Antrea Egress的基礎運作機制及解決的問題。下篇文章將實際地更進一步說明如何配置，以及進行相關的議題討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞