阿里云应用了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微信公众号。