极氪汽车的云资源治理细探

作者：极氪汽车吴超

前言

2021 年，极氪 001 迅速崭露头角，仅用 110 天便创下了首款车型交付量“最快破万”的纪录。2022 年 11 月，极氪 009 在短短 76 天内便率先完成了首批交付，刷新了中国豪华纯电品牌交付速度的纪录。2023 年 6 月，极氪汽车再次交付 10620 辆，成为保持五个月连续同比增长的唯一豪华纯电品牌。至此，极氪 001 已成为全球最快突破 10 万辆销售的豪华车，再次稳居 30 万元以上纯电车型销冠。

在过去的两年里，极氪汽车业务加速发展，数字化发展部门面临巨大挑战。作为支持公司履约交付、整车交付、支付结算等诸多核心系统的技术部门，团队几乎每天都需要应对不同规模的应用发布，且应用系统所需的云资源消耗日益增加。之前，为确保业务快速发展得到有效支持，基础设施的整体架构缺乏顶层统筹规划，形势犹如野蛮生长。公司虽然在行业赛道中不断打破交付纪录，但疯狂增长背后，则是濒临失控的基础设施框架及成本支出，这种状况正对未来业务的可持续发展，带来了极大的风险和隐患。

因此，从去年开始，技术中台团队制定了明确的技术目标，力求尽快成立专项小组，深度整治现有基础设施的问题。团队期待通过改进基础架构，为极氪汽车未来基础架构的可持续发展保驾护航。

管理挑战

摆在面前的第一个问题，就是云原生场景下的资源管理。

事实上，自 2021 年起，我们便开始了微服务和容器化改造计划，90% 以上的服务以容器的形式构建和部署。早期在讨论如何优化计算资源的配置时，常规的做法是对服务器进行资源利用率检测，对利用率不超过一定阈值的资源，按照 CPU /内存峰值用量调整即可。但在云原生环境下，由于 Kubernetes 为容器资源管理提供了资源请求（Request）与资源限制（Limit）的语义描述，使得应用可以超额分配在对应的服务器资源上，若只是简单的分析计算资源利用率，而忽略了资源的分配率，可能导致在下一次应用发布时，因资源不足而无法调度容器到对应节点。

公司当前使用到阿里云及多个私有云平台，运行了数十个 K8s 集群，同时这些集群上承载了数千个 Pod 节点，在实际运行应用系统时，许多服务的利用率并不高，造成了极大的资源浪费。但是当我们着手制定计划，希望优化这部分资源时，发现诸多挑战：

业务目标

为应对云资源治理方面的不足，以及不同云平台的能力差异，我们曾考虑过是否需要建立一套 CMP 多云管理平台，对所涉及到的云平台及账号统一管理。但是在评估是否要立项时，我们认为云原生时代下“以资源为中心”的多云管理理念，难以满足我们对于应用架构设计的期待。这种管理方式，不仅开发成本极高，还需要适配多个云厂商的不同接口，并且对于资源管理的意义并没有想象中的大，只是解决了一部分资源开通创建的工作，但这并非是云原生环境下应用管理的核心场景及工作。

极氪当前的基础设施架构主要是以 K8s 集群为底座，这意味着只要能够管理好这些集群，便能够管理好资源，从而为上层的业务系统提供更大的价值。于是，我们在设计资源管理方案时，彻底摈弃了 CMP 的以资源为中心的多云资源管理理念，投向了聚焦于云原生基础设施的管理这一方向。

平台技术团队将此次在资源管理域的项目目标定义为：成本可见、用量可控、配置可管， 而当前需要解决的问题包括：

1. 成本洞察与分析： 设计更为精细化的成本均摊模型，看清各业务的成本支出情况，同时为不同业务提供 Pod 资源利用率的智能分析，辅助运维部署工程师在应用发布时，合理设置资源规格；

2. 配置基线检查： 针对现有部署脚本配置合规性问题，做基线检查，确保调整优化后的配置能够满足日常监控、故障自愈等场景；

3. 收敛 K8s 集群数量： 在不影响业务的情况下，对部分业务量较小的闲散 K8s 集群进行合并，收敛集群数量，降低架构复杂度及管理成本；

4. 基础设施无状态化： 考虑到未来的出海业务可能部署在当前未覆盖的云厂商，我们希望以 K8s 作为标准技术底座，将基础设施尽可能做到无状态化，在应用发布过程中，仅需要改动少量参数即可完成应用的上线工作。

方案选型

成本摊销

由于极氪当前大多数的应用部署在阿里云，基于二八原则，我们首先调研了关于阿里云 ACK FinOps 的解决方案。对于极氪的当前的基础设施现状来说，ACK FinOps 套件是一个不错的选择，其分别包含了集群、命名空间（Namespace）、节点池和应用四个维度的成本分析方案。

借助于命名空间和应用维度的成本分析，这种基于实际资源用量的分账逻辑，使得账单分摊不再局限以服务器为单位，从而也为未来 K8s 集群数量收敛，提供了必要的能力支持。

但在云原生的场景下，针对容器级别的成本摊销，需要考虑更多维度的业务场景。举例来说，一台 4C32G 的服务器，资源被分配出去 3C/8G，那么这个时候，CPU 资源影响了这台服务器剩余资源的瓶颈，反之亦然。此外，K8s 的 pod 资源模型支持 request、limit 两个维度的资源分配，而影响到调度资源的则是 request。对于一些被设置为 BestEffort 或是 Burstable QoS 等级，资源被超卖的节点来说，难以完全基于某个指标去判断逻辑合理性。

ACK FinOps 的成本分摊模型为我们提供了更丰富的选择，分别能够提供基于 CPU、内存单维度资源分摊模型和权重混合资源分摊模型等多种不同的逻辑实现。

单维度资源分摊模型的优势在于解释成本低，Pod 成本的计算逻辑大体为：

*Pod 成本 = （Pod 申请资源（Request）/ node 资源总量）node 节点单价即可。

业务团队仅需为实际使用量付费，当 K8s 集群规模较大时，未被分配的剩余闲置资源数越少，则也能侧面说明云平台团队治理能力的体现。

关于权重混合资源分摊模型，本质上要解决的是在同一集群内，同时充满了多样化的业务场景及开发技术栈。例如，对于一台 4C8G 的服务器，同时部署一个 1C6G 的服务和一个 2C1G 的服务，则这个使用，无论基于内存还是 CPU 的申请资源作为成本摊销的依据，均明显不合理。

在调研完了两种不同的分摊模型之后，考虑到极氪当前业务开发语言主要为 Java 技术栈的现状，应用 Pod 会向集群申请大量内存资源，导致内存的调度水位升高。虽然内存的单位成本较 CPU 而言，便宜的多，但对于该业务场景而言，内存成为了集群是否需要被扩容的瓶颈点。同时，不同于 CPU 的 QoS 存在显性的超卖，内存资源的利用率几乎约等于分配率，因此在此场景下，我们使用单一资源模型作为部门的成本分摊模型。

另一个问题是成本分账的颗粒度，未来整体平台架构的规划在完成了集群数量的收敛之后，会按照系统维度在命名空间层面做逻辑隔离，通过命名空间的分账方式能够满足业务需求。

ACK 成本洞察

至此，云原生应用容器成本分摊的整体策略方向基本确定下来。

资源水位分析

关于应用容器资源配额的优化，主要集中在 CPU 和内存两个方面：

• CPU 资源优化：若只是调整 Pod 的 QoS 等级，将 CPU 的 Request 值做出调整，虽然短期可超卖更多的 CPU 资源用于资源部署，但对于线上应用来说一旦工作负载过高，易于出现资源争抢，致使服务被驱逐的情况。
• 内存资源优化：由于 Java 的内存资源在启动 JVM 时会被长时间占用，随着应用运行时间增加，一些代码质量较差的服务会逐渐出现内存未被及时回收的情况，从而导致 OOM 内存溢出。为避免 Pod 内存资源分配资源不足导致业务受损，工程师在启动 Pod 时设置的 Request/limit，通常会比 JVM 的堆栈内存要高出一定的比例。优化内存的同时，也需要考虑到业务潜在的 OOM 风险。

而容器服务 ACK 自带免费的成本套件 ack-koordinator 提供的资源画像能力，能够帮助我们长周期、持续性的识别到集群内未被合理使用的资源，并给出推荐值作为参考依据，实现容器粒度的资源规格推荐，降低容器配置的复杂度。

ACK 资源画像会为工作负载的每个容器资源规格生成画像值，通过对比画像值（Recommend）、原始资源请求量（Request），以及画像配置的资源消耗冗余（Buffer），资源画像控制台会为工作负载生成操作的提示，例如对资源请求提高或降低（即升配或降配）。若工作负载有多个容器，则会提示偏差幅度最大的容器。

当画像值大于原始资源请求量：表示容器长期处于资源超用状态，存在稳定性风险，应及时提高资源规格，控制台提升建议升配，避免未来运行过程中的稳定性风险。而当画像值小于原始资源请求量时，则表示容器可能有一定程度的资源浪费，可以降低资源规格。

其底层算法会持续不断地收集容器的资源使用数据，取 CPU 和内存的聚合统计值生成画像结果，并针对时间因素采用了周期衰减算法；在聚合统计时，会给较新的数据采样点分配更高的权重，同时参考了容器出现 OOM 等运行状态信息，进一步提高了应用画像给出推荐值的准确性。最后，是从资源的可持续管理的视角出发，我们希望能够将现有的发布平台与资源画像的功能打通，做到自动推荐配置调优，从而规避未来业务量变化后，响应调整相对滞后的弊端。因此在同阿里云的云原生应用平台团队提出该需求之后，很快得到了响应，目前已能够提供 API 的能力，与极氪现有发布流程联动。

应用发布资源配额优化

资源管理

多云环境下的 K8s 多集群管理，最后是关于如何解决极氪分布式云现状下的资源管理问题。由于我们当前存在着私有云和 IDC，不同的环境下的计费模型存在比较大的差异，财务模型也各不相同，这些都对多云运管平面的成本分析能力提供了更多的挑战。

为此，我们选择了 ACK One 统一管理极氪当前涉及到的数十个线上、线下 K8s 集群，以便在业务发展过程中，为工程师管理集群带来更好的一致性的云原生应用管理体验。ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，能够统一管理阿里云上、边缘、部署在客户数据中心以及其他云上的 Kubernetes 集群，并简化集群管理界面，从而灵活地根据自身业务和数据管控等需求。

结合 ACK One，阿里云容器服务 FinOps 套件提供了统一的云服务厂商的账单与询价接入与默认实现，支持主流的云服务厂商、IDC 自建机房的费用数据的接入，并通过一致的云原生容器场景成本分摊与估算模型，进行成本管理。此外，还提供了多集群、多环境的统一集群管理、统一资源调度、统一数据容灾和统一应用交付能力，也提供了统一的财资治理能力。

ACK One 多集群管理应用场景

最后，ACK FinOps 套件能够下发至线下及混合云环境，非常适合分析云下 IDC 节点及应用的成本。由于 ACK FinOps 无法获取线下以及其它云厂商的单位价格，为此，ACK One 为每个节点提供基于标签 Label 的方式，配置单独价格的相关配置方案。

kubectl label nodes  node.kubernetes.io/price-per-day="100"

在选择 ACK One 作为极氪云原生 K8s 多集群管理解决方案时，除了对于成本管控以外，配置检查和备份管理等功能也是我们当前所重点关心的。以配置检查为例，基于阿里云容器安全最佳实践，能够一键免费检查多云/混合云集群应用配置安全风险，保证多云/混合云集群容器应用的安全性、有效性和稳定性，并及时发现了早前的存量应用配置潜在的安全稳定性隐患。

应用 Pod 配置检查包括：

• 安全性：特权参数配置，高危内核 Capabilities，root 用户启动，未开启 TLS 的 Ingress，匿名用户权限绑定等。
• 有效性：CPU /内存资源配额限制缺失等。
• 稳定性：liveness 和 readiness 探针缺失，单副本启动等。

建设成果

通过阿里云容器服务提供的 ACK One 多集群管理、云原生资源画像等功能，极氪得以对线上及线下近 30 套 K8s 集群实现统一管理。取得了多方面的实质性的业务成果：

• 高效的资源利用

  通过利用资源画像功能分析数千个 Pod 的资源使用情况，企业识别并检查了空闲资源、找到了潜在的资源配置问题。在修复这些问题后，部署策略得到优化，从而为企业减少了近 25% 的资源用量。这一举措每年帮企业节省了数百万元的 IT 成本投入，并显著提高了资源利用效率。

• 系统稳定性和业务连续性的保障

  结合业务需求，企业制定了多种备份策略。针对这些策略，在 ACK One 平台上执行数据备份和恢复操作。这一做法提高了企业的业务连续性和数据安全性，进一步加强了系统的稳定性。

• 跨云和混合云资源的集中管理

  ACK One 多集群管理功能使得企业能够在阿里云容器管理平台上实现对多个 K8s 集群的集中管理和维护，包括线上和线下环境。这种统一的管理架构降低了企业操作复杂性，提高了工作效率。

• 敏捷的业务拓展和快速响应

  通过优化 K8s 集群和资源配置，企业能够在业务需求变化时更加敏捷地进行资源调整及扩展。这种弹性架构确保了企业能够在市场环境变化时迅速调整策略，提高竞争力。

• 应用发布策略的优化

  借助 ACK One 的分析功能，企业得以优化应用发布策略，从而使系统更加稳定和高效。企业不仅降低了故障率，还释放了更多的时间和精力来关注核心业务的创新和发展。

• 提升团队技能和合作效率

  在使用 ACK One 进行统一管理的过程中，企业内部团队对于 K8s 集群和相关产品技术的掌握程度逐渐提高。此外，由于各个职能团队之间在 ACK One 平台进行协作，也提高了团队的合作效率。

未来展望

今天，云计算已经成为全社会的数字经济基础设施，而云原生技术正在深刻地改变企业上云和用云的方式。极氪汽车作为新能源汽车的头部企业之一，在过去两年的高速发展过程中，围绕着云原生基础设施架构做了大量的技术、架构以及产品的关键选型，并整体落地了微服务、K8s、DevOps 等云原生代表技术及能力。与此同时，在分布式云技术设施架构的大背景之下，也面临了多重的挑战，也踩过不少的坑。

云原生时代的 FinOps 成本治理是一个很大的话题，FinOps 基金会将其定义为成本分析（Inform）、成本优化（Optimize）、持续运营（Operate）三个阶段。虽然前两个阶段能够更加显性的达到快速降本的目标，但如若不持之以恒的精细化管控资源，很快便会回到原样，只有将资源管理纳入到应用发布流程管控之中，才能真正管好云，用好云。面向未来，确保基础设施架构具备可持续发展的能力，赋能业务以更加稳定、高效、低成本的方式运行，充分发挥云的巨大价值，释放技术红利，仍有更长的路要走。