简介：在这篇博文中，咱们将简要解释须要思考的畛域，KEDA 如何使利用主动伸缩变得简略，以及为什么阿里云企业分布式应用服务（EDAS）在 KEDA 上齐全标准化。
联结作者 |
Yan Xun，阿里云 EDAS 团队高级工程师
Andy Shi，阿里云开发者倡导者
Tom Kerkhove，Codit 容器化业务负责人兼 Azure 架构师、KEDA 维护者、CNCF 大使
起源 | 阿里巴巴云原生公众号
当你在伸缩 Kubernetes 时，你会想到一些畛域，然而如果你是 Kubernetes 的老手，你可能会感觉有些难以应酬。
在这篇博文中，咱们将简要解释须要思考的畛域，KEDA 如何使利用主动伸缩变得简略，以及为什么阿里云企业分布式应用服务（EDAS）在 KEDA 上齐全标准化。
伸缩 Kubernetes
当治理 Kubernetes 集群和应用程序时，你须要认真监督各种事件，比方：
- 集群容量——咱们是否有足够的可用资源来运行咱们的工作负载？
- 应用程序工作负载——应用程序有足够的可用资源吗？它能跟上待实现的工作吗？(像队列深度）
为了实现自动化，你通常会设置警报以取得告诉，甚至应用主动伸缩。Kubernetes 是一个很好的平台，它能够帮忙你实现这个即时可用的性能。
通过应用 Cluster Autoscaler 组件能够轻松地伸缩集群，该组件将监督集群，以发现因为资源短缺而无奈调度的 pod，并开始相应地增加 / 删除节点。
因为 Cluster Autoscaler 只在 pod 调度适度时才会启动，所以你可能会有一段时间距离，在此期间你的工作负载没有启动和运行。
Virtual Kubelet（一个 CNCF 沙箱我的项目）是一个微小的帮忙，它容许你向 Kubernetes 集群增加一个“虚构节点”，pod 能够在其上调度。
通过这样做，平台供应商（如阿里巴巴、Azure、HashiCorp 和其余）容许你将挂起的 pod 溢出到集群之外，直到它提供所需的集群容量来缓解这个问题。
除了伸缩集群，Kubernetes 还容许你轻松地伸缩应用程序：
- Horizontal Pod Autoscaler（HPA）容许你增加 / 删除更多的 Pod 到你的工作负载中，以 scale in/out（增加或删除正本）。
- Vertical Pod Autoscaler（VPA）容许你增加 / 删除资源到你的 Pod 以 scale up/down（增加或删除 CPU 或内存）。
所有这些为你伸缩应用程序提供了一个很好的终点。
HPA 的局限性
尽管 HPA 是一个很好的终点，但它次要关注 pod 自身的指标，容许你基于 CPU 和内存伸缩它。也就是说，你能够齐全配置它应该如何主动缩放，这使它弱小。
尽管这对于某些工作负载来说是现实的，但你通常想要基于其余中央如 Prometheus、Kafka、云供应商或其余事件上的指标进行伸缩。
多亏了内部指标反对，用户能够装置指标适配器，从内部服务中提供各种指标，并通过应用指标服务器对它们进行主动伸缩。
然而，有一点须要留神，你只能在集群中运行一个指标服务器，这意味着你必须抉择自定义指标的起源。
你能够应用 Prometheus 和工具，比方 Promitor，从其余提供商那里获取你的指标，并将其作为繁多的假相起源来进行伸缩，但这须要大量的管道（plumbing）和工作来进行扩大。
必定有更简略的办法……是的，应用 Kubernetes Event-Driven Autoscaling（KEDA）！
KEDA 是什么？
Kubernetes Event-Driven Autoscaling（KEDA）是一个用于 Kubernetes 的单用处事件驱动主动伸缩器，能够很容易地将其增加到 Kubernetes 集群中以伸缩应用程序。
它的指标是使应用程序主动扩大非常简单，并通过反对伸缩到零（scale-to-zero）来优化老本。
KEDA 去掉了所有的伸缩基础设施，并为你治理所有，容许你在 30 多个零碎上进行伸缩或应用本人的伸缩器进行扩大。
用户只须要创立 ScaledObject 或 ScaledJob 来定义你想要伸缩的对象和你想要应用的触发器；KEDA 会解决剩下的所有！
你能够伸缩任何货色；即便它是你正在应用的另一个工具的 CRD，只有它实现 /scale 子资源。
那么，KEDA 从新创造轮子了吗？不！相同，它通过在底层应用 HPA 来扩大 Kubernetes，HPA 应用咱们的内部指标，这些指标由咱们本人的指标适配器提供，该适配器取代了所有其余适配器。
去年，KEDA 退出了 CNCF，作为 CNCF 沙箱我的项目，打算往年晚些时候提案降级到孵化阶段。
阿里巴巴基于 OAM/KubeVela 和 KEDA 的实际
企业分布式应用服务（EDAS）作为阿里云上的次要企业 PaaS 产品，多年来以微小的规模服务于私有云上的有数开发者。从架构的角度来看，EDAS 是与 KubeVela 我的项目一起构建的。其总体架构如下图所示。
在生产上，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 的主动伸缩性能将很快
原文链接
本文为阿里云原创内容，未经容许不得转载。