简介：在云原生技术栈逐渐普及之后，如何能够以效率更高、用户更容易接纳的方式落地 Kubernetes 技术体系，让云原生的发挥出真正的价值，正在迅速成为大家津津乐道的一个话题和全新的挑战。而伴随着大家对云原技术的关注点从“怎么用”逐渐上升到“怎么用的更好’上来，CNCF 应用交付领域小组（CNCF SIG App Delivery）联合阿里巴巴云原生应用平台团队推出了《从 0 到 1：打造现代云原生应用管理平台》系列文章，旨在帮助读者更好的落地和实践云原生核心技术，打造出属于自己的、“以应用为中心”的 Kubernetes 平台。

来源 | 阿里巴巴云原生公众号

作者 |炎寻  阿里云 EDAS 核心开发工程师Andy Shi  阿里云技术布道师

导读：在云原生技术栈逐渐普及之后，如何能够以效率更高、用户更容易接纳的方式落地 Kubernetes 技术体系，让云原生的发挥出真正的价值，正在迅速成为大家津津乐道的一个话题和全新的挑战。而伴随着大家对云原技术的关注点从“怎么用”逐渐上升到“怎么用的更好’上来，CNCF 应用交付领域小组（CNCF SIG App Delivery）联合阿里巴巴云原生应用平台团队推出了《从 0 到 1：打造现代云原生应用管理平台》系列文章，旨在帮助读者更好的落地和实践云原生核心技术，打造出属于自己的、“以应用为中心”的 Kubernetes 平台。

背景与场景

阿里云企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）是一个应用全生命周期管理和监控的一站式 PaaS 平台，同时也是 Open Application Model (OAM) 模型在公有云上的第一个互联网级商用平台层实现。今天，EDAS 的应用管理层内核已经完全基于 KubeVela 开源项目构建于原生的 Kubernetes 集群之上，以高效、稳定、智能、可扩展的方式服务了成千上万名云上应用开发者。在本文中，我们会以 EDAS 的底层技术实现作为具体案例，介绍阿里云在生产环境中设计与落地智能化的应用扩缩容策略中踩到的“坑”、解决方案以及构建以云原生应用平台过程中的最佳实践。

阿里云进行应用扩缩容遇到的挑战与选型思考

作为阿里云面向应用管理与交付领域的核心产品，EDAS 较早就已经完成了从自研虚拟机架构到 Kubernetes 容器集群的架构整体迁移。当然，同大多数基于 Kubernetes 的 PaaS 类似，在这个阶段，EDAS 在应用自动弹性伸缩功能上，是完全基于 Kubernetes 原生 HPA（Horizontal Pod Autoscaler）提供的 CPU 和 Memory 两个基础指标的。但是，随着用户量的增加和需求的日渐多样化，原生基于 HPA 的应用扩缩容策略逐渐暴露出了很多不足之处：

• 第一，对基于细粒度的应用级负载指标（比如：RT 或者 QPS）进行自动扩缩支持不佳。

作为一个“ The Platform for Platform”项目，Kubernetes 提供的内置能力主要是围绕着容器级别的管理和编排来展开的，但是对于以应用和用户为核心关注点的产品来说，像 CPU 和 Memory 这样粒度的扩缩容指标就显得太粗粒度了。但是一个“尴尬”的局面是，尽管 HPA 提供了一定程度的自定义指标功能，但它的可扩展性整体上还是不够灵活，自定义指标的可插拔性也不是很好，尤其是当我们希望把指标细化到应用甚至源码层面的时候，经常会碰到需要修改 HPA 代码的情况（而 HPA 代码又是 Kubernetes 代码的一部分）。这就迫切的需要我们在思考如何通过一个扩展性更强的、外部框架来进行细粒度的应用扩缩容策略。

• 第二，无法支持对应用 Scale To Zero的需求。

我们知道，在 Serverless/FaaS 场景中 Scale To Zero 是一个比较典型的自动伸缩场景，可以有效的帮助用户节省闲置资源、降低平台的使用成本。实际上， 现代微服务应用中，很多用户托管在云上的微服务，也都具备 Serverless 应用的一些特征，比如无状态、主要根据流量进行响应等等，对于它们来说，Scale To Zero 也是一个非常重要的诉求。但是，Kubernetes 内置的 HPA 并不关注这个场景，是不会提供出这个能力的。而 EDAS 作为一个全功能通用 PaaS 产品，对 Scale To Zero 的诉求是独立的、无平台锁定的原子性能力，不可能通过引入 OpenFaaS 或者 Knative 这样的 Serverless 专属方案来解决所有用户场景下的问题。

• 第三，无法支持定时扩缩容的需求。

除了 Scale To Zero 之外，定时扩缩容也是 EDAS 的企业级用户非常迫切需要的一个能力。同样的，对于这个应用运维能力的诉求，也必须是独立的原子性能力，而不能为了一个需求引入一整套其它的平台级方案进来。

基于上述问题，阿里云团队开始规划 EDAS 产品自动弹性伸缩能力的新版本。而与此同时，EDAS 产品底层架构自 2020 年初也开始了基于 Open Application Model （OAM）的一系列演进升级，旨在通过引入一个标准化、可插拔的应用定义模型替代 EDAS 原有的 Application  CRD，从而既为使用者提供一个以“应用为中心”的上层抽象而不是强制用户学习 Kubernetes 中的底层概念，又利用模型的可扩展性确保 EDAS 能够将云原生生态中的各种能力一键“插入”到产品当中。所以，这个新版自动弹性伸缩组件的设计与实现，也自然而然的同 EDAS 的 OAM 化架构结合在了一起。

在这个新的架构中，一个应用的“自动弹性伸缩”策略，是作为这个应用的“特征”（Trait）存在的。当然，这里提到的“应用”这个概念，是 EDAS 在 Kubernetes 之上借助 OAM 为用户暴露出来的一个上层抽象，并且完全通过用户侧的原语进行描述。所以，这里的问题就出现了，在 Kubernetes 具体的实现层，这种用户定义的、面向应用的弹性伸缩策略，又该如何实现或者选型呢？

结合前面提到的三个具体的挑战，以及新版 EDAS 基于 OAM 的 Kubernetes 原生化设计，阿里云团队决定直接从开源社区中来引入一个水平扩缩容组件来解决上述问题，并且针对 EDAS 的场景提炼出了三点主要的选型诉求：

1. 这个水平扩缩容组件提供的应该是简单稳定的原子化能力，而不能跟某个具体的场景化方案（比如 Serverless）绑定。这同时也是 OAM 模型对“应用特征”的基本规范和要求；
2. 这个水平扩缩容组件的扩容指标应该是插件式的，这样阿里云团队才能够方便得扩展出基于定时、消息队列堆积消息数、应用监控指标甚至 AI 预测结果的“以应用为中心”的弹性策略；
3. 原生支持 Scale To Zero，并且满足第一条的要求。

而经过在社区中的评估和选型，最后阿里云团队选择了微软开源 KEDA 项目，它目前已经移交给 CNCF 托管。KEDA 项目可以原生支持 Scale To Zero，更重要的是，它针对应用级水平扩缩容，解耦了被伸缩对象和伸缩指标，并分别提出了对应的抽象接口（ Scaler + Metrics Adapter 机制），从而即提供了强大的插件机制，又能够为所有扩缩策略提供一层统一的定义方式。此外，KEDA 的设计和架构比较简，没有很复杂的黑科技存在，内置的很多 Scaler 可以直接使用，非常符合 EDAS 产品的整体诉求。

EDAS 基于 OAM 和 KEDA 的云原生 PaaS 架构

在技术架构上，阿里云 EDAS 产品内核是基于 OAM 社区的 KubeVela 开源项目构建的。正是借助了 OAM 提供的 Kubernetes 原生的扩展机制，在上线像 KEDA 这样来自云原生开源社区的能力时，EDAS 产品研发团队并不需要像传统 PaaS 团队那样进行大量的二次开发甚至修改用户侧 API，而只需要将 KEDA 的 CRD 按照 OAM 规范“注册”成为 EDAS 的一个 Autoscale Trait，完成监控数据对接，用户即可使用到这个新增的水平扩容能力。整体架构可以用如下所示的示意图表示清楚：

在具体实现中，EDAS 主要借助阿里云的 ARMS 服务提供的细粒度的应用级监控数据，来驱动 KEDA 对工作负载进行快速的水平扩容。而除了在 KEDA 中增加了 ARMS Scaler 外，EDAS 对 KEDA v1 Release 中存在的问题也进行了很多修复或者增强，包括：

• 多个同类型的 Trigger 的指标值会被相加而不是独立计算导致容量值计算有误；
• KEDA 在创建 HPA 时，名字如果超长则会被简单地 Trim 到 63 字符，没有检查是否符合 DNS 规则，导致有时报错；
• Trigger 不能被禁用，这在生产环境下会有稳定性风险；

上述修复，EDAS 团队已经提交或者正在提交至 KEDA 上游中，其中有一部分已经在 KEDA v2 Release 中得到了修复。

此外，Kubernetes 中还有一个困扰了大家很久的问题就是自动扩容和灰度发布在很多时候会发生冲突。针对这个问题， EDAS 借助 OAM 的模型层语义对这两个能力进行了互斥处理。

当前工作与未来计划

在目前工作的基础上，EDAS 正在与开源社区合作，为基于 KEDA 的 Autoscaler Trait 增加很多新的能力，这包括：

• Trigger 支持禁用功能；
• 提供 Decider 抽象，能够以扩展的方式，在扩容的过程中加入更多的决策逻辑；
• 支持 Dry Run 功能；
• 支持容量变更的灰度，回滚，观测功能；
• 支持 Webhook 通知；

而在未来，EDAS 的主要工作重点会专注于如何在当前的架构上同 EDAS 的 AIOps 能力结合，从而为整个平台引入更加智能的弹性体验，这包括：

1. 更智能的决策机制

• 结合上下游应用状态综合决策
• 结合自适应限流综合决策
• 结合专家系统，根据封网期，大促态的规则综合决策
• 结合历史数据分析综合决策
• 提供容量诊断并自动推荐扩缩策略

2. 更可控的扩缩容过程

• 提供 webhook 在扩缩变更时发送通知
• 提供交互在人工确认后才进行扩缩变更操作
• 提供扩缩变更过程的灰度，回滚，观测功能
• 提供 Dry Run 功能

3. 更丰富的触发器体系

• 应用 QoS 触发器
• 数据库指标触发器
• 消息队列指标触发

在接下来的发布中，这些基于 KEDA 的创新与增强，很快就能够为 EDAS 的用户带来更加强大、智能、稳定的应用自动弹性能力与更加友好的使用体验。

总结

本文主要以 EDAS 的智能弹性伸缩能力为切入点，介绍了阿里云企业级应用平台在经典 PaaS 场景下依托 OAM 和 KubeVela 项目为底座，支持 KEDA 水平扩缩容组件的过程中遇到的挑战和解决办法。后续，这套基于 KEDA 的应用特征会集成更广泛的扩缩容指标和更智能的决策机制。

而在同云原生生态共同演进的同时，阿里云 EDAS 服务在云原生应用管理领域的大规模实践，也为 OAM 社区带来了应用版本化、依赖管理、运维特征交互与批量下发机制等大量生产级增强，以及丰富的最佳实践和经验教训。也正是得益于标准与开放的产品架构，阿里云 EDAS 服务才能够迅速的同 KEDA 等云原生社区“新势力”打成一片，以标准化、可扩展的方式，快速的为用户上线强大的、源自开源社区的各种应用管理能力，真正做到了“以用户为中心”来做技术创新与演进，正式迈向云原生应用 PaaS 的下一个时代。

原文链接：https://developer.aliyun.com/article/779281?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

原文链接：https://blog.csdn.net/alitech2017/article/details/111292444

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。