Grafana如何利用Karpenter消除50%的云资源浪费？｜落地案例

原文链接：
https://grafana.com/blog/2023/11/09/how-grafana-labs-switched-to-karpenter-to-reduce-costs-and-complexities-in-amazon-eks/

编译：cloudpilot.ai

Grafana 团队在他们的官方博客中介绍了他们从采用 Cluster Autoscaler 转向 Karpenter 的历程，本文将介绍他们如何进行选型，以及使用 Karpenter 的实践经历。

Grafana 是一款业界最为流行的可视化分析工具。2022 年，Grafana 首次登陆 AWS 并开始使用亚马逊弹性 Kubernetes 服务（Amazon EKS）时，选择了Cluster Autoscaler（以下简称“CA”）作为自动扩展工具。它开放且简单，而且在此之前，它已经过无数人的实战检验。然而，没过多久，Grafana 团队就意识到它并不适合自己。

这篇文章将深入探讨为什么 CA 不是长期解决方案，Grafana 考虑过哪些替代方案，以及为什么最终选择了Karpenter。此外，还将探讨一些相关的得失和经验教训，以及 Karpenter 如何帮助 Grafana 降低了成本和复杂性，进而帮助他们为使用 AWS 的用户提供了更好的服务。

免责声明：本文使用的是 Karpenter v1alpha5 API 规范。该项目最近在 v1beta1 规范中引入了一些突破性的变化，同时对核心组件进行了重命名。例如，Provisioners 已更名为 NodePools。为了保持一致性，本文决定保留 v1alpha5 版的命名，因为撰写本文时（2023.11）正在运行的是这个版本，并且掌握相关经验。

采用 CA 时面临的挑战

Grafana 开始使用 CA 时遇到了许多阻碍，它们限制 EKS 集群效率和灵活性。在了解如何通过采用 Karpenter 来解决其中的许多问题之前，让我们先来了解一下导致 Grafana 遇到这些问题的原因。

请求的容量与实际获取的容量(CPU requested vs. obtained)

CA 通过扩展和缩减 Kubernetes 节点组来工作。它监控那些无法调度现有节点的待定 Pod，并根据节点组的定义和其底层的自动扩展组（Auto Scaling Groups）来提供新节点，以便这些 Pod 可以调度到新的节点上。

在 AWS 上，你可以为节点组定义多种实例类型。然而，如果为节点组列出多个实例类型，CA 只会对其中一种实例类型进行计算，以确定需要扩展的节点数量。 然后，它会向 AWS 请求相应数量的实例，但你无法控制实际获取的实例类型。这可能会导致获得的容量与实际需求不匹配，从而需要进行更多的调整。

为了解决这个问题，CA 建议在定义节点组时，尽量使用相同规格的实例。这是一个相对简单的解决方案。

举个例子，与其在同一组中同时包含 m5.2xlarge 和 m5.4xlarge 实例，不如定义两个独立的节点组，分别包含每种实例规格。这样一来，CA 就可以专注于每个节点组的特定实例规格，并根据该规格进行资源计算。

这种方法的缺点在于，CA 在选择最佳实例时的选项有限。最终，你会在两个节点组之间进行随机选择，这可能会导致节点资源未被充分利用，进而引发频繁的节点更替。

假设你需要三台 m5.2xlarge 实例的容量。如果 CA 选择了 m5.2xlarge 节点组，它会计算需要三个实例并发出请求。但如果它选择了 m5.4xlarge 节点组，它会请求两个实例，其中至少有一个实例会被低效利用。根据你设定的阈值，这个实例可能会被标记为待删除，因为其利用率低于设定的利用率阈值。