c 网站开发项目,三亚网站建设报价,旅游管理网站业务模块,金科做的网站简介#xff1a; 在这篇博文中#xff0c;我们将简要解释需要考虑的领域#xff0c;KEDA 如何使应用自动伸缩变得简单#xff0c;以及为什么阿里云企业分布式应用服务#xff08;EDAS#xff09;在 KEDA 上完全标准化。 联合作者 | Yan Xun#xff0c;阿里云 EDAS 团队…简介 在这篇博文中我们将简要解释需要考虑的领域KEDA 如何使应用自动伸缩变得简单以及为什么阿里云企业分布式应用服务EDAS在 KEDA 上完全标准化。 联合作者 |  Yan Xun阿里云 EDAS 团队高级工程师 Andy Shi阿里云开发者倡导者 Tom KerkhoveCodit 容器化业务负责人兼 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 AutoscalerHPA​允许你添加/删除更多的 Pod 到你的工作负载中以 scale in/out添加或删除副本。Vertical Pod AutoscalerVPA​允许你添加/删除资源到你的 Pod 以 scale up/down添加或删除 CPU 或内存。 所有这些为你伸缩应用程序提供了一个很好的起点。 ​ HPA 的局限性 虽然 HPA 是一个很好的起点但它主要关注 pod 本身的指标允许你基于 CPU 和内存伸缩它。也就是说你可以完全配置它应该如何自动缩放这使它强大。 ​ 虽然这对于某些工作负载来说是理想的但你通常想要基于其他地方如 Prometheus、Kafka、云供应商或其他事件上的指标进行伸缩。 ​ 多亏了外部指标支持​用户可以安装指标适配器从外部服务中提供各种指标并通过使用指标服务器对它们进行自动伸缩。 ​ 但是有一点需要注意你只能在集群中运行一个指标服务器这意味着你必须选择自定义指标的来源。 ​ 你可以使用 Prometheus 和工具比如 Promitor从其他提供商那里获取你的指标并将其作为单一的真相来源来进行伸缩但这需要大量的管道plumbing和工作来进行扩展。 ​ 肯定有更简单的方法……是的使用 Kubernetes Event-Driven AutoscalingKEDA ​ KEDA 是什么 Kubernetes Event-Driven AutoscalingKEDA是一个用于 Kubernetes 的单用途事件驱动自动伸缩器可以很容易地将其添加到 Kubernetes 集群中以伸缩应用程序。 ​ 它的目标是使应用程序自动扩展非常简单并通过支持伸缩到零scale-to-zero来优化成本。 ​ KEDA 去掉了所有的伸缩基础设施并为你管理一切允许你在 30 多个系统上进行伸缩或使用自己的伸缩器进行扩展。 ​ 用户只需要创建 ScaledObject 或 ScaledJob 来定义你想要伸缩的对象和你想要使用的触发器KEDA 会处理剩下的一切 ​ 你可以伸缩任何东西即使它是你正在使用的另一个工具的 CRD只要它实现/scale 子资源。 ​ 那么KEDA 重新发明轮子了吗不相反它通过在底层使用 HPA 来扩展 KubernetesHPA 使用我们的外部指标这些指标由我们自己的指标适配器提供该适配器取代了所有其他适配器。 ​ 去年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 的自动伸缩功能将很快在 KEDA 中发布。 原文链接 本文为阿里云原创内容未经允许不得转载。