共计 4514 个字符，预计需要花费 12 分钟才能阅读完成。
阿里云应用了 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 微信公众号。
