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

接續Antrea網誌系列，接下來我想和大家討論的是Antrea本身的兩個網路與定址相關功能：Antrea Egress / Antrea IPAM。但在開始說明這兩個機制前，先得討論在原生Kubernetes方案內基礎的網路與定址設計，通常在企業環境內會產生什麼問題，才進而能探討為什麼需要新的機制，有哪些效益。因此本篇的重點就先著重在『現行的問題是什麼』。

下面是本篇用來舉例，但很典型顯示常見企業客戶Kubernetes環境的示意圖。在此環境內有一個Kubernetes叢集，上面放了多個生產應用 (Portal / ERP / CRM / Vote)。每個生產應用為了資源區隔等考量，放在各自對應的Namespace裏面。

請大家回憶一下原生Kubernetes最基本的定址機制，或是我們叫做Node-IPAM：

  • 每一個Kubernetes Node內會被分配一個子網段。上圖內，最左邊的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加進來時，就從上面的範圍內拿一段走，做為自己的子網段。
  • 當一個Pod被分派在某台Node內啟用運作時，會從這個Node的內部子網段內分派一個IP 地址填入。在上圖左邊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。

接著請看下面第二個圖。客戶的現狀是應用資料庫目前還在外部沒有轉成容器，因此K8S內的Pod要能夠連到外部資料庫進行存取。

在標準Kubernetes的Pod基礎連外機制 (Egress) 做法是什麼呢？

  • 每個Pod連外時，都會用所在K8S Node的Interface IP做Source-NAT。上圖內，在左邊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可以連線到它身上，此時要怎麼做呢？

用上面兩張圖，我們討論了近年幾乎在每個客戶Kubernetes生產環境都有碰到的網路問題，用下面這張圖來做個整理。這些問題尤其常出現在金融與政府客戶要進行應用轉型過程當中：

  • 外部防火牆或業務系統只看得到K8S Node IP，看不到真實的應用網路連線來源，無法對應是哪個業務系統，此時在資安政策要求的防火牆控管、應用連線稽核紀錄都無法進行
  • 也不單純是連外才有這個問題，即使都在Kubernetes內部連接不用NAT，但當應用仍然要求紀錄連線資訊時，看到的IP是雜亂的。比如說在前面的案例，如果AP日誌紀錄了有10.10.1.5的pod來連接它，我們只知道這是一個在Node 1號上面運作的Pod，其他什麼資訊都沒有。況且Pod如果重啟，IP就換掉了，這個IP資訊根本沒有意義
  • 對於外對內的連線，很多客戶也希望不要有NAT像是Nodeport / LB / Ingress等機制，而可以直接用標準路由的方式讓外部系統連到這些Pod。在基礎標準CNI運作方式是不容易滿足的
  • 很多客戶希望Pod產生時IP可以固定不要變動。當然，通常也是稽核的考量。甚至有些是應用不想改，程式碼內就把IP寫死了。

先講一下之前每次聽到這些客戶要求時，我的內心想法喔。簡而言之就是：那你繼續用虛機不就好了嗎？用虛機也是部署很快很敏捷很穩定效能很好的啊？上面你的每個要求用vSphere全部通通都做得到啊？

基本上是這樣喔，整個雲原生應用，還有Kubernetes架構相關的設計，就是要把IP對應用的影響與綁定移除掉。IP地址只是最底層要連接時的構件，但上層應用構件互聯時，就僅用構件的服務名稱 / FQDN即可。應用層構件的識別應該是採用比如公私鑰而非IP地址，構件間的安全保護，也應該改由Label / Service這些來定義而不會是IP或網段。如果客戶整個應用從上層往下都採用雲原生的概念來考慮，構件都改為容器，前面那四個困擾應該是不存在的。

但現況就是絕大部分的企業應該都還會有這些原本應用的技術債，難以在短期內大幅翻新。也因此，如果新技術方案在企業轉型過程中，能夠解決或至少緩解上述問題，那對客戶當然也會有很大的好處。我們接下來討論Antrea Egress與IPAM功能，就會著重在如何透過這些新機制，來解決前述客戶的痛點。