关于云原生:国内最大规模上云实践-鹅厂如何在云原生20时代挖呀挖

👉腾小云导读

2022 年 10 月，腾讯自研业务产品全面完成云原生上云。自研业务产品云上规模已冲破 5000w CPU，借助云原生的技术劣势，全面晋升了腾讯自研业务产品的经营效率，在此过程中咱们也对腾讯云产品进行了打磨和验证。无论是在业务场景、稳定性要求、运维效率等多个方面，大规模容器化过程中都面临不少的技术挑战。本篇将进行分享，心愿能够给宽广开发爱好者带来灵感。

👉看目录，点珍藏

1 我的项目背景

1.1 腾讯自研业务产品云原生上云历程简介

1.2 腾讯有状态服务的共性

2 腾讯大规模业务容器化面临的几个挑战

2.1 容器疾速降级

2.2 容器原地热降级

2.3 面向业务产品的全局疾速扩缩容

2.4 对利用屏蔽多样的底层机型，晋升资源池利用率

2.5 从面向集群到面向利用的调度编排

3 总结

腾讯自研业务产品历经三年，包含 QQ、微信、王者光荣、腾讯会议等亿级用户规模的业务产品，都已全面上云。自研业务产品云上的资源规模已冲破 5000 万核，打造了国内最大规模的云原生实际榜样。各位读者点👉这里👈进入页面，左边扫码关注腾讯云开发者公众号，回复「云原生」可下载鹅厂 7w 字大规模云原生技术实际案例集、腾讯云技术实际精选文集。

在这个过程中，腾讯做了大量的技术优化和冲破，包含优化 K8s 集群、全局的资源管理调度，实现了 65% 的 CPU 利用率、晋升容器利用链路上各层的稳定性等等。

3 年工夫，腾讯最终达成了全面云原生上云的指标。在容器利用治理上，有几个事件十分要害：

最晚期须要云原生理念的布道。让所有业务产品”意识“到云原生上云所带来的业务价值。几年前，腾讯外部的 K8s Oteam 联结腾讯学堂推出了第一个面向全公司的 K8s 系列课程。
提供易用性和稳定性的容器治理平台。这解决不同的业务场景容器化上云的痛点并积淀了产品的能力，让所有腾讯业务产品都真实感受到云原生上云的价值。
资源调度编排能力。底层海量的资源规模，须要打造极好的资源调度编排能力，晋升全局的资源利用率，从团体层面达成上云后的降本增效目标。
度量机制。「各个业务产品云原生上云做的怎么样」须要有一套度量机制。例如腾讯的云原生成熟度模型，无效帮忙各个业务晋升了业务产品的云原生成熟度。

上面将次要介绍开发过程中咱们遇到的局部技术挑战和解决方案，各位将能看到咱们在此过程中是如何一步步去夯实产品能力的。

腾讯自研业务产品容器化上云始终以腾讯云产品为底座，整个过程分为两个阶段，云原生上云 1.0 和 2.0 阶段。2022 年前次要是 1.0 阶段，技术核心在「离线混部、在线混部」场景中，业务产品的容器化状态次要经验了富容器和微容器 2 个状态。

通过大规模自研业务产品的容器化，团队积淀了各种业务场景下容器化上云的最佳实际计划和产品所需的能力，例如容器调度（单集群和多集群）、弹性伸缩、有状态服务容器化、大规模资源管理、稳定性晋升、业务运维效率晋升等。

上云阶段不仅仅是把业务产品容器化上云，更重要的是要给业务产品带来理论的价值。这里有腾讯云原生的成熟度规定，来考核腾讯自研业务产品和其对应的容器平台。次要从四个维度考核：

最大的权重维度是资源利用率，指业务产品容器利用率、平台资源利用率。还有弹性伸缩能力、容器可调度能力以及申请的 Pod 资源是不是小外围的资源。通过这些外围指标来标准和评估业务产品云原生上云的过程和成果。

应用 IPC 共享内存时，可能有超 GB 的有状态本地数据，降级时不能失落，而且只容许 ms 级的用户无感知抖动。
局部模块的开发框架须要反对热降级：在容器降级时反对热降级。
海内外多地区部署，单个模块最多的实例数超过 1 万，整个产品的 Workload 十万级，散布在上百个集群中。
底层应用的资源有各代的老旧机型，也有绝对较新的机型，但业务产品基本上不筛选机型。

这些业务产品个性使其在 TKE 治理上面临微小挑战，既要尽量兼容这些业务产品个性，也要放弃其应用镜像公布和降级的云原生准则。TKEx 利用治理平台形象出了这些个性背地的需要，研发了多集群对立灰度公布、多地区多集群工作负载治理、面向利用的多集群协同扩缩容、容器疾速降级、容器热降级等通用的平台能力。

针对「应用 IPC 共享内存，可能有超 GB 的有状态本地数据，降级时不能失落，而且只容许 ms 级的用户无感知抖动」这个业务产品个性，TKEx 利用治理平台开发团队设计研发了使容器疾速降级的产品能力，提供像过程重启一样的 ms 级业务抖动体验，这也是腾讯会议容器化上云很有挑战性的点。

容器原地降级，也是一种针对有状态服务进行降级的无效伎俩。实现在 Pod 不重建的状况下，Pod 内某个 Container 进行重建，放弃了 IPC 共享内存，本地有状态数据不失落。然而原地降级过程中，尽管容器网络和存储不再须要重新分配和挂载，然而依然须要 ReCreate Container，就会存在 Image Pull 和 Container 销毁和启动的过程。

因而原地降级的整个流程消耗工夫肯定是秒级的，这会造成服务的秒级不可用。联合 ReadinessGateway 能做到按需增加 / 剔除路由，实现过程中申请无损。然而用户的有状态数据是在本地的，申请外表无损，而实际上用户对应的长链接服务曾经无奈失常提供服务了。这会导致会议秒级中断，是不可行的。

Pod 里有 3 个要害容器，它们的职责别离如下:

接下来，此处咱们以业务从版本 V1 降级到版本 V2 为例，论述降级流程。

用户第一次部署业务，如上最右边的 Pod, 一共有 3 个容器。biz-sidecar，biz-container（配置环境变量版本号为 1）以及 biz-pause（配置环境变量版本号为 1）。所有容器启动后会别离将 version1, version2 文件的内容更新为 1，biz-sidecar 此时为 Ready。
更新 Pod 前的 biz-pause 容器为业务 V2 版本的镜像，同时环境变量版本号为 2，等该容器原地降级后把 version2 文件的内容更新为 2，之后开始期待文件锁。此时 biz-sidecar 探针转为 notReady 状态。
StatefulSet-Operator Watch 待 biz-sidecar 为 notReady 后，再将之前的 v1 版本的业务镜像替换成 biz-pause 镜像，同时环境变量版本号为 2。等 pause 镜像容器原地重启后，会将之前 v1 业务镜像所占文件锁开释，同时 version1 内容更新为 2。此时 sidecar 探针为 Ready, 整个降级完结。

值得注意的是，原生 K8s apiserver 容许批改 Pod 的 image 等，不反对批改 resource 以及环境变量等，所以该计划须要批改 K8s apiserver 的相干代码。另外为了保障 Pod request 资源以及其 Pod qos 不变，StatefulSetPlus-Operator 在降级时须要对各阶段容器进行 Resource 调整。

最初，基于这个技术原理，咱们封装成 TKEx 利用治理平台所需能力的产品，提供简略好用的操作体验。用户按规定编译好镜像后，只需降级时勾选「疾速降级」，即可实现整个过程。

通过占位容器、状态机 Sidecar 容器、原地降级、共享 volume、文件锁机制，实现容器降级时业务过程的疾速切换。

放弃镜像公布的云原生体验，实现形式齐全是 K8s 原生，回绝把容器当虚拟机应用。

局部模块公布须要放弃共享内存数据不变，并且业务本身要有热重启能力，容器化如何提供业务热降级的能力？ 是云直播等业务模块是否顺利容器化的要害。针对「局部模块的开发框架反对热降级，须要在容器降级时反对原地热降级」这一业务诉求，TKEx 利用治理平台基于 Kubernetes 原地降级、共享 volume、Probe 和占位容器的关键技术，实现并实现了原生的业务容器原地热降级的技术计划和平台能力。

计划阐明：

将业务镜像按职责一拆为二，一个负责业务 bin 文件更新，一个负责业务运行环境。
通过占位容器、原地降级、共享 Volume、探针机制的根底性能，实现容器热降级。

其中，占位容器负责将业务新版本镜像中的新版本业务 bin 复制到共享 volume。业务容器 watch 共享 volume 中相干内容的变动，并能够进行过程 reload 热降级。

而业务容器的探针 Readiness 要负责感知原地热降级的状态，从而反对原地热降级的时候依然能进行容器流量治理。但实际上，因为原地热降级通常是 ms 级的，通常没有必要去在这 ms 级工夫范畴内做路由的剔除和增加。

此过程中，需始终保持以镜像公布的云原生体验，实现形式齐全 k8s 原生，回绝把容器当作虚拟机用的形式去做业务过程降级。遗憾的是目前还没有将这些技术原理封装成平台能力，所以业务要做原地热降级的常识门槛依然较高。

因接入需要和容灾、多活的需要，有些头部业务产品海内外多地区部署单个模块最多的实例数超过 1 万。整个产品的 Workload 万级，散布在上百个集群，和其相似的自研业务产品其实不少。这种业务产品有一个特点，通常对一段时间的「PCU（同时最大在线人数）」的预估来提前进行扩缩容的决策。

例如以后业务产品的 PCU 是 2kw, 须要扩容到 3kw，外围链路上的大部分模块都须要在以后规模的根底上扩容 50%。在如此简单的业务散布拓扑中，要提前进行大规模扩缩容会面临很多艰难：

因为 Workload 数量万级，如果间接对面向 Kubernetes 集群的 Workload 进行操作，须要投入十分多的运维人力独特参加。
因为扩容规模较大，会呈现某些集群的资源有余的问题，包含集群内的计算资源、存储资源、网络资源等。过程中若频繁遇到这类问题，会导致扩容效率极低，沟通老本极高。
在扩缩容失败中遇到的各种问题，很容易被脱漏，短少自动化收集和聚合整个扩缩容动作呈现的所有要害事件和日志的能力。

为此，平台进行了基于业务自建拓扑的全局疾速扩缩容产品能力建设，通过工作的模式治理全局扩缩容，外围能力如下：

第一，用户抉择一批跨业务、跨集群的 Workload，组成一个全局的业务拓扑 Set，作为业务产品维度的扩缩容工作设计的对象，设置全局扩缩容参数，实现扩缩容下发动作。以后反对「基于步长 」和「 基于等比例」两种扩缩容策略，反对配置 HPA 的 Workload 和未配置 HPA 的 Workload 的提前全局扩缩容。这里有 2 种状况：

对于配置了 HPA 的 Workload 的全局扩缩容，次要依据步长或比例调整 HPA 对象的 minReplicas 和 maxReplicas；
对于未配置 HPA 的 Workload 的全局扩缩容，次要依据步长或比例调整 Workload Spec 的 Replicas。

第二，在配置好全局扩容后，资源概览页反对依照「计算资源」、「IP 资源」、「配额」三个维度展现资源需要、资源库存和具体资源缺口等数据，不便按需补充对应资源。

第三，基于业务大盘视图展现的整个扩缩容工作的所有 Workload 和 Pod 实时状态信息，能够疾速找出异样 Pod（状态异样、实时利用率异样），疾速把握整体业务服务扩缩容状态。

第四，提供业务产品的全局 Workload 扩缩容状态视图。反对依照业务、集群、地区等维度聚合查看整个扩缩容工作中所有 Workload 的扩缩容停顿，并有残缺的 Workload 列表页展现各 Workload 运行中正本数量、指标正本数量、库存正本数和异样信息。

计划阐明： 在 TKEx 利用治理平台中，基于 Clusternet 构建的多集群治理计划，业务产品全局疾速扩缩容的外围组件 Global Scaler Operator 部署在 Clusternet Hub Cluster 中，用户在平台前端构建生成 ScalerJob CR 后，会主动生成 ScalerTemplate。

Global Scaler Operator 外围治理着 2 个 CRD，别离是后面提到的扩缩容工作 ScalerJob 和扩缩容模板 ScalerTemplate。

CRD	解析
ScalerJob	定义全局扩缩容配置，并关联扩缩容模板 ScalerTemplate，为整个全局扩缩容提供按指定策略触发运行、回滚、终止等外围能力的定义和状态治理。
ScalerTemplate	定义要扩缩容的 Workloads 对象及其 Scale 参数，也提供全局扩缩容回滚模板的能力。

全局疾速扩缩容策略：后面提了 2 个业务产品全局扩缩容策略，这里举个例子做简略阐明。如果业务产品 X 有 3 个 Workload，散布在广州、上海、北京，正本数别离是 10, 20, 30，以后反对的 PCU 是 10w，须要新增扩容反对 5w PCU。

底层应用的资源有各代的老旧机型，也有新代机型。如何让业务能无差别的应用这些资源，是晋升整个资源池利用率必须要解决的问题。例如 Application X 的实例散布在北上广 3 个地区，调度在多个集群中应用了腾讯云 S3、S4、S5、S6 多种机型资源。如果不做各个实例的路由权重上的差异化解决，那么必定会呈现每个实例的负载不统一。这就容易呈现老旧代机型高负载，新代机型低负载的状况。并且均匀负载并不高，不能触发原生 HPA，从而导致业务服务质量呈现降落。

如果应用的服务路由零碎具备「依据实例负载或者自定义指标动静调整服务权重」的能力，这一问题将失去大幅缓解。

为了解决这个问题，目前有 2 个解决方案，别离利用在不同的业务场景中：

【计划 1】

引入机型族的概念。基于计算、存储、网络等方面的要害性能指标，构建综合性模型，将性能靠近的机型放入同一个机型族（一般性能机型族、高性能机型族、指定机型），从而大幅收敛本来裸露给用户的底层机型。调度上保障同一个 Workload 都应用一个机型族，最终使得各个业务实例在申请量统一的状况下负载根本平衡。这样业务的均匀负载就与各个实例的负载方差很小，HPA 也能失常工作，以保障业务的服务质量。

这种计划次要实用于批量计算型业务，也实用于业务对机型性能有肯定要求的业务，或者必须指定某个具体机型的通用计算场景，然而可能会面临一些资源调度上的危险，例如业务指定机型或机型族的资源有余等问题。这个计划实质上是在缓解这类对资源有性能要求的业务问题。机型族利用越多，该计划对晋升底层各种好差料的成果就越好。

【计划 2】

将底层算力标准化、产品化。平台将底层的所有机型算力都依照预设的模型折算到规范算力，平台从底层资源池中按需调度算力组合成业务须要的规范算力需要。利用在部署和扩缩容时须要的资源，都以规范算力为单位，不必再关注任何机型信息。

例如，利用 X 须要在广州任意 2 个可用区等比例算力部署，共须要 32c200g (c 示意规范 cpu 单位，g 示意规范内存单位)。假如底层资源池中一共有 3 种机型，机型 A 的算力为规范算力的 50%，机型 B 的算力为规范算力的 200%，机型 C 的算力正好是规范算力，则利用 X 可能的部署拓扑如下。

这里还有一个重要的工作，就是须要依据各种底层组合的机型的算力，动静调整对应的服务路由权重。因而 TKEx 利用治理平台联结北极星 Polaris，将各个机型的算力动静折算成路由权重动，实现了基于机型算力的业务全局动静路由权重能力，最终使得同一个 Workload 下不同机型的负载根本保持平衡。

前几年大家更多关注的是怎么给用户提供间接面向 K8s 集群的业务管理能力。在小规模业务场景下，这种形式没有痛点。但随着业务规模的减少，这里的业务管理痛点就逐步裸露。用户要感知底层大量的可用区和集群，对应大量的 Workload、ConfigMap、Service、Ingress 对象的治理。因而这里要转换思路，由面向集群到面向利用的调度编排，这意味着用户不必再关注集群，不必关注底层资源，不必关注每个集群中的 K8s 对象治理，只需关注利用自身。

举个例子，某个业务产品在全网有上万个 Workloads 和 Pods，散布在寰球十几个地区、近百个集群。要对这个业务某个模块做一次全网降级变更，依照以前面向集群的形式实现效率较低，当然借助下层的 DevOps 流水线能够晋升一些效率。所以要形象出面向利用的治理能力，简化业务产品在部署、扩缩容、降级变更、配置管理、流量治理、业务看板等方面的操作体验和效率。

要实现这一指标，外围的底层能力建设就在多集群编排调度上，能够基于 Clusternet 的多集群治理能力来实现。例如，利用想部署同城多活的场景，TKEx 利用治理平台间接提供这种部署策略，不必去指定 Region 去找适合的集群独自部署，间接指定 Region 后，Clusternet 动静拆分调度器 i，主动依据集群容量、地位拓扑等信息来做调度决策，抉择适合的集群并做好最佳的正本散布决策。

再例如，配置利用弹性伸缩时，不须要再面向集群配置 HPA。会有一个全局的多集群 HPA Coordinator Controller 做多集群 HPA 协同，能够依据集群容量、集群的可用性做 HPA 参数的动静调整和协同，保障业务扩容时不会因为某个集群的资源有余无奈扩容，会主动在其余可用集群中扩容。

还有很多重要业务场景，须要在多集群编排中解决。例如面向利用灰度降级时，利用对应的 Workloads 散布在底层多个集群中，如何做好多集群的利用灰度公布？ConfigMap 的多集群灰度公布也是一样的情理。另外，给用户提供的大盘视图、监控告警能力等等都不再是面向集群维度的，而是面向利用的多集群聚合维度的。

腾讯领有国内最大规模的云原生实际案例，过程中大量的技术和产品能力服务了大量业务场景，包含音视频、游戏、电子商务、社交、办公协同、出行等。咱们正在将这里积攒的各种业务场景的最佳实践经验，例如利用的标准化检测、业务的 QoS 定义、利用多集群灰度公布、利用多集群自愈等等，都输入到云原生利用治理平台这个私有云产品中。

用同样的利用治理平台同时服务好腾讯外部和内部客户，与开发者们一起迈入云原生 2.0 时代。以上是本次分享全部内容，欢送大家在[公众号]（点👉这里👈进入开发者社区，左边扫码即可进入公众号）评论区分享交换。如果感觉内容有用，欢送分享转发～

‍
–

-End-

原创作者|王涛

技术责编|王涛

你怎么对待云原生？云原生将来的发展趋势是什么？ 欢送在[公众号]（点👉这里👈进入开发者社区，左边扫码即可进入公众号）评论区探讨。咱们将选取 1 则最有创意的分享，送出腾讯云开发者 - 文化衫 1 个（见下图）。5 月 17 日中午 12 点开奖。

点👉这里👈进入页面，左边扫码关注腾讯云开发者公众号，回复「云原生」查看鹅厂离线学习包：

7w 字腾讯大规模云原生技术实际案例集

腾讯云技术实际精选集

‍