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

首先，為什麼企業在生產環境內會運用Kubernetes (K8S)來進行容器式的應用部署？

  • K8S建立能乘載容器運作，由多個底層虛機或實體機建立的資源池。用戶（開發團隊）進行應用部署時，不需要再去考慮是放在哪台主機上、哪個網路、儲存設備這些問題
  • K8S不是在管理一個一個container，而是以基於微服務的應用方式來進行配置。開發團隊可以撰寫一個應用的宣告檔：有哪些微服務、各微服務內的docker image是哪個、版本是多少、一個微服務內要起幾個container、有哪些標籤？這個宣告檔 (YAML format) 可以很容易地在小幅修改後拿到不同的K8S環境內（比如說測試環境移到生產環境，公有雲移回私有雲）來進行運作，部署出一模一樣的應用
  • K8S會監控底層與容器的狀態，並且在狀態改變時嘗試去回復。舉例來說，如果K8S的Master看到有一個Node（虛機 / 實體機）不見了，會嘗試將在這個Node上運作的container在其他還有正常運作的Node重開。
  • K8S自己提供應用內服務到服務間的東西向負載平衡機制（無需第三方方案）。當用戶要把任一服務內的容器進行scale-out / scale-in，比如說，用戶把Web container由8個提升到16個時，K8S內的負載平衡機制也能自動對應處理。採用K8S的應用，用戶僅需要考慮南北向（外部到應用）的負載服務機制
  • K8S能夠很容易地進行應用的升版 (Rolling Upgrade) 或回復 (Restore)。或是開發團隊在採用兩組生產環境，交互升級的Blue/Green Deployment機制時，K8S也能夠極為容易地進行整個應用 / 單一微服務的升版作業

嗯嗯聽起來都很棒，但和網路都無關啊。好接下來開始了：如同我們在前篇docker network內討論的，docker的原始機制問題是用了一大堆NAT。在同一個Host內的容器間溝通沒問題，但有兩組以上的docker host這下問題就大了。在Kubernetes內，網路配置要求：

  • 在環境內，無論放在哪邊，container與container間的溝通不可以有NAT，必須要直接溝通。
  • 各個K8S node（K8S環境內提供乘載container資源的虛機或實體機）與container間的溝通不可以透過NAT
  • 任一個container看到自己的IP與其他container看到他的IP必須一樣（同樣的，沒有NAT）

簡而言之，K8S內的環境必須要建立一個/多個跨不同設備 (nodes) 的共通網路，各個容器都直接連在這些網路上互通，無需透過NAT轉換。一個應用內的多個微服務部署時，各個容器會有自己的IP定址，即使跨多個實體設備，容器能透過這些IP直接互連。

K8S內定義了一個新的構件叫做Pod。一個Pod可以放一個或多個容器（但常只有一個，如果有兩個以上容器，連接Port必須不一樣），每個Pod會有一個獨一無二的IP。在下圖內，大的藍色六角形是K8S內的Node （提供資源的實體或虛擬機），而在每個Node內可以有多個Pod （紫色六邊形），每個PoD都有自己的IP地址。在不同Node內的不同Pod，必須能夠互相連通，比如說下圖內的10.10.10.2與10.10.10.3兩個Pods雖然在不同的Node，也要能直接互連

https://kubernetes.io/docs/tutorials/kubernetes-basics/expose-intro/

好，問大家一個問題。我們要在K8S內建立一個container / Pods本身可以看到、互通的IP網路，容器透過這個網路連接時，封包可能會跨不同的虛機 / 實體設備、跨越底層的實體網路來進行連接。上面的概念，在我們談NSX / SDN這些概念時，就是什麼東西？

就是邏輯網路 Logical Network啊！就是透過VXLAN / Geneve這些封裝協定，跨實體三層網路，跨設備建立K8S內可認得的邏輯交換器啊！這些事情我們NSX超強的啊。

還沒完。在K8S內的同一個微服務內會有多個容器。當其他微服務或外部用戶要接取到這個微服務時，K8S會利用不同的”Service”來定義連接的方式。Service有不同種類，比如說有微服務要連到另一個微服務時的東西向負載平衡機制 (Cluster IP)，或是由外部用戶要連到一個微服務的南北向負載平衡機制 (Ingress)。比如說回到上圖，當其他的用戶或服務要連到Service B (包含了10.10.10.2 / 10.10.10.3 / 10.10.10.4這幾個Pod以及之內的container)，是連到Service B的服務IP 10.10.9.2。K8S會再去配置這個連往10.10.9.2的要求，要由後端的哪台Pod/container來提供服務。

在服務與服務間的東西向負載平衡是由K8S自己進行。但南北向的負載平衡則會需要第三方的方案。那，什麼方案裡面可以動態、無限制地提供用戶需求的第三方負載平衡構件呢？NSX啊啊啊！

好，那K8S會怎麼實作出上述的網路要求呢？其實他們並沒有規定。能滿足上述機制的第三方方案都可搭配K8S運作。因此大家可能會聽到一些像是Flannel / Calico / Nuage / OVS Networking的不同產品。好，講到這邊，我們終於要詢問一個問題：看起來用K8S作為微服務 / SaaS App開發是個好架構，但為什麼底層應該用NSX呢？

除了剛剛談到的可以提供跨實體層的邏輯網路 / 南北向負載平衡外，大部分其他的方案，都還沒有辦法做到下列在生產環境內很重要的事情：

  • 微服務間與微服務內怎麼進行安全阻隔？簡而言之，容器間的微分段怎麼做？
  • 如果明明應該要能通的，結果卻不知道為什麼不通。要怎麼進行K8S內網路的troubleshooting？

因此在接下來的幾篇，我們要開始和大家討論NSX-T與K8S整合的效益與演示。

最後，上述關於K8S內的PoD / 網路 / Service的介紹其實很簡略，大家若有興趣，建議到https://kubernetes.io/docs/concepts/cluster-administration/networking/ 這個網頁以及其他的相關連結進一步了解。