腾讯会议大规模使用Kubernetes的技术实践

腾讯会议，一款提供灵活协做的线上会议解决方案。其中大量的模块是有状态服务，在使用Kubernetes为其进行容器化部署时，Pod升级需保持共享内存、长链接服务。升级时只容忍ms级抖动，需提供大规模分批灰度发布、业务配额控制等能力，并同时解决集群节点负载不均衡、上万Pods的Workload的HPA性能差等问题。这里将向你们介绍TKEx容器平台及其在灰度发布、资源管理、弹性伸缩等方面的能力。

海量规模下Kubernetes面临的挑战

在腾讯自研业务中，已经有几百万核跑在Kubernetes上，要在如此体量的容器场景提供可靠稳定的容器服务，不管在底层、集群能力、运营或运维等各个方面都面临具体挑战。

1. 咱们怎么进行容器可靠高性能的灰度发布? 尤为是在自研业务里面，大量的服务是有状态的服务, 原生的Kubernetes StatefulSet已经没法知足咱们如此大规模的容器发布需求。
2. 调度层面须要作哪些优化，从而保证在Pod漂移和重调度的过程当中保证业务的稳定性。
3. 在优化资源编排性能方面，如何在整个平台层面和业务层面作好后台管理。
4. 在大规模的弹性伸缩方面如何提供高性能和全面的弹性伸缩能力。

TKEx容器平台简介

TKEx容器平台的底层基于腾讯公有云的TKE和EKS两个产品，它是使用Kubernetes原生的技术手段服务于腾讯内部的业务, 包括腾讯会议、腾讯课堂、QQ及腾讯看点等。TKEx在灰度发布、服务路由、弹性伸缩、容器调度、资源管理、多集群管理、业务容灾、在离线混部等方面作了大量工做，好比：

1. 经过Kubernetes API/Contoller/Operator的原生方式适配腾讯内部各类系统，好比服务路由系统、CMDB、CI、安全平台等。
2. 经过声明式的方式，对全部的托管业务进行生命周期管理。
3. 支持在线业务、大数据、AI等类型做业。
4. 实如今线业务和离线业务的混合部署，同时提高整个资源的利用率。
5. 经过优化linux的内核，加强资源底层隔离能力。
6. 集成Tencent Cloud Mesh(TCM)服务为自研业务提供ServiceMesh服务。
7. 在大规模的集群里面，对弹性伸缩的各类组件进行改造和优化，以保证它的性能和可用性。
8. 基于业务产品维度，提供多租户和配额管理能力。

下面是TKEx平台缩略版的架构图，仅包括本次讨论的相关能力。

1. 底层基于TKE和EKS两个产品，在上层服务于在线业务、AI训练以及大数据做业。
2. 中间这四个框主要包括在应用和路由管理、资源编排调度、弹性伸缩、混部。下面会重点介绍其中前三个部分。

高效稳定的发布能力

业务没有大规模使用StatefulSet的滚动更新能力，对于有状态服务来讲，原生的滚动更新机制的发布可控性太差，对于multi-zone容灾部署的业务更是很难作精细化的发布策略。咱们提供了分批灰度发布策略供有状态服务使用，约80%的Workload都选择了这种策略。

以一个业务分两批进行发布为例，第一批升级两个Pod，用户能够指定是哪两个Pod，也能够按照必定比例指定第一批是10%，由平台自动选择10%的Pod进行灰度，剩余Pods在第二批进行灰度。

• 自动分批机制：若是Pod的探针完善且能真实反映业务是否可用，用户可使用自动分批机制，上一批次完成后可经过自定义的批次时间间隔和健康检查机制自动进行下一批的灰度发布或者自动回滚。
• 手动分批机制：用户也能够经过手动分批机制，在上一批次灰度完成后，可人为在业务层面确认上一批的灰度是否成功，来决定是否触发下一批灰度仍是回滚。

分批灰度发布更安全、更可靠、更可控的特性，整个发布过程更灵活。因为单个批次内全部选中Pods的更新都是并发的，所以能够应付紧急快速发布的需求。

StatefulSetPlus是咱们用来实现分批灰度发布的CRD，它继承了Kubernetes原生的StatefulSet的全部能力，并在此之上新增和优化了大量特性。StatefulSetPlus主要提供的核心特性包括自动的以及手动的分批灰度发布，在发布异常时能够进行全量一次回滚或者分批次的回滚。Pod更新的策略支持两种形式，一种是Pod重建的方式，另外一种是Pod的原地升级方式。同时咱们还提供了一些高级特性，好比：

1. 支持Pod升级过程当中保持Pod使用的共享内存数据不丢失，这个特性很是适合于像腾讯会议这样的音视频业务。
2. 若是升级过程当中触发了Workload的扩容，那么扩容的时候会使用上一个好的版本进行扩容，而不是像原生的StatefulSet和Deployment同样，使用最新的镜像进行扩容，由于最新的镜像版本有多是不可用的，扩容出来的Pod可服务型存在风险。
3. 在存储编排方面，咱们继承了StatefulSet的Per Pod Per PV的特性，同时也支持Per Workload Per PV的特性，即单个StatefulSetPlus下面全部的Pod共享一个PV，也就是相似Deployment共享PV的模式。
4. 在StatefulSet里面，当节点出现异常，好比出现了NodeLost的状况下，出于有状态服务的可用性考虑，不会进行Pod重建。在StatefulSetPlus中，监听到NodeLost后，对应的Pod会自动漂移。这还不够，咱们会经过NPD检测，上报事件或Patch Condition快速发现节点异常，对StatefulSetPlus Pod进行原地重建或者漂移等决策。
5. StatefulSetPlus还有一个很是重要的特性，就是它支持ConfigMap的版本管理以及ConfigMap的分批灰度发布，这是决定ConfigMap可否大规模在生产中使用的关键能力。

这里特别介绍一下，如何支持Pod升级过程当中保持共享内存数据不丢失，而且在升级过程当中，单个Pod只有毫秒级的服务抖动。主要的实现原理就是在Pod里面，经过一个占位容器和业务容器进行文件锁的抢占动做，来实现升级过程当中两个容器的角色进行快速切换。

动态的资源调度和管理

kubernetes的调度原生是使用静态调度的方式，在生产环境会出现集群里面各个节点的负载不均衡的状况，而且形成很大的资源浪费。

动态调度器是咱们自研的一个调度器扩展器，主要任务是平衡集群中各个节点真实的负载，在调度的时候，将各个节点的真实负载归入考量的范畴。

动态调度器必需要解决的一个技术点是调度热点的问题。当集群中有一批节点负载比较低，这时用户建立大量的Pod，这些Pod会集中调度到这些低负载的节点上面，这将致使这些低负载节点在几分钟以后又会成为高负载节点，从而影响这批节点上Pod的服务质量，这种现象尤为在集群扩容后很容易出现。咱们自研的调度热点规避算法，极大的避免了某个节点由于低负载被动态调度器调度后成为延迟性的高负载热点，极少数高负载节点在de-scheduler中会基于Node CPU的历史监控进行节点降热操做。。

咱们但愿可以快速地感知集群的异常状况，包括kubelet异常、docker异常、内核死锁以及节点是否出现文件描述符即将耗尽的状况，从而能在第一时间去作决策，避免问题的恶化。其中快速发现这个动做是由Node Problem Detector（NPD）组件负责的，NPD组件是基于社区的NPD进行了大量的策略扩展。

NPD检测到异常后，除了NPD组件自己对节点自愈的动做以外，de-scheduler还会基于异常事件和当前集群/Workload现状协助进行动做决策，好比Pod驱逐、Container原地重启。这里要重点提一下，咱们基于Self算法的分布式的Ping检测，可以快速发现节点的网络异常状况，由de-scheduler对网络异常节点上的Pods进行漂移。

在腾讯内部，产品的管理是分多个层级的，所以在配额管理方面，咱们没有使用Kubernetes原生的ResourceQuota机制，而是研发了DynamicQuota CRD来实现多层级的、动态的面向业务的Quota管理。

好比从业务维度，腾讯会议是一个产品、腾讯课堂是一个产品，每一个产品下面都会有多级业务模块，在作资源规划和配额管理的时候，是基于产品维度的。在实际部署的时候，实际上Workload绑定到对应的CMDB的最后一级模块。因此，这里须要自动的将产品配额下发到CMDB多级模块的机制，经过DynamicQuota不仅是作资源使用上限的控制，更重要的是保证这个业务有这么多配额能够用，防止被其余业务抢占了。

固然这里还有一些关键问题，好比为了不资源浪费，咱们须要把一些产品的空闲资源借调给其余已经超过配额控制可是须要继续使用更多资源的业务，这样配额就有了灵活的弹性。

同时咱们也利用了DynamicQuota控制在线业务和离线业务占用资源的比例，主要是为了保证在线业务始终会有必定的配额可使用，防止离线业务无限制侵占整个平台的资源，同时也能更好的控制集群负载。

大规模和高性能的弹性伸缩

在扩缩容方面，这里主要介绍纵向扩缩容和横向扩缩容作的工做。社区的VPA不太适合不少腾讯的自研业务，由于扩缩容都是基于Pod的重建机制，在扩容效果和对业务的感知方面，都不是很好。

咱们自研了Vertical Workload AutoScaler (VWA) CRD用于Pod的垂直扩缩容，主要解决的问题是:

1. 当业务出现突发流量的时候，HPA扩容不及时，致使下面Pod的资源利用率暴涨，进而引起业务的雪崩。VWA有更快的响应速度，而且不须要重建Pod，所以比HPA更快更安全。
2. 业务在使用容器规格的时候，常常把容器规格配置得比较高，Pod资源使用率会比较低，经过VWA自动进行降配，优化资源利用率。
3. 当节点出现高负载的状况下，这个节点上面跑着在线和离线业务，咱们会经过VWA快速地对离线业务容器进行在线降配，从而保证在线业务的服务质量。

这里面核心的特性，包括提供原地升级容器规格的能力，而不须要重建Container，性能上作了优化，单集群能支持上千个VWA对象的扩缩容。同时也支持VWA的个性化配置，好比能够配置每个VWA对象的循环同步周期，每次扩容的最大比例以及缩容的最大比例等。

最后再介绍一下在HPA方面咱们作的工做。Kubernetes原生的HPA Controller是内置在kube-controller-manager里面的，它存在着如下缺陷：

1. 它不能独立部署，若是集群中有成千上万的HPA对象，原生HPA Controller是很难承受的，稳定性也直接受限于kube-controller-manager。
2. 另外在性能方面，原生HPA Controller在一个协程里面遍历全部HPA对象，因此在大规模HPA场景下，同步实时性得不到保证。

咱们自研了一个HPAPlus Controller，它兼容了原生的HPA对象，而后能够独立部署，在性能方面相似VWA同样作了不少性能优化，同时丰富了每一个HPA对象可自定义的配置，好比同步周期、扩容比例、容忍度等。

HPAPlus-Controller还实现了与CronHPA和VWA进行联动决策，好比当VWA持续扩缩容达到了所属节点的上限，没法继续扩容的时候，这个时候会自动托管给HPA触发横向扩容。

总结

腾讯自研业务海量规模，除了文中介绍到弹性伸缩、调度和资源管理、灰度发布等方面面临的挑战外，咱们还在多集群管理、在离线混部、ServiceMesh、异构计算、AI/大数据框架支持等多方面作了大量工做。另外，TKEx底层正在大量使用EKS弹性容器服务来提供更好的容器资源隔离能力、弹性能力，以实现真正的零集群运维成本和高资源利用率的目标。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！