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


GaiaStack介绍

GaiaStack是腾讯基于Kubernetes打造的容器私有云平台。这里有几个关键词:
  1. 腾讯:GaiaStack可服务腾讯内部所有BG的业务;
  2. Kubernetes:GaiaStack的技术实现主要是依托于Kubernetes和容器;
  3. 私有云:GaiaStack通过腾讯云向外部企业输出解决方案,并成功在金融、游戏、政务、互联网等各行业落地。


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

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

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

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

GaiaStack应用全生命周期管理

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

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

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

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

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

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

配置管理包括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的现场,而没有经过调度器的环节,也消除了调度失败导致升级失败的风险。

第三,每次升级可以灵活的选择要升级的实例个数以及具体哪些(个)实例。
06.jpg

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

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

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

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


08.jpg

GaiaStack关键技术

全系统HA、热升级

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

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

全网络模式支持

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

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

多资源管理维度

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

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

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

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

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

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

存储管理

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,以及众多新特性的开发。
14.jpg

P2P Registry

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

Tapp应用

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

对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。
17.jpg

18.jpg

GaiaStack和社区Kubernetes版本的关系

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

主要有几个方面:

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

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

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

原文链接:https://mp.weixin.qq.com/s/DMkFqxgdgOmrLWKqVDVeTw

0 个评论

要回复文章请先登录注册