超容器会是云原生应用的答案吗？

在云计算的早期阶段，开发人员一直在寻找着 PaaS 所承诺的那样的场景，在哪里他们可以专注于构建应用程序，而不是让管理服务器这种事情分他们的心。但是，随着云原生应用的崛起，这个梦想可能不需要太久就可实现。

其中一种运行云原生应用的方法就是设置容器的平台，对于使用公有的 IaaS 的开发者和研究机构来说，这就意味着：

• 创建一个虚拟机集群（首先需要考虑的是容量规划、实例类型、集群规模）
• 配置虚拟机实例（软件依赖、安全补丁等）
• 准备虚拟机的存储（再次容量规划以及卷管理）
• 设置虚拟机网络（防火墙、访问控制列表、网络地址转换、路由表等）
• 在虚拟机中部署容器编排引擎（COE）（调度策略、服务发现、流量代理等等）
• 在虚拟机中部署容器存储系统（挂载、复制、数据同步、失效切换等）
• 设置容器的网络

一旦用户完成了上述所有的步骤，就可以开始启动自己的容器了。这时的用户必须对容器进行监控以及对它们的各个组件都进行有效的管理，以确保系统处于稳定的运行状态。你有没有觉得这些过程有些沉重、乏味、且容易出错？更为重要的是上述这些还和应用沾不上边。虽然这时用户没有受限于物理的空间，但是仍然处于 IaaS 的捆绑中，我们该如何应对？来改变和减轻管理上的困难问题？

进入超容器（HyperCantainer）的世界

超容器是一款开源的虚拟化容器的技术产品。它使用的并非是 Linux 的容器，而是使用 Hypervisor （像Xen） 来启动一个容器镜像。为什么这么做？要解释隐藏于此的背后的技术，让我们先来看看 Linux 的容器是如何工作的。当我们去启动一个 Linux 容器时，来自宿主机的 Cgroup 和 一些命名空间（namespace） 会将容器的进程隔离起来。然而，此进程并未真的和外界相隔离，它依然在宿主机的内核下运行，因此，从流程的角度来看的话，一个 Linux 容器的启动是这样子的：

Linux 容器 = Cgroup（资源限制）+ NameSpace（访问隔离）+ 主机内核 + 数据（镜像）

作为宿主机的内核是被共享的，也就是说所有的 （Linux）容器均运行在同一个主机中，在多租户的环境中使用 Linux 容器来部署应用程序因为缺乏内核级的隔离导致其是不安全的（多租户的环境中虚拟机的集群采用的是租户之间的安全边界）。

超容器（HyperCantainer）的出现就是解决此问题的，当然是改变了一些内部的技术：

• 资源限制和访问隔离：从 Cgroup + NameSpace 变为 Hypervisor (KVM ,Xen, 等等）
• 主机内核变为客户机内核

相应的流程也变为：

超容器 = Hypervisor + 客户机内核 + 数据（镜像）

在超容器中，可以根据需要来访问应用程序的进程：内核和数据。区别在于容器不再是运行在宿主机的内核上了。取而代之的是，每个容器都拥有自己的、独立的、客户机内核。基于此种形式，所运行的应用程序被完美的隔离，不仅是其它的容器，也包括宿主机。

还有超容器具有卓越的性能表现，在超小客户机内核的协助下，超容器能够在毫秒级 (100-150ms) 别的启动，这远远的高于虚拟机的启动。有些人还是认为这个速度还是低于 Linux 容器的速度，但考虑到应用程序通常都会有所延迟的情况下，在实践中，这根本就没有什么区别。

管理的便捷性

这要感谢内置的隔离，使得超容器并不需要在虚拟机的内部来进行扩容，相反，它能够在云的环境中替代虚拟机。

无需虚拟机的主机，也不需要集群环境，连同的有虚拟机的容量规划、虚拟机的配置、COE、集群使用率等等。整个云运行的就如在一台单一的主机上一样，容器的管理是同样的一如在本地的笔记本电脑中。

• hyper pull 将镜像从（私有）的注册处拉到云中
• hyper run 直接启动虚拟机，无需虚拟机
• hyper link 不同的容器像运行在同一台主机上一样
• hyper commit 创建一个新的镜像
• hyper push 将镜像从云中上传到（私有）注册处
• hyper associate floating 公有 IP 到访问互联网
• hyper exec 来访问容器

剩下的不同就是，此“云电脑”拥有无限的能力。开发人员可以在任何时候启动任意数量的容器, 而不用担心例如还剩多少内存。

超级弹性

对于云原生应用的定义其中之一就有：弹性，开发人员一直希望系统是具有自适应负载的能力的，传统上实现此是基于虚拟机的自动伸缩功能来扩展和缩小的功能的，这可是出了名的缓慢而笨重，Linux 容器让这些稍好点，因为它拥有分层的镜像以及提供新的是超级节省成本。但是，由于有虚拟机集群的存在，一些笨重的东西还是有所遗留，考虑下当虚拟机池容量不够使时，要添加额外的资源需要采取如下漫长的步骤：

• 部署新的虚拟机实例
• 虚拟机完成自举后加入到现有的集群
• 在新的节点上 COE 部署更多的容器
• 根据新的容器，应用程序将负载平衡到这些新的容器上。

在大多数情况下，此过程需要花费好几分钟来完成。这种情形下去应对客户的流量高峰的话，可能会有些太迟。在超容器的上下文中，天生的隔离帮助我们略过这些虚拟机的步骤，结合次秒级启动性能, 它使应用程序变得超弹性的。服务超载时, 它只是要求备份, 和新的容器很快将被运行。

按秒计费

毫秒级的性能的另外一个好处就是可以按秒来计费。鉴于龟速的虚拟机启动过程，一般情况下价格都是按照小时或分钟来计算的，此种模式在动态的使用情况下，由于低敏捷性所以带来了更高的成本，比如 Dev/QA。基于虚拟机的集群，价格的结构会越来越糟糕，即使是在前期投资（简称为 CapEx）就需要预留池，这样的话就造成一定的浪费，毕竟有资源在闲置。

超容器尽管可以让用户在 2 秒内启动 100 个容器，压缩一些数据或者是运行并行的构建在最后的提交会花上 10 秒，销毁所有的容器只需要 1 秒钟，所有这些加起来 2+10＋1=13 秒。这种按秒计算的模式不仅能够节省开销，它的按需响应的特性也让用户无需作 CapEx，这就避免了浪费，并能够适应一些新的事件驱动的模型，如 AWS lamda 、 Spark 流、 CD／CI 。

Cattle, cattle, cattle

云原生应用对待其组件应该被视为是“牛群中的牛”，而不是宠物。当发现它们出了问题是，不是说悉心的去照看它们，为它们找医生，而是简单粗暴的将之遗弃，并使用新近克隆的来取而代之。这对于 Linux 容器来说是一件很容易的事情，但是其底层的虚拟机则会是人们的噩梦－龟速的部署、过长的周期、以及昂贵的管理。在这种情况下，一个系统（安全）需要为客户机操作系统打补丁，我们就必须去使用原来的系统管理工具来维护它们。

但是稍作对比，超容器就完全解决这些让系统管理员们头疼的问题。因为在一个超容器中只有客户机内核和镜像，所以就没有维护客户机操作系统这一说，没有 yum 安装、没有计划任务、没有 /etc、没有迁移部分，总而言之是完全没有服务器管理这一说。超容器本质上是一成不变的、无需特别注意、而且节省很多的时间。结合特性毫秒级的启动，它能够完美的适应哪些便宜的、一次性的基础设施的“牛群”环境。

DIY 并不是意味着你可以为所欲为

有状态的应用负载，如数据库，从一开始就是让容器颇为头痛的。一如 Linux 容器是运行在虚拟机之上的，它整合到 IaaS 的存储服务中是非常困难的，这时开发者们会专门针对容器留出数据的解决方案，而这往往是复杂还不成熟的。

超容器提供了 IaaS 中通用的一些虚拟化技术，例如分布式文件系统或 SDN。开发者不再需要部署他们自身的 LXC 解决方案，就可以享受云计算所带来的服务管理：

• hyper 挂载分布式的块存储卷到容器；
• hyper 快照会生成持久的备份。

到处运行

IaaS 的客户受到厂商锁定这是一个不争的事实。不同的 Hypervisor、加上不兼容的虚拟机镜像格式，这都对开发者部署应用的灵活性提出了很大的挑战。超容器通过技术无关顺利的解决了此问题。在本文写作的时候，超容器已经支持了目前市场上主要的一些 Hypervisor，其中包括 Xen、KVM 和 VirtualBox，构建在各种异构的技术之上，超容器提供了和 Docker 一致的接口，包括 API、镜像格式、以及工作流。这就带来了最大可能的移植性：应用可能是部署在一个由 LXC 所驱动的私有 CaaS（容器即服务），可以直接无缝的迁移（扩展）到一个由超容器所驱动的公有 CaaS 中。

无服务的特性

通过从传统的全栈式的虚拟机到以应用为中心的容器，对于 Hypervisor 的重新利用，超容器做到了，其为多租户环境带来了所必需的隔离，同时还保持了 Linux 容器的优点：毫秒级的启动、升级的不变形、以及可移植性。所谓的无服务特性，有下面几点内容：

• 安全的容器成为新的构建障碍
• 自然的去掉了虚拟机集群，让云计算像本地笔记本电脑一样容易使用
• 超级弹性让应用的自动扩展在几秒内完成
• 按秒计费，成就真正意义上的事件驱动

我们坚持认为超容器就是云原生应用的答案！开发人员终于可以只去关注代码了，而无须分心去管理服务器。不妨尝试下我们的产品： hyper.sh 。

关于作者

王旭是 Hyper_ 的 CTO 和联合创始人，在此之前，王旭是中国移动大云的首席架构师，在中国移动的项目中他掌管着内核、分布式存储、以及大数据等的产品线。王旭在 Debian、Linux 内核、虚拟化、分布式文件系统、以及 NoSQL 数据库有着超过 10 年的丰富经验，他拥有北京邮电大学（BUPT）的博士学位。

查看英文原文： Is HyperContainer the Answer for Cloud Native Applications?