自從出現了以YAML格式撰寫組態檔的Docker Compose，讓多個容器（Container）所組成的應用服務在Red Hat、Windows等作業系統皆可執行，可說真正實踐了過去Java陣營希望達成的跨平台目標。緊接著Google釋出的Kubernetes（以下簡稱K8s）可用於自動部署、擴展和管理容器化應用程式，使得「Docker+K8s」逐漸成為現代應用開發的主流架構。
只是K8s現階段仍快速地發展中，在實作於企業營運環境時，勢必得解決幾個普遍存在的問題。VMware資深技術顧問何宗憲指出，首要是不容易維運，例如安裝前需要先餵入憑證，安裝Master與Worker節點，完成後再測試，若發現資源不夠，必須得增設主機；或者操作過程中發生系統錯誤狀況，得重新安裝建置。
其次是網路為CoreOS的Flannel服務，架構較為簡單，須仰賴預先配置的IP路由，不具備擴充能力，一旦節點數量較多，路由配置可能多達幾千條規則，往往難以執行調整變更、問題排除等工作；第三是開發者僅關注於容器環境，但維運者在意的安全性、高可用性與擴充性，卻是現階段K8s運行環境的挑戰，因此眾家IT大廠相繼基於自家優勢投入發展，例如VMware、Pivotal、Google聯手推出的PKS（Pivotal Container Service），即著眼於協助解決前述的問題。
BOSH實現開發者隨需選用K8s版本
過去Docker、K8s尚未成為主流時，只有PaaS平台採用容器技術建構不同的專屬應用環境，直到CoreOS貢獻出Flannel工具，是專為K8s所設計的覆蓋網路（Overlay Network），儘管功能性不多，至少當時已可解決Docker於網路層跨多台主機的架構模式。緊接著K8s社群共同制定出容器網路介面（CNI），使得K8s發展日益迅速，相對的，市場上對PaaS關注度則逐漸下滑。
「VMware透過技術合作方式提出PKS之前，其實本就有VIC、Photon Platform與Photon OS等方案，在Dell收購後進行產品線審查，決議停止發展Photon Platform，取而代之的是PKS。」何宗憲說。
就架構面來看，PKS主要是透過BOSH介接到不同雲端平台，讓封裝檔案內的程式碼呼叫運行。BOSH的定義是IaaS操作者，扮演中介軟體的角色，只要K8s部署指定為AWS、GCP、Azure、vSphere、OpenStack等不同雲端供應商介面（CPI），經由BOSH即可執行部署與調度。
「BOSH技術即來自Pivotal，這也是後來Dell整併後，決定保留PKS而非Photon Platform的主因。」何宗憲說。該技術最初起源於Google內部的Borg叢集管理系統，主要負責的五名Google工程師轉職到Pivotal之後發展為BOSH開源專案，期望能夠達到「Borg++」，因此取「r的下一個字母為s，以及g的下一個字母為h」稱之為BOSH。
在Pivotal容器服務環境中，BOSH底層有VMware NSX-T確保安全性，上層運行PKS控制平面包含K8s on BOSH（以前稱為Kubo，現已改名為Cloud Foundry Container Runtime，簡稱CFCR），以及在兩岸三地被廣泛採用的Harbor開源專案，用以存放映像檔倉庫（Repository）。主要目的是藉由BOSH來實現K8s On-demand，也就是容器即服務（CaaS）的概念，不僅可讓開發團隊依照專案需求申請不同版本的K8s技術環境，同時也不會有廠商設計專屬的指令集，直接採用K8s原生的執行方式即可。
自主復原降低IT維運負擔
 |
| ▲VMware資深技術顧問何宗憲強調，以IaaS為基礎架構Master節點與Worker節點，開發者毋須關注底層環境，容器即服務（CaaS）即可提供不同應用開發所需的運行環境。 |
執行BOSH部署時，首先要指定雲端供應商介面，其次是Linux虛擬機樣板StemCell佈建，依據YAML檔案配置Master與Worker節點運行的虛擬主機環境。該虛擬主機上的BOSH Release為已經配置完成的Kubo，透過「pks create-cluster」指令，即可自動產生K8s叢集架構，不同開發團隊可藉此產生獨立的運行環境。
「我們的定位較其他廠商不同，更多面向於IT人員，畢竟VMware的操作者並非開發者。就維運的角度來看，更在意的是版本更新、高可用性、安全性等問題，也因此Pivotal已通過美國國防部安全檢查，實際被應用在軍方單位。」何宗憲強調。
假設單一Worker節點故障顯示為紅色，Container仍可正常運行，BOSH會偵測到訊號異常，因為所有的指令都是透過BOSH執行部署，得以掌握所有節點狀態，當訊號遺失時，將執行刪除VMDK、再產生一台虛擬主機掛載到叢集的方式，來實現自主復原（Self-healing）。當然，自主復原實踐的因素還包括底層的SDDC（軟體定義資料中心）架構，可基於實體資源池來彈性配置。
為什麼刪除VMDK還要再增添掛載？他指出，主要是在容器環境中有Persistent Volumes機制，可能有些資料會寫入磁碟區，若全部刪除，資料也會一併消失，因此要先卸載，新增虛擬主機後再把資料附加回來。
「自主復原能力現階段在K8s中不具備，未來恐怕也難以實現。之所以有此論點是因為K8s不會限制部署環境，若為實體主機而非IaaS環境，根本無法達到自我復原。」何宗憲說。
IDC FutureScape在2017年針對全球企業基礎架構預測，容器技術發展到2020年，將至少有70%被部署在虛擬化基礎架構；Gartner年初發布預測也指出，今年（2018）將會有超過60%的容器是運行在虛擬主機之上。
論及Hypervisor技術，仍是VMware最具優勢。何宗憲進一步說明，「確實有另一派的說法是虛擬主機須要佔用3%到5%資源，基於實體機運行的容器環境，較可確保效能。概念上我認為有道理，但是藉此來降低系統中斷風險，更是營運環境關注的重點。在此同時，VMware也會持續以新技術克服Hypervisor耗用效能的問題，例如RDMA。」
以前虛擬網卡，必須由CPU把封包遞送到實體網卡，確實須耗用效能，現在只要網卡支援RDMA驅動程式，虛擬與實體網卡彼此之間可直接傳遞，不須再透過CPU，VMware稱為RoCE（RDMA over Converged Ethernet），在vSphere 6.5版本中即已提供。
在維運K8s時，如果遇到實體資源不足須再增添Worker節點，實體機的作法就只能再架設一台，即使是採用Ansible等自動化部署工具，皆需要一段安裝建置時間。相較之下，「PKS則是透過Resize叢集指令即可立即擴充，大約兩分鐘安裝完成Kubo並加入K8s，就可以產生一個Worker節點。」
PKS定位並非僅提供K8s叢集，而是打造完整的架構，可運行多個K8s，而且藉由自行修復能力讓IT人員毋須介入維運。若資源不足時，輸入指令集即可彈性擴充，IT人員只要專注於維運已相當熟悉的vSphere即可提供開發者所需的容器環境。