100个容器周边项目详解之容器引擎

前序

随着现在容器技术的火热，越来越多的人愿意接触容器，而容器本身并不只是一个独立工程，而是伴随着容器的升级，改进，其周边衍生出了很多技术其中包括容器OS、容器引擎，基础架构的容器网络、存储、安全，容器运行必不可少的镜像仓库、编排，及运维关注的监控、日志等技术，而这些技术的核心就是，我们将各个功能组件根据自己的生产需求组合起来，构成一个大的较为复杂的，功能齐全的技术战参考阿里云发布的100个容器周边项目，分为14个主要的类别，并对我们身边的技术做比较详细的比较和讲解。

容器引擎

容器引擎是容器集群生态圈的核心部分，容器引擎与内核Namespace和CGroup等功能直接交互，并提供相应API使得外部能够与之集成的工具或服务。

docker与Rkt的区别

有一篇文章曾这样讲到两者的联系“Rocket和Docker没有竞争性。Docker平台是一个产品，Rocket是一个组件。企业可以选择Docker替代Cloud Foundry，也可以使用Rocket构建Cloud Foundry。CoreOS在发布Rocket时就指出，Rocket的出现是因为有些人需要一个更“纯净”的容器。换句话说，Rocket算是“App Container Specification”的标准实现”

功能边界

CoreOS认为引擎作为一个独立的组件，而Docker目前已发展成为一个平台，这也是CoreOS推出Rocket的官方原因之一。从功能角度来对比，Docker提供了日志、镜像和管理，甚至在1.12版本集成了swarm集群功能。而Rocket（rkt）的边界为在Linux系统上运行应用容器的功能组件。

容器安全

兼容性

发布较晚的rkt在对Docker兼容性方面采用包容的态度，且rkt和kubernetes保持一致，基本运行单元为pod。

Systemd与docker的命名空间

关于Rocket的讨论最多的话题是systemd-spawn或者是 systemd， 其中systemd做的或者说能够做的事情多是进程管理 。 CoreOS已将systemd作为他们Linux发行版的init系统。他们可以接着使用Init 脚本或者upstar，但是他们选择使用了将来会成为所有主流Linux版本标准的init系统。 不是使用Rocket必须要用systemd，而Rocket仅仅是“重用”了systemd和systemd-nspawn

Docker一直倡导一个容器运行一个进程。因为Linux容器主要是为了实现主机的进程隔离，而每个容器运行一个进程，会给你带来更多的灵活性和复合型，独立的更新、回滚等，操作更加简单。然而，当你创建一个新的Docker容器或事实上LXC容器，容器被重新分配一套由libcontainer提供的全新的Linux命名空间。实话说，我觉得这有点浪费。于Docker还挺有意义，因为你要在一个容器中运行一个单独的进程，并且如果你想提供更通用的进程环境，来覆盖大多数的用例，你可能需要libcontainer高效提供的大量可用命名空间。 只为一个进程创建一组命名空间，增加了内核大量的额外管理工作。如果你的主机上运行了很多的容器，可能会出现内核某些方面的瓶颈。你可能会说开销很小，但是为什么非要过度占用内核呢？因此，为了节省开销，可以共享进程之间的命名空间。但是有个问题，如果你开始共享命名空间，并且创建它的容器已经终止，它会删除共享命名空间的所有的进程。Kubernetesde在设计Pod时，就考虑到这个问题了。 Kubernetes Pod中第一个被创建的容器，会被从internal/24 VLAN中分配一个IP地址，该IP地址也被Pod内共享一个network namespaces的容器共享。

Hyper

Hyper是一个可以在hypervisor上，不安装完整操作系统，直接运行Docker Image的运行引擎。Hyper可以在hypervisor上运行一组相关的Docker Image，而不是一个，也正是Kubernetes所阐述的Pod的概念——不是一个虚机，不是一个胖容器，而是一组关联的容器。再进一步说，Hyper致力于成为一个平台中立、hypervisor中立的执行引擎，除了支持KVM/QEMU外，接下来Hyper还将会支持Xen。

Hypervisor的最明显的好处就在于，hypervisor的进程是由另一个kernel调度，系统调用由另一个kernel处理，而并非宿主机的kernel。这样，一方面用户可以选择自己的kernel，另一方面也增强了隔离性，hypervisor发生漏洞，对宿主机和其它虚拟机的威胁的概率是远低于容器漏洞的，毕竟容器向用户进程暴露了太多的入口点。虚拟机的另一个优势是，虚拟机相关的产业链已经非常成熟，Xen/KVM已经有十多年的历史了，围绕虚拟机打造的OpenStack也有五年的历史了，和虚拟机有顺畅合作的软硬件上下游产品非常多，容器正在赶超，但虚拟机无疑是先行者。Hypervisor简化了硬件模型和kernel的硬件支持，这样就不必费力去扫描和初始化一些本没有用的设备；我们省掉了完整的OS，这样就没有了init任务的影响；我们还是用了qboot，降低了老旧BIOS在引导过程中消耗的空间；此外还有一些流程上的细节优化，最终呈现出了Hyper现在的性能。

Garden

在CloudFoundry的下一代PaaS项目Diego中，Pivotal团队对于Warden进行了基于Golang的重构，并建立了一个独立的项目Garden。在Garden中，容器管理的功能被从server代码里分离出来，即server部分只负责接收协议请求，而原先的容器管理则交给backend组件，包括将接收到的请求映射成为Linux（假如是Linux backend的话）操作。值得注意的是：这样backend架构再次透露出了warden跨平台的野心，可以想象一旦Windowsbackend被社区（比如IronFoundry）贡献出来后的威力。更重要的是，RESTful风格的API终于被引入到了Garden里面，原作者说是为了实验和测试，但实际上Docker最成功的一点正是友好的API和以此为基础的扩展能力。

Pouch

Pouch是一款轻量级的容器技术，拥有快速高效、可移植性高、资源占用少等特性，主要帮助阿里更快的做到内部业务的交付，同时提高超大规模下数据中心的物理资源利用率。

Pouch 技术优势

隔离性强

隔离性是企业走云化之路过程中，无法回避的一个技术难题。隔离性强，意味着技术具备了商用的初步条件；反之则几乎没有可能在业务线上铺开。哪怕是阿里巴巴这样的技术公司，实践容器技术伊始，安全问题都无法幸免。众所周知，行业中的容器方案大多基于 Linux 内核提供的 cgroup 和 namespace 来实现隔离，然后这样的轻量级方案存在弊端：

容器间，容器与宿主间，共享同一个内核；

内核实现的隔离资源，维度不足。

面对如此的内核现状，阿里巴巴采取了三个方面的工作，来解决容器的安全问题：

用户态增强容器的隔离维度，比如网络带宽、磁盘使用量等；

给内核提交 patch，修复容器的资源可见性问题，cgroup 方面的 bug；

实现基于 Hypervisor 的容器，通过创建新内核来实现容器隔离。

容器安全的研究，在行业中将会持续相当长时间。

P2P 镜像分发

蜻蜓是基于智能 P2P 技术的通用文件分发系统。解决了大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题。大幅提升发布部署、数据预热、大规模容器镜像分发等业务能力

富容器技术

富容器”技术的实现，主要是为了在 Linux 内核上创建一个与虚拟机体验完全一致的容器。如此一来，比一般容器要功能强大，内部有完整的 init 进程，以及业务应用需要的任何服务，当然这也印证了 Pouch 为什么可以做到对应用没有“侵入性”。技术的实现过程中，Pouch 需要将容器的执行入口定义为 systemd，而在内核态，Pouch 引入了 cgroup namespace 这一最新的内核 patch，满足 systemd 在富容器模式的隔离性。从企业运维流程来看，富容器同样优势明显。它可以在应用的 Entrypoint 启动之前做一些事情，

内核兼容性

Pouch 支持所有内核版本，而现有的容器技术支持的 Linux 内核都在 3.10 以上。不过技术层面万幸的是，对 2.6.32 等老版本内核而言，namespace 的支持仅仅缺失 user namespace；其他 namespace 以及常用的 cgroup 子系统均存在；但是 /proc/self/ns 等用来记录 namespace 的辅助文件当时还不存在，setns 等系统调用也需要在高版本内核中才能支持。而阿里的技术策略是，通过一些其他的方法，来绕过某些系统调用，实现老版本内核的容器支持。

Pouch 架构

Pouch 的生态架构主要包含两个方面：1.如何对接容器编排系统；2.如何加强容器运行时。

参考