一、前言
得物 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 集群的时候，参考华为开源的 Karmada 解决方案，在此基础之上做了定制开发。容器管控平台负责管理应用集群的原始特征和配置，管理 CICD 流程，向 Host Kubernetes 集群发起容器对象管控请求。Host Kubernetes 集群通过 PropagationPolicies 管理工作负载如何分发到 Member Kubernetes 集群，通过 OverridePolicies 管理差异化的配置。单 Kubernetes 集群下我们使用了分批发布的方式来管理应用集群的发布，在引入联邦管理之后，我们把分批发布的逻辑从容器管控层面下移到了 Host Kubernetes 集群上。为了兼容存量的通过 Kubernetes Service 进行调用的服务，我们在 Member Kubernetes 集群通过自定义的 MCS-Controller 来管理跨集群的 Service/Endpoints 对象，在 Host Kubernetes 层通过 MCS-Validator 做双重校验，确保跨集群的 Service 的一致性。
三、容器调度优化与混部
应用画像
应用服务的研发人员在部署应用集群实例时，通常会申请超过应用集群本身承载业务流量时所要消耗的资源量，这是可以理解的（要确保系统的资源利用率安全水位，防止过载造成系统夯住），但是不同的研发人员对这个“度”把握是不一样的，因为合理地设置应用集群的资源用量是依赖研发人员经验的，也就是说主观性会更强。
为了解决上述问题，业内的做法通常是通过分析应用集群的过往资源利用率数据，来刻画出应用集群在业务流量下的实际资源利用率曲线，这就是应用画像。如下图所示是我们建设的画像系统的架构框图，该画像系统不仅负责应用的画像分析，也负责宿主机、Kubernetes 集群的画像分析，用来指导整个容器平台对资源的管理。
图片
容器的监控数据通过 Prometheus 方案进行采集和管理，自研的 KubeRM 服务将它作为数据源，周期性计算产出应用画像、宿主机画像和 Kubernetes 集群画像（资源池画像）。容器平台部署在线服务服务时，可参考画像值来配置应用集群的资源规格，这里的画像值就是指 Pod 的 Request 值，计算公式如下：
Pod Request = 指标周期性利用率 / 安全水位
公式中“指标周期性利用率”是画像系统通过统计学手段、AI 模型等方法计算分析出的资源指标（CPU/内存/GPU显存）在实际业务流量下所表现出的周期性的规律。画像值的生效我们通过以下 4 个策略进行实施：
- 针对 P3/P4 等级的服务，默认在服务部署时生效画像值。
- 针对非 P3/P4 等级的服务，将画像值推荐给用户，由用户决定部署时是否采用画像。
- 分资源池设置不同的生效策略（默认生效，或者用户决定生效）。
- GPU 显存的画像不做默认生效，推荐给用户，让用户决定。
交由用户决定画像是否生效时，如何让用户更倾向于去生效画像呢？我们使用差异化计费的策略：生效了画像的应用集群实例按照其 Pod 配置的 Request 值计费，未生效画像的应用集群实例按照其 Pod 配置的 Limit 值计费。用户可以根据自己服务的实际情况选择生效画像，以降低成本；平台也因为画像而拿到了更多可以调度的资源，用于其它更多的场景。
此外，画像系统也接入了 KubeAutoScale 自动伸缩器，在业务低峰期，可以指导自动伸缩器对部分场景在线服务做副本缩容操作，以便释放出更多的资源供给其它场景使用（比如：混部任务场景），后面的章节会详细介绍。
资源预占
当整个容器集群的资源冗余量不是很充足的时候，在以下几种情况下是会出现 “虽然集群层面总量资源是够的，但是业务 Pod 却无法调度”的问题，影响业务发布效率和体验。
- 在集群中容器实例变更比较频繁的时候，某个大规格的业务集群在做滚动更新时，释放的旧的实例很可能被小规格的容器实例所抢占，导致无法调度。
- 研发同学负责 2 个应用服务 A 和 B，它们的规格都是一样的。为了保证总体成本不变会，选择将 A 服务的实例缩掉一些，然后扩容 B 服务的实例。因为 Kubernetes 默认调度会按照 Pod 创建时间来依次调度新 Pod，当用户缩容完 A 服务的实例再去扩容 B 服务实例的时候，A 服务释放的资源很可能被其他容器实例抢占，导致 B 的实例无法调度。
- 在大促、全链路压测等业务需要紧急扩容的情况下，容器平台会新扩宿主机节点以满足业务需求，不曾想新扩容的机器资源却被那些“小而快（拉起频繁，执行时间短）”的任务给见缝插针地抢占了，一方面会导致大规格的服务实例无法调度，另一方面还造成了较多的资源碎片。
为了解决以上问题，我们在调度器中自定义实现了资源预占的调度插件（通过 CRD 定义资源预占期望，影响调度决策），用来提升用户体验和提高调度效率。
图片
图片
平衡调度
为了更好地平衡集群中节点的水位，以避免过热节点的出现、尽量减少碎片资源等为目标来思考和设计，我们基于 Kubernetes 提供的调度器扩展框架，自定义实现了多个调度插件：
- CoolDownHotNode 插件：给最近调度过 Pod 的节点降低优先级，避免热点节点。
- HybridUnschedulable 插件：阻止使用弹性资源的 Pod 调度到某些节点上。
- NodeBalance 插件：用于平衡各节点上 CPU Request 值与画像的比值，平衡各节点 CPU 使用率。
- NodeInfoRt 插件：基于画像打分数据和实时打分数据优化 Pod 调度。
在实时混部
从今年 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 训练任务、其它数据处理任务，为了消除训练任务对在线业务的影响，通过以下策略进行保证：
- 设置宿主机安全水位，通过调度插件防止过热节点出现。
- 通过 CPU Group Identity 进行优先级竞争，保障离线任务的调度优先级绝对低于在线服务。
- 对离线任务进行独立挂盘，避免影响在线服务的磁盘 IO。
- 夜间时段通过 KubeAutoScaler 进行对在线服务进行弹性缩容，等比例提升内存的空闲率，保障离线任务有足够的内存资源。
弹性伸缩
- HPA：Horizontal Pod Autoscaling，水平方向的 Pod 副本扩缩容。
- VPA：Vertical Pod Autoscaling，垂直方向的 Pod 规格扩缩容。
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% 左右。
资源池管理
不得不承认的是容器化初期业务方是占据主动的，业务侧会基于稳定性、资源供给量上的考量要求容器平台独立建集群，或者资源池，容器平台也会选择粗放式管理而应承这些需求。随着容器化的推进，业务侧的信心也会增强，容器平台对资源的把控程度也会更好，我们逐步采取以下几个动作来收敛资源的管理，提高整体的资源分配率：
- 冗余量控制：业务的发布是有周期的，我们会根据发布周期，动态调整容器平台管理的资源冗余量。在保证日常的迭代开发的同时，尽可能缩小冗余量。
- 集群合并：统一规划 Kubernetes 集群，按照区域（上海、杭州、北京等）、网络环境类型（测试、预发、生产）、业务形态（普通业务、中间件、基础设施、管控集群等）等维度讨论和决策，下线不必要的集群。
- 资源池合并、规整机型：合并资源需求特征比较相近的资源池（例如：计算型的、内存型的），选择合适的机型。与业务沟通，下线或者合并利用率过低的小资源池。
- 碎片整理：单靠调度器的优化，在调度时尽可能避免碎片力量有限。加上在线服务的变更频率一般比较低，如果不做重调度，长时间累积下来，集群中会存在大量碎片。所以，针对多副本的应用集群，在健壮的优雅停机机制基础上，我们适当进行了一些碎片整理任务（重建 Pod 自由调度、重调度、宿主机腾挪等），有效地减少了资源碎片。
工作负载规格治理
用户自定义工作负载的规格在云原生场景下也是一个常用的做法，这看似对用户友好的做法却对容器平台造成了一些挑战，因为如果对用户设置规格的自由度不做一些限制，很可能出现一些非常不合理的规格设置（例如：6C120G、20C4G），会产生调度碎片、成本分摊计算标准也难统一。
为了解决规格的问题，我们对在线服务的资源规格做了限制，不允许用户随意指定，而是由平台给出规格列表，由用户选择使用。规格列表可以分资源池设计、也可以分业务场景设置。针对任务型的工作负载，我们定义了 3 种 CPU 类型的资源规格（普通型、计算型、内存型，分别对应不同的 CPU:内存比例）。针对特殊的任务需求，我们约定了资源规格当中 CPU:内存的范围。针对使用 GPU 的任务，因每种 GPU 卡的 CPU/内存/显存规格配比都是不一样的，我们定义了针对每种 GPU 卡的 CU 单位，用户只需要选择相应的 CU，填写 CU 数量即可。规格约定之后，我们针对不同的规格做了差异化计费，保证了规格申请和成本分摊上的合理性。关于规格的定义和计费标准，详见下表。
图片
产品自建
得物的基础设施是在云上，所以在业务发展过程中，部分服务能力我们是会直接选用云上产品的。算法侧的模型训练任务，最开始的时候就是选用云上产品，随着容器化的推进，我们自建的 AI 平台（KubeAI 平台）逐步承接模型训练任务，使得训练任务的成本大幅下降。
自建 KubeAI 平台，使得我们将训练使用的资源与在线服务、其它离线任务场景使用的资源纳入了统一的管理体系，便于从全局的视角去合理地调度分配资源，为 AI 模型训练场景拿到更多的可用资源。本文前述 2.5 小节，我们就是通过混部的方式，将在线服务的资源供给了训练任务使用，当前已经在常态混部。
图片
多云策略
作为云上用户，多云策略是我们的长期目标。在多云之间获得议价主动权、符合合规性要求、获得更充足的资源供给。尤其今年 4 月份以来，随着 GPT/AIGC 方面的爆发、政策因素导致单个云商的 GPU 资源对我们供给不足，阻碍业务发展。我们及时采用多云策略，将 GPU 业务分散到不同的云供应商，保障业务正常开展。当然，多云的接入不是一蹴而就的，而是需要分业务场景逐步推进，周期较长，难度较大，我们需要考虑以下问题：
- 梳理业务，找到适合多云的业务场景，或者找到适合在多云之间灵活迁移的业务场景。
- 因不同云供应上的机房可能在不同的区域，所以需要考虑跨地域服务访问、中间件依赖问题。
- 跨云供应商的数据访问和传输问题，涉及到专线建设、成本问题。
五、云原生AI场景建设
我们期望云原生容器技术的落地是要覆盖全场景的，要将云原生技术在普通服务、中间件产品和特殊的业务场景上都能发挥其巨大优势。目前 MySQL、Redis、Miluvs、ElasticSearch 等产品都已经在推进容器化。云原生 AI 场景的建设，我们通过 KubeAI 平台的建设在持续推进。
图片
KubeAI 是得物 AI 平台，是我们将云原生容器技术落地得物全站业务过程中，逐步收集和挖掘公司各业务域在AI模型研究和生产迭代过程中的需求，逐步建设而成的一个云原生 AI 平台。KubeAI 以模型为主线提供了从模型开发，到模型训练，再到推理(模型)服务管理，以及模型版本持续迭代的整个生命周期内的解决方案。此外，随着 AIGC 的火热发展，我们经过调研公司内部 AI 辅助生产相关需求，上线了 AIGC/GPT 服务，为得物丰富的业务场景提供了 GAI 能力，助力业务效果提升。关于 KubeAI 平台相关解决方案，我们之前发布过一些文章，欢迎大家阅读交流，这里不再赘述。
- 一文读懂得物云原生AI平台-KubeAI的落地实践过程
- 得物AI平台-KubeAI推理训练引擎设计和实践
- 得物大模型平台，业务效果提升实践
- GPU推理服务性能优化之路
六、展望
云原生容器技术在得物的落地开展还是比较快的，业务覆盖面也比较广泛。经过 2 年时间的实践落地，已经全面深入资源管理系统、预算/成本管理机制、应用服务发布流程、AI 算法等管理体系和业务场景。接下来：
- 在容器化，我们会继续推进中间件产品的容器化，进一步提升基础设施的资源效率。
- 我们会继续巩固混部方案，继续探索弹性容量、调度优化等方案，进一步提升资源效率。
- 在稳定性方面，我们会继续关注容器平台/Kubernetes 本身的稳定性建设，防范风险，切实保证业务平稳运行。
- 与业务场景一起探索快速接入多云，以及多云之间的快速切换能力，保障业务规模在持续增长的情况下，容器基础设施切换灵活、坚如磐石。
