腾讯基于Kubernetes的企业级容器云平台GaiaStack (转)

GaiaStack介绍

GaiaStack是腾讯基于Kubernetes打造的容器私有云平台。这里有几个关键词：

1. 腾讯：GaiaStack可服务腾讯内部所有BG的业务；
2. Kubernetes：GaiaStack的技术实现主要是依托于Kubernetes和容器；
3. 私有云：GaiaStack通过腾讯云向外部企业输出解决方案，并成功在金融、游戏、政务、互联网等各行业落地。

GaiaStack的产品功能主要分为下面两个部分，分别是集群管理员的集群管理功能，以及集群用户的应用全生命周期管理的功能。

集群管理中包括对集群的部署、监控、告警、日志以及规划管理等。应用全生命周期的管理是从开码构建开始，到交付中心、应用的上线、以及后续对应用的自动化运维等各种操作。

从整体架构看，GaiaStack基于Kubernetes、Ceph、Docker、网络等底层技术，完善了认证鉴权，自动化运维等方面，支持代码构建、镜像仓库、应用管理、服务编排、负载均衡、自动运营等应用场景，并向用户提供了访问入口、WebShell、日志检索、配置管理、WebPortal、操作审计等用户工具。

我们对GaiaStack的定位是一个Cluster Operation System，因此它需要承载各种各样的应用类型，即All on GaiaStack，比如开发应用、测试应用、微服务应用、有状态应用、科学计算应用、GPU应用等等。要支持所有类型的应用，仅仅将原生的Kubernetes产品化是远远不够的。

GaiaStack应用全生命周期管理

应用生命周期以代码构建开始，可以关联代码仓库、CI/CD、制作镜像等。一个项目可以被自动或者手动构建多次，也可以从页面上看到每次构建的详细日志。

GaiaStack支持使用代码仓库中已有的Dockerfile，以及云Dockerfile，方便直接在线修改。同时，GaiaStack可以和任何基于Kubernetes的DevOps产品做对接，方便适应企业内部已有的研发流程，还可以自定义流水线。

GaiaStack的两个交付中心：镜像仓库和编排模板

镜像仓库中的镜像可以分为个人镜像、业务镜像，还可以查看全部的公共镜像，支持镜像的导入以及安全扫描。

编排支持Kubernetes编排和Compose编排，镜像和编排都有权限管理，都可以作为应用创建的入口。编排中可见关系图、YAML编码和操作记录。在最新的2.9版本，我们又新增了服务市场的交付中心，里面有各种高可用版本的基础服务，比如Redis、MySQL、ZK等。

GaiaStack的应用分为三个层次，即Stackappinstance。Stack、App、instance都支持创建、删除操作。其中App还新增了停止、启动和重启、复制等操作，编排、应用、实例列表都是多集群、多租户视图，所有视图都支持查询和过滤操作。

配置管理包括ConfigMap和Secret，主要还是Kubernetes自身的机制，但是做了产品化，所以可以直接在界面上对配置做新建、编辑、删除、关联应用等等操作。配置也是提供所有业务、所有集群的同一视图，一个配置组下面的多个配置统一查看和管理。

应用通过GaiaStack发布之后，对应用的运维还远远没有结束，需要对应用做持续的运营操作。

常规操作主要是两类：扩缩容和升级

扩缩容分为主动扩缩容和自动扩缩容，对于自动扩缩容，因为Kubernetes本身支持，这里不再赘述，主要讲一下GaiaStack和Kubernetes不同的机制。

GaiaStack对应用的缩容可以支持定点裁撤，比如银行的业务希望对没有交易处理的实例做缩容，比如游戏的业务希望对没有连接的实例做缩容，比如我们要裁撤掉集群中的某些计算节点等等。

而Kubernetes的缩容，主要是实例数的减少，缩掉的是哪些实例由系统自动决定的。对于升级，GaiaStack除了支持Kubernetes的滚动升级之外，还增加了对应用灰度升级的支持。即选择某一个或N个实例先升级到新版本，在充分的稳定性或者功能性验证后，再考虑升级其他实例，该灰度的过程可以分为任意批次。有时为了验证多个版本，一个应用内也可以同时有多个版本并行存在，充分保证现网的服务质量以及版本的可控性。

下面以现网上一个提供图片识别的OCR服务应用为例，查看其中一个实例的事件：

1. 2018-02-06 11:46:38 V7版本开时候运行；
2. 2018-02-09 09:33:02 对该实例做灰度升级，从V7版本升级到V8版本；
3. 2018-02-09 09:33:02 开始pull V8版本的image。

从这个事件流中可以发现有几个点：

第一，GaiaStack记录了每个实例的所有历史事件，而不是新的Pod开始后就看不到旧的Pod，所以可以跟踪从V1到V8的所有版本历史；

第二，灰度升级是一种原地升级，不但提升了效率，还可以复用原来Pod的现场，而没有经过调度器的环节，也消除了调度失败导致升级失败的风险；

第三，每次升级可以灵活的选择要升级的实例个数以及具体哪些（个）实例。

应用提交到GaiaStack之后，绝不希望进入到一个黑盒子，而是想对其做各种探测，GaiaStack为用户提供了多种探测方式。操作记录中记录了对应用的所有操作记录，特别是当操作失败时，会有失败原因的提示，也可以对用户的操作进行审计。

事件管理包括应用以及实例的事件，并可以查看历史的“所有”事件，避免因为Kubernetes只保存一段时间事件导致在定位问题时丢失关键事件，但并不会增加etcd的压力。用户也可以直接通过WebShell的方式进入容器，并进行各种操作。所有探测操作都是在认证和鉴权的保护下进行。

为了简化应用的使用门槛，GaiaStack默认为每一个App提供了自动的应用和实例的访问入口，方便查看应用页面，如下图中的TensorFlow作业。也可以将一个已有域名绑定在访问入口。除了访问入口，GaiaStack还提供了和主流负载均衡的自动对接。如在腾讯内部实现了与TGW和L5的自动对接，在腾讯云和黑石环境上，也和对应的负载均衡做了对接。

GaiaStack中的负载均衡实现有几个特点：

1. 负载均衡可以跨集群；
2. 负载均衡可以跨App；
3. 负载均衡可以对单个实例做操作，即可以对某一个或者多个实例做绑定、解绑以及再绑定等操作；
4. 负载均衡的生命周期和应用的生命周期独立，即可以在创建应用时绑定负载均衡，也可以在应用运行中绑定或解绑负载均衡。

GaiaStack关键技术

全系统HA、热升级

GaiaStack保证全平台无单点，任何管理节点异常都不会导致平台不可用。所有组件都支持热升级，所谓的热升级是指，GaiaStack自身做升级时，其上面运行的业务可以完全不受影响，不但不会丢失Pod，也不会对Pod有重启操作。

另外GaiaStack同时服务腾讯内部和外部业务，新版本是腾讯内部先升级试用稳定后才发对外版本，以保证对外版本均是稳定版本。GaiaStack的私有云版本还实现了一套产品化的自动安装部署工具，提供了全部可视化的操作方式，降低了学习成本，并可以减少运维人员的操作失误。

全网络模式支持

容器的网络一直是Kubernetes的一个重点和难点。GaiaStack在设计容器网络时有几个原则。第一是要具有普适性，方便GaiaStack适应各种环境。比如Calico性能不错，但是跨二层网络需配置交换机BGP路由信息，对底层网络有较大侵入性。第二是要兼顾性能，比如GaiaStack的Overlay的实现，我们汲取了Flannel/Calico容器网络开源项目的优处，实现了基于IPIP和Host Gateway的Overlay网络方案。同节点容器报文无桥接方式，利用主机路由表进行转发，避免跨主机容器访问时Bridge的二层端口查询。同网段节点容器报文无封包，跨网段节点容器报文利用IPIP协议封包。下面的柱状图是在千兆网卡的环境使用Netperf对这种方案进行了测试，图中长连接和短连接都是64字节。

最终，GaiaStack通过自研的网络插件，实现了四种网络模式，GaiaStack之所以提供四种网络模式，是因为针对不同的应用场景，最适合的网络模式是不同的，可以对每种网络模式扬长避短，每种网络模式都有对应的场景。应用在创建的时候，可以直接选择想要的网络模式，同一主机的不同容器可以选择不同的网络模式。

多资源管理维度

大家听到了很多容器相对于虚拟机的优势，但是不可避免的，我们也要注意一下容器相对于虚拟机的劣势，比如安全方面，比如隔离维度方面。这一节我们中重点讲一下资源管理维度。GaiaStack将所有的资源都纳入了Quota管理维度中，如下图所示。

Docker和Kubernetes都默认支持CPU和内存管理，我们将GaiaStack的资源管理纬度扩展到全维度，来保证各种应用可以安全的共享集群和主机的资源。

下面以网络入带宽为例：当没有网络入带宽控制时，在同一个主机上的各进程的带宽和时延都得不到任何保证。

我们对网络IO的控制目标主要有两个：

一是保证配额资源，第二是当有空闲资源时，不要浪费，可以借用其他Cgroups的空闲带宽。当然还有优先级相关的控制，以及性能的要求。加入了GaiaStack的网络入带宽控制之后，对于资源需求分别是50M和800M的两个Cgroups，机器可供分配的总带宽是850M，也就是没有空闲带宽，两个Cgroups都按照自己的资源需求得到了带宽。

第二个图，机器上仍然是850M的总带宽，两个Cgroups分别是20和70M，那么有130M的空闲带宽，我们可以看到两个Cgroups可以用到超过自己配额的资源。

存储管理

Kubernetes已经有了一些存储管理，但主要还是基于PV/PVC的机制，而应用更需要的是把本地存储能够像CPU、内存一样的当作资源来管理，比如一个磁盘有100G空间，可以让10个需要10G的Pod共享，并且每个Pod所占用的空间是可控的。但磁盘容量的调度和管理会比CPU、内存更加复杂，因为很多计算节点通常是多个分区，比如腾讯的某些服务器，有十几个磁盘。

为了得到更精确的调度和控制，我们将所有分区的可用资源信息都做了上报和管理。也将磁盘容量作为GaiaStack应用提交时可以指定的一个资源维度，让用户可以按照需求来申请。

有了磁盘容量管理之后，解决了用户的日志等本地存储的需求，但是我们发现仍然不能解决所有的存储场景。比如，当用户需要更大的磁盘空间时，可能这个空间已经超出了单机的范围。比如当Pod发生迁移时，需要带数据迁移。比如当业务发现申请的磁盘容量不足，需要在线扩容时等等，此时，云硬盘就是一个很好的解决方案。但通常的云硬盘操作是由用户来申请，然后在创建应用的时候关联，在需要回收的时候清理掉。我们线上有些App有4k多个实例，用户无法实现这么大规模的云盘管理和操作。

因此，GaiaStack又引入了轻盘的概念，即由系统来维护轻盘的生命周期，用户只需要指定轻盘的size和文件系统类型，就可以无需改动代码而使用云盘的好处。在具体的云盘实现支持中，GaiaStack还可以支持独占型和共享型的云盘，来满足不同的场景需要。

在私有云场景下，云盘的底层实现，我们使用的是Ceph，在公有云的场景下，可以和公有云的基础设施做对接。

为何在私有云中选择Ceph

第一、Ceph本身是一个非常优秀的存储系统。它的RBD几乎是OpenStack的事实标准，RGW和FS也得到了越来越广泛的应用。

第二、容器平台用到了Ceph的所有场景，比如云盘使用的是RBD，共享云盘使用了CephFS，Registry的后端存储用的是Ceph RGW，而Ceph是一个统一的分布式存储，我们就不需要为每种场景去选择和维护不同的存储系统了，大大降低了我们的管理成本和实现复杂度。

第三、Ceph是GaiaStack的一个子团队，我们在腾讯内部也运营着服务各个BG的ceph存储平台，名为Tethys，也做了非常多的优化，包括在可扩展性方面，实现了多MDS，在性能方面，特别针对大目录中大量文件的场景做了性能优化，另外，在内核的CephFS模块，也fix了大量的内核bug，以及众多新特性的开发。

P2P Registry

Registry是GaiaStack的基本组件，我们服务在线应用时，一般没有什么问题，但在离线应用中，需要大规模的应用部署时，性能问题就暴露的比较明显了，为此，我们开发了P2P的Registry。在镜像下载过程中，引入BT协议，在blob上传时，对blob生成种子，在下载镜像的blob时，先下载种子，再通过种子文件下载数据。而在具体的实现中，我们采用了一个外部的agent组件，这样不需要修改Docker daemon，对Docker做到了零入侵，并且也优化了peer选取算法，尽量减少Registry的流量。

Tapp应用

Kubernetes已经支持了很多的应用类型，如deployment、statefulset、job等等，但是这些应用类型对于腾讯的很多业务还是不够，经过多年的海量运营教育，我们已经有了腾讯独有的应用模式，为此，我们扩展了Kubernetes的应用，增加了Tapp（Tencent App）类型。不过在后来的推广中发现，Tapp不仅仅是腾讯的需求，很多企业都有类似的需求，因此我们现在称Tapp为“通用服务”。如实例具有可以标识的ID。实例有了ID，业务就可以将很多状态或者配置逻辑和该id做关联；每个实例可以绑定自己的云硬盘；可以 实现真正的灰度升级/回退；可以指定实例id做删除、停止、重启等操作；对每个实例都有生命周期的跟踪。

对GPU的支持

GaiaStack从2015年起就支持腾讯的AI平台，GPU的场景对GaiaStack也提出了非常多的要求。通过GaiaStack来实现云化的GPU管理，提升效率和易用性。我们使用Tapp来支持GPU的应用，让GPU应用可以更好的云存储打通。智能感知GPU拓扑，支持GPU的拓扑调度，提升了应用执行效率。镜像与驱动分离，使得更新驱动版本对用户透明。经过几年的发展，很多GPU集群已经变成了异构集群，不同型号的GPU，价格和性能差异都很大，为此我们在quota管理中，不但有卡数的维度，也同时引入了卡的类型。由于GPU应用大部分是离线业务，所以GaiaStack实现了业务组之间的弹性Quota管理，用以提升整个集群的整体使用率。最近我们还上线了GPU软件虚拟化的特性，进一步提升了GPU卡的使用率。

如下图是两个实验场景：左图实验是vcuda-1容器器申请了0.5个卡，7680MB，运⾏行行在0号GPU，vcuda-2容器器独占卡，运行在1号GPU；vcuda-1的训练速率是平均43.8/s，vcuda-2的训练速度是平均86.6/s。右图实验是vcuda-1容器器申请了了0.3卡，7680MB，运行在0号GPU，vcuda-2容器器申请了60%利用率，12800MB，运行在0号GPU；vcuda-1的的训练速率是平均25.22/s， vcuda-2的训练速度是平均54.7/s。

GaiaStack和社区Kubernetes版本的关系

GaiaStack是一个企业版的Kubernetes容器平台，基于生产环境的需求，对可用性做了很多完善，也实现了很多的功能，但是我们也非常谨慎的处理与社区版本的关系。

主要有几个方面：

第一、跟随社区。社区的大版本我们都会Merge。所以GaiaStack的大多数实现都是非入侵的实现，比如网络是我们自研的Galaxy插件，GPU的管理也是一个GPU Manager的插件，等等，方便与社区版本的Merge。

第二、贡献社区。我们在Ceph、Docker、Kubernetes等社区都会积极的贡献，我们也在腾讯内部连续两年拿到行业贡献奖。

第三、兼容社区Kubernetes的所有原生接口，不对用户做特殊要求。