Salesforce已完成对 1000 多个 AmazonElastic 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/

数字公告板提供商 Pinterest 发布了一篇文章，解释了其新平台Moka在大规模数据处理方面的未来蓝图。该公司正在将核心工作负载从老化的 Hadoop 基础设施迁移到基于 Kubernetes 的系统上，该系统运行在亚马逊 EKS 上，以 Apache Spark 作为主要引擎，并即将支持其他框架。

在一个包含两篇文章的博客系列中，Soam Acharya、Rainie Li、William Tom 和 Ang Zhang 描述了 Pinterest 大数据平台团队如何考虑下一代大规模数据处理平台的替代方案，因为现有的基于 Hadoop 的系统（内部称为 Monarch）的局限性变得越来越明显。他们将 Moka 作为搜索的结果，以及基于 EKS 的云原生数据处理平台，该平台现在运行的生产负载达到了 Pinterest 的规模。该系列的第一部分关注整体设计和应用层。相比之下，第二部分转向作者所说的“Moka 的基础设施重点方面，包括经验和未来方向”。

文章从实际角度描述了向 Kubernetes 的转变。它展示了一个全行业的转变，即大型技术公司现在将 Kubernetes 视为数据的控制平面，而不仅仅是无状态的服务平台。在大数据社区日益增长的受欢迎程度和越来越多的采用的鼓励下，团队探索了基于 Kubernetes 的系统，作为 Hadoop 2.x 最有可能的替代品。任何候选平台都必须满足可扩展性、安全性、成本以及托管多个处理引擎的精确标准。Moka 是如何在不放弃现有 Spark 投资的情况下现代化 Hadoop 时代的数据平台的一个例子。

第二篇文章的核心主题是如何在 Kubernetes 上以非常大的规模运行 Spark。作者解释了他们如何围绕 Moka 添加日志、指标和作业历史服务，以便工程师可以在不了解底层集群拓扑的情况下调试和调整作业。他们使用 Fluent Bit 对日志集合进行标准化，并使用 OpenTelemetry 和 Prometheus 兼容的端点发布统一指标。这为基础设施和应用程序团队提供了系统健康的一致视图。

Pinterest 还投资于通过基础设施即代码的方式使平台可重复使用。在文章中，团队概述了他们如何使用 Terraform 和 Helm 创建 EKS 集群、配置网络和安全以及部署支持组件，如 Spark 历史服务器。

Pinterest 的工程师还讨论了处理不同的硬件架构。他们描述了他们如何构建多架构镜像，以便他们的数据工作负载在 Intel 和基于 ARM 的实例上运行良好，包括 AWS Graviton，并将此与集群规模的成本和效率目标联系起来。InfoQ 编辑 Eran Stiller 在 LinkedIn上对该项目中的总结指出，Moka“提供了容器级别的隔离、ARM 支持、YuniKorn 调度，并通过整合工作负载和跨实例类型的自动扩展实现了显著的成本节省”。这些细节将工作置于云用户寻求在不牺牲性能的情况下削减基础设施成本的更大趋势之中。

关于处理引擎的更广泛的行业对话为 Pinterest 的故事增添了细微差别。在另一篇LinkedIn帖子中，Acharya 写道：“虽然 Spark 是我们的主要主力，但 Moka 的成功意味着 Pinterest 的其他用例也在效仿：Flink Batch 已经投入生产，Apache Ray 紧随其后，Flink Streaming 也将在今年晚些时候推出”。通过对 Spark 和 Flink 技术的深入探讨，我们可以了解到这一点的重要性。强调 Spark 仍然非常适合大型批处理和交互式分析工作负载，而 Flink 是“为实时、有状态的流处理而构建的”，具有严格的逐事件处理。团队将 Moka 呈现为一个灵活的基础，可以根据特定工作负载的需求添加不同的引擎，而不是一个只支持 spark 的平台。

外部观察者从 Pinterest 案例中吸取了教训。ML工程师通讯将 Moka 文章描述为“在 Kubernetes 上部署 EKS 集群、Fluent Bit 日志、OTEL 指标管道、镜像管理和 Spark 的自定义 Moka UI”的例子，将其与其他现代数据基础设施案例研究并列。这些反应表明，Moka 被视为一类云原生数据系统的参考架构。

然而，团队确实将他们的迁移工作呈现为一个正在进行的旅程，而不是一个已经完成的项目。在博客和进一步的LinkedIn帖子中，Pinterest 作者讨论了“经验和未来的方向”，并描述了早期概念验证如何导致随着对新堆栈的信心增长而逐步远离 Hadoop 的迁移。Acharya 指出，“最好的问题出现在规模上”，构建平台涉及“解决难题”，因为团队转移了实际工作负载。对于其他组织来说，这种经验可能是最重要的教训。复制围绕 Kubernetes、EKS 和 Spark 的技术选择相对简单，但从遗留系统中解耦并投资于可观测性、自动化和多引擎支持的过程可能是未来真正的工作。

原文链接：

https://www.infoq.com/news/2026/01/pinterest-kubernetes-bigdata/

亚马逊云科技推出了Amazon EKS Capabilities，这是一套完全托管的、Kubernetes 原生特性，旨在简化工作负载编排、AWS 云资源管理以及 Kubernetes 资源组合和自动化。这些能力现在已在大多数 AWS 商业区域普遍可用，它将流行的开源工具捆绑到一个托管的平台层中，减轻了工程团队的运维负担，并在Amazon Elastic Kubernetes Service（EKS）上实现了更快的应用程序部署和扩展。

EKS Capabilities 集成了许多 Kubernetes 用户已经依赖的三个核心组件：Argo CD、AWS Controllers for Kubernetes（ACK）和Kube Resource Orchestrator（KRO），并在 AWS 拥有的基础设施中运行它们，这些基础设施与客户集群抽象隔离。Argo CD 提供声明式的持续部署和GitOps工作流，允许直接从版本控制同步资源和应用程序。ACK 通过自定义资源扩展 Kubernetes，用于直接在 Kubernetes API 内管理 AWS 服务，如S3、DynamoDB和RDS。KRO 提供了一个简化的机制，用于创建和管理组合的自定义资源，帮助平台团队定义可重用的、更高层次的抽象，而无需手动处理复杂的控制器逻辑。

通过将这些能力作为托管的 AWS 资源而不是集群内的插件提供，EKS Capabilities消除了用户自己安装、补丁、扩展或更新基础 Kubernetes 工具的需求。AWS 处理扩展、维护、安全补丁和兼容性升级，使平台工程师和开发人员能够更多地专注于交付业务逻辑，而不是管理平台组件。实际上，团队继续使用熟悉的接口如kubectl、GitOps 工作流和声明式清单与 Kubernetes 一起工作；不同的是，持续部署和资源编排等核心服务由 AWS 作为 EKS 平台的一部分提供和维护。

这种转变与云原生运维的更广泛趋势相一致，在云原生运维中，托管服务越来越多地吸收了无差别的繁重工作，使组织能够更容易地扩展 Kubernetes 的采用。平台团队可以将常规的基础设施集成卸载到 AWS 托管的能力中，同时保留原生的 Kubernetes 工作流，应用程序开发人员则从统一、一致的能力中受益，这些能力跨越了集群，而无需投资于定制的平台工具。通过 EKS 控制台、AWS CLI、eksctl或其他自动化工具启用 EKS 能力。当将 Argo CD、ACK 或 KRO 等能力添加到集群中时，它将作为 AWS 资源出现，可以像其他 AWS 服务一样进行标记、管理和监控。权限通过 AWSIdentity and Access Management（IAM）配置，对于 Argo CD 单点登录等功能，支持与 AWS IAM 身份中心的集成。AWS 还自动分析破坏性变更，并对活动功能应用更新或补丁，减少管理开销。

虽然每个功能都是独立且可选的，允许团队只启用他们需要的功能，但它们共同为 Kubernetes 环境提供了一个连贯、可扩展的平台层，融合了应用程序部署、AWS 资源控制和自定义资源组合。这种方法旨在缩短交付时间，最小化操作摩擦，并帮助组织在开发、测试和生产环境中大规模采用 Kubernetes。

这次更新引起了云和 DevOps 社区的共鸣。在Reddit上，实践者强调了托管 Argo CD 支持和集成的 AWS 资源管理的便利性，这是尝试新功能的令人信服的理由，特别是对于那些寻求统一 GitOps 工作流和资源配置而不进行手动插件管理的团队。同时，一些观察者指出，尽管托管能力减少了设置工作，但它们仍然需要 Kubernetes 专业知识和仔细的成本考虑，因为采用规模扩大，成本也被质疑是一个潜在的问题，因为许多团队可能已经有自己管理这些的方法，并且看不到为这项新的 AWS 功能支付额外费用的好处。

随着企业继续在混合云和多云环境中采用 Kubernetes，Amazon EKS Capabilities 通过将运维最佳实践嵌入到服务本身，代表了降低平台复杂性和加速云原生应用程序交付的一步。

https://www.infoq.com/news/2025/12/aws-eks-workload-orchestration/