KEDA宣布2.0版本｜自动伸缩应用程序到下一个水平

阿里云使用了KEDA进行自动伸缩：

“Alibaba’s Enterprise Distributed Application Service （EDAS） which is built with KubeVela project adopts KEDA as the implementation for its auto-scaling trait （see: trait system of Open Application Model） from mid of 2020. In Alibaba, EDAS has served more than 1000+ applications from both Alibaba Cloud’s customers and internal scenarios. EDAS’s KEDA based auto-scaling trait uses Alibaba’s ARMS （i.e. Application Real-Time Monitoring Service） as the trigger by default, and it’s also under integration with AIOps system of EDAS for advanced scenarios such as capacity diagnose based auto-scaling.”

– Lei Zhang, Staff Engineer at Alibaba Cloud & SIG App Delivery Chair

一年前，我们激动地宣布了带有核心伸缩器集的1.0版本，允许社区开始自动伸缩Kubernetes部署。我们对这一响应感到兴奋和鼓励，看到许多用户在Kubernetes集群中利用KEDA实现事件驱动和无服务器伸缩。

使用KEDA，任何容器都可以直接基于事件源指标伸缩到零和突发伸缩。

KEDA最初是由微软和红帽公司发起的，而我们一直努力成为个开放的和供应商中立的项目，以支持所有想要扩展应用程序的人。

这就是今年早些时候我们捐赠并接受为CNCF沙箱项目的原因。我们认为这是个强烈的信号，让社区完全与CNCF的开放心态和供应商中立保持一致。

自从KEDA 1.0发布以来，我们一直为许多不同的源增加新的伸缩器，包括IBM MQ、Postgres和华为Cloudeye，支持新的身份验证提供商，如HashiCorp Vault，并不断改进用户体验，使应用程序自动伸缩变得非常简单。

今天，我们很高兴地宣布另一个里程碑--KEDA 2.0现在已经普遍可用，可以扩展所有的工作负载了！?

开始使用

有很多方法可以开始使用KEDA：

• 使用OperatorHub.io来安装
• 使用Helm来安装：

$ helm repo add kedacore https://kedacore.github.io/charts
$ kubectl create namespace keda
$ helm install keda kedacore/keda –namespace keda –version 2.0.0

• 使用deployment YAML安装：

$ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml

想看看它的实际操作吗？尝尝我们的样品吧。

有什么新特性？?

KEDA 2.0带来了大量的改进和修复。请查看变更日志，查看此版本中变更和改进的完整列表。

在Kubernetes集群中有两种类型的工作负载可以自动伸缩：类似deployment的工作负载或类似job的工作负载。KEDA1.x通过在ScaledObject资源中指定它，支持扩展这两种类型，并且仅限于扩展Kubernetes Deployment或Jobs资源。

在KEDA 2.0中，我们拆分了这两个选项，并引入了个单独的资源来描述这两种类型，以更好地适应配置和行为的不同需求--ScaledObject和ScaledJob资源。

KEDA 2.0带来了另一个期待已久的特性，你可以在一个ScaledObject/ScaledJob上指定多个触发器，这样你的工作负载就可以基于不同的触发器进行自动伸缩（例如，Kafka和Prometheus），KEDA将基于伸缩器选择最大的值来定义伸缩决策，比如副本的目标数目。

ScaledObject的改进

ScaledObject描述类似deployment的工作负载的规范。我们说的不仅仅是Kubernetes Deployment，有了KEDA 2.0，你可以扩展StatefulSet或任何其他实现/scale子资源的自定义资源（例如Argo Rollouts）。这带来了更多的场景和用例，可以从KEDA及其自动伸缩功能中获益。用户可以简单地在他们的自定义资源实现/scale端点，并获得开箱即用的自动伸缩！

如果你在Kubernetes版本>= 1.18上运行KEDA，那么你可以从可配置的伸缩行为中获益，它允许你指定向上和向下伸缩的行为。这就向KEDA暴露了Kubernetes Horizontal Pod Autoscaler的新功能。

引入ScaledJob

如前所述，KEDA 2.0为扩展Kubernetes Job提供了个单独的自定义资源。这允许我们适应并简化规范和配置，因为扩展Job与扩展类似deployment的工作负载有不同的需求。

扩展Job可以有不同的用例，并且这些用例在不同的伸缩器中可能会有所不同。这就是为什么在KEDA 2.0中引入了ScaledJob的ScalingStrategy，它允许用户选择不同的策略来扩展Kubernetes Job。

新的伸缩器

KEDA 2.0引入了新的伸缩器供你使用。

首先，我们的社区一起添加了Azure Log Analytics和IBM MQ伸缩器。

通过使用我们新的CPU/Memory伸缩器，你不再需要混合和匹配Horizontal Pod Autoscaler（HPA）和ScaledObject--你现在可以完全标准化使用KEDA，我们将为你处理所有的HPA！

有了我们新的外部推送伸缩器，你可以通过使用推送模型来实现更反应性的自动伸缩来构建自己的伸缩器并在KEDA中触发伸缩动作，而不是使用外部伸缩器中当前基于拉的模型来创建一个拉模型。

最后，使用我们新的Metrics API伸缩器，你可以自动地根据通过REST API提供的指标进行伸缩，而不必构建自己的伸缩器。这允许你基于你的环境中可用的指标源（例如用于自动化流程的内部API或Microsoft Dynamics CRM API）进行自动伸缩决策。

我们也对现有的伸缩器进行了各种改进，以优化我们的伸缩。

操作和可扩展性

KEDA现在在操作器和Metrics服务器pod上暴露了Liveness和Readiness探测器，管理员可以更好地了解KEDA的状态和运行状况。

KEDA Metrics服务器现在暴露关于每个使用的伸缩器的Prometheus指标。现在，当HorizontalPodAutoscaler处于活动状态时（> 0副本），这些指标与ScaledObject指标一起工作。在KEDA的后续版本中，还计划扩展这一功能，并为ScaledJob提供指标。

开发人员现在可以使用go-client库，该库允许从应用程序内部轻松操作KEDA API。

迁移到KEDA 2.0

我们希望现有的客户能够超级简单的使用2.0！但有什么变化呢？

我们正在做一些一般性的改变：

• 用于KEDA自定义资源定义（CRD）的API命名空间已经从keda.k8s.io更改成keda.sh
• 伸缩作业现在通过ScaledJob CRD完成，而不是ScaledObject CRD
• ScaledObject现在使用spec.scaleTargetRef.name，而不是spec.scaleTargetRef.deploymentName
• ScaledObject不再需要deploymentName标签（最近几个v1版本已经忽略了它）

为了在所有伸缩器提供更一致的体验，我们引入了触发器元数据的灵活性和可用性，为此我们必须跨伸缩器做一些改变，同时也改进了Azure Service Bus、Kafka和RabbitMQ伸缩器。

通过使用我们的迁移指南了解更多关于如何迁移的信息！

注意：不支持并排运行KEDA1.x和2.0。

KEDA附带一个指标服务器，而Kubernetes只允许你在集群中运行其中一个。

在我们的文档中了解更多关于KEDA的架构。

KEDA?社区

如果没有我们伟大的社区，KEDA就不会有今天的成就--他们通过他们的特性请求、贡献、测试我们的候选版本和他们的支持帮助我们形成了KEDA 2.0版本。

很高兴看到越来越多来自世界各地的人开始从诸如IBM、Oracle、Pivotal、Polidea、Tripadvisor、VMWare、Zapier等公司回馈--没有他们我们不可能做到这一点！

我们很荣幸地看到其他的技术也采用KEDA应用在他们自己的产品中，这里有一些：

• Apache Airflow & Astronomer正在使用KEDA自动伸缩工作流程。
• Dapr推荐KEDA自动伸缩Dapr应用程序
• Fission正在构建一个KEDA连接器目录，以在Kubernetes上扩展它们的无服务器功能。
• Knative使用KEDA自动伸缩Knative Event Source

我们非常感谢这些公司和技术采用了KEDA：

你在生产中也使用KEDA吗？不要犹豫，让我们知道！

展望未来?

我们已经在这个里程碑上工作了一段时间，很高兴终于能够正式发布KEDA 2.0！但是我们并没有就此止步，我们已经开始在v2.1上工作了。

透明度是成为一个成功的开源项目的必要条件，我们希望KEDA的未来是开放的。正因为如此，我们引入了个公开的KEDA高层路线图，允许你了解我们的项目进展，并允许你提供建议，以便我们适应。

接下来，我们将进一步改进KEDA项目，专注于通过引入安全策略、自动漏洞扫描等，使其更加健壮，以确保我们提供的软件是安全的，因此你不必担心。

随着KEDA的持续发展，许多组织都做出了回馈，并分享了许多非常有趣的依赖于KEDA的用例。我们正在写一个参考案例来展示KEDA对客户的价值。

随着我们继续与社会各界合作，我们的目标是建议在今年晚些时候/明年年初进入CNCF孵化阶段。我们将采取下一步行动，把KEDA的好处带给每一个用户，我们从社区得到的任何支持都是非常有用的。

最后但并非最不重要的是，我们希望人们能够展示他们对KEDA的支持，并致力于提供你可以购买并自豪地穿着的商品！坐等我们的战利品出现。

感谢你的阅读，祝你伸缩愉快！

KEDA维护者。

点击阅读网站原文。

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。