本文將說明Container生產環境內的網路與安全架構及需求，先說明SaaS Web生產架構內有那些重要的構件，分別加以介紹，然後剖析Docker網路架構的運作方式，最後說明Kubernetes（K8S）內的PoD、網路以及服務。
部署Kubernetes（K8S）
為什麼現在許多企業在生產環境內，會運用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由八個提升到十六個時，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。
在圖3內，大的空心六角形是K8S內的Node（提供資源的實體或虛擬機），而在每個Node內可以有多個Pod（實心六邊形），每個PoD都有自己的IP地址。在不同Node內的不同Pod，必須能夠互相連通，比如說圖內的10.10.10.2與10.10.10.3兩個Pods雖然在不同的Node，也要能直接互連。
 |
| ▲圖3 K8S運作示意圖。（資料來源：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 / Type = LoadBalancer）。
回到圖3，當其他的用戶或服務要連到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開發是個好架構，但為什麼K8S/Docker底層應該用NSX呢？」
除了剛剛談到的可以提供跨實體層的邏輯網路及南北向負載平衡外，大部分其他的方案，都還沒有辦法做到下列在生產環境內很重要的事情：
1. 微服務間與微服務內怎麼進行安全阻隔？簡而言之，容器間的微分段怎麼做？
2. 如果明明應該要能通的，結果卻不知道為什麼不通。要怎麼進行K8S內網路的Troubleshooting？
已經太長篇大論了，在接下來的投稿，要和大家討論NSX-T與K8S整合的效益與演示。而上述關於K8S內的PoD、網路、Service的介紹其實很簡略，若有興趣，建議到「https://kubernetes.io/docs/concepts/cluster-administration/networking/」這個網頁以及其他的相關連結進一步了解。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞