乐趣区

关于腾讯云:腾讯会议大规模使用Kubernetes的技术实践

jiezi

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

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

退出移动版