容器即服务：从零构建企业级容器集群

2013 年 作为 DevOps 技术咨询师加入思特沃克公司；2014 年 第一届CoreOS 中国 Meetup 讲师；2015 年 第一届极客邦 CNut 全球容器技术大会讲师；2015 年 第九届 ThoughtWorks 中国软件持续交付大会讲师；2015 年 出版《CoreOS 实践之路》一书；2016 年 CSDN 架构技术实战峰会讲师；2016 年 StuQ 容器集群技术直播课程讲师。

在容器集群的生态圈中，各个部分相互依赖和关联，形成了如图 1-1 所示的复杂技术栈。中间部分是作为核心的容器引擎，它需要基于特定的存储引擎和操作系统的支持。为了能够大规模地运行应用服务，在容器引擎之上还有其他各种需求，比如容器网络、服务发现、负载均衡、任务调度等，这些需求本身是容器引擎无法满足的，因此需要将各种基础设施进行组合。构建这样的一个体系，实际上容器集群就已然演化成了一个平台化的服务。

图 1-1 容器集群平台

• 从基础设施到平台

云计算通常被划分为三层，分别是 SaaS（软件即服务）、PaaS（平台即服务）和 IaaS（基础设施即服务），它们对应了云计算的三种应用方式。SaaS 层的应用主要以与业务直接相关的服务为中心，即各行各业的互联网相关业务，如电子商务、金融保险、电信通讯等等，这些不同的服务，都可以通过企业应用的 SaaS 方式进行交付，从而获得动态扩缩和弹性调度的能力，而这些能力恰恰是由下层的 PaaS 提供的。云计算的发展使得大规模服务部署的需求越发旺盛，而 PaaS 和 IaaS 分别提供了这些部署的能力和载体。IaaS 以资源为中心，提供资源弹性，让整个资源以按需获取的方式提供出来。PaaS 以上层应用为中心，提供部署弹性。

云计算的三层发展并不是十分平衡的，在最初的一段时间里，相对 IaaS 和 SaaS 而言，PaaS 的发展一直比较滞后。其根本原因在于，早期 PaaS 始终没有解决好本身的复杂度以及与应用层的耦合度问题。这个问题促使了以容器平台技术为核心的新一代 PaaS 体系的形成，为了区别他们与早期的 PaaS，这一代平台体系通常被称为 CaaS。

用户的业务需求是动态变化的，用户需要以快速、高效的方式实现其容器应用的横向扩展。在 CaaS 中的许多特性和传统 PaaS 都有相似的地方，例如屏蔽底层资源差异、屏蔽分布式部署细节、资源动态扩缩、内置监控、日志、网络解决方案等。但从另一方面来说，CaaS 的生态是基于容器和微服务理念打造的，相较于传统 PaaS，它更加轻量，同时也具有更好的普适性，更易于维护。

可用性通常是分布式应用的重要指标。单点失效是分布式系统的基本假设，当单个容器失效时需要有机制将容器重建甚至迁移到其他计算资源上，从而保持整体服务不受影响。CaaS 也要对计算资源故障进行容错。值得一说的是，在对服务器和服务器集群进行管理的时候，有两种截然不同的管理方式，它们通常被比喻成“饲养宠物”的方式和“放牧牲畜”的方式，如图 1-2 所示。

图 1-2 “饲养宠物”和“放牧牲畜”

在现实场景中，“饲养宠物”型的服务器管理方式其实十分常见。比如说对于数据库服务器，一般企业里的数据库服务器绝对不允许宕机，因为数据库一旦宕机，所有服务就全部不可用了，所以要有人为维护，也就是 DBA 要做的事情。人围着机器转，这是典型的饲养宠物型的服务器管理思路，一旦数据库宕机马上需要有人去修。那么“放牧牲畜”是一种怎样的管理方式呢？对于规模巨大的集群，比如由数千、上万乃至更多服务器组成的集群，如果要确保每一个节点永远处于工作状态，所需要的运维将极其复杂，人力成本将是一个天文数字。因此，集群管理的关注点不应该放在每个单独的节点上，而是一定要能够允许一些服务器处于故障状态，也就是说集群的容错能力才是最需要被关注的设计要素。

实际上，对运行在一个带健康检查的负载均衡背后的数个 Web 服务来说，即使有一些出现了异常，集群依然能够对外提供服务。就像是牛群中忽然少了几只牛，整个牛群依然井然有序，并不会因此进入混乱状态。

集群中管理服务实际上总是隐含着对服务高可用性的需求，而这两种服务的管理方式并非存在着孰优孰劣。像是数据库这类需要持久化存储服务的高可用实施方式，通常是采用多个副本和分片来实现的，虽然能够容忍一定程度的故障，但在故障发生时，人为地进行分析和恢复的确是必要和安全的做法。而像大多数 Web 应用那样不带数据状态的服务，当个别节点不可用时，只要能够快速地识别出来，然后部署新的节点来替代它们就足够了，这样的过程是完全可以被自动化的。

容器本身的环境隔离和快速部署特性，对于“放牧牲畜”这样的任务，实在是再合适不过了。通过 CaaS 管理服务能够在系统出现软硬件故障时其有较好的容错性，放养型的运作管理方式也能够有效降低集群和 CaaS 平台本身的维护成本、运维成本。

作为云计算中一种平台式的概念，CaaS 同样存在“公有 CaaS”和“私有 CaaS”的分别。前者提供的是存在于在开放的互联网上，任何用户都能够以快速的、按需付费的方式进行容器部署和管理的服务平台。后者主要是存在于企业内部，针对特定应用场景优化或是与企业自身业务流程相吻合的容器化软件交付平台。想要完全外包硬件来支持快速应用程序开发的企业可以利用公共 CaaS 服务；想要保持应用程序开发工作在企业内部的企业可以利用私有云解决方案。

从技术的实现来看，CaaS 服务是需要依托于 IaaS 的基础设施实现的。服务的扩缩本质上依然是主机资源的伸缩，只是通过容器的包装屏蔽了复杂性。因此许多目前比较成功的CaaS 平台也都是依托于特定 IaaS 实现的，下面给出了一些示例。

• Amazon ECS：全称是 Amazon EC2 Container Service，这是亚马逊基于它的云平台设计的用于直接运行容器的云端服务。
• CoreOS Tectonic：这是 CoreOS 公司与 Google 公司合作的公有云和私有云的CaaS解决方案，卖点在于备受推崇的Google-style infrastructure 服务和 CoreOS 系统本身的安全特性。
• Docker Datacenter：这是 Docker 公司推出的私有云 CaaS 解决方案，包含 Universal Control Plane 和 Trusted Registry 等服务，作为 Docker 官方的首选推荐，具有不错的竞争力。
• Google Container Engine：由 Google 公司提供的，架设在 Google Compute Engine之上的公有云容器运行平台，与亚马逊的 ECS 是直接的竞争对手。
• Project Magnum：基于 OpenStack 架构的 CaaS 解决方案，它通过 OpenStack 的 API服务将基于 Swarm、Kubernetes、Mesos 的容器发布过程集成到私有 IaaS 云中。

国内近年来也涌现了许多耳熟能详的 CaaS 平台，灵雀云、道客云、时速云、有容云、精灵云、希云等本土企业都相继发布了自己的容器管理系统，笔者相信这个领域依然具有十分广阔的发展空间。

• 数据中心操作系统

虚拟化技术自诞生以后就不断地改变着人们使用硬件资源的方式，近年来，从搜索引擎到社交网络再到微服务和SaaS，虚拟化一直作为支持软件规模化运用背后的关键驱动力。

如果没有虚拟化所带来的服务器利用率的提升和相关成本的节约，那么现在所使用的大多数线上公共服务及企业级的云计算均是不可能实现的。随着数据中心转型，虚拟化背后最初的设想，即把一台大型、昂贵的服务器划分为多台虚拟机理念已然有了不同的含义。相反，虚拟化不再是分配个别服务器的资源，而是将大量的服务器合并为一个仓库规模的虚拟计算机，以运行分布式的应用程序。

维基百科对数据中心的定义是：包括计算机系统和其他与之配套的设备，还包含冗余的数据通信连接、环境控制设备、监控设备以及各种安全装置的一整套复杂的设施。在传统数据中心里，主机与任务的分配是静态的，为了确保所有服务能获得充分的峰值资源，通常会为每种任务分配足量的资源，这使得主机的利用率十分低。同时，还需要由许多 IT专业人员组成的团队来保障所有的服务器能运行，并且确保其中的各个应用程序都能按需获得与之匹配的网络、存储、CPU 等资源。这个工作量十分繁重，以至于必须有一种特殊的管理系统来自动化地处理所有设备上的重复事务，然而这些管理系统往往专用于特定数据中心甚至是特定服务类型任务的。

数据中心操作系统是一个很有趣的概念，它的目的是设计一种通用的服务管理系统，使得用户能够像使用个人计算机操作系统那样，直观且高效地管理部署在整个数据中心的容器即服务：从零构建企业级容器集群数以万计的应用服务。这个概念是在加州大学伯克利分校的博士生 Matei Zaharia 于 2011年美国俄勒冈州波特兰举为的 Usenix 年度技术会议上发表的论文 The Datacenter Needs anOperating System中提出的。Zaharia 也是著名大数据计算框架 Spark 的主要开发者。

在这篇论文里，Zaharia 认为数据中心托管了许多种类的应用程序，包括存储系统、网络应用、长期运行的服务和批量分析。并且随着计算机集群用户数量的增长，这些应用程序的数量在未来还将持续增加。许多企业都设计了自己管理系统来统一处理数据中心中运行的任务。比如，Google 利用 Pregel（一种用于图片应用的框架）、Dremel（一种用于交互式数据挖掘的低延迟系统）和 Percolator（一种增量索引系统）来增强其 MapReduce 计算能力。Facebook 的 Hadoop 数据库处理数百个用户的几乎同时互动的 SQL 查询。但是由于许多类似这些任务的管理系统都是由特定框架和体系管理的，它们之间通常无法共享计算和存储资源。因此，有必要推出一个更强大的、能够处理整个数据中心事务的通用操作系统，使得数据中心的操作人员能够在多个应用程序间有效地反复利用资源。

然而设计一个能够处理数据中心全部资源的操作系统要比制作一个用于个人设备运行应用服务的操作系统困难得多。数据中心操作系统要能够把所有这些集中在一个管理平台并且提供资源共享、数据共享、编程抽象和调试，为整个数据中心提供分布式调度与协调功能，统一协调各类资源，实现数据中心级的弹性伸缩能力。其实从现代云计算的观点来看，数据中心操作系统就相当于一套完善的 IaaS+PaaS 且支持多租户的体系，但现实中存在各式各样的服务和应用，传统的 PaaS 平台对服务设计的侵入性较强，无法直接适配复杂的业务场景，需要对服务进行改造。因此当前比较成功的数据中心操作系统，包括 Google的 Borg 和 Zaharia 设计出的 Mesos，实际上都采用了 IaaS+CaaS 的方式来实现。Borg 和Mesos 等早期数据中心操作系统的设计都远远早于 Docker，它们各自实现了类似的容器化功能。对于所有的数据中心，无论公共或私人还是混合模式，未来都应该趋向于采用这些统一化部署和管理的超大规模架构。这些通过智能软件、容器技术和微服务整合在一起的新型数据中心，将给企业计算带来全新的云经济和云规模，带来全新且前所未有的业务模式。

值得一提的是，“DC/OS”（Data Center Operation System）这个词已经被 Mesosphere公司注册，成为了旗下一款数据中心操作系统产品的名称。然而从本质的定义来看，本书将介绍的 SwarmKit、Kubernetes、Mesos 和 Rancher 等集群方案都实现了对容器集群的规模、生命周期和资源调度等维度的管理，因此也在不同程度上实现了数据中心操作系统的这个理念。

容器技术的发展不是一蹴而就的，然而近年来随着 Docker 提出的 build、ship、run 理念，容器的应用为软件的交付和管理带来了显著的效率提升。容器的集群化使用是容器发展的下一个阶段，“容器即服务”概念的提出，将容器集群本身作为一种屏蔽服务器资源细节、提供部署和调度能力的服务。在短短几年里，围绕容器和集群周边的技术已经十分繁荣，逐渐形成一个至底而上的完整生态圈。本书在接下来的章节中将依次介绍几种主流的容器集群以及容器集群周边的技术方案。

————

以上内容节选自《容器即服务：从零构建企业级容器集群》一书，预计春节前可以与大家见面。

• 内容简介

本书介绍了容器即服务的发展过程和主要内容，重点阐述当下主流的Swarmkit、Kubernetes、Mesos和Rancher开源容器集群方案，并探讨了容器技术在网络、存储、监控、日志等方面的运用场景和基础知识，以及该领域在近年来的一些新的发展方向。本书适合一线架构师、开发者、运维人员乃至技术管理者进行阅读。