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