自許引領資料中心演進到軟體定義新時代的VMware，除了以Hypervisor技術著稱，早在2015年，也關注到容器（Container）運行環境較虛擬主機更輕量的優勢，不僅納入Docker Engine，以便於容器建置於虛擬主機，同時也提出自家的Photon OS容器平台，讓IT管理者可在單一介面中控管兩種相異技術環境。
欲建置新興的微服務架構於容器環境，從Hypervisor到容器本身，原就可完全採用開源陣營工具來搭建，只是當容器數量增長到成千上百個，勢必會造成維運負擔，必須得搭配工作流程引擎來輔助執行，例如Docker Swarm或Mesos等調度工具，在兩年前可說獲得相當多企業青睞，如今則是以Google釋出的Kubernetes（K8S）為主流，幾乎成為業界標準，藉此操控容器環境的調度。
專注於發展地端資料中心相關應用的VMware也開始採納K8S，但並非自主研發，而是協同Pivotal及Google Cloud，共同打造企業級K8S解決方案PKS（Pivotal Container Service）。VMware副總經理暨技術長吳子強指出，容器技術對VMware而言並不陌生，過去五年來內部陸續有研發專案在推展，例如Photon OS容器平台，直到2017年8月正式發布PKS，VMware選擇與K8S建立合作關係而非自主開發調度工具，把研發能量投入在發展容器環境整合K8S後仍不足之處。畢竟執行容器調度時，基礎架構亦須搭配，問題是底層不屬於K8S控管範疇，萬一容器環境出現可用性問題，又欠缺安全防護機制，恐會導致應用服務中斷。
建立容器環境可視化確保高可用性
 |
| ▲ VMware副總經理暨技術長吳子強認為，儘管開放陣營有許多工具可實作容器環境，對於企業商業營運而言，更在意的是技術支援能力，例如知名的持續整合與持續部署工具Jenkins，企業勢必會選用商業化版本。 |
欠缺可視化機制可說是原生容器亟需處理的棘手問題。一旦採用直接在伺服器上安裝Linux作業系統的建置模式，無須增設Hypervisor層來啟用，首先將面臨到的問題是Linux作業系統本身有配置IP位址，環境中運行的容器卻並非基於IP來溝通，難以配置應用程式安全控管措施。
吳子強說明，「早期許多企業建立的觀念是容器環境要建置在實體主機之上，如今放眼全球啟用容器的數量，30%是運行在Google雲端平台，卻沒有一個直接建置在實體主機環境，原因是那樣不僅沒有幫助，反而製造更多困擾。」
因此PKS解決方案中，由Pivotal開發的BOSH技術，補足了許多可提高容器環境可用性的機制。基礎架構環境則是搭配了VMware vSphere、vSAN以及NSX-T，來建立底層安全性機制，再透過BOSH整合Google原生的K8S，如此一來，才得以讓容器環境具備穩定性與安全性能力。
BOSH技術的主要定位是控制層，可補強K8S欠缺的機制，例如自主復原（Self-healing）能力。吳子強舉例，當500個容器同時上線運行，其中3個停止服務時，K8S雖可掌握資訊，卻無法更進一步採取行動。此時BOSH偵測到已停止服務的容器時，會自動啟用來遞補，以補強可視化偵測之後的執行能力。
另一項PKS平台的特點，則是設計提供K8S On-Demand的能力，開發團隊可依據專案需求選用合適的K8S版本，無須受限於平台內建版本，運用成熟的虛擬化環境來實作，讓每個開發專案皆可具有專屬K8S叢集，彼此互不干擾。
SDN建立微分割加固容器應用安全性
至於PKS底層的基礎架構，vSphere原本並非關鍵環節，畢竟Hypervisor層也可選用KVM、Hyper-V等技術建置。「然而vSphere核心整合的NSX-T，則可說是現階段市場上，唯一商業軟體可支援容器環境的軟體定義網路（SDN）建立微分割（Micro-Segmentation）。這個機制可說是硬需求，畢竟唯有徹底解決底層網路的穩定性與安全性問題，才能讓企業有信心在正式營運環境中實作，因此NSX-T在PKS建構的環境中扮演極重要的角色。」吳子強強調。
他以日前實際參與國內大型企業的招標會議舉例，制定的規格條件有兩個指標性要求，其一是容器環境必須建置在Hypervisor平台之上，而非實體主機；其二是為了確保容器安全性，底層架構的SDN環境必須具備資安控管機制。「有趣的是，當天有意參與標案的所有廠商，容器環境的微分割與SDN皆是整合NSX-T來實作，主因是目前開放陣營發展的工具尚未成熟。」
其實不只在容器環境，NSX在各種不同應用領域的重要性逐年遞增。吳子強說明，NSX可讓網路配置與安全機制，同時實作在虛擬主機與容器環境，藉此達到控管政策一致性，即使未來遷移到AWS、Google公有雲平台時，資料中心的網路亦可進一步延伸直接接取，以加快遷移的速度與降低複雜度。
不須修改程式碼遷移到雲端
近兩年來IT大廠紛紛基於K8S調度工具提供建置容器環境的解決方案，吳子強觀察，可惜的是，即便最早轉向整合K8S的PaaS平台，在市場上也已奠定知名度，仍無法避免只要K8S社群釋出更新版本，商業版解決方案供應商亦必須盡快跟進的問題，若搭建的平台設計過多客製化機制，勢必會面臨窒礙難行的窘境。
「儘管PKS去年才提出，藉由整合Google原生K8S建立的優勢，不僅讓開發者得以沿用撰寫程式呼叫K8S的習慣，可大幅降低導入新解決方案的接受門檻，同時可在完全毋須變更程式碼的前提下，達到可攜式的目的。」
從本土企業端實際的狀況來看，在提出建置的規格條件中，通常會特別關注地端容器環境可能因發展策略轉變，必須遷移到AWS、Google等公有雲平台時，是否需要變更程式碼的問題。「事實上，過去異質平台的遷移，勢必得變更甚至重新撰寫程式碼，但VMware可保障在不修改程式碼之下來實現，主要即是因為PKS平台為VMware與Google合作打造，整合的是原生的K8S。此外，一旦釋出新版，Google與VMware的協議是讓PKS在一個月內跟進到K8S最新版，因為版更速度對於企業用戶而言相當重要。」
此外，針對初期建置容器環境規模較小，抑或是僅為了提升速度的需求，吳子強建議則無須導入PKS平台，在Hypervisor環境中即可同時啟用虛擬主機與容器，搭配VIC（vSphere Integrated Containers）就足以因應；若是需求更輕量，不關注虛擬主機數量與配置規模，僅著重於啟用時要達到秒級的應用，建置模式可更加單純，也不用建置VIC，只要運用在vSphere 6.7新版本中內建的Instant Clone技術，直接在記憶體內執行，即可快速新增虛擬主機，來達到秒級速度。他強調，資訊科技的發展日新月異，實踐應用需求的方式絕對不會只有一種選項，選用合適的方案才能真正解決問題。