转载

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对不同用户做隔离

下面这张图是一个清晰的架构描述：

Docker, Hyper和GuestOS的终结

在这个体系下，用户需要预先在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：

Docker, Hyper和GuestOS的终结

在图里右侧的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的基石！

正文到此结束