得物 App 作为互联网行业的后起之秀，在快速的业务发展过程中基础设施规模不断增长，继而对效率和成本的关注度也越来越高。我们在云原生技术上的推进历程如图所示，整体上节奏还是比较快的。

从 2021 年 8 月开始，我们以提升资源使用率和资源交付效率为目标，开始基于云原生技术建设整个服务体系的高可用性、可观测性和高运维效率，同时要保证成本可控。在容器化过程中我们遇到了很多的挑战，包括：如何将存量的服务在保持已有研发流程不变的情况下，做到容器化部署和管理；容器化之后如何做到高效地运维；如何针对不同的业务场景，提供不同的容器化方案等等。

此外，通过技术手段实现持续的成本优化是我们的长期目标，我们先后建设落地了画像系统、混部方案和调度优化等方案。本文把得物在推进云原生容器技术落地过程中相关方案和实践做一些总结和梳理，欢迎阅读和交流。

容器与 ECS 的资源形态是有差异的，所以会造成在管理流程上也会有不同之处。但是为了尽可能降低容器化带来的使用体验上的差异，我们参考业内容器应用 OAM 模型的设计模式，对容器的相关概念做了屏蔽和对等解释。例如：以“应用集群”的概念代表 CloneSet 工作负载（Kruise 提供的一种 Kubernetes 扩展工作负载）；将单个 Pod 约定为一个应用集群的实例；以“应用路由/域名配置”的概念代表针对 Ingress/Service 的设置。

在应用集群的构造上（即如何构造出 Kubernetes 工作负载对象），我们设计了“配置/特征分层”的方案，将一个应用集群所处归属的应用、环境组、环境上的配置进行叠加后，使用 Helm 工具渲染生成 Kubernetes 资源对象，提交给容器平台。

CI 和 CD 过程均使用这种配置/特征分层的方式，一方面可以解决应用依赖的中间件信息的管理问题（由相应的提供者统一维护）；另一方面，这种管理方式可以让中间件组件/服务变更时按照不同维度进行，整体上降低了配置变更带来的风险。

Sidecar 容器在应用集群实例中除了扮演“协作者”的角色外，我们还基于它做了权限管理，以便对应在 ECS 形态下的不同用户的登陆权限，也算是一举两得。当然，在容器场景下也是可以定义不同的用户，赋予不同的角色，但是强依赖基础镜像的维护。

云原生场景下的解决方案对应用集群而言本身就是高可用的，比如：容器编排引擎 Kubernetes 中支持 Pod 实例的拓扑分布设置、支持可用区设置、副本数设置、 Service 负载均衡的设计等，这些都能保证应用集群的高可用。那如果单个 Kubernetes 集群不可用了，会有什么的影响呢，该如何解决？多集群管理方案就是我们解决 Kubernetes 的可用性问题的思路。

如果 Kubernetes 控制面不可用了，会导致应用发布受损，较严重的情况也会影响容器服务的可用性。所以，为了保证 Kubernetes 的可用性，一方面要保证 Kubernetes 各组件的健壮性，另一方面要适当控制单个 Kubernetes 集群的规模，避免集群过大造成系统性风险升高。我们的解决思路就是“不要把鸡蛋放在一个篮子里”，用联邦的方式管理多个 Kubernetes，将业务分散到不同的 Kubernetes 集群。

联邦的思想在 Kubernetes 诞生不久就被开始讨论，逐步设计实现，从最初社区的 KubeFate V1.0 到 V2.0，再到企业开源的 Karmada、KubeAdmiral 逐渐成熟起来，并实际应用到了生产场景。那如果没有集群联邦，多个 Kubernetes 集群就没法管理了吗？当然不是的，容器管控平台其实也能做这件事情，笔者在几年之前还对此深以为然，但现在已经完全改变看法了。因为在实际的生产落地过程中我们发现，相比在管控中用 if...else/switch 的方式，亦或配置的方式相比，基于 CRD 的方式来管理多集群效率更高、逻辑更清晰。

为了兼容存量的通过 Kubernetes Service 进行调用的服务，我们在 Member Kubernetes 集群通过自定义的 MCS-Controller 来管理跨集群的 Service/Endpoints 对象，在 Host Kubernetes 层通过 MCS-Validator 做双重校验，确保跨集群的 Service 的一致性。

落地云原生容器技术的目标是期望在敏捷、弹性和可用的基础上，最终实现资源利用率上的提升、成本上的节省。这通常有 2 个实现途径，一个是通过技术的手段，另一个则是通过治理方法。本章重点介绍我们在容器精细化调度和混部实践方面的技术方案设计和落地过程。

应用服务的研发人员在部署应用集群实例时，通常会申请超过应用集群本身承载业务流量时所要消耗的资源量，这是可以理解的（要确保系统的资源利用率安全水位，防止过载造成系统夯住），但是不同的研发人员对这个“度”把握是不一样的，因为合理地设置应用集群的资源用量是依赖研发人员经验的，也就是说主观性会更强。

为了解决上述问题，业内的做法通常是通过分析应用集群的过往资源利用率数据，来刻画出应用集群在业务流量下的实际资源利用率曲线，这就是应用画像。如下图所示是我们建设的画像系统的架构框图，该画像系统不仅负责应用的画像分析，也负责宿主机、Kubernetes 集群的画像分析，用来指导整个容器平台对资源的管理。

容器的监控数据通过 Prometheus 方案进行采集和管理，自研的 KubeRM 服务将它作为数据源，周期性计算产出应用画像、宿主机画像和 Kubernetes 集群画像（资源池画像）。容器平台部署在线服务服务时，可参考画像值来配置应用集群的资源规格，这里的画像值就是指 Pod 的 Request 值，计算公式如下：

Pod Request = 指标周期性利用率 / 安全水位

公式中“指标周期性利用率”是画像系统通过统计学手段、AI 模型等方法计算分析出的资源指标（CPU/内存/GPU显存）在实际业务流量下所表现出的周期性的规律。画像值的生效我们通过以下 4 个策略进行实施：

交由用户决定画像是否生效时，如何让用户更倾向于去生效画像呢？我们使用差异化计费的策略：生效了画像的应用集群实例按照其 Pod 配置的 Request 值计费，未生效画像的应用集群实例按照其 Pod 配置的 Limit 值计费。用户可以根据自己服务的实际情况选择生效画像，以降低成本；平台也因为画像而拿到了更多可以调度的资源，用于其它更多的场景。

此外，画像系统也接入了 KubeAutoScale 自动伸缩器，在业务低峰期，可以指导自动伸缩器对部分场景在线服务做副本缩容操作，以便释放出更多的资源供给其它场景使用（比如：混部任务场景），后面的章节会详细介绍。

当整个容器集群的资源冗余量不是很充足的时候，在以下几种情况下是会出现 “虽然集群层面总量资源是够的，但是业务 Pod 却无法调度”的问题，影响业务发布效率和体验。

为了解决以上问题，我们在调度器中自定义实现了资源预占的调度插件（通过 CRD 定义资源预占期望，影响调度决策），用来提升用户体验和提高调度效率。

为了更好地平衡集群中节点的水位，以避免过热节点的出现、尽量减少碎片资源等为目标来思考和设计，我们基于 Kubernetes 提供的调度器扩展框架，自定义实现了多个调度插件：

从今年 1 月份开始，我们着手做在离线混部的落地，一期的目标着眼于将在线服务与 Flink 任务进行混部。之所以选择 Flink 任务做混部，是因为它与在线服务有一个相似之处，那就是它是一种常驻的离线任务，在它启动之后如果没有特殊情况，一般不会下线，这种特质会使得我们的容器集群调度频次、Pod 的变更程度会低一些，进而对稳定性的挑战也会小一点，整体混部风险也会低一些。

在没有混部的情况下，我们的集群整体利用率较低，即便画像功能能帮助用户尽可能合理的为自己的服务实例设置资源规格，但对容器平台而言这依然很被动。所以为了挖掘出可以用来混部的资源，我们为不同等级的服务设置不同的绑核策略。如下表所示定义了 4 种应用类型（LSX、LSR、LS、BE），适用于 P0~P4 范围和离线任务，绑核策略从完全绑核到部分绑核，再到完全共享。

离线任务（Flink 任务）属于 BE 类型，可以使用的资源是在宿主机所有 CPU 核心里面单独划分出来的一部分专用 CPU 核心，再加上 LS 的共享 CPU 核心，以及 LSR、LS 类型的应用上共享出来的部分 CPU 核心。

LSX、LSR 和 LS 类型的应用服务的容器实例均申请使用 Kubernetes 原生的资源 CPU/Memory 资源；BE 类型的任务需要申请使用我们自定义的资源 BE-CPU/BE-Memory 资源。

基于 Kubernetes 的 Device-Plugin 机制我们自研实现了 Kube-Agent 组件，该组件在集群中的所有节点上以 Damonset 的方式部署，一方面负责根据自定义策略将本节点上可用的 BE 资源上报给 API-Server（通过 Kubelet 组件间接上报），另一方面负责执行 CPU 绑核操作。随着混部的深入，该组件也承担了更多的工作内容（例如：执行 CPU 算力压制操作、参数动态调整操作，执行 VPA 操作等）。

一期的混部在应用级别划分的基础上，应用了 CPU 核划分策略来实现混部。站在 CPU 核心的角度来看，通过 CPU 核划分策略之后，每个 CPU 核心已经有了自己的负载归属，能否充分利用取决于分配到它上面的业务特性。但站在整机的利用率上来看（或者站在整个集群的利用率角度来看），依然有很大的提升的空间。混部二期的时候，我们考虑对BE资源进行二次超卖，以另一种新的自定义资源（OT 资源）进行分配使用。使用 OT 资源的任务不独占绑核，而是共享划分给 BE 资源的所有 CPU 核心。

我们使用 OT 资源来混部 AI 训练任务、其它数据处理任务，为了消除训练任务对在线业务的影响，通过以下策略进行保证：

容器平台的弹性能力相较于传统 IDC 资源管理模式、ECS 资源管理方式的要更上一个台阶，因为它更侧重将弹性伸缩的决策权交给应用服务，而不是资源管理方。云原生技术中常说的弹性伸缩方案通常包含2种方式：

Kubernetes 中通过资源对象 HorizontalPodautoScalers 来支持工作负载的水平扩缩容，在较早的版本中只支持 CPU 和内存这两个资源指标，较新版本中也开始支持自定义指标了。针对 VPA 的需求，目前 Kubernetes 层面还没有比较稳定的可用功能，因为对一个 Pod 实例做资源规格的调整，会涉及到宿主机上资源账本的管理问题、监控问题，也会涉及到 Pod 的重建/容器重启动作，影响面会比较大，目前社区中依然在讨论。但企业在 VPA 方面，也都是跃跃欲试，会设计自己的个性化 VPA 方案，本文前述应用画像功能，就是我们得物在 VPA 方案上探索的第一步。

此外，我们在实际的支撑业务云原生化转型过程中发现，与通过服务的资源使用率指标来帮助业务来决策服务实例副本数的调整的方式相比，定时扩缩容反而能让研发同学更有信心，研发同学可以根据自己负责的业务服务的流量特征，来设置定时地缩容或者扩容自己的服务实例数量。

为了满足弹性伸缩场景的所有需求，我们设计实现了 KubeAutoScaler 组件，用来统一管理 HPA、VPA、定时伸缩等弹性伸缩策略配置。此外，如前所述，该组件与画像系统相互协作，在混部场景下可以帮助在夜间对部分低流量的服务做缩容操作，释放更多的资源供离线任务使用。

弹性伸缩方案在 GPU 服务场景帮我们避免了很多的资源浪费，特别是在测试环境。如图所示，我们为 GPU 服务注入了一个名为 Queue-Proxy 的 Sidecar 容器，用来采集服务流量，当流量低于某个阈值时，会按照比例减少实例数；当流量为 0 并持续了一段时间之后，会完全缩零。当冷启动时，请求会经过激活器 Activator，激活器再通知 KubeAutoScaler 进行服务扩容。生产环境的部分服务也开启了这一套机制，但在流量低峰期不会完全缩容至零，会维持一个最小的副本数。

为了更好地提升整体的资源利用、降低基础设施成本，与技术方案的落地周期长、复杂度高的特点比起来，通过治理方法往往能在较短时间内达到不错的效果，特别是在应用服务容器化部署改造进行到后期的时候。我们通过以下 5 个方面的治理实践，降本效果明显。

因为历史原因，我们的模型推理服务在刚开始的时候使用的是 V100 的机型，该机型显存较大、GPU 算力较优，更适合用在训练场景，在推理场景的话有点大材小用了。经过机型对比分析，我们选用了一个性价比较高的 A10 机型，推理服务的成本整体降低了 20% 左右，而且因为 A10 机型配备的 CPU 架构有升级，对前后处理有较高要求的推理服务而言稳定性和性能均有提升。

从 V100 切换到 A10，主要的工作在于基础镜像的替换，因为部分模型服务可能使用了较低版本的 CUDA，但是 A10 卡的算力需要配备较高的 CUDA。另外，因为两种卡的 GPU 算力也是有差异的，替换之后需要对推理结果做对比验证才可以上线。我们基于流量回放的思路，设计了 AB 实验功能帮助业务做切换测试。

在使用 CPU 计算资源的场景上，我们对算力要求一般、对 CPU 指令集因无特殊要求、对单核/多核性能无要求的服务，均将其使用的机型从 Intel 的切换到了 AMD 的，整体成本降低 14% 左右。

不得不承认的是容器化初期业务方是占据主动的，业务侧会基于稳定性、资源供给量上的考量要求容器平台独立建集群，或者资源池，容器平台也会选择粗放式管理而应承这些需求。随着容器化的推进，业务侧的信心也会增强，容器平台对资源的把控程度也会更好，我们逐步采取以下几个动作来收敛资源的管理，提高整体的资源分配率：

用户自定义工作负载的规格在云原生场景下也是一个常用的做法，这看似对用户友好的做法却对容器平台造成了一些挑战，因为如果对用户设置规格的自由度不做一些限制，很可能出现一些非常不合理的规格设置（例如：6C120G、20C4G），会产生调度碎片、成本分摊计算标准也难统一。

为了解决规格的问题，我们对在线服务的资源规格做了限制，不允许用户随意指定，而是由平台给出规格列表，由用户选择使用。规格列表可以分资源池设计、也可以分业务场景设置。针对任务型的工作负载，我们定义了 3 种 CPU 类型的资源规格（普通型、计算型、内存型，分别对应不同的 CPU:内存比例）。

针对特殊的任务需求，我们约定了资源规格当中 CPU:内存的范围。针对使用 GPU 的任务，因每种 GPU 卡的 CPU/内存/显存规格配比都是不一样的，我们定义了针对每种 GPU 卡的 CU 单位，用户只需要选择相应的 CU，填写 CU 数量即可。规格约定之后，我们针对不同的规格做了差异化计费，保证了规格申请和成本分摊上的合理性。关于规格的定义和计费标准，详见下表。

得物的基础设施是在云上，所以在业务发展过程中，部分服务能力我们是会直接选用云上产品的。算法侧的模型训练任务，最开始的时候就是选用云上产品，随着容器化的推进，我们自建的 AI 平台（KubeAI 平台）逐步承接模型训练任务，使得训练任务的成本大幅下降。

自建 KubeAI 平台，使得我们将训练使用的资源与在线服务、其它离线任务场景使用的资源纳入了统一的管理体系，便于从全局的视角去合理地调度分配资源，为 AI 模型训练场景拿到更多的可用资源。本文前述 2.5 小节，我们就是通过混部的方式，将在线服务的资源供给了训练任务使用，当前已经在常态混部。

作为云上用户，多云策略是我们的长期目标。在多云之间获得议价主动权、符合合规性要求、获得更充足的资源供给。尤其今年 4 月份以来，随着 GPT/AIGC 方面的爆发、政策因素导致单个云商的 GPU 资源对我们供给不足，阻碍业务发展。我们及时采用多云策略，将 GPU 业务分散到不同的云供应商，保障业务正常开展。当然，多云的接入不是一蹴而就的，而是需要分业务场景逐步推进，周期较长，难度较大，我们需要考虑以下问题：

我们期望云原生容器技术的落地是要覆盖全场景的，要将云原生技术在普通服务、中间件产品和特殊的业务场景上都能发挥其巨大优势。目前 MySQL、Redis、Miluvs、ElasticSearch 等产品都已经在推进容器化。云原生 AI 场景的建设，我们通过 KubeAI 平台的建设在持续推进。

KubeAI 是得物 AI 平台，是我们将云原生容器技术落地得物全站业务过程中，逐步收集和挖掘公司各业务域在AI模型研究和生产迭代过程中的需求，逐步建设而成的一个云原生 AI 平台。KubeAI 以模型为主线提供了从模型开发，到模型训练，再到推理(模型)服务管理，以及模型版本持续迭代的整个生命周期内的解决方案。此外，随着 AIGC 的火热发展，我们经过调研公司内部 AI 辅助生产相关需求，上线了 AIGC/GPT 服务，为得物丰富的业务场景提供了 GAI 能力，助力业务效果提升。关于 KubeAI 平台相关解决方案，我们之前发布过一些文章，欢迎大家阅读交流，这里不再赘述。

云原生容器技术在得物的落地开展还是比较快的，业务覆盖面也比较广泛。经过 2 年时间的实践落地，已经全面深入资源管理系统、预算/成本管理机制、应用服务发布流程、AI 算法等管理体系和业务场景。接下来：

在容器化，我们会继续推进中间件产品的容器化，进一步提升基础设施的资源效率。

我们会继续巩固混部方案，继续探索弹性容量、调度优化等方案，进一步提升资源效率。

在稳定性方面，我们会继续关注容器平台/Kubernetes 本身的稳定性建设，防范风险，切实保证业务平稳运行。

与业务场景一起探索快速接入多云，以及多云之间的快速切换能力，保障业务规模在持续增长的情况下，容器基础设施切换灵活、坚如磐石。