宝马重磅发布：CPU利用率↑9%，年省$100万，Karpenter成云原生扩缩新答案！- 大数跨境

首页

宝马重磅发布：CPU利用率↑9%，年省$100万，Karpenter成云原生扩缩新答案！

Karpenter

2025-11-28

导读：本篇博客描述了宝马从 Kubernetes 集群自动扩缩器（CAS）迁移至 Karpenter 的历程，以帮助宝马提升灵活性、运营效率并降低成本。我们将重点介绍推动这一决策的关键因素，详细讲解实施过程

Karpenter 开源地址：

https://github.com/kubernetes-sigs/karpenter

宝马集团旗下的 BMW Connected 公司负责为宝马全球超过 2300 万辆互联车队开发和运营高端数字化服务。

2019年，宝马做出战略决策，将整个互联汽车后端系统（包含1300多个微服务）从本地数据中心迁移至亚马逊云科技（AWS）云平台。

如今，宝马互联汽车后端作为一个高度复杂、高性能的服务网格运行，包含超过 375 个 Amazon Elastic Kubernetes Service（EKS）集群，每天跨 4 个AWS区域处理超过 120 亿次请求和 145 TB的数据流量。

本篇博客描述了宝马从 Kubernetes 集群自动扩缩器（CAS）迁移至 Karpenter 的历程，以帮助宝马提升灵活性、运营效率并降低成本。我们将重点介绍推动这一决策的关键因素，详细讲解实施过程，并分享在此过程中获得的宝贵经验。

大规模优化面临的挑战

宝马最初采用集群自动扩缩器（CAS）作为核心的弹性伸缩方案，以满足其Amazon EKS集群动态变化的资源需求。然而，随着业务规模持续扩大，一系列关键挑战逐渐显现：

• 多节点组管理复杂度激增：管理大量自动伸缩组（Auto Scaling Groups）的运维负担日益加重，每个节点组都需要独立配置和维护，导致操作复杂性呈指数级增长。
• 高可用性与快速升级的平衡难题：在严格遵守宝马严格安全规范的前提下，既要保障核心业务应用的高可用性，又要实现集群的快速平滑升级，这一者之间的平衡变得越来越具有挑战性。
• 安全合规性要求的持续压力：每个集群升级和扩展操作都必须通过严格的安全审核，这种安全至上的要求使得传统基于节点组的扩缩模式难以适应快速变化的业务需求。

随着数百个集群的运行，CAS 的局限性逐渐暴露，宝马需要一个更现代的解决方案来满足其不断发展的性能和效率需求。

推动宝马决定迁移至 Karpenter 的主要益处包括：

• 计算效率：动态节点生命周期管理、智能装箱调度和灵活的实例选择，通过优化的可用区（AZ）布局，有助于最大化利用率和降低延迟。
• 成本优化：通过消除闲置容量和支持包括 Spot 实例在内的多种实例类型，Karpenter有助于实现规模适中的资源调配，从而在不影响性能的情况下降低云支出。
• 可扩展的自动化：Karpenter 的声明式方法及其与 Kubernetes 的深度集成，简化了扩缩操作，并支持宝马未来实现全面基础设施自动化的愿景。
• 卓越运营：漂移检测功能可以识别新的 Amazon 机器镜像（AMI）发布，通过确保及时升级和修复漏洞，有助于维护宝马的系统安全。

引入 Karpenter

为了应对这些挑战，宝马选择采用 Karpenter——AWS 专为 Amazon EKS 构建的自动扩缩解决方案。这标志着宝马在处理资源分配和集群管理方式上的根本性变革。

尽管 CAS 和 Karpenter 的最终目标都是自动扩缩，但它们的基本方法存在显著差异。

Karpenter 通过直接调用 Amazon EC2 应用程序编程接口（API）来配置节点，从而提供独特的优势，实现了更强的响应能力以及更智能、更安全的自动扩缩能力。

Karpenter 与 CAS 采用根本不同的扩缩方法。如图1所示。

图1：集群自动扩缩器（CAS）与Karpenter的架构差异

迁移方法

宝马首先部署了一个概念验证（PoC），以量化收益并收集经验教训，确保后续生产环境实施更顺畅、风险更低。

概念验证（PoC）

在迁移的初始阶段，宝马遵循 Karpenter 开源官方指南，并调整步骤以适应宝马的基础设施标准和工具链。

然而，宝马并未直接使用 AWS 命令行界面，而是利用 Terraform 和 GitHub Actions 来实现受控、可重复的部署流水线。这符合 DevOps 最佳实践，实现了渐进式部署和轻松回滚的能力。

以下是实施概念验证所采取的方法和步骤概要：

1. 创建身份与访问管理（IAM）角色和策略：创建 Karpenter 所需的 IAM 角色和策略。
2. 标记网络资源：为虚拟私有云（VPC）子网和安全组添加必要标签，以支持动态配置，并包含标签和选择器，使 Karpenter 能够高效管理工作负载。
3. 更新 aws-auth ConfigMap：更新 aws-auth ConfigMap 以启用 Karpenter 节点访问。
4. 隔离 Karpenter：将Karpenter安置在专用的节点组中，以防止其在集群协调过程中干扰其自身运行的节点。
5. 部署 Karpenter：使用Terraform部署Karpenter，包括自定义节点亲和性配置。
6. 配置资源定义：验证自定义资源定义（CRD），为不同类型的工作负载创建 NodePools 和 EC2NodeClasses。
7. 设置工作负载亲和性：为关键工作负载分配亲和性，确保正确的放置位置。
8. 停用 CAS：在迁移完成后，停用CAS和托管节点组（MNG）。

尽管基础设施设置大体顺利，宝马仍需克服几个挑战：

• 临时存储：对于无状态节点池，默认的20GB存储因容器镜像过大而不够用，因此引入了额外的 Amazon EBS 卷映射。
• 镜像拉取延迟：通过将 kubelet 配置中的 registryPullQPS 从 5 提高到 50 来解决，以更高效地处理宝马容器注册中心的负载。
• Pod协调：通过将 NodePools 上的中断预算减少到10%，缓解了过度的 Pod 中断，从而限制了同时进行的节点替换数量。

概念验证的结果带来了显著改进，如图2和图3所示，整体CPU利用率提升了约9%，每小时成本降低了13%。

图2：集群自动扩缩器（CAS）下的资源利用率

图3：Karpenter 下的资源利用率

生产环境实施（PI）

在概念验证取得积极成果后，宝马决定将 Karpenter 推广至生产环境。

回滚策略

为防止Karpenter的推出出现意外，定义了以下回滚策略：

• 通过基础设施即代码（IaC）禁用 Karpenter。
• 扩缩集群自动扩缩器（CAS），恢复通过其进行节点组管理和扩缩。
• 从集群中移除 Karpenter 组件（Pod和CRD）；重置托管节点组（MNG）的最小/最大节点数。
• 如有需要，清理任何残留的 Karpenter 相关资源。

生产环境实施

宝马的生产环境推广遵循了精心设计的六步走策略，确保从集群自动扩缩器（CAS）到 Karpenter 的平稳过渡：

1. 专用节点组隔离
通过为Karpenter控制器创建带有特定污点和标签的专用托管节点组，确保其与业务应用负载完全隔离。这种设计有效防止了Karpenter在协调集群状态时可能对自身运行节点造成的干扰，提升了平台的稳定性。
2. Terraform 自动化集成
将 Karpenter 专属的 IAM 角色、节点亲和性规则等配置深度嵌入现有的 EKS Terraform 模块，实现基础设施的代码化管理和自动化部署。这一做法不仅保证了配置的一致性，还显著提升了部署效率。
3. 精细化工作负载分割
针对无状态服务、有状态服务和 GPU 工作负载等不同类型，分别创建定制化的 NodePools 和 EC2NodeClasses。这种细粒度的资源分配策略确保每种工作负载都能获得最匹配的实例类型，实现成本与性能的最优平衡。
4. 平稳的控制器切换
在验证 Karpenter 运行稳定后，将 CAS 逐步缩容至零，完成集群管理权的无缝移交。这一有序的切换过程有效避免了两套扩缩系统可能产生的规则冲突。
5. 受控渐进式发布
通过特性标志（use_karpenter）实现迁移过程的精准控制。在每个节点组排空前执行完整的健康检查，确保 Pod 就绪性和系统稳定性，最大限度降低业务影响。
6. 全链路可观测性
建立定制化监控看板，实时追踪 Karpenter 的核心指标、性能表现和节点配置行为。这套监控体系为运维团队提供了充分的可见性，确保能够快速识别并响应潜在问题。

图4显示了宝马迁移至 Karpenter 后的结果架构。平台 VPC 托管着一个 Amazon EKS 托管节点组，其中包含 Karpenter，用于配置 Amazon EC2 按需实例或 Spot 实例，并使用 Amazon EventBridge 和 Amazon 简单队列服务（SQS）处理终止事件。通过 VPC 对等连接，在托管 EKS 平台的 VPC 与产品 VPC 之间提供连通性，使内部团队能够部署诸如 Amazon 关系数据库服务（RDS）等资源，供 EKS 应用程序使用。

图4：包含 Karpenter 的宝马 EKS 平台架构

迁移至 Karpenter 在基础设施效率、性能和成本优化方面带来了显著且可衡量的改进。CPU 利用效率提高了约12%，从 84% 提升至93% —— 这主要得益于 Karpenter 的动态装箱调度和实时实例配置。

此外，所有环境中的 CPU 核心总数减少了 10% 到 16% 不等。不同的降低百分比反映了环境特定因素（包括压缩算法的预算约束、集群规模和工作负载特征）的差异。这些因素直接影响 Karpenter 在每个环境中分配和优化资源的方式。这为宝马带来了每年超过 100 万美元的 AWS 基础设施成本总节约。

图5：生产环境迁移前后 CPU 核心数量对比

除了提高效率和节约成本外，此次迁移还为宝马带来了多项关键的运营和战略利益，包括有助于：

通过更快的节点配置，改善工作负载启动延迟。

通过匹配实例类型与实时 Pod 资源需求，减少过度配置。

通过主动处理 Spot 实例中断，提高弹性。

通过更少的节点组配置和简化的扩缩逻辑，简化运营。

通过启用 ARM 支持和改进的 GPU 能力，增强平台灵活性。

为内部宝马团队创建自定义 Nodepool 产品，提高宝马 EKS 平台效率。

实现动态节点大小调整，以高效处理大型容器，包括 AI 工作负载所需的容器。

这些结果与其他企业实施 Karpenter 的观察结果一致，这些组织报告了更好的资源利用率、增强的自动化以及在不牺牲应用性能或可靠性的情况下的成本降低。Karpenter 的实时决策、拓扑感知调度和对多种实例类型的支持被证明是释放这些效益的关键。

AWS Karpenter迁移示例项目

为支持更广泛的采用，AWS 开源了一个示例项目，该项目反映了本篇博客中描述的 Karpenter 实现。此资源使用户能够在其自身的 Amazon EKS 环境中更快速地测试和理解从 CAS 到 Karpenter 的迁移过程，包括有助于：

配置基础设施：设置VPC和包含核心组件的Amazon EKS集群。

安装插件：部署核心EKS插件（CoreDNS、kube-proxy和CAS）用于初始基准测试。

部署示例工作负载：安装示例应用以模拟真实工作负载。

安装和配置Karpenter：部署带有EC2NodeClasses和NodePools的Karpenter，用于动态扩缩。

迁移工作负载：将工作负载从CAS管理无缝过渡到Karpenter管理。

通过CI/CD自动化：手动使用或集成到CI/CD流水线中，实现可重复的基础设施交付。

该项目是开发者理解和验证 Karpenter 的理想起点。您可以通过 Karpenter-cluster 获取项目代码，按照 README.md 的指引快速开始体验。

总结

宝马从 CAS 迁移到 Karpenter，标志着在现代化 Amazon EKS 工作负载扩缩方面取得了关键性进展。

这一转变有助于赋能宝马更快速地响应需求、提升 CPU 利用率，并通过智能装箱和动态配置降低运营开销。这项举措为宝马在成本效率和资源优化方面带来了可衡量的改进，同时为未来的创新和扩展提供了灵活的基础。

Karpenter 与 AWS API 的无缝集成、先进的调度逻辑和开源可扩展性，帮助宝马将其云基础设施与高性能互联汽车服务的要求对齐。

宝马的历程表明，对于管理大规模 Kubernetes 集群的组织而言，Karpenter 在自动扩缩能力上提供了一次变革性的升级，为提升运营效率和敏捷性铺平了道路。虽然当前的优化收益主要来自 Karpenter 的装箱能力，但在启用 Spot 实例采用后，预计还将实现额外的成本节约。

宝马的实践证明：
Karpenter 是大规模 Kubernetes 集群弹性优化的下一代答案。

“Karpenter使我们能够更智能地运营、更快速地扩展，并为下一代互联汽车服务做好准备。”
—— Céline Laurent-Winter博士，宝马集团互联汽车平台副总裁