groundcover 推出 Kubernetes 资源自动调优测试版

周二，groundcover 推出了测试版 Autonomous Infrastructure，基于生产数据持续调整 Kubernetes（K8s）Deployment 的 CPU 和内存请求。

该测试版基于 groundcover 于 9 月收购的 K8s 资源优化平台 Wand 的技术构建，利用 groundcover 的 eBPF 传感器已采集的数据来指导资源分配决策，同时让工程师直接了解这些决策可能如何影响基础设施成本和工作负载性能。

groundcover 首席执行官兼联合创始人 Shahar Azulay 向 The New Stack 讲述了公司试图把握的平衡：“目标并不是简单地把资源请求压到尽可能低，而是在整个环境的效率与稳定性之间找到恰当的平衡点。”

这意味着，对于实际消耗远低于已分配资源的工作负载，可以下调其请求；但当工作负载需要额外资源才能可靠运行时，也可能需要上调请求。目标并非单纯缩小基础设施规模，而是让环境持续获得所需的资源，同时不为不需要的容量付费。

如何实现？Azulay 表示，团队需要“一个持续反馈循环，利用真实的生产遥测数据来识别工作负载何时过度配置或配置不足，并安全地加以调整。”

难道没人知道给 K8s 工作负载合理配置资源的好办法？

并非没有尝试。目前已有多种方式来处理 K8s 工作负载合理配置这一负担。

例如，定时调整会在选定的时间间隔应用变更，因此可能无法在两次计划更新之间做出响应。原地调整可以更改运行中 Pod 的资源，但某些变更需要重启容器。自动化工具也可以在工程师设定的策略范围内生成并应用建议。

当被问及为何 K8s 资源合理配置仍然让人头疼时，Azulay 告诉 The New Stack，挑战在于如何在成本效率与应用稳定性之间取得恰当平衡：

“资源请求通常是在部署时设定的，那时团队只能在工作负载尚未经历真实生产流量之前做出最佳估算，”他解释道。“挑战在于工作负载在不断变化，而资源配置往往一成不变。”

“挑战在于工作负载在不断变化，而资源配置往往一成不变。”

初始部署之后，团队可能就对闲置的工作负载不闻不问，也就是说，他们不会重新审视最初的资源请求并进行重新配置。虽然工作负载可能仍能正常运转，但这种方式意味着团队可能在不知不觉中让它们处于过度配置或配置不足的状态——并付出高昂代价。

对于运行数百或数千个工作负载的组织来说，保持这些配置准确成为一项持续的工程任务。团队必须分析利用率、识别优化机会、测试新设置，并在流量和应用行为变化时重新审视。即使具备专业知识，他们也未必有时间持续去做这件事。

Azulay 将过度配置描述为“更安全的选择，因为没人愿意冒性能问题或宕机的风险”。但这种额外的安心可能带来不必要的基础设施成本；在 2025 年发表于 Applied Sciences 的一项研究中，研究人员发现，与传统的最大资源分配方式相比，优化 K8s 资源分配使综合性能与成本评分提升了约 50%。

配置不足则带来不同的风险。请求帮助 Kubernetes 调度 Pod，而 CPU 请求会影响资源争用时的 CPU 时间分配；设置过低可能导致工作负载 CPU 时间不足。限制的作用方式不同：CPU 限制会导致节流，而超出内存限制可能触发内存不足（OOM）终止。当节点面临内存压力时，较低的内存请求还会增加被驱逐的风险。

工作负载请求与集群自身成本之间也存在关联。Karpenter 等节点自动扩缩器可以根据工作负载请求的资源来配置或移除节点，但它们无法判断这些请求是否准确反映了每个应用的实际需求。如果工作负载持续请求过多资源，自动扩缩器可能维持超出必要的容量。合理调整这些请求，能为节点自动扩缩器提供更准确的基础设施分配依据。

如果正确合理配置的答案就藏在你的生产数据里呢？

Groundcover 认为正是如此。因此，其新的 Autonomous Infrastructure 借助 groundcover eBPF 传感器，该传感器已在应用和基础设施层面采集遥测数据。测试版利用这些生产历史数据为 Kubernetes Deployment 推荐 CPU 和内存请求。全新的 Deployment 会保持学习状态，直到积累足够数据。

但这种方法并不是简单地观察到资源消耗出现峰值后再上调请求。等到反应式系统做出响应时，性能影响可能已经发生。相反，groundcover 的优化引擎会分析工作负载随时间变化的行为，包括使用模式和资源争用情况，以预判容量需求，并让工作负载为预期的需求变化做好准备。

这一区别对于流量会周期性激增的工作负载很重要。目标是在需求到来时有足够的资源可用，同时不必为峰值消耗永久分配资源。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）