Kubernetes自动扩展以适应事件驱动的工作负载

Kubernetes具有多种形式，是构建分布式系统的强大工具。 但是，存在一个大问题：开箱即用的设计仅提供基于资源的扩展。 如果您查看它的历史（来自Google内部的Borg服务作为对AWS的回应），那么这一决定就不足为奇了。 它设计用于的大多数应用程序和服务都是资源受限的，使用大量数据，并且依赖于内存和CPU。

并非所有分布式应用程序都是这样。 许多，特别是那些与IoT（物联网）系统配合使用的系统，需要对事件做出快速响应。 这里最重要的是I / O，提供事件和消息以按需触发流程。 这个模型可以很好地与我们所谓的无服务器计算相结合。 大多数无服务器模型都依赖于按需快速扩展新的计算容器，这种方法在具有自己的控制器的专用虚拟基础架构上可以很好地运行，但是与Kubernetes的资源驱动的扩展并不特别兼容。

[ 也在InfoWorld上：复杂性会杀死Kubernetes吗？ ]

KEDA简介：基于Kubernetes的事件驱动自动缩放

微软和红帽一直在合作为Kubernetes增加事件驱动的扩展， 在2019年5月的微软Build大会上宣布了他们的开源KEDA项目 。 最初的KEDA代码很快引起了人们的注意， 该项目最近发布了1.0版本 ，目的是让该项目被Cloud Native Computing Foundation采用。

KEDA可以在任何Kubernetes集群上运行，从而增加了对可用于推动扩展的一组新指标的支持。 现在，您不仅可以响应CPU和内存负载，还可以基于接收到的事件的速率进行响应，从而降低了排队延迟和事件数据丢失的风险。 由于消息量和CPU需求没有直接关联，因此启用KEDA的集群可以在消息到达时生成新实例，而这要早于传统的Kubernetes指标可以做出响应。 它还可以支持在队列为空时将集群缩减为零，从而将成本降至最低，并使Kubernetes集群的行为类似于Azure Functions。

[ 同样在InfoWorld上：22个使Kubernetes更好的开源工具 ]

部署KEDA

像Microsoft的许多最新分布式应用程序工具一样，KEDA明确地与平台无关。 考虑到Kubernetes支持尽可能多的平台的方法以及避免在发行版之间分叉平台的非正式协议，这并不奇怪。 Microsoft提供了一种在Azure功能中安装KEDA的方法，或者您可以使用Helm图表或YAML将其添加到任何Kubernetes安装中。

使用Helm进行部署可能是最好的选择，因为可以轻松编写脚本并将其添加到基础结构存储库中。 要安装KEDA，请将其GitHub存储库添加到您的Helm安装中。 将Helm储存库更新为使用KEDA图表后，针对所使用的Helm版本运行适当的安装命令。 在运行图表之前，Helm 3用户将需要使用kubectl向其Kubernetes安装中添加名称空间。

安装后，需要配置KEDA以与您选择的洁牙机配合使用 。 用KEDA术语来说，缩放器是用于监视事件源的工具，该事件源用于缩放Kubernetes应用程序。 尽管您可以创建自己的应用程序，但KEDA社区已汇总了一套涵盖大多数常见方案的应用程序，从Apache Kafka到通过AWS Cloudwatch和GCP的发布/订阅工具的Azure事件中心 。

[ 也在InfoWorld上：微软的开放应用模型和Rudr解释 ]

内部KEDA自动缩放

KEDA实现了两个关键的Kubernetes角色，这些角色被部署为Kubernetes集群中的单独容器。 第一个是keda-operator ，它是一个控制器，用于管理其他容器，并根据需要进行缩放。 第二keda-operator-metrics-apiserver ，它管理容器的扩展服务，在检测到定义的度量（例如队列长度）时扩展集群。 KEDA并不是用于管理事件的工具。 您的pod代码将需要为您处理。 KEDA所做的所有工作就是监视队列，以确保您的集群始终具有最佳实例数，以避免丢失数据或给系统增加严重的延迟。

实施事件驱动的扩展并不难 。 将缩放器附加到事件源后，KEDA随后将链接到同一名称空间中的Kubernetes部署。 与大多数Kubernetes一样，KEDA的行为在XAML中使用自定义资源定义进行了描述。 首先，为扩展行为定义规格，列出目标，轮询间隔和冷却时间以及最小和最大副本数。 所有这些都有默认选项，但是您需要对其进行调整。

默认轮询间隔为30秒。 这可能适合于低频率的事件，但是如果您希望处理大量数据，则需要增加该数据以避免队列积压。 同样，您可能需要将冷却时间更改为更适合您的云提供商的容器计费策略的时间。

[ 通过InfoWorld Daily新闻通讯了解软件开发，云计算，数据分析和机器学习方面的最新发展 ]

正确配置KEDA

在配置KEDA时，了解事件驱动的应用程序的基础模式非常重要。 例如，选择适当的冷却时间可以通过将活动容器的数量保持为最少来降低成本。 但是，启动新容器时会有相关的延迟。 这会给系统增加延迟，在许多情况下，最好保持最少数量的副本运行，以确保最快的响应时间。 由您确定是否适合您的应用程序的经济模型。

如果您有长期运行的事件，那么使用KEDA扩展部署可能会成为一个问题。 由于容器由Kubernetes自己的控制器管理，因此即使事件仍在处理中，资源也有可能被清除。 另一种选择是使用KEDA处理Kubernetes作业 ，将每个事件视为已创建的单个作业，运行以处理单个消息，然后终止。 可以很容易地看到这种使用Azure Functions托管容器的方法，允许您将无服务器代码在云之间移动到自己的基础结构中。

有趣的是，看到Microsoft与KEDA之类的工具与Red Hat合作。 云应用程序不应仅局限于一个公共云，这使得与平台无关的Kubernetes服务成为突破公共云围墙花园的重要工具。 使用KEDA意味着您可以在任何经过​​认证的Kubernetes发行版上运行相同的无服务器应用程序，从集中式超大规模服务一直到在Raspberry Pis群集上运行的边缘实现。

From: https://www.infoworld.com/article/3481620/kubernetes-autoscaling-for-event-driven-workloads.html