【编者按】 CaaS(Container-as-a-Service)的出现,一方面继承了PaaS的理念,另一方面期望借助Docker的通用性,使得CaaS已经彻底取代了传统的PaaS(Heroku,CloudFoundry),成为社区和Startup圈子的关注焦点。但是CaaS的理念是分离底层IaaS资源,使得用户专注于应用开发,而GuestOS的存在破坏了这种透明性,Hyper的出现使GuestOS丧失了在CaaS中的价值,而随着IaaS向CaaS的逐步演进,我们也将目睹未来云计算市场里GuestOS的终结。
以下为原文:
GuestOS这个词想必对于从事云计算的同学并不陌生。在Docker出现之前,云计算分为经典的三层:
在IaaS堆栈中,每一个虚拟机(VM)都运行着一个完整的操作系统。为了区别与物理服务器上的OS,大家习惯性的把VM里的OS称为GuestOS,而把物理机上的OS称为HostOS。对于用户而言,GuestOS是IaaS平台的标配,用户需要登录GuestOS来进行配置,部署代码,运行应用。
随着Docker的出现,云服务的分类中又涌现了一个新成员:CaaS(Container-as-a-Service)。CaaS一方面继承了PaaS的理念,希望通过将应用与底层基础资源的分离,达到简化应用开发,减少运维成本,加速业务的效果;另一方面期望借助Docker的通用性,避免PaaS的技术局限性,更加贴近IaaS的用户体验。
从走势来看,CaaS已经彻底取代了传统的PaaS(Heroku,CloudFoundry), 成为了社区和Startup圈子的关注点。但无论是Google GKE, AWS ECS, 还是Tutum,GiantSwarm等等,目前CaaS大多是建立在IaaS之上,理由很简单:
下面这张图是一个清晰的架构描述:
在这个体系下,用户需要预先在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服务。但这两者都存在问题:,
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,以及要运行的Docker镜像。这种Kernel+Image的"固态"组合使得HyperVM和Docker容器一样,实现了Immutable Infrastructure的效果。
从用户角度来看,一个Immutable的HyperVM对简化运维有很大的作用:
这样"固态而快速“的运维流程大大降低了应用部署,升级,回滚的复杂度,同时消除了生产环境里的手工因素,避免了人为事故的风险。
在另一方面,借助VM天然的隔离性,Hyper能够完全避免LXC共享内核的安全隐患。结合HyperVM"固态"的特性,这使得我们可以抛弃之前IaaS+VM+Agent+Container的思路重新思考CaaS:
在图里右侧的CaaS里:
在Hyper的CaaS架构里,
在Hyper CaaS之前,CoreOS和RancherOS是两个非常流行的Minimalist Linux Distro。虽然它们不是专门为VM设计的,但却被常常用作GuestOS,在IaaS上运行Docker容器。Hyper的出现使GuestOS丧失了在CaaS中的价值,而随着IaaS向CaaS的逐步演进,我们也将目睹未来云计算市场里GuestOS的终结。但这并不意味着CoreOS的终结,恰恰相反,新一代的极简OS将回归它们的本源:运行在Bare metal之上,成为未来CaaS的基石!(责编/魏伟)
作者简介:
王旭:HYPER创始人,CTO,前VisualOps CTO,多年的Debian,Kernel,分布式存储老兵