【編者按】CaaS（Container-as-a-Service）的出現(xiàn)，一方面繼承了PaaS的理念，另一方面期望借助Docker的通用性，使得CaaS已經(jīng)徹底取代了傳統(tǒng)的PaaS（Heroku，CloudFoundry），成為社區(qū)和Startup圈子的關(guān)注焦點。但是CaaS的理念是分離底層IaaS資源，使得用戶專注于應(yīng)用開發(fā)，而GuestOS的存在破壞了這種透明性，Hyper的出現(xiàn)使GuestOS喪失了在CaaS中的價值，而隨著IaaS向CaaS的逐步演進(jìn)，我們也將目睹未來云計算市場里GuestOS的終結(jié)。
以下為原文：
GuestOS是什么
GuestOS這個詞想必對于從事云計算的同學(xué)并不陌生。在Docker出現(xiàn)之前，云計算分為經(jīng)典的三層：
SaaS
PaaS
IaaS
在IaaS堆棧中，每一個虛擬機（VM）都運行著一個完整的操作系統(tǒng)。為了區(qū)別與物理服務(wù)器上的OS，大家習(xí)慣性的把VM里的OS稱為GuestOS，而把物理機上的OS稱為HostOS。對于用戶而言，GuestOS是IaaS平臺的標(biāo)配，用戶需要登錄GuestOS來進(jìn)行配置，部署代碼，運行應(yīng)用。
IaaS + PaaS --> CaaS
隨著Docker的出現(xiàn)，云服務(wù)的分類中又涌現(xiàn)了一個新成員：CaaS（Container-as-a-Service）。CaaS一方面繼承了PaaS的理念，希望通過將應(yīng)用與底層基礎(chǔ)資源的分離，達(dá)到簡化應(yīng)用開發(fā)，減少運維成本，加速業(yè)務(wù)的效果；另一方面期望借助Docker的通用性，避免PaaS的技術(shù)局限性，更加貼近IaaS的用戶體驗。
從走勢來看，CaaS已經(jīng)徹底取代了傳統(tǒng)的PaaS（Heroku，CloudFoundry）, 成為了社區(qū)和Startup圈子的關(guān)注點。但無論是Google GKE, AWS ECS， 還是Tutum，GiantSwarm等等，目前CaaS大多是建立在IaaS之上，理由很簡單：
Docker是基于Linux Container，正好運行在IaaS提供的VM里；
Container的隔離性不夠，導(dǎo)致無法基于容器提供安全的多租戶CaaS服務(wù)，只能根據(jù)VM對不同用戶做隔離
下面這張圖是一個清晰的架構(gòu)描述：
在這個體系下，用戶需要預(yù)先在IaaS平臺上創(chuàng)建一組VM，再在VM里部署CaaS的agent；CaaS master通過這些運行在GuestOS里的agent遠(yuǎn)程操縱用戶的VM，部署Docker鏡像，啟動Container，監(jiān)控應(yīng)用運行狀態(tài)并進(jìn)行相應(yīng)相應(yīng)的管理。
這個架構(gòu)的好處是簡單易行，不好的地方在于GuestOS的不透明性。前文提過，CaaS的理念是分離底層IaaS資源，使得用戶專注于應(yīng)用開發(fā)。GuestOS存在破壞了這種透明性，比如必須預(yù)建VM集群。換句話說，用戶需要在應(yīng)用部署前做好各種規(guī)劃：集群規(guī)模，VM size，GuestOS選擇（CentOS，Ubuntu?），GuestOS內(nèi)部的配置（磁盤RAID，LVM）等等。大家都知道，現(xiàn)實里計劃總是趕不上變化，每次新業(yè)務(wù)需求出現(xiàn)時往往關(guān)聯(lián)著底層配置的變化。于是，雖然有了CaaS，但運維的同學(xué)們?nèi)匀恍枰l繁的手動調(diào)整VM配置，管理GuestOS。
此外，GuestOS+Container實質(zhì)上是在IaaS上層建立一個VM資源池，通過master對池中的資源進(jìn)行分配調(diào)度，最大程度的提高資源池利用率。這有點類似物理機IDC時代，預(yù)先購置一堆物理服務(wù)器，托管或者自建機房。無論是CaaS還是物理機，由于業(yè)務(wù)負(fù)載本身的不確定性，資源池里任何時間點必然有一部分VM被閑置浪費掉。
第三，這個架構(gòu)的另一弊端在于CaaS服務(wù)無法借助IaaS的底層功能。以SDN為例，目前絕大部分的IaaS平臺都提供了非常完整的VPC功能，用戶可以根據(jù)自身需求靈活的定義復(fù)雜的網(wǎng)絡(luò)拓?fù)浜桶踩呗浴．?dāng)使用CaaS服務(wù)時，如果用戶需要類似的SDN功能，那要么CaaS平臺本身提供，要么借用IaaS服務(wù)。但這兩者都存在問題：，
CaaS提供：這意味著在IaaS的VPC網(wǎng)絡(luò)之內(nèi)再創(chuàng)建一套VPC網(wǎng)絡(luò)，無論是性能，復(fù)雜度，可靠性，還是調(diào)試難度，可想而知都非常不理想
借用IaaS：用戶可以在 創(chuàng)建VM資源池的同時，使用IaaS的SDN功能，在資源池內(nèi)部定義VPC網(wǎng)絡(luò)，這樣就避免了嵌套CaaS VPC。Again，計劃跟不上變化，當(dāng)業(yè)務(wù)變變更時，用戶要隨時調(diào)整資源池，這無疑不是PaaS/CaaS追尋的目標(biāo)。
基于Hyper的CaaS
Hyper是一個基于虛擬化技術(shù)（hypervisor）的Docker引擎。它可以使用任意的hypervisor（KVM，Xen，VMWare等等）直接運行Docker鏡像。
[root@user ~:]# docker pull nginx:latest
[root@user ~:]# hyper run nginx:latest
[root@user ~:]# docker ps
[root@user ~:]#
[root@user ~:]# hyper list
......
Done
值得指出的是，雖然Hyper同樣通過VM來運行Docker應(yīng)用，但HyperVM里并沒有GuestOS，相反的，一個HyperVM內(nèi)部只有一個極簡的HyperKernel，以及要運行的Docker鏡像。這種Kernel+Image的"固態(tài)"組合使得HyperVM和Docker容器一樣，實現(xiàn)了Immutable Infrastructure的效果。
從用戶角度來看，一個Immutable的HyperVM對簡化運維有很大的作用：
VM配置（磁盤格式化，網(wǎng)卡屬性，進(jìn)程管理）在運行前指定，用戶無需登錄進(jìn)行操作
所有配置在VM運行過程中完全固化，不產(chǎn)生變化
當(dāng)業(yè)務(wù)應(yīng)用發(fā)生變更時，不用像之前描述的那樣登錄VM手動修改配置，而是借助HyperVM的毫秒級啟動特性，快速創(chuàng)建新HyperVM取代原有VM
這樣"固態(tài)而快速“的運維流程大大降低了應(yīng)用部署，升級，回滾的復(fù)雜度，同時消除了生產(chǎn)環(huán)境里的手工因素，避免了人為事故的風(fēng)險。
在另一方面，借助VM天然的隔離性，Hyper能夠完全避免LXC共享內(nèi)核的安全隱患。結(jié)合HyperVM"固態(tài)"的特性，這使得我們可以拋棄之前IaaS+VM+Agent+Container的思路重新思考CaaS：
在圖里右側(cè)的CaaS里：
用戶只需要準(zhǔn)備好Docker鏡像，將定義好的Mesos Marathon模板文件提交給CaaS平臺
CaaS平臺分析Marathon文件，創(chuàng)建所需的SDN網(wǎng)絡(luò)和存儲卷，并啟動HyperVM運行用戶Docker鏡像
對于新版本鏡像部署，網(wǎng)絡(luò)和存儲配置變更的情況，用戶將修改好的Marathon文件再次提交即可
在Hyper的CaaS架構(gòu)里，
HyperVM取代了Container成為CaaS的調(diào)度單元，所有HyperVM的配置由CaaS完成，用戶不再需要登錄VM手動操作
用戶不再需要預(yù)先創(chuàng)建VM資源池，也不再有VM閑置浪費
由于Hyper底層使用的是虛擬化技術(shù)，所以SDN，分布式存儲等等成熟的IaaS技術(shù)可以直接在Hyper CaaS里直接使用，既簡化了平臺復(fù)雜度，也提高了性能和可靠性
OS的未來
在Hyper CaaS之前，CoreOS和RancherOS是兩個非常流行的Minimalist Linux Distro。雖然它們不是專門為VM設(shè)計的，但卻被常常用作GuestOS，在IaaS上運行Docker容器。Hyper的出現(xiàn)使GuestOS喪失了在CaaS中的價值，而隨著IaaS向CaaS的逐步演進(jìn)，我們也將目睹未來云計算市場里GuestOS的終結(jié)。但這并不意味著CoreOS的終結(jié)，恰恰相反，新一代的極簡OS將回歸它們的本源：運行在Bare metal之上，成為未來CaaS的基石！（責(zé)編/魏偉）
作者簡介：
王旭：HYPER創(chuàng)始人，CTO，前VisualOps CTO，多年的Debian，Kernel，分布式存儲老兵
京公網(wǎng)安備 11010502049343號