宝马集团如何在 AWS Graviton 上加速车联网工作负载
内容提要
宝马集团将车辆连接平台Orbit从x86迁移至AWS Graviton，采用Karpenter动态节点池、多架构镜像和双构建流水线，并通过污点机制让应用自愿迁移。迁移后年省约60万美元，性价比提升40%，NGINX入口CPU降约57%，超65%生产负载运行于Graviton，每日13万次构建部署未中断。
延伸解读
迁移策略：平台先行与自愿选择
宝马没有强制全量切换，而是先在Karpenter、Prometheus等核心平台服务上验证Graviton兼容性，再通过污点机制让应用团队自愿选择迁移。这种“平台先行”的做法提前暴露了兼容性问题，并建立了回滚模式，降低了大规模迁移的风险。同时，双架构镜像和专用节点池确保应用随时可回退到x86，无需重建镜像或修改流水线，为团队提供了安全网。
构建流水线的双轨设计
为支持多架构，团队保留了两种构建方式：QEMU模拟构建适合简单流水线，无需额外runner；原生Graviton构建则避免模拟开销，更适合依赖复杂、构建耗时的应用。通过GitHub Actions可复用工作流，团队能按需选择。此外，使用Crane镜像公共基础镜像时只保留所需平台，避免存储浪费。这种灵活设计让迁移不打断每日13万次构建部署。
调度机制：污点与亲和性配合
Graviton节点池默认带有污点，只有显式配置了容忍和节点选择器的应用才能调度上去，防止未适配的工作负载意外运行。同时，Kubernetes节点亲和性规则会优先将Pod调度到Arm节点，但不是强制。这种“软偏好+硬隔离”的组合，既引导工作负载自然流向Graviton，又保留了x86作为后备，实现了可控的渐进式迁移。
实际收益与适用边界
迁移后年节省约60万美元，性价比提升40%，NGINX入口CPU降低约57%，目前超65%生产负载运行在Graviton上。这些数据表明Graviton在Web入口类工作负载上收益显著。但文章也提示，计算密集型构建应避免QEMU模拟，改用原生或交叉编译。对于其他团队，需评估自身工作负载特性，并优先在平台层验证兼容性，再逐步推广。
Q&A
宝马集团把车联网平台迁移到AWS Graviton后节省了多少成本？
迁移后每年节省约60万美元的基础设施成本，性价比提升约40%。
宝马集团如何确保应用团队在不影响服务的情况下迁移到Graviton？
通过污点机制让Graviton节点池需要显式容忍才能调度，应用团队可自愿选择迁移；同时采用双架构镜像和双构建流水线，确保应用可随时回退到x86，避免服务中断。
宝马集团在CI/CD流水线中如何支持多架构构建？
使用两种构建方式：基于QEMU的模拟构建和基于Graviton运行器的原生构建，两者都生成多架构镜像（通过manifest列表）。团队还镜像公共基础镜像时使用Crane保留多架构支持。
迁移后NGINX入口控制器的性能有哪些具体提升？
NGINX入口控制器迁移到Graviton后，CPU消耗降低约57%，性价比提升约40%，峰值负载下扩展效率提高，处理相同流量所需计算容量更少。
宝马集团迁移过程中总结了哪些关键经验？
关键经验包括：使用污点、选择器和容忍实现可选调度；使用多架构镜像简化发布和回滚；先在平台服务上验证再推广；优化模拟构建，计算密集型构建应使用原生或交叉编译。
目前宝马集团有多少生产负载运行在Graviton上？
超过65%的生产负载运行在Graviton上，每日13万次构建和部署未中断，支持超过2450万辆联网车辆。
