容器技术经验谈

最新推荐文章于 2024-08-17 16:40:08 发布

蔚1

最新推荐文章于 2024-08-17 16:40:08 发布

阅读量902

点赞数

文章标签： Docker 容器

本文链接：https://blog.csdn.net/valada/article/details/79910134

版权

内容简介

以 Docker 为代表的容器技术逐渐走向企业的落地实践，技术开发者关心的不是容器技术如何“改变世界”，而是如何利用容器技术和自身的业务、场景结合起来，从而切实提高自己企业的开发效率和减少运维成本。从这个意义上来说，容器技术正在走向成熟。

2017年以微服务、Serverless 等和容器技术密切相关的新概念、新技术、新思想不断涌现，技术的发展瞬息万变、一日千里。如何把握技术潮流，实现开发者和企业的升华，已经成为技术人员不可回避的话题。

本期我们聚焦国内在容器技术领域权威企业的一线实践者，来为我们深刻剖析容器技术目前发展的最新动态，以及就业界关心的微服务、Serverless 等新技术话题，希望借此为开发者带来新思考。

本书内容

Docker 在美团点评的实践

文/郑坤

本文介绍美团点评的 Docker 容器集群管理平台。该平台始于2015年，是基于美团云的基础架构和组件而开发的 Docker 容器集群管理平台。目前该平台为美团点评的外卖、酒店、到店、猫眼等十几个事业部提供容器计算服务，承载线上业务数百个，日均线上请求超过45亿次，业务类型涵盖 Web、数据库、缓存、消息队列等。

作为国内大型的 O2O 互联网公司，美团点评业务发展极为迅速，每天线上发生海量的搜索、推广和在线交易。在容器平台实施之前，美团点评的所有业务都是运行在美团私有云提供的虚拟机之上。随着业务的扩张，除了对线上业务提供极高的稳定性之外，私有云还需要有很高的弹性能力，能够在某个业务高峰时快速创建大量的虚拟机，在业务低峰期将资源回收，分配给其他的业务使用。美团点评大部分的线上业务都是面向消费者和商家的，业务类型多样，弹性的时间、频度也不尽相同，这些都对弹性服务提出了很高的要求。在这一点上，虚拟机已经难以满足需求，主要体现在以下两点。

第一，虚拟机弹性能力较弱。使用虚拟机部署业务，在弹性扩容时，需要经过申请、创建和部署虚拟机、配置业务环境、启动业务实例这几个步骤。前面的几个步骤属于私有云平台，后面的步骤属于业务工程师。一次扩容需要多部门配合完成，扩容时间以小时计，过程难以实现自动化。如果可以实现自动化“一键快速扩容”，将极大地提高业务弹性效率，释放更多的人力，同时也消除了人工操作导致事故的隐患。

第二，IT 成本高。由于虚拟机弹性能力较弱，业务部门为了应对流量高峰和突发流量，普遍采用预留大量机器和服务实例的做法。即先部署好大量的虚拟机或物理机，按照业务高峰时所需资源做预留，一般是非高峰时段资源需求的两倍。资源预留的办法带来非常高的 IT 成本，在非高峰时段，这些机器资源处于空闲状态，也是巨大的浪费。由于上述原因，美团点评从2015年开始引入 Docker，构建容器集群管理平台，为业务提供高性能的弹性伸缩能力。业界很多公司的做法是采用 Docker 生态圈的开源组件，例如 Kubernetes、 Docker Swarm 等。我们结合自身的业务需求，基于美团云现有架构和组件，实践出一条自研 Docker 容器管理平台之路。我们之所以选择自研容器平台，主要出于以下考虑。

快速满足美团点评的多种业务需求

美团点评的业务类型非常广泛，几乎涵盖了互联网公司所有业务类型。每种业务的需求和痛点也不尽相同。例如一些无状态业务（例如 Web），对弹性扩容的延迟要求很高；数据库，业务的 master 节点，需要极高的可用性，而且还有在线调整 CPU，内存和磁盘等配置的需求。很多业务需要 SSH 登陆访问容器以便调优或者快速定位故障原因，这需要容器管理平台提供便捷的调试功能。为了满足不同业务部门的多种需求，容器平台需要大量的迭代开发工作。基于我们所熟悉的现有平台和工具，可以做到“多快好省”地实现开发目标，满足业务的多种需求。

从容器平台稳定性出发，需要对平台和 Docker 底层技术有更高的把控能力

容器平台承载美团点评大量的线上业务，线上业务对SLA可用性要求非常高，一般要达到99.99%，因此容器平台的稳定性和可靠性是最重要的指标。如果直接引入外界开源组件，我们将面临3个难题：1. 我们需要摸熟开源组件，掌握其接口、评估其性能，至少要达到源码级的理解；2. 构建容器平台，需要对这些开源组件做拼接，从系统层面不断地调优性能瓶颈，消除单点隐患等；3. 在监控、服务治理等方面要和美团点评现有的基础设施整合。这些工作都需要极大的工作量，更重要的是，这样搭建的平台，在短时间内其稳定性和可用性都难以保障。

避免重复建设私有云

美团私有云承载着美团点评所有的在线业务，是国内规模最大的私有云平台之一。经过几年的经营，可靠性经过了公司海量业务的考验。我们不能因为要支持容器，就将成熟稳定的私有云搁置一旁，另起炉灶再重新开发一个新的容器平台。因此从稳定性、成本考虑，基于现有的私有云来建设容器管理平台，对我们来说是最经济的方案。下面我将分别介绍容器平台的架构、组件设计和功能特性。

美团点评容器管理平台架构设计

我们将容器管理平台视作一种云计算模式，因此云计算的架构同样适用于容器。如前所述，容器平台的架构依托于美团私有云现有架构，其中私有云的大部分组件可以直接复用或者经过少量扩展开发。容器平台架构如图1所示。

图1 美团点评容器管理平台架构

从图1可以看出，容器平台整体架构与云计算架构是一致的，自上而下分为业务层、PaaS 层、IaaS 控制层及宿主机资源层。

业务层：代表美团点评使用容器的业务线，它们是容器平台的最终用户。

PaaS 层：使用容器平台的 HTTP API，完成容器的编排、部署、弹性伸缩，监控、服务治理等功能，对上面的业务层通过 HTTP API 或者 Web 的方式提供服务。

IaaS 控制层：提供容器平台的 API 处理、调度、网络、用户鉴权、镜像仓库等管理功能，对 PaaS 提供 HTTP API 接口。

宿主机资源层：Docker 宿主机集群，由多个机房，数百个节点组成。每个节点部署 HostServer、Docker 、监控数据采集模块，Volume 管理模块，OVS 网络管理模块，Cgroup 管理模块等。

容器平台中的绝大部分组件是基于美团私有云已有组件扩展开发的，例如 API、镜像仓库、平台控制器、HostServer、网络管理模块，下面将分别介绍。

API

API 是容器平台对外提供服务的接口，PaaS 层通过 API 来创建、部署云主机。我们将容器和虚拟机看作两种不同的虚拟化计算模型，可以用统一的 API 来管理。即虚拟机等同于 set（后面将详细介绍），磁盘等同于容器。这个思路有两点好处：1. 业务用户不需要改变云主机的使用逻辑，原来基于虚拟机的业务管理流程同样适用于容器，因此可以无缝地将业务从虚拟机迁移到容器之上；2. 容器平台 API 不必重新开发，可以复用美团私有云的 API 处理流程。

创建虚拟机流程较多，一般需要经历调度、准备磁盘、部署配置、启动等多个阶段，平台控制器和 Host-SRV 之间需要很多的交互过程，带来了一定量的延迟。容器相对简单许多，只需要调度、部署启动两个阶段。因此我们对容器的 API 做了简化，将准备磁盘、部署配置和启动整合成一步完成，经简化后容器的创建和启动延迟不到3秒钟，基本达到了 Docker 的启动性能。

Host-SRV

Host-SRV 是宿主机上的容器进程管理器，负责容器镜像拉取、容器磁盘空间管理、以及容器创建、销毁等运行时的管理工作。

镜像拉取：Host-SRV 接到控制器下发的创建请求后，从镜像仓库下载镜像、缓存，然后通过 Docker Load 接口加载到 Docker 里。
容器运行时管理：Host-SRV 通过本地 Unix Socker 接口与 Docker Daemon 通信，对容器生命周期的控制，并支持容器 Logs、exec 等功能。
容器磁盘空间管理：同时管理容器 Rootfs 和 Volume 的磁盘空间，并向控制器上报磁盘使用量，调度器可依据使用量决定容器的调度策略。

Host-SRV 和 Docker Daemon通过 Unix Socket 通信，容器进程由 Docker-Containerd 托管，所以 Host-SRV 的升级发布不会影响本地容器的运行。

镜像仓库

容器平台有以下两个镜像仓库。

Docker Registry：提供 Docker Hub 的 Mirror 功能，加速镜像下载，便于业务团队快速构建业务镜像；
基于 Openstack 组件 Glance 扩展开发的 Docker 镜像仓库，用以托管业务部门制作的 Docker 镜像。

镜像仓库不仅是容器平台的必要组件，也是私有云的必要组件。美团私有云使用 Glance 作为镜像仓库，在建设容器平台之前，Glance 只用来托管虚拟机镜像。每个镜像有一个 UUID，使用 Glance API 和镜像 UUID，可以上传、下载虚拟机镜像。Docker 镜像实际上是由一组子镜像组成，每个子镜像有独立的 ID，并带有一个 Parent ID 属性，指向其父镜像。我们稍加改造了一下 Glance，对每个 Glance 镜像增加 Parent ID 的属性，修改了镜像上传和下载的逻辑。经过简单扩展，使 Glance 具有托管 Docker 镜像的能力。通过 Glance 扩展来支持 Docker 镜像有以下优点：

可以使用同一个镜像仓库来托管 Docker 和虚拟机的镜像，降低运维管理成本；
Glance 已经十分成熟稳定，可以减少在镜像管理上踩坑；
使用 Glance 可以使 Docker 镜像仓库和美团私有云“无缝”对接，使用同一套镜像 API，可以同时支持虚拟机和 Docker 镜像上传、下载，支持分布式的存储后端和多租户隔离等特性；
Glance UUID 和 Docker Image ID 是一一对应的关系，利用这个特性我们实现了 Docker 镜像在仓库中的唯一性，避免冗余存储。

可能有人疑问，用 Glance 做镜像仓库是“重新造轮子”。事实上我们对 Glance 的改造只有200行左右的代码。Glance 简单可靠，我们在很短的时间就完成了镜像仓库的开发上线，目前美团点评已经托管超过16,000多个业务方的 Docker 镜像，平均上传和下载镜像的延迟都是秒级的。

高性能、高弹性的容器网络

网络是十分重要的，又有技术挑战性的领域。一个好的网络架构，需要有高网络传输性能、高弹性、多租户隔离、支持软件定义网络配置等多方面的能力。早期 Docker 提供的网络方案比较简单，只有 None、Bridge、Container 和 Host 这四种网络模式，也没有用户开发接口。2015年 Docker 在1.9版本集成了 Libnetwork 作为其网络的解决方案，支持用户根据自身需求，开发相应的网络驱动，实现网络功能自定义的功能，极大地增强了 Docker 的网络扩展能力。

从容器集群系统来看，只有单宿主机的网络接入是远远不够的，网络还需要提供跨宿主机、机架和机房的能力。从这个需求来看，Docker 和虚拟机来说是共通的，没有明显的差异，从理论上也可以用同一套网络架构来满足 Docker 和虚拟机的网络需求。基于这种理念，容器平台在网络方面复用了美团云网络基础架构和组件，逻辑架构设计如图2所示。

图2 美团点评容器平台网络架构

数据平面，我们采用万兆网卡，结合 OVS-DPDK 方案，并进一步优化单流的转发性能，将几个 CPU 核绑定给 OVS-DPDK 转发使用，只需要少量的计算资源即可提供万兆的数据转发能力。OVS-DPDK 和容器所使用的 CPU 完全隔离，因此也不影响用户的计算资源。

控制平面我们使用 OVS 方案。该方案是在每个宿主机上部署一个自研的软件 Controller，动态接收网络服务下发的网络规则，并将规则进一步下发至 OVS 流表，决定是否对某网络流放行。

MosBridge

在 MosBridge 之前，我们配置容器网络使用的是None模式。所谓 None 模式也就是自定义网络的模式，配置网络需要如下几步：

在创建容器时指定 —net=None，容器创建启动后没有网络；
容器启动后，创建 eth-pair；
将 eth-pair 一端连接到 OVS Bridge 上；
使用 nsenter 这种 Namespace 工具将 eth-pair另一端放到容器的网络 Namespace 中，然后改名、配置 IP 地址和路由。

然而，在实践中，我们发现 None 模式存在一些不足：

容器刚启动时是无网络的，一些业务在启动前会检查网络，导致业务启动失败；
网络配置与 Docker 脱离，容器重启后网络配置丢失；
网络配置由 Host-SRV 控制，每个网卡的配置流程都是在 Host-SRV 中实现的。以后网络功能的升级和扩展，例如对容器添加网卡，或者支持 VPC，会使 Host-SRV 越来越难以维护。

为了解决这些问题，我们将眼光投向 Docker Libnetwork。Libnetwork 为用户提供了可以开发 Docker 网络的能力，允许用户基于 Libnetwork 实现网络驱动来自定义其网络配置的行为。就是说，用户可以编写驱动，让 Docker 按照指定的参数为容器配置 IP、网关和路由。基于 Libnetwork，我们开发了 MosBridge—适配美团云网络架构的 Docker 网络驱动。在创建容器时，需要指定容器创建参数 —net=mosbridge，并将 IP 地址、网关、OVS Bridge 等参数传给 Docker，由 MosBridge 完成网络的配置过程。有了 MosBridge，容器创建启动后便有了网络可以使用。容器的网络配置也持久化在 MosBridge 中，容器重启后网络配置也不会丢失。更重要的是，MosBridge 使 Host-SRV 和 Docker 充分解耦，以后网络功能的升级也会更加方便。

解决 Docker 存储隔离性的问题

业界许多公司使用 Docker 都会面临存储隔离性的问题。就是说 Docker 提供的数据存储的方案是 Volume，通过 mount bind 的方式将本地磁盘的某个目录挂载到容器中，作为容器的“数据盘”使用。这种本地磁盘 Volume 的方式无法做到容量限制，任何一个容器都可以不加限制地向 Volume 写数据，直到占满整个磁盘空间。

图3 LVM-Volume方案

图3 LVM-Volume 方案

针对这一问题，我们开发了 LVM Volume 方案，如图3所示。该方案是在宿主机上创建一个 LVM VG 作为 Volume 的存储后端。创建容器时，从 VG 中创建一个 LV 当作一块磁盘，挂载到容器里，这样 Volume 的容量便由 LVM 加以强限制。得益于 LVM 机强大的管理能力，我们可以做到对 Volume 更精细、更高效的管理。例如，我们可以很方便地调用 LVM 命令查看 Volume 使用量，通过打标签的方式实现 Volume 伪删除和回收站功能，还可以使用 LVM 命令对 Volume 做在线扩容。值得一提地是，LVM 是基于 Linux 内核 Devicemapper 开发的，而 Devicemapper 在 Linux 内核的历史悠久，早在内核2.6版本时就已合入，其可靠性和 I/O 性能完全可以信赖。

适配多种监控服务的容器状态采集模块

容器监控是容器管理平台极其重要的一环，监控不仅仅要实时得到容器的运行状态，还需要获取容器所占用的资源动态变化。在设计实现容器监控之前，美团点评内部已经有了许多监控服务，例如 Zabbix、Falcon 和 CAT。因此我们不需要重新设计实现一套完整的监控服务，更多地是考虑如何高效地采集容器运行信息，根据运行环境的配置上报到相应的监控服务上。简单来说，我们只需要考虑实现一个高效的 Agent，在宿主机上可以采集容器的各种监控数据（如图4所示）。

图4 监控数据采集方案

这里需要考虑两点：

监控指标多，数据量大，数据采集模块必须高效率；
监控的低开销，同一个宿主机可以跑几十个，甚至上百个容器，大量的数据采集、整理和上报过程必须低开销。

针对业务和运维的监控需求，我们基于 Libcontainer 开发了 Mos-Docker-Agent 监控模块。该模块从宿主机 proc、CGroup 等接口采集容器数据，经过加工换算，再通过不同的监控系统 driver 上报数据。该模块使用 GO 语言编写，既可以高效率，又可以直接使用 Libcontainer。而且监控的数据采集和上报过程不经过 Docker Daemon，因此不会加重 Daemon 的负担。

在监控配置这块，由于监控上报模块是插件式的，可以高度自定义上报的监控服务类型，监控项配置，因此可以很灵活地适应不同的监控场景的需求。

支持微服务架构的设计

近几年，微服务架构在互联网技术领域兴起。微服务利用轻量级组件，将一个大型的服务拆解为多个可以独立封装、独立部署的微服务实例，大型服务内在的复杂逻辑由服务之间的交互来实现。

美团点评的很多在线业务是微服务架构的。例如美团点评的服务治理框架，会为每一个在线服务配置一个服务监控 Agent，该 Agent 负责收集上报在线服务的状态信息。类似的微服务还有许多。对于这种微服务架构，使用 Docker 可以有以下两种封装模式。

将所有微服务进程封装到一个容器中。但这样使服务的更新、部署很不灵活，任何一个微服务的更新都要重新构建容器镜像，这相当于将 Docker 容器当作虚拟机使用，没有发挥出 Docker 的优势。

将每个微服务封装到单独的容器中。Docker 具有轻量、环境隔离的优点，很适合用来封装微服务。不过这样可能产生额外的性能问题。一个是大型服务的容器化会产生数倍的计算实例，这对分布式系统的调度和部署带来很大的压力；另一个是性能恶化问题，例如有两个关系紧密的服务，相互通信流量很大，但被部署到不同的机房，会产生相当大的网络开销。

对于支持微服务的问题，Kubernetes 的解决方案是 Pod。每个 Pod 由多个容器组成，是服务部署、编排、管理的最小单位，也是调度的最小单位。Pod 内的容器相互共享资源，包括网络、Volume、IPC 等。因此同一个 Pod 内的多个容器相互之间可以高效率地通信。

我们借鉴了 Pod 的思想，在容器平台上开发了面向微服务的容器组，我们内部称之为 set。一个 set 逻辑示意如图5所示。

图5 set逻辑示意图

图5 set 逻辑示意图

set 是容器平台的调度、弹性扩容/缩容的基本单位。每个 set 由一个 BusyBox 容器和若干个业务容器组成， BusyBox 容器不负责具体业务，只负责管理 set 的网络、Volume 和 IPC 配置。

图6 set的配置JSON

图6 set 的配置 JSON

set 内的所有容器共享网络，Volume 和 IPC。set 配置使用一个 JSON 描述（如图6所示），每一个 set 实例包含一个 Container List，Container 的字段描述了该容器运行时的配置，重要的字段有：

Index，容器编号，代表容器的启动顺序；
Image，Docker 镜像在 Glance 上的 name 或者 ID；
Options，描述了容器启动时的参数配置。其中 CPU 和 MEM 都是百分比，表示这个容器相对于整个 set 在 CPU 和内存的分配情况（例如，对于一个4核的 set 而言，容器 CPU:80，表示该容器将最多使用3.2个物理核）。

通过 set，我们将美团点评的所有容器业务都做了标准化，即所有的线上业务都是用 set 描述，容器平台内只有 set，调度、部署、启停的单位都是 set。

对于 set 的实现上我们还做了一些特殊处理：

Busybox 具有 Privileged 权限，可以自定义一些 sysctl 内核参数，提升容器性能。
为了稳定性考虑，用户不允许 SSH 登陆 Busybox，只允许登陆其他业务容器。
为了简化 Volume 管理，每一个 set 只有一个 Volume，并挂载到 Busybox 下，每个容器相互共享这个 Volume。

很多时候一个 set 内的容器来自不同的团队，镜像更新频度不一，我们在 set 基础上设计了一个灰度更新的功能。该功能允许业务只更新 set 中的部分容器镜像，通过一个灰度更新的 API，即可将线上的 set 升级。灰度更新最大的好处是可以在线更新部分容器，并保持线上服务不间断。

Docker 稳定性和特性的解决方案：Mos Docker

众所周知，Docker 社区非常火热，版本更新十分频繁，大概2～4个月左右会有一个大版本更新，而且每次版本更新都会伴随大量的代码重构。Docker 没有一个长期维护的 LTS 版本，每次更新不可避免地会引入新的 Bug。由于时效原因，一般情况下，某个 Bug 的修复要等到下一个版本。例如1.11引入的 Bug，一般要到1.12版才能解决，而如果使用了1.12版，又会引入新的 Bug，还要等1.13版。如此一来，Docker 的稳定性很难满足生产场景的要求。因此十分有必要维护一个相对稳定的版本，如果发现 Bug，可以在此版本基础上，通过自研修复，或者采用社区的 BugFix 来修复。

除了稳定性的需求之外，我们还需要开发一些功能来满足美团点评的需求。美团点评业务的一些需求来自于我们自己的生产环境，而不属于业界通用的需求。对于这类需求，开源社区通常不会考虑。业界许多公司都存在类似的情况，作为公司基础服务团队就必须通过技术开发来满足这种需求。

基于以上考虑，我们从 Docker 1.11版本开始，自研维护一个分支，我们称之为 Mos Docker。之所以选择从版本1.11开始，是因为从该版本开始，Docker 做了几项重大改进：

Docker Daemon 重构为 Daemon、Containerd 和 runC 这3个 Binary，并解决 Daemon 的单点失效问题；
支持 OCI 标准，容器由统一的 rootfs 和 spec 来定义；
引入了 Libnetwork 框架，允许用户通过开发接口自定义容器网络；
重构了 Docker 镜像存储后端，镜像 ID 由原来的随即字符串转变为基于镜像内容的Hash，使 Docker 镜像安全性更高。

到目前为止，MosDocker 自研的特性主要有：

MosBridge，支持美团云网络架构的网络驱动；
Cgroup 持久化，扩展 Docker Update 接口，可以使更多的 CGroup 配置持久化在容器中，保证容器重启后 CGroup 配置不丢失。
支持子镜像的 Docker Save，可以大幅度提高 Docker 镜像的上传、下载速度。

总之，维护 MosDocker 使我们可以将 Docker 稳定性逐渐控制在自己手里，并且可以按照公司业务的需求做定制开发。

在实际业务中的推广应用

在容器平台运行的一年多时间里，已经接入了美团点评多个大型业务部门的业务，业务类型也是多种多样。通过引入 Docker 技术，为业务部门带来诸多好处，典型的好处包括以下几点。

快速部署，快速应对业务突发流量。由于使用 Docker ，业务的机器申请、部署、业务发布一步完成，业务扩容从原来的小时级缩减为秒级，极大地提高了业务的弹性能力。

图7 某业务虚拟机和容器平均单机QPS

图7 某业务虚拟机和容器平均单机 QPS

图8 某业务虚拟机和容器资源使用量

节省 IT 硬件和运维成本。Docker 在计算上效率更高，加之高弹性使得业务部门不必预留大量的资源，节省大量的硬件投资。以某业务为例（如图7、图8所示），之前为了应对流量波动和突发流量，预留了32台8核 8G 的虚拟机。使用容器弹性方案，即3台容器+弹性扩容的方案取代固定32台虚拟机，平均单机 QPS 提升85%，平均资源占用率降低44-56%。

Docker 在线扩容能力，保障服务不中断。一些有状态的业务，例如数据库和缓存，运行时调整 CPU、内存和磁盘是常见的需求。之前部署在虚拟机中，调整配置需要重启虚拟机，业务的可用性不可避免地被中断了，成为业务的痛点。Docker 对 CPU、内存等资源管理是通过 Linux 的 CGroup 实现的，调整配置只需要修改容器的 CGroup 参数，不必重启容器。

结束语

本文介绍了美团点评 Docker 的实践情况。经过一年的推广实践，从部门内部自己使用，到覆盖公司大部分业务部门和产品线；从单一业务类型到公司线上几十种业务类型，证明了 Docker 这种容器虚拟化技术在提高运维效率，精简发布流程，降低 IT 成本等方面的价值。

目前 Docker 平台还在美团点评深入推广中。在这个过程中，我们发现 Docker （或容器技术）本身存在许多问题和不足，例如，Docker 存在 I/O 隔离性不强的问题，无法对 Buffered I/O 做限制；偶尔 Docker Daemon 会卡死，无反应的问题；容器内存OOM导致容器被删除，开启 OOM _ kill _ disabled 后可能导致宿主机内核崩溃等问题。因此 Docker 技术，在我们看来和虚拟机应该是互补的关系，不能指望在所有场景中 Docker 都可以替代虚拟机，因此只有将 Docker 和虚拟机并重，才能满足用户的各种场景对云计算的需求。

CoreOS vs. Docker 容器大战引擎

文/雷伟

选择哪个技术流派从某种意义上，也决定了选择哪种生态，这也是当前使用容器的公司面临的一大难题。本文将从容器引擎为切入点，说明这两大流派的历史、初衷和技术对比。

容器引擎玩家知多少

看到这个标题，你的表情可能是这样滴“惊愕”。容器引擎不就是 Docker 么？这时，CoreOS 可能在后面默默地流泪，因为 CoreOS 的 rkt 也是玩家中的一员。虽然目前 Docker 的容器使用者相对更多，但 rkt 的发展也不可忽视。

Rocket 与 Docker 引发的站队

前世

故事要从2013年开始说起。是的，Docker 公司在2013年发布了后来红遍大江南北的 Docker 产品，新技术带来一次革命，也带来新的市场机遇，CoreOS 也是其中的一员，在容器生态圈中贴有标签：专为容器设计的操作系统 CoreOS。作为互补，CoreOS+Docker 曾经也是容器部署的明星套餐。值得一提的是，CoreOS 为 Docker 的推广和源码社区都做出了巨大的贡献。

然而好景不长，CoreOS 认为 Docker 野心变大，与之前对 Docker 的期望是“一个简单的基础单元”不同，Docker 也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与 CoreOS 的布局有直接竞争关系。

2014年底，CoreOS 的 CEO Alex Polvi 正式发布了 CoreOS 的开源容器引擎 Rocket（简称 rkt），作为一份正式的“分手”声明。当然，Docker 的 CEO Ben Golub 也在官网作出了及时回应，总体意思表明没有违背初心，但这些都是应用户和贡献者的要求而扩展的，希望大家能一起继续并肩作战。

图1 容器生态

今生

当然，我们都知道了后来的事实，作为容器生态圈的一员，Google 坚定的站在了 CoreOS 一边，并将 Kubernetes 支持 rkt 作为一个重要里程碑，Docker 发布的 Docker 1.12版本开始集成了集群 Swarm 的功能。作为相亲相爱的一家人，Google 于2015年4月领投 CoreOS 1200万美元，而 CoreOS 也发布了 Tectonic，成为首个支持企业版本 Kubernetes 的公司。从此，容器江湖分为两大阵营，Google 派系和 Docker 派系。

而 CoreOS 除了 Rocket 和 CoreOS 外，也提供类似 Docker Hub 的 Quay 的公共镜像服务，也逐步推出容器网络方案 Flannel、镜像安全扫描 Clair、容器分布式存储系统 Torus（2017年2月在对应 GitHub 项目上表示停止开发）等优质的开源产品，包括早期的 etcd，各个产品都和 Kubernetes 有了很好的融合。

图2 容器组织

CNI & CNCF

在两大派系的强烈要求（对撕）下，2015年6月，Docker 不得已带头成立了 OCI 组织，旨在“制定并维护容器镜像格式和容器运行时的正式规范（OCI Specifications），以达到让一个兼容性的容器可以在所有主要的具有兼容性的操作系统和平台之间进行移植，没有人为的技术屏障的目标（artificial technical barriers）”。在2016年8月所罗门和 Kubernetes 的 Kelsey Hightower 的 Twitter 大战中，所罗门透露出对容器标准化消极的态度。

有意思的是，同年（2015年）7月，Google 联合 Linux 基金会成立了最近国内容器厂商陆续加入的 CNCF 组织，并将 Kubernetes 作为首个编入 CNCF 管理体系的开源项目。旨在“构建云原生计算并促进其广泛使用，一种围绕着微服务、容器和应用动态调度的以基础设施架构为中心的方式”。陆续加入 CNCF 的项目有 CoreDNS、Fluentd（日志）、gRPC、Linkerd（服务管理）、openTracing、Prometheus（监控）。

表1 常用功能对比

表2 安全对比

表3 兼容运行单元对比

Docker 与 Rocket 的关系

接下来说说 Docker 和 Rocket 的一些对比。

Docker 和 Rocket 目前都遵循 OCI 标准，但两者对容器引擎的设计初衷有较大差异：

功能边界

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

容器安全

容器安全也是 CoreOS 一直诟病 Docker 的地方，Docker 自1.10后的版本在安全性上也在不断增强。以下从容器的安全方面，包含镜像、系统、容器运行时三部分横向对比。需要说明的是，镜像安全中镜像扫描也尤为重要，Docker Cloud 和 Docker Hub 提供在线漏洞扫描，CoreOS 也提供了 Clair 开源项目对接 CVE 库进行镜像的漏洞扫描。

兼容性除了两者在功能和安全上的对比，为了用户方便评估，在兼容性上也稍作比较。可以看到，发布较晚的 rkt 在对 Docker 兼容性方面采用包容的态度，且 rkt 和 Kubernetes 保持一致，基本运行单元为 pod。

总结

本文从历史的角度说明 rkt 的由来，及引伸的技术流派问题。同时，也对 Docker 和 rkt 从设计（功能、安全和兼容性）的初衷进行简单对比。如果单从 Docker 和 rkt 社区相比，Docker 目前热度更高，但后续如何发展，与其说是简单的 Docker 和 rkt 对比，倒不如说是两大技术流派的选择。

对于容器引擎的选择，虽然 rkt 在安全和兼容性设计上更胜一筹，但当前用户使用 Docker 较多，笔者分析主要也是以下原因：

安装便利。对于企业常用的 OS，在 CentOS 中进行 yum 和 Ubuntu 中进行 apt-get，即可方便安装；同比，目前 CoreOS 官网信息表明，rkt 针对 CentOS 版本还不能使用在生产环境中，对 Ubuntu 也没有发布对应的安装包。另外，对于国内的网络环境，笔者科学上网后几经波折才下载到 rkt 的 release 版本。
社区活跃度。从两者在 Git Hub 中的数据，可以看到 Docker 社区无论在贡献者数量和提交次数上都比 rkt 社区要多，一定程度上也说明了两者用户的使用数量。这点和两者首个版本发布的时间有很大关系。

鉴于以上，建议容器平台使用者和学习者目前可以优先考虑 Docker 作为容器引擎，或是直接使用容器相关厂家提供的从容器引擎到容器云平台的整体解决方案。对于需要基于容器进行二次开发形成产品的容器厂家，尤其是基于 Kubernetes 提供服务的厂家，建议同时对 rkt 保持关注。