KubeVela + KEDA：为应用带来“与生俱来”的弹性伸缩能力

KubeVela + KEDA：为应用带来“与生俱来”的弹性伸缩能力

伸缩 Kubernetes

当管理 Kubernetes 集群和应用程序时，你需要仔细监视各种事情，比如：​

集群容量——我们是否有足够的可用资源来运行我们的工作负载？ 应用程序工作负载——应用程序有足够的可用资源吗？它能跟上待完成的工作吗？(像队列深度）

通过这样做，平台供应商​（如阿里巴巴、Azure、HashiCorp 和其他）允许你将挂起的 pod 溢出到集群之外，直到它提供所需的集群容量来缓解这个问题。​除了伸缩集群，Kubernetes 还允许你轻松地伸缩应用程序：​

Horizontal Pod Autoscaler（HPA​）允许你添加/删除更多的 Pod 到你的工作负载中，以 scale in/out（添加或删除副本）。 Vertical Pod Autoscaler（VPA​）允许你添加/删除资源到你的 Pod 以 scale up/down（添加或删除 CPU 或内存）。

所有这些为你伸缩应用程序提供了一个很好的起点。​

HPA 的局限性

你可以使用 Prometheus 和工具，比如 Promitor，从其他提供商那里获取你的指标，并将其作为单一的真相来源来进行伸缩，但这需要大量的管道（plumbing）和工作来进行扩展。​肯定有更简单的方法……是的，使用 Kubernetes Event-Driven Autoscaling（KEDA）！​

KEDA 是什么？

去年，KEDA 加入了 CNCF，作为 CNCF 沙箱项目，计划今年晚些时候提案升级到孵化阶段。​

阿里巴巴基于 OAM/KubeVela 和 KEDA 的实践

在生产上，EDAS 在阿里云上集成了 ARMS 监控服务，提供监控和应用的细粒度指标。EDAS 团队在 KEDA 项目中添加了一个 ARMS Scaler 来执行自动缩放。他们还添加了一些特性，并修复了 KEDA v1 版本中的一些 bug。包括：​

当有多个触发器时，这些值将被求和，而不是作为单独的值留下。 当创建 KEDA HPA 时，名称的长度将被限制为 63 个字符，以避免触发 DNS 投诉。 不能禁用触发器，这可能会在生产中引起麻烦。

EDAS 团队正在积极地将这些修复程序发送给上游 KEDA，尽管其中一些已经添加到 V2 版本中。​

为什么阿里云将 KEDA 标准化为其应用的自动伸缩器

当涉及到自动扩展特性时，EDAS 最初使用上游 Kubernetes HPA 的 CPU 和内存作为两个指标。然而，随着用户群的增长和需求的多样化，EDAS 团队很快发现了上游 HPA 的局限性：​

对定制指标的支持有限，特别是对应用程序级细粒度指标的支持。上游 HPA 主要关注容器级指标，比如 CPU 和内存，这些指标对于应用程序来说太粗糙了。反映应用程序负载的指标（如 RT 和 QPS）不受现成支持。是的，HPA 可以扩展。然而，当涉及到应用程序级指标时，这种能力是有限的。EDAS 团队在尝试引入细粒度的应用程序级指标时，经常被迫分叉代码。 不支持伸缩到零。当他们的微服务没有被使用时，许多用户都有将规模伸缩到零的需求。这一需求不仅限于 FaaS/无服务器工作负载。它为所有用户节省成本和资源。目前，上游 HPA 不支持此功能。 不支持预定的伸缩。EDAS 用户的另一个强烈需求是预定的伸缩能力。同样，上游 HPA 不提供此功能，EDAS 团队需要寻找非供应商锁定的替代方案。

基于这些需求，EDAS 团队开始规划 EDAS 自动伸缩特性的新版本。与此同时，EDAS 在 2020 年初引入了 OAM，对其底层核心组件进行了彻底改革。OAM 为 EDAS 提供了标准化的、可插入的应用程序定义，以取代其内部的 Kubernetes 应用程序 CRD。该模型的可扩展性使 EDAS 能够轻松地与 Kubernetes 社区的任何新功能集成。在这种情况下，EDAS 团队试图将对 EDAS 新的自动伸缩特性的需求与 OAM 自动伸缩特性的标准实现相结合。​基于用例，EDAS 团队总结了三个标准：

自动伸缩特性应该将自己呈现为一个简单的原子功能，而不需要附加任何复杂的解决方案。 指标应该是可插入的，因此 EDAS 团队可以对其进行定制，并在其之上构建以支持各种需求。 它需要开箱即用地支持伸缩到零。

经过详细的评估，EDAS 团队选择了 KEDA 项目，该项目是由微软和红帽开源的，已捐赠给 CNCF。KEDA 默认提供了几个有用的 Scaler，并开箱即用地支持伸缩到零。它为应用程序提供了细粒度的自动伸缩。它具有 Scalar 和 Metric 适配器的概念，支持强大的插件架构，同时提供统一的 API 层。最重要的是，KEDA 的设计只关注自动伸缩，这样就可以轻松地将其集成为 OAM 特性。总的来说，KEDA 非常适合 EDAS。​

展望未来

下一步，阿里巴巴正在积极推动由 AIOps 驱动的 KEDA 特性，目标是为其自动伸缩行为带来智能决策。这将从本质上实现基于专家系统和历史数据分析的自动伸缩决策，利用阿里巴巴的 KEDA 组件中新实现的应用 QoS 触发器和数据库度量触发器等。因此，我们期待一个更强大、更智能、更稳定的基于 KEDA 的自动伸缩功能将很快在 KEDA 中发布。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。