简介： 在这篇博文中，咱们将简要解释须要思考的畛域，KEDA 如何使利用主动伸缩变得简略，以及为什么阿里云企业分布式应用服务（EDAS）在 KEDA 上齐全标准化。
联结作者 |
Yan Xun，阿里云 EDAS 团队高级工程师
Andy Shi，阿里云开发者倡导者
Tom Kerkhove，Codit 容器化业务负责人兼 Azure 架构师、KEDA 维护者、CNCF 大使
起源 | 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 的主动伸缩性能将很快在 KEDA 中公布。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。