腾讯基于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

第1、Ceph自己是一个很是优秀的存储系统。它的RBD几乎是OpenStack的事实标准，RGW和FS也获得了愈来愈普遍的应用。

第2、容器平台用到了Ceph的全部场景，好比云盘使用的是RBD，共享云盘使用了CephFS，Registry的后端存储用的是Ceph RGW，而Ceph是一个统一的分布式存储，咱们就不须要为每种场景去选择和维护不一样的存储系统了，大大下降了咱们的管理成本和实现复杂度。

第3、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容器平台，基于生产环境的需求，对可用性作了不少完善，也实现了不少的功能，可是咱们也很是谨慎的处理与社区版本的关系。

主要有几个方面：

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

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

第3、兼容社区Kubernetes的全部原生接口，不对用户作特殊要求。