解決K8s網路定址缺陷　Antrea Egress從頭學(二)

前篇文章舉了一個採用Antrea Egress的例子，並說明透過此項機制，可讓位於不同Namespace，或具備不同K8s Label的Pod，以管理者指定的來源IP地址轉址後往外部網路進行連接，達成企業需求的安全政策阻擋與稽核管理。而本文將進一步說明Antrea Egress的細部配置機制。首先，再度貼上架構釋例圖，如圖1所示。

Antrea Egress機制在社群版本1.6版之後預設為開啟，之前則是預設關閉。基本上，如果是安裝最新的版本就不用考慮開啟配置的問題，但這個功能的開關是在Antrea的ConfigMap內。可以用「kubectl get configmap -n kube-system | grep antrea-config」指令找出ConfigMap的名稱，然後執行「kubectl edit configmap」指令來查看與修改。與Egress相關的配置分別在antrea-agent.conf和antrea-controller.conf內，要確認Egress的配置是顯示為true，如圖2所示。

接著，在上述的配置中，希望在lab Namespace（圖1左上部分）內的Pod往外連線時，要帶172.16.18.131這個IP，yelb-app Namespace（圖1右上部分）內的Pod往外連線時，要帶172.16.18.132這個IP。要進行此配置，必須先建立一個ExternalIPPool物件：

apiVersion: crd.antrea.io/v1alpha2 kind: ExternalIPPool metadata:   name: external-ip-pool spec:   ipRanges:   - start: 172.16.18.131     end: 172.16.18.139   nodeSelector: {}  # All Nodes can     be Egress Nodes

在上面的配置內建立了一個External IP Pool，名稱叫做external-ip-pool。這個Pool內包含了172.16.18.131到172.16.18.139共9個可以後續配置為Egress IP的地址（必須與K8s Node IP同網段）。然後，配置了一個nodeSelector的空集合。nodeSelector定義了哪些Kubernetes Node可以被用來作為Egress對外使用。如果沒有配置，代表每一個K8s Node都可以被選為Egress出口。

接著，定義一個Egress物件叫做egress-lab。在下面的配置中，要求所有來自lab namespace的Pod（定義於namespaceSelector），要指定採用172.16.18.131這個IP地址作為對外的來源IP：

apiVersion: crd.antrea.io/v1alpha2 kind: Egress metadata:   name: egress-lab spec:   appliedTo:     namespaceSelector:       matchLabels:         kubernetes.io/metadata.         name: lab   externalIPPool: external-ip-pool   egressIP: 172.16.18.131

相同地，下面的配置對應所有yelb-app namespace的Pods，連外時要採用172.16.18.132這個IP地址作為來源IP：

apiVersion: crd.antrea.io/v1alpha2 kind: Egress metadata:   name: egress-yelb-app spec:   appliedTo:     namespaceSelector:       matchLabels:          kubernetes.io/metadata.          name: yelb-app   externalIPPool: external-ip-pool   egressIP: 172.16.18.132

接著，將三點很快地說明一下：

‧在Egress內指定的egressIP必須要位於前面定義的external-ip-pool內，如果沒有寫，就會由前面的Pool內隨機分配一個。

‧沒有辦法指定各個Namespace一定要採用哪個Node做出口，但在ExternalIPPool內的nodeSelector可以限制出口會位於哪幾台K8s Node上。

‧在Egress內，除了採用namespaceSelector來選擇一個Namespace的所有Pod外，也可以利用podSelector，透過pod label來選擇具有特定標籤的Pod。

進行完上述的配置，可以使用「kubectl get egress」指令查看相關狀態。從圖3內可以看到，對應到lab namespace的egress-lab，採用的Egress IP是172.16.18.131，指定到antrea-lab-node-01這個K8s Node上。而對應yelb-app namespace的egress-yelb-app，採用的Egress IP是172.16.18.132，指定到antrea-lab-node-02這個K8s Node上：

root@antrea-lab-mgmt-01:~# kubectl get egress NAME    EGRESSIP    AGE    NODE egress-lab         172.16.18.131    9m14s             antrea-lab-node-01 egress-yelb-app    172.16.18.132     9m14s            antrea-lab-node-02

實際驗證一下，圖3是在lab namespace內建的pod busybox-deployment-f554854db-cljxm，位於node-01上，IP是10.203.1.9。使用kubectl exec指令，由這個Pod去ping外部的資料庫172.29.161.22，由圖3看到可以ping通。同一時間，在上列資料庫上用Wireshark抓連線封包，能夠看到這些ping網路流來自172.16.18.131。

接下來，透過同樣在lab namespace內，另一個位於node-02上的pod busybox-deployment-f554854db-m28r7，IP是10.203.2.7。一樣由這個Pod去ping相同的資料庫172.29.161.22，在Wireshark看到這些ping網路流仍然是來自172.16.18.131，如圖4所示。

然後，換一個Namespace。在yelb-app namespace內，位於node-01上的pod yelb-ui-c45c7dbbc-fph6n，IP是10.203.1.4。從這個Pod去ping 172.29.161.22，在Wireshark看到網路流來源改變了，是來自172.16.18.132，如圖5所示。

在上面的展示配置，以及從Wireshark實際抓封包可看出Egress功能的運作機制，確實能夠達成讓兩個不同Namespace（lab/yelb-app）內的Pod，各自帶不同以管理者能夠指定的來源IP地址轉址後，再往外部網路進行連接。希望本文中的討論可以讓大家更進一步地了解Antrea Egress相關的運作機制。上述的相關配置如果各位想要了解細部資訊，可以連到「https://antrea.io/docs/main/docs/egress/」這個網頁，對於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的功能。

回顧一下與本篇開頭相同的展示架構圖，如圖6所示。

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

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

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

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

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

Antrea Egress的配置限制

Antrea要運作Egress機制有兩個主要限制：

1. 目前僅能在Linux Node上運作，無法在基於Windows的Kubernetes Node上運行。

2. 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部署時必須使用「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的控制器會定期（5分鐘）檢查相關配置，並把手動配置部分移除，重新變回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功能開啟即可，如圖9所示。

結語

這兩篇文章已就Antrea Egress的相關架構、效益、功能進行了詳盡討論，應該是在多數Kubernetes部署環境內對企業客戶具有好處的機制。到此，本系列以總共六篇的投稿進行Antrea的討論，包含架構、授權方式，以及幾個重要功能，包括與NSX的安全整合，還有網路端的Egress機制等。Kubernetes無可否認地是企業IT Infra環境的現在進行式，而底層Container Network Interface是否穩定並具備企業需求的安全與網路功能，自然也會是資訊單位關注的重點。希望透過這六篇文章，讓大家對Antrea的功能、效益與運作機制能有更進一步的了解。

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞