腾讯会议,一款提供灵活协作的线上会议解决方案。其中大量的模块是有状态服务,在使用Kubernetes为其进行容器化部署时,Pod升级需保持共享内存、长连接服务。升级时只容忍ms级抖动,需提供大规模分批灰度发布、业务配额控制等能力,并同时解决集群节点负载不均衡、上万Pods的Workload的HPA性能差等问题。这里将向大家介绍TKEx容器平台及其在灰度发布、资源管理、弹性伸缩等方面的能力。
在腾讯自研业务中,已经有几百万核跑在Kubernetes上,要在如此体量的容器场景提供可靠稳定的容器服务,无论在底层、集群能力、运营或运维等各个方面都面临具体挑战。
TKEx容器平台的底层基于腾讯公有云的TKE和EKS两个产品,它是使用Kubernetes原生的技术手段服务于腾讯内部的业务, 包括腾讯会议、腾讯课堂、QQ及腾讯看点等。TKEx在灰度发布、服务路由、弹性伸缩、容器调度、资源管理、多集群管理、业务容灾、在离线混部等方面做了大量工作,比如:
下面是TKEx平台缩略版的架构图,仅包括本次讨论的相关能力。
业务没有大规模使用StatefulSet的滚动更新能力,对于有状态服务来说,原生的滚动更新机制的发布可控性太差,对于multi-zone容灾部署的业务更是很难做精细化的发布策略。我们提供了分批灰度发布策略供有状态服务使用,约80%的Workload都选择了这种策略。
以一个业务分两批进行发布为例,第一批升级两个Pod,用户可以指定是哪两个Pod,也可以按照一定比例指定第一批是10%,由平台自动选择10%的Pod进行灰度,剩余Pods在第二批进行灰度。
分批灰度发布更安全、更可靠、更可控的特性,整个发布过程更灵活。由于单个批次内所有选中Pods的更新都是并发的,因此可以应付紧急快速发布的需求。
StatefulSetPlus是我们用来实现分批灰度发布的CRD,它继承了Kubernetes原生的StatefulSet的所有能力,并在此之上新增和优化了大量特性。StatefulSetPlus主要提供的核心特性包括自动的以及手动的分批灰度发布,在发布异常时可以进行全量一次回滚或者分批次的回滚。Pod更新的策略支持两种形式,一种是Pod重建的方式,另一种是Pod的原地升级方式。同时我们还提供了一些高级特性,比如:
这里特别介绍一下,如何支持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的垂直扩缩容,主要解决的问题是:
这里面核心的特性,包括提供原地升级容器规格的能力,而不需要重建Container,性能上做了优化,单集群能支持上千个VWA对象的扩缩容。同时也支持VWA的个性化配置,比如可以配置每一个VWA对象的循环同步周期,每次扩容的最大比例以及缩容的最大比例等。
最后再介绍一下在HPA方面我们做的工作。Kubernetes原生的HPA Controller是内置在kube-controller-manager里面的,它存在着以下缺陷:
我们自研了一个HPAPlus Controller,它兼容了原生的HPA对象,然后可以独立部署,在性能方面类似VWA一样做了很多性能优化,同时丰富了每个HPA对象可自定义的配置,比如同步周期、扩容比例、容忍度等。
HPAPlus-Controller还实现了与CronHPA和VWA进行联动决策,比如当VWA持续扩缩容达到了所属节点的上限,无法继续扩容的时候,这个时候会自动托管给HPA触发横向扩容。
腾讯自研业务海量规模,除了文中介绍到弹性伸缩、调度和资源管理、灰度发布等方面面临的挑战外,我们还在多集群管理、在离线混部、ServiceMesh、异构计算、AI/大数据框架支持等多方面做了大量工作。另外,TKEx底层正在大量使用EKS弹性容器服务来提供更好的容器资源隔离能力、弹性能力,以实现真正的零集群运维成本和高资源利用率的目标。