在今天的云原生生态系统中,波动的工作负载和动态的流量模式是常态。适应这种不可预测的行为需要能够实时调整的系统。自动伸缩是必需的,可以确保资源的最佳分配,遏制过度成本,并促进资源的高效使用。
自动伸缩不仅关乎成本。它在维护应用性能和吞吐量方面发挥着关键作用。通过避免欠配置(导致用户体验不佳)和过度配置(导致不必要的成本),自动伸缩可以实现合理的平衡。
HPA,作为 Kubernetes 的本地解决方案,根据观察到的指标(主要是 CPU 和内存)来扩展 Pod 的数量。虽然对于统一的工作负载来说非常直接和有益,但当考虑到其无法扩展到零并且完全依赖 CPU 和内存指标时,它的局限性就变得明显了。
VPA更多地涉及资源的调整而不是扩展它们。它评估需求并动态调整资源,确保工作负载的合适适配。但这里有一个问题:增强型的 Pod 并不一定更好。有时,拥有更多的工作进程来处理数据比拥有一个大而强大的工作进程更高效。
尽管内置的 Kubernetes 自动伸缩器如 HPA 和 VPA 提供了基本的扩展能力,但它们在范围上天然有限。它们主要关注 CPU 和内存指标可能对于现代应用来说是一个重大限制,因为这些应用可能需要对各种指标做出反应,其中一些甚至可能不是来自应用程序本身的指标。
现代应用面临的引人注目的挑战之一是根据外部系统的事件来进行扩展。例如:
展以处理或分析数据的涌入。
此外,还存在将扩展到零的必要来有效管理资源的情况,或者存在不同指标的组合决定扩展逻辑的情况,例如 CPU 利用率与数据库读/写速率。这些微妙的需求突显了内置 Kubernetes 自动伸缩器的不足之处。
Kubernetes 引入了一个自定义指标的接口,旨在为水平 Pod 自动伸缩器(HPA)提供更多超越 CPU 和内存指标的适应性。然而,实际实现中出现了挑战。
尽管强大,但自定义指标 API 并不直观易用。它要求对 Kubernetes 内部有详细的了解,使设置和调整变得繁琐。
Prometheus 适配器试图通过利用自定义指标 API 来弥合这一差距,引入了 Prometheus 的广泛指标。但它也有一些缺点:复杂、不直观的配置以及仅与 Prometheus 指标相关联。实施和维护配置需要不断的警觉性。基础架构或应用程序的更改可能会触发重新配置的需求。
Kubernetes 事件驱动自动伸缩(KEDA)不仅与 Kubernetes 的自定义指标 API 集成,还使其变得更加可访问。这是用户友好界面如何改变体验的证明,使自动伸缩真正具有可定制性和多功能性。
KEDA 提供了多个技术优势:
虽然传统的指标如 CPU 和内存提供了一些见解,但现实世界的应用程序通常需要更精细和多样化的指标来进行有效的自动伸缩。以下是一些要考虑的情景:
这样多样化的现实场景强调了需要一种多功能的自动伸缩解决方案,能够理解并响应多种度量标准。KEDA 凭借其灵活性和适应性有效地应对了这些挑战。
尽管 Kubernetes 拥有原生的自动伸缩工具如 HPA 和 VPA,以及像 Prometheus 适配器这样的扩展,但它们通常伴随着复杂性。而 KEDA 提供了一个简单的平台,适用于各种各样的自动伸缩需求。它处理事件驱动的扩展,包括缩减到零,这是一个重大优势。此外,设置 KEDA 更加简单,减少了用户在处理 Kubernetes 自定义指标时通常会遇到的典型障碍。
KEDA 的活跃社区证明了它的实用性。对该项目的定期贡献、像 Kedify 或 Microsoft 这样的供应商以及不断增加的企业采用显示出它在 Kubernetes 生态系统中日益重要。
最后更新于 2024/09/06