Salesforce已完成对 1000 多个 Amazon Elastic Kubernetes Service（EKS）集群从 Kubernetes Cluster Autoscaler 到Karpenter的分阶段性迁移，Karpenter 是 AWS 的开源节点配置和自动伸缩解决方案。这次大规模转型旨在减少扩展延迟，简化操作，降低成本，并为公司广泛的 Kubernetes 团队内部开发人员提供更灵活自助的基础设施。
面对基于自动伸缩组的自动伸（Auto Scaling）和集群自动伸缩（Cluster Autoscaler）的限制，包括扩展速度慢、跨可用区利用率低以及成千上万的节点组的激增，Salesforce 的平台团队构建了自定义工具来安全、可靠地自动化和管理迁移。这种方法结合了精心编排的节点转换和自动化，尊重 Pod 中断预算（Pod Disruption Budgets，PDBs），支持回滚路径，并与公司的 CI/CD 配置管道集成。
迁移之旅始于 2025 年中期的低风险环境，并在 2026 年初投入生产之前经历了测试和验证阶段。Salesforce 的工程师开发了一种内部 Karpenter 转换工具和补丁检查，可以处理节点轮换、亚马逊机器镜像（Amazon Machine Image，AMI）验证和优雅的 Pod 驱逐，从而实现了跨不同节点池配置的可重复和一致的转换。
通过这次转型，团队解决了操作上的挑战，例如配置错误的 PDBs 阻止了节点替换、Kubernetes标签长度限制导致自动化失败，以及 Karpenter 高效打包需要调整以防止单副本应用程序中断的工作负载模式。这些见解导致了改进的实践，包括主动策略验证和工作负载感知中断策略。
Salesforce 报告了迁移后可衡量的操作和成本改善。通过采用 Karpenter 的动态配置模型，集群扩展延迟从分钟减少到几秒，通过更智能的打包提高了节点利用率，并显著减少了对静态自动伸缩组的依赖。
由于自动化流程取代了手动节点组管理，使开发人员可以自己声明节点池配置，操作开销减少了大约 80%。这种加速的采用减少了对中央平台团队的依赖。此外，初步结果显示，2026 财年成本节省了约 5%，预计随着 Karpenter 的打包和现货实例利用率继续优化资源，预计 2027 财年将进一步减少 5-10%。
Salesforce 的迁移突出了大规模 Kubernetes 操作中的更广泛趋势，其中传统的自动伸缩机制难以跟上动态工作负载和异构基础设施需求的步伐。Karpenter 的实时决策、对异构实例类型的支持（包括 GPU 和 ARM）以及与云 API 的更紧密集成，与集群自动伸缩器相比，实现了更快的响应和更高效的节点使用。
其他从传统的 Kubernetes 自动伸缩向 Karpenter 等更动态的解决方案进行大规模过渡的组织面临了许多与 Salesforce 记录的相同结构性挑战。例如，Coinbase公开描述了其向 Karpenter 的转变，以处理具有变化需求模式的复杂混合工作负载集群，提到了扩展延迟和资源效率的改善，同时减少了静态节点组引起的操作摩擦。同样，宝马集团分享了在其汽车平台上采用 Karpenter 如何更好地利用现货实例和工作负载感知调度，实现了更快的开发人员反馈循环和降低基础设施成本波动。这些案例呼应了 Salesforce 的观察，即集群自动伸缩器依赖于预定义的自动伸缩组和较慢的决策路径，可能会阻碍具有多样化和突发工作负载的环境的响应能力。
Salesforce 迁移的不同之处在于其规模和自动化工具：转换超过 1000 个不同的 EKS 集群需要定制工具来处理策略验证、Pod 中断预算限制、Kubernetes 标签限制和舰队级别的增量推出自动化。其他公司报告了在个别集群或较小舰队中从 Karpenter 中的获益，但 Salesforce 的方法强调了在企业规模上可重复、自动化的转换，集成了回滚和合规性保障。在实践中，这意味着不仅要替换自动伸缩逻辑，还要协调工作负载模式、治理控制和全球平台上开发人员的自助服务期望。虽然这些迁移的最终目标是更快的扩展、更好的利用率和减少手动开销，但 Salesforce 的蓝图突出了将这些好处带给大型、生产关键环境所需的操作规程和自定义自动化。
随着企业越来越多地采用 Kubernetes 来支持关键任务服务，Salesforce 的经验为其他考虑类似转型的组织提供了一个蓝图，证明了自动化、联合自动扩展可以带来性能、成本效率和开发者速度的显著提升——前提是必须有周密的规划和工具支持来支撑这一变化。
原文链接：
https://www.infoq.com/news/2026/01/salesforce-eks-karpenter/
