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

本篇開始談Antrea在網路上的另一個重要功能Antrea IPAM。本系列網誌的第十二篇裡有和大家詳細討論基礎Kubernetes內Pod的IP定址機制，或是叫做Node IPAM。快速回憶一下，在基礎機制內，

  • 每一個Kubernetes Node內會被分配一個獨立的子網段。
  • 當一個Pod被分派在某台Node內啟用運作時，會從這個Node的內部子網段內分派一個IP 地址填入。
  • 在同一個Namespace內的不同Pod，拿到的IP地址是對應到的網段是混亂的，僅能判斷這個Pod是在哪個Node上，完全無法從IP辨認這個Pod是隸屬哪個Namespace / Project / 應用。
  • 沒有辦法手動指定或是固定一個Pod的IP地址。如果一個Pod被刪除重啟，可能拿到完全不同的IP地址。
  • 外部系統一定得要透過NAT (Service LoadBalancer或是Nodeport) 才能連到K8S內部的Pod

上述的狀況在雲原生應用不嚴重，但如果企業把一個原本在實體機或虛機上的傳統應用，不修改就直接要放到Kubernetes內運作，上面的定址方式就會造成大問題：應用內的IP稽核方式無效，過NAT造成連線失效，應用構件內IP地址寫死無法更動，這種亂七八糟的問題都會冒出來。因應到這些要求，Antrea這邊的回應就是直接採用不同的定址機制，也就是這邊開始要談的Antrea IPAM。

當我們運作Antrea IPAM機制時，

  • 每個Namespace內或是由label指定的Pod，可以直接分派到不同範圍的IP Pool，指定不同的VLAN tag。
  • 可依需求指定Pod IP地址。
  • 由實體網路設備直接提供底層各網段、網段間的閘道，及對應的VLAN。
  • Pod與Pod或是Pod對外的連線不做SNAT，也不進行封裝，全部由實體網路提供傳輸。

在上圖內，

  • 紫色Namespace: ns-ap內的所有Pod，定址都放到172.16.19.0/24網段內。當這些Pod連外時，K8S Node會打vlan 19 tag到網路封包內，運作於底層的vlan 19二層網段。
  • 同樣的，橘色Namespace: ns-db內的所有Pod，定址都放到172.16.20.0/24網段內。當這些Pod連外時，K8S Node會打vlan 20 tag到網路封包內，運作於底層的vlan 20二層網段。
  • 172.16.19.0/24 (vlan 19)、172.16.20.0/24 (vlan 20)、及外部網路間的路由，全部由標準網路路由設備提供。

上面的機制應該很直接很容易理解吧，請問大家，這和標準的傳統虛擬化定址機制，有什麼不一樣呢？

完全沒有不一樣。請想像一下，上圖相當於虛擬化環境內有兩個Port Group分別對應VLAN 19與VLAN 20。不同業務的虛機將網卡各自接到對應的Port Group上。沒有NSX的標準虛擬化方案，Port Group沒有三層路由機制，因此底層實體網路也同樣要預先把對應兩個網段的VLAN與路由配置好。然後所有虛機間的通訊就直接由實體網路進行。

既然是這麼傳統這麼直接的做法，那在原本傳統環境運作的業務雖然轉成了虛機，在上面當然還是可以跑得嚇嚇叫：

  • 每一個Pod的IP地址完全要放哪個網段，是否要固定，完全可以由管理者來進行配置。
  • Pod的IP地址與實際業務、機器可以做到一對一對應，安全政策配置或稽核管理都與傳統方式一致
  • 以實體網路用路由的方式進行連線，沒有任何NAT去進行來源或目的IP變更。

很不錯對吧，但我還是重複地要問有這些網路需求的客戶一個問題，既然上面的這些要求如此重要，應用又怎樣都不能改，『你們幹嘛不繼續用虛擬機就好了呢』？

先到這邊，下篇我們進行Antrea IPAM的細部配置介紹。