腾讯会议，一款提供灵便合作的线上会议解决方案。其中大量的模块是有状态服务，在应用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弹性容器服务来提供更好的容器资源隔离能力、弹性能力，以实现真正的零集群运维老本和高资源利用率的指标。

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