接續前面的文章，對於在利用Kubernetes（K8S）的大型生產環境內，NSX-T如何提供網路接取及維運除錯的功能的展示，這裡將要與大家討論在Kubernetes環境內如何利用NSX-T做到Container間的微分段。
有很多點需要思考！生產環境內除了能夠讓應用正常執行，還需要考慮到效能是否符合需求、失效時可否快速回復、安全機制是否遵循規範、更新與換版應該要如何執行、管理是否方便。VMware之所以能夠大幅度地將原本資料中心內的實體架構汰換為虛擬化架構，是因為透過vCenter/vSphere以及對應的管理與維護功能，在不同客戶的環境內證明符合上述生產環境的需求，很多地方甚至比原本的實體機表現更好。
那當這一天來臨：開發團隊已經利用容器的方式來進行服務開發，直接提供不同微服務的Docker Image，要求在生產環境進行部署。以企業來說，這個服務要放在哪裡呢？
公有雲是一個選項。在AWS的Elastic Container Service、GCP的Google Kubernetes Engine、微軟的Azure Container Service這些平台上進行新應用的開發是非常簡易快速的，但上生產環境是另一回事，或許精算後成本太高、企業的重要營運秘密與客戶資料不能放到公有雲上、Service Level還無法達到需求等等。
所以，要規劃放在自己的資料中心內吧？那此時，大家會只裝台Linux，上面裝個Docker，就當作生產環境了嗎？不會吧！就像前幾篇問大家的一樣：生產環境裡的虛擬化架構不會只有單台vSphere。大家會規劃幾台x86伺服器，內接∕外接儲存，負載平衡機制考量，網路與安全配置的規劃，用vCenter/vSphere進行管理，還會搭配像vRealize Operations來進行告警與儀表板。同樣地，跑容器時，也是如此。
所以一個能跑容器的生產架構是必須的。底層是Docker，CaaS架構採用Kubernetes。但在K8S底層，為什麼應該選用NSX-T來提供這個環境的網路及安全方案？為什麼不用Flannel、OVS Network、Weave Net等等其他的選項呢？而且，為什麼容器還是要跑在虛擬化架構裡呢，用實體機不是挺好嗎？理由包括以下幾項：
‧因為在私有雲內，企業需要最高等級的安全防護機制來保護應用，即便是採用容器的形式。不然，用公有雲就挺好的啊？但在K8S架構內，絕大部分其他的方案，都還無法支援，或沒有簡易的方式來進行安全防護。
‧因為是企業自行進行維運，所以需要一個容易管理、具備完善除錯工具的網路環境，提供高Service Level的容器環境。
‧因為在私有雲內不僅僅只有容器，還有之前已經在運作的虛擬環境。企業需要一個共通、完整支援虛機及容器等不同架構、網路及安全Team能夠集中管理的統合方案。
‧因為企業的環境已經有虛擬化架構的資源池，而且有維運嫻熟的虛擬化管理者，要在上面起幾台Linux虛機跑K8S+Container是彈指間的事，要隨時擴充幾個Linux Node加大容器資源池也馬上提供。難道還要建個獨立環境，買新實體機接SAN Storage拉網路線接監控機制裝Linux裝Driver？每次擴充都打算買新伺服器找機櫃空間重新來一次？
‧因為企業的自有生產環境內需要有強大原廠的產品與服務團隊的支持能力，而不是出問題的時候自己去Open Source的論壇詢問。
以上是對於NSX-T在Kubernetes架構上方案的介紹與討論。
結語
VMware在後續容器架構的支援上有相當多的團隊在進行相關的方案開發，包含這系列談到的NSX-T網路與安全搭配，與Google/Pivotal合作的Pivotal Container Service（PKS），以及相關在雲自動化平台對於容器的支援。在企業自有資料中心逐步轉往新應用架構的路程上，相信VMware能持續成為大家重要的夥伴。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞