GaiaStack 让Docker 有了一个聪明的智能大脑，具体体现在以下方面：

1.1 GaiaStack 是什么

Docker 与云计算相结合是一场伟大的革命，Docker 的可移植性使得Docker 容器可以运行在云上的任意一台机器上，

而云可以更智能地管理容器。为了让更多的业务充分利用Docker 的优势，GaiaStack 基于Docker 和Kubernetes 打造了一

套完整的容器云平台，它提供了从Code 到Cloud 的一站式解决方案，覆盖了开发、测试、构建、部署、运维等所有环节，

简化了环境的部署，改变了应用的交付模式。GaiaStack 让应用开发者像使用一台超级计算机一样使用整个集群，极大地

降低了资源管理门槛。自动化的作业调度、资源保证和隔离，让多业务共享集群，提升资源使用率的同时，具备很高的伸

缩性和可靠性。

GaiaStack 容器云平台基于腾讯数据平台部门底层资源调度系统Gaia，为了满足如今腾讯大数据平台的大规模、高并

发需求，我们将调度器性能提升了150 倍，并且实现建设通用资源管理平台的目标。从2014 年的Gaia 到如今GaiaStck，平

台在腾讯内部已经经过各个业务的多时锤炼，稳定运行，我们欣喜地看到了GaiaStack 给业务带来的便利及成本优势，同时

GaiaStack 也将走出去，服务于更多的用户。

Docker 可以寻找到更加适合的机器来运行，对于应用来说，真正做到了”Machines are anonymous”。

Docker 可以以最大化资源利用率的方式运行，节约成本。

Docker 可以自动部署，无需人工参与。

Docker 容器不再受到机器故障的制约，可以自动迁移。GaiaStack 会自动识别故障机器，自动迁移Docker 容器到健康

机器上。

Docker 可以实现智能化扩容/ 缩容决策。

Docker 畅游云端，充分利用云平台的大规模效应，服务于海量用户。

…

01

1. GaiaStack 概览

软件开发流程图

1.2 谁会从GaiaStack 受益

GaiaStack 为用户提供了从构建至交付到运行的一整套的解决方案，解决了开发、测试和运维人员的痛点并且在一定

程度上做到了人力的解放。下图 ( 软件开发流程图) 是一个简单的软件开发流程，按照这个流程，我们看下GaiaStack 带来

的好处。

开发环节

开发人员可以简单快速地构建起开发环境，并保持统一的开发环境。比如对于PHP 开发，所有开发人员的开发环境

都可以从GaiaStack 提供的私有镜像仓库或公有镜像仓库中拉取一个基础Image PHP:Latest，然后基于这个Image 做开

发。开发完成后，开发人员只需将最终的程序做成一个新的Image 上传到镜像仓库即可，它可供进一步的开发、测试和部署。

GaiaStack 还提供了代码构建的功能，开发人员开发完代码后，可以自动生成Image，以供开发和测试，带来了更大的便利。

构建环节

开发人员向测试交付版本时只需要告诉Image 名字即可，再也不需要写繁琐的部署文档了，更重要的是，测试和开发可

以保持一致的环境，避免了测试过程中由于环境不一致引入的“额外功”，减少了测试人员部署系统的时间开销。

部署环节

从前运维人员拿到的一般是程序发布包，有了Docker 之后，可以将应用和所有依赖在容器级别上打包，并可以做到真

正的秒级部署。

02

管理环节

运维人员可以很方便地在GaiaStack 页面创建和管理应用，在创建应用时可以选择Image 的名字和版本，还可以指定

更多的属性（比如：CPU、MEM 和磁盘等）。应用运行时，可以让应用根据负载情况进行自动地扩容缩容。GaiaStack 还提

供了很多好用、“智能”的功能，具体可见后面的介绍。

GaiaStack 打通了从“构建”到“交付”到“运行”的全流程，解决了开发、测试和运维的痛点，提供了一整套解决方案，

使用GaiaStack 后，开发人员开发代码，经代码构建自动生成Image，开发和测试测试Image 后就可以直接部署了，大大地

简化了流程，避免了开发、测试和部署环境不同带来的问题。

03

2.1 代码构建

2.2 应用管理

GaiaStack 提供了从代码构建到应用部署的全流程的云容器服务, 部分主要功能如下图( 功能概览图) 所示

代码构建是指关联代码管理库（包括Github、SVN、Gitlab），GaiaStack 平台从代码库中获取源码并打包成镜像，并将

镜像同步到镜像仓库中。

代码构建支持持续集成，只要用户提交代码更新到代码仓库，就可以自动触发单元测试，如果通过测试，将会把新的镜

像同步到镜像仓库，以便后续选择镜像快速部署创建应用。

应用管理是GaiaStack 的核心功能点，通过对应用的创建、查看、升级、停止、删除、扩缩容等操作，对应用进行统一管

理。

2. GaiaStack 主要功能

为了方便用户使用，我们提供了如下主要功能：支持微服务和通用服务两种应用类型；灵活扩大或缩小业务规模，弹性

伸缩；支持灰度升级版本，可以选择将当前应用镜像版本升级为其他版本；支持自动容灾容错：支持实例本地重试与跨机迁移；

支持多种网络模式；支持多种存储方式：本地磁盘、云硬盘、内置云硬盘；支持负载均衡；支持多集群的管理；支持通过网页

直接登录Docker 容器； 灵活实时展示应用相关的配置信息、实例列表、资源监控、日志、操作记录等。

2.3 存储

2.4 镜像仓库

2.5 监控告警

GaiaStack 为应用提供了多种存储方式：

本地磁盘：将数据存储在机器本地磁盘上，性能更高，而且实例本地重试时数据不丢失。

云硬盘：在创建应用之前申请云硬盘，绑定到实例上，发生跨机迁移时数据也不会丢失。

内置云硬盘：更智能的云硬盘，按需使用，无需提前申请。

GaiaStack 镜 像 仓 库 同 时 支 持Registry V1.0 和V2.0 版本 的 镜 像 格 式 和API。我 们 增 加 了Registry P2P 下 载，加 速

Registry 的分发下载，支持高并发性，让应用更快地运行起来。

为了方便用户使用，我们提供了如下主要功能：

自动同步官方 Image( 可以指定需要同步的官方 Image 列表 ；) 分组权限管理； 图像界面查看和管理 Image 列表；创建 App 时，

从下拉列表选取 Image。

GaiaStack 的监控告警主要分为两部分：指标展示及事件告警（指标告警、异常事件告警），用户可以根据监控告警查

看应用运行状态，并支持短信或邮件通知。

04

指标展示：对象范围包括实例、应用、业务、集群、节点；资源对象包括 CPU、内存、云硬盘、本地磁盘存储、磁盘读写速率、

网络出入带宽； 资源范围包括总资源（ 如某个业务总共有多少资源）、已分配资源（即应用申请了多少资源）、实际使

用资源（即应用实际使用了多少资源）。

指标告警：用户可以为每个指标设置阈值，如设置某个业务的 CPU 已分配量超过多少或少于就报警。

异常事件告警：异常事件告警从各个方面监控集群的健康状况，目前有 60+ 类告警，常见有本机告警（机器 Crash、资

源紧张等）、集群告警（ETCD 失联、实例迁移等）。

05

3.1 通用服务（Tapp）

3.2 网络模式

Kubernetes 已经支持了很多的应用类型，如微服务应用、有状态应用、Job 类型应用等等，但是这些应用类型对于有

些应用（比如腾讯内部的很多应用）还是不够，为此，我们扩展了Kubernetes 的应用，增加了Tapp（Tencent App）类型。

GaiaStack 自研了遵循CNI 网络标准的Kubernetes 网络插件，与黑石的VPC 网络进行了打通，为每个容器分配一个黑

石VPC 网络的IP，使得容器与容器，容器与黑石物理机，容器与集群外同VPC 的服务均可直接路由。这种方式让容器和普通

机器几乎具有相同的使用方式，没有端口冲突问题，而且可以无障碍的和其他机器或容器通信，与周边系统的对接也非常容

易。GaiaStack 的负载均衡功能是直接使用容器的VPC IP 注册黑石的负载均衡，避免了Kubernetes 基于Iptables NAT 实

现的NodePort 方式的性能损失。GaiaStack 网络没有NAT 过程，也没有封包解包过程，因此其性能相比于各类开源容器

Overlay 网络也更好。

GaiaStack on 黑 石的网络 拓扑 如下图 所 示。假设客户在VPC X 已 经 创建 好SubnetH，且 购买 好宿主 机A、B、C，

GaiaStack 集群初始化阶段，相关组件会自动调用黑石VPC 网络的相关接口，为每台宿主机申请并绑定一个独立的同VPC

的子网段，子网段大小视业务需求可配置。

GaiaStack 基于Kubernetes 而做的，但Kubernetes 也不是万能的，我们对Kubernetes 在HA、Quota 准入和管理机制、

资源管理纬度和方式、应用类型、RBD Plugin、日志管理等等、很多方面都做了完善和改进，也修复了开源项目的一些Bug，

提升了可用性。本节介绍一下GaiaStack 的优势。

3. GaiaStack 的特点和优势

1) 实例具有可以标识的 ID：

实例有了 ID，业务就可以将很多状态或者配置逻辑和该 ID 做关联。

2) 每个实例可以绑定自己的云硬盘（Ceph RBD）

3) 实现真正的灰度升级 / 回退

Kubernetes 中也有灰度升级的概念，但是我们认为和公司内部常用的灰度升级不同，Kubernetes 的“灰度”概念是

“逐个”的概念，而很多业务需要的是稳定的灰度，即同一个 App，需要有多个版本同时稳定长时间的存在。

4) 可以指定实例 ID 做删除、停止、重启等操作

对于微服务 App 来说，由于没有固定 ID，因此无法对某个实例做操作，而是全部交给了系统去维持足够的实例数。

5) 对每个实例都有生命周期的跟踪

对于同一个实例，可以由于机器故障发生了迁移、重启等操作，虽然不是一个 Pod 了，但是我们用实例 ID 串联起来，

就获得了实例真正的生命周期的跟踪，对于判断业务和系统是否正常服务具有特别重要的意义。

3.3 多维度资源管理

GaiaStack 网络插件默认使用Linux Bridge 设备保证容器与宿主机上层交换机二层连通，也支持使用MacVlan、

SRIOV 网桥。

06

Docker 和Kubernetes 都默认支持CPU 和内存管理，基于以前Gaia 项目在资源管理方面的积累，我们也将GaiaStack

的资源管理纬度扩展到全维度，以更好地保证在线离线业务可以共享集群资源。

1) Disk Space（磁盘空间）

很多业务都需要较大的本地磁盘空间， 因此磁盘容量成为第一个扩展的资源纬度。Disk Space 比 CPU、内存管理更复

杂的方面主要是， 多磁盘容量管理， 在设计上我们扩展了Scheduler，避免了多个决策中心。在对容量做控制时，采用了

Softlimit+Hardlimit 的弹性控制算法，同时也考虑到了 Pod 的优先级。

2) Network IO

网络出带宽的管理比较成熟，Tc+Cgroups 即可，并且可以做到弹性控制。但是对于网络入带宽却比较复杂，为此我们在

内核中引入了 Net_rx 模块。实现了以下设计目标：

某个Cgroup 网络繁忙时，能保证其设定配额不会被其他Cgroup 挤占。

在某个Cgroup 没有用满其配额时，其他Cgroup 可以自动使用其空闲的部分带宽。

在多个Cgroup 分享其他Cgroup 的空闲带宽时，优先级高的优先；优先级相同时， 配额大的占用多，配额小的占用少。

尽量减少为了流量控制而主动丢包。

具体数据见下文图表：

07

同优先级且无空闲带宽，可以保证Cgroups 设置带宽

同优先级有空闲带宽，空闲带宽会根据Cgroups 做分配

08

不同的优先级，空闲带宽优先满足优先级高的Cgroup

3) Disk IO

Cgroups 中虽然有 Disk IO 的模块 Blkio，但是有几个明显的问题：

对BufferIO 失控。cgroup 通过识别Pid，控制磁盘IO。但在Buffer IO 中，失去了原有的Pid 信息，导致不可控。

在IO Weight 方面（Cfq机制），是通过时间片进行分割的，而不是通过Iops 或者Bps 进行衡量。用户观察到的传输数

据波动比较大。

Cgroup 对IO 的控制目前是Hard 模式(Throttle)，即给某个进程限速后，该进程永远不会超过该速率，造成很大的资

源浪费。为此，我们实现EIC-IO（Elastic IO，弹性IO），采取了弹性控制，并且可以控制Buffer Write。尽量减少为了流

量控制而主动丢包。

具体数据见下文图表：

09

Assured=10Mbps, Ceil=50Mbps：对于单IO，若磁盘有空闲带宽，则会突破Assured 速率，最高达到Ceil 速率。

对于并行IO，若磁盘有空闲带宽，且空闲带宽可以满足并行IO Ceil 值总和，则这些并行IO 会按照Ceil 速率下发IO。但若空

闲带宽不能满足并行IO 的Ceil 值总和，则会优先分配给Assured 值比较大的IO。

3.4 应用编排

3.5 负载均衡对接

通常一个真实的应用，不仅仅包含一个App，所以GaiaStack 增加了对应用编排的支持，让用户可以通过提交一个编

排，来对多个应用统一做管理。

在Docker 的开源方案中，目前看起来Kubernetes 确实是占有优势，但是我们也没有忽略掉其他用户，为此，我们不

但支持Kubernetes 的Pod 编排，也引入了对Compose 编排的支持。

10

3.6 云硬盘

腾讯内很多的应用都用到了L5 或者TGW，因此，GaiaStack 自动对接了公司的L5 以及TGW，减轻了用户自己对接的

工作，并且当容器发生迁移、扩缩容时，业务端不需要感知，真正将业务云化。同时我们也对接了腾讯云上的负载均衡，以

便用户更好地使用，后续还将对接其他云环境的负载均衡，甚至提供GaiaStack 自有的负载均衡。( 部分页面如下图)

Ceph在 云 上 的 存 储， 具 有 天然 的 优 势， 一 方 面 是 因 为 Ceph本 身 具 有 非 常 优 秀 的 特 性， 另 一 方 面，Docker、

Kubernetes 等开源项目很多都已经和ceph 结合的很好。我们团队基于Ceph 的Tethys 平台（更快更稳定的Ceph 统一存储

平台——Tethys），已经稳定支持了腾讯内各个部门的很多业务，因此GaiaStack 基于Tethys 实现了云硬盘。

GaiaStack 对接负载均衡

1) 普通云硬盘

业务自己申请、维护云硬盘。可以提前将数据导入云硬盘，也可以由容器生成云硬盘的数据，同一个云硬盘也可以作为

状态保存媒介在容器间流转。云硬盘的生命周期完全交给用户去控制，并可以在线做扩容操作。( 部分页面如下图 )

11

GaiaStack 创建云硬盘

GaiaStack 内置云硬盘

2) 内置云硬盘

除了容器云中普通云硬盘的场景，GaiaStack 还增加了内置云硬盘，即将云硬盘内嵌到 App 中，不需要用户维护和关

注，系统会自动为每个实例分配云硬盘，扩展了磁盘空间，而且在迁移时可以不丢数据。用户程序可以像使用本地磁盘一样，

不需要修改原有业务逻辑，但是数据却被自动云化了。

12

3.7 日志管理

3.8 更高效的私有仓库registry

GaiaStack 搜集了用户所有log，并提供了搜索入口，这样，一个app 的所有实例的log 就可以通过同一个入口去做日

志的全文检索，看到整体的情况，也可以过滤日志的级别和主机，避免了登陆一个个Container。同时，对于每个实例的

log，GaiaStack 也提供了页面的查看方式， 以及Webshell 登陆去查看以及执行对log 文件执行shell 命令的操作。

GaiaStack 的目标是支持成千上万的集群，这对镜像仓库的性能提出了要求。多个Docker 客户端同时Pull Image 会带

来以下几个问题：

页面查看实例的所有log 以及通过webshell 查看log

大多数公司的临时解决方案都是提前 Pull 这个 Image 或基础镜像。这会带来额外的运营成本，机器上能存储的 Image

也是有限的，会定期清理。因此，我们还需要找到更好的解决方案。

我们的目标是以最小的代价满足需求，尽量不修改 Docker 源代码，否则要强制用户使用我们的 Docker 版本，尽量不

改变用户使用习惯， 否则不利于推广使用。首先我们想到的方案是扩容 Registry 机器数，为了达到最好的体验，我们的机

器数最好能处理最坏的情况，但其他时间我们又用不到这么大规模，会造成机器浪费。我们还考虑过另一种方案，层次性

传输，首先从 Registry 传输到 2 个节点，再从这 2 个节点传输到 4 个节点，再依次传输，这也是可行的，不过实现起来略

微复杂。最终我们发现通过 BT 传输是更合适的，Layer 层数据大，适合 BT 传输。

流量大：每个Client 的传输速度可达到20M+/s，多个Client 就可以占满Registry 机器的网络带宽。

并发请求多：Client 会同时请求多个Layer 的数据，请求数为：Client 数 * Layer 数。测试发现1 台机器Pull 一个1G

大小的Image 时间约为1 分钟左右，100 多台机器同时pull 一个1G 大小的Image 成，时间将会涨到8 分钟左右，这

是不可接受的。

13

我们开发了带有 P2P 分发功能的 Registry（其框架如下图所示），让节点之间可以传输 Image 内容。我们在腾讯云的

200 台物理机上测试了在不同的节点数和不同的 Image 大小的情况下的 Pull 时间，对比了原生的 Docker 和我们的 P2P

Registry 的效果，200 个节点同时 Pull 1G 的 Image 时，Docker 平均用时 571s，P2P Registry 用时 71s，可以看到 P2P

Registry 的效果提升是很明显的。

3.9 一键部署

GaiaStack 可以一键快速部署，我们可以通过Web 页面上的可视化操作对背后系统复杂的组件进行自动化部署，大大

降低了使用者人力成本及学习成本。部署系统的基本功能包括主机管理、组件管理和配置管理等。