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

作者：极氪汽车吴超

前言

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

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

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

管理挑战

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

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

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

1. 资源管理复杂度高： 相比于应用直接部署在服务器上，云原生架构的优势在于对底层计算资源的管理更为精细化，以集群为单位的资源调度方式，对于提升集群利用率有显著的作用。但与之带来的问题便是管理复杂度的问题。通过一个集群统一管理应用，虽然降低了总体资源成本，但使得分账、拆账变得更为复杂，早期为了能够解决各业务的分账以及权限管控等场景，职能团队分别创建了不同的 K8s 集群，给到对应的项目组，用于部署应用系统，但集群的资源利用率并没有得到有效提升。同时，随着业务的不断扩展，这些集群涉及到不同部门、不同环境，版本已存在越来越大的差异。在应用部署时，由于管理人员的水平参差不齐，导致在日常运维及问题诊断时，十分耗时。
2. 资源分配不够智能： 业务类别千差万别，有 B 端运营管理，也有 C 端的高并发应用，虽然 K8s 提供了资源分配的方式，但是对于运维发布人员来说，难以预判未来应用的真实流量情况，以至于难以合理分配 CPU /内存资源大小，仅按照经验参数统一给出默认规格配置。
3. 如何实现长期主义： 在制定策略时，我们担心此类运动式的架构优化活动，即便投入了大量的人力成本，也只能在短期内使得资源管理"看上去很美"，而随着业务架构的不断调整，又或者因优化资源产生稳定性影响之后，对未来持续运营管理资源的信心将会消减，从而使得原本的成本投入的边际收益趋向于零。

业务目标

为应对云资源治理方面的不足，以及不同云平台的能力差异，我们曾考虑过是否需要建立一套 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）三个阶段。虽然前两个阶段能够更加显性的达到快速降本的目标，但如若不持之以恒的精细化管控资源，很快便会回到原样，只有将资源管理纳入到应用发布流程管控之中，才能真正管好云，用好云。面向未来，确保基础设施架构具备可持续发展的能力，赋能业务以更加稳定、高效、低成本的方式运行，充分发挥云的巨大价值，释放技术红利，仍有更长的路要走。