Docker, Hyper和GuestOS的终结

jopen 8年前


【编者按】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的基石!