KEDA快报:基于Kubernetes,事件驱动的自动缩放

自上一次Microsoft Build 2019会议以来已经有一段时间了。此后引起我们关注的新闻是基于Kubernetes的事件驱动自动缩放(KEDA)的发布。我们想进一步了解这个解决方案。

KEDA是什么?

KEDA是一个由Red Hat和Microsoft的工程团队合作而启动的项目。通常将其定义为一个开源组件,我们可以将其安装在Kubernetes集群中,以实现基于事件的容器扩缩。我们知道Kubernetes原生支持基于CPU和内存指标来扩缩容器,这样看来某种意义上KEDA扩展了Kubernetes的功能。由于该项目仍在开发中,因此您可以在 GitHub 上跟踪其进度。前不久已经1.0 release , 可以放心在生产环境中使用。

KEDA包括一组特殊的适配器(连接到数据源以获取度量标准的组件)。度量标准还用于确定是否以及如何扩缩容器。目前,有12个此类连接器:RabbitMQ,Kafka,Nats,Redis数据库,Azure Event Hub,Azure Queue, Azure 服务总线, AWS SQS, AWS CloudWatch, GCP Pub/Sub, prometheus和External连接器。External连接器用于满足更多定制化需求。此外在KEDA1.1 版本将支持 HuaweiCloud 云监控连接器。

如我们所见,KEDA使Kubernetes集群成为事件驱动架构的有效基础架构,而无需基于事件队列创建其扩展组件。

KEDA 架构

根据上图,KEDA为每个群集提供三个基本组件:

  • Scaler -连接到选定源(例如RabbitMQ)并读取其指标(队列大小)的组件
  • Metrics Adapter —指标适配器,将由Scaler读取的指标转发到Horizo​​ntal Pod Autoscaler(HPA)以启用水平应用程序自动缩放
  • Controller -最后一个,也可能是最重要的元素,可为容器的使用者提供从0到1(或从1到0)的缩放比例。为什么只有1和0?因为整个解决方案希望扩展Kubernetes的功能,而无需从头开始提供任何功能。 Controller扩展到第一个实例,然后HPA使用Metrics Adapter转发的指标执行进一步的克隆。控制器还负责连续监视是否出现了新的 ScaledObject 部署

如何创建一个ScaledObject部署

要将KEDA与我们的容器一起使用,我们首先必须创建一个ScaledObject部署。例如,在YAML中,我们可以指定缩放规则并选择要复制的容器。

示例如下:

apiVersion: keda.k8s.io/v1alpha1

kind: ScaledObject

metadata:

name: keda-service-bus-function

labels:

deploymentName: keda-service-bus-function

spec:

scaleTargetRef:

deploymentName: keda-service-bus-function

containerName: azure-functions-container

pollingInterval: 30

cooldownPeriod: 300

minReplicaCount: 1

maxReplicaCount: 500

triggers:

type: azure-servicebus

metadata:

queueName: my-queue

connection: SB_CONN_STRING

queueLength: ‘10’

ScaledObject 配置项对于使用有效的缩放机制是必不可少的。例如,看看 minReplicaCount 设置为“ 1”时,它将保护我们免受冷启动的影响。

KEDA集成Azure Functions

您可能想知道如何在架构中利用KEDA。 KEDA for Microsoft Azure的基本应用是将Azure Functions迁移到Kubernetes。

是的,以前确实有可能。我们已经可以在Docker容器中然后在Kubernetes中运行Azure Functions。 KEDA在这里没有带来任何新的东西。

但是,直到现在,我们完全负责创建适当的协调器来扩展功能实例。现在,KEDA正在为我们承担扩缩控制器的角色。

KEDA和Azure Functions 核心工具

当KEDA首次出现时,Microsoft随后修改了其Azure Functions核心工具。与KEDA的Azure Functions集成专门适用于这些工具,这些工具获得了额外的代码:

func kubernetes

让我们看看如何使用它:

KEDA实战

我们将通过一个快速演示,在其中创建一个Azure Function,该Function应由KEDA在我们的群集中进行扩缩。

  1. 让我们从必需工具和组件开始

    • Azure Functions Core Tools (minimum version 2.7) — available here
    • Visual Studio Code (with Azure Functions)
    • Kubectl connected to our cluster
    • Docker
      我在Azure(AKS)中配置了群集并创建了以下服务:
    • Azure Service Bus (with a queue)
    • Azure Storage Account (for our functions)
    • Azure Container Registry (here’s where our function, a Docker image, will appear before running in Kubernetes)

2.接下来,我们转到Visual Studio Code并使用我之前提到的扩展名创建一个新函数:

帮助文档

请注意,在第19行中,我将线程执行暂停了30秒。我这样做只是为了更明确地证明此缩放方法有效。

3.让我们继续前进。在 local.settings.json 中,我们应该提供两个设置的配置:

- AzureWebJobStorage -- 在这里,我们说明先前创建的Azure存储的连接字符串的值

- keda-test_SERVICEBUS -- 这是我们的服务总线的连接字符串

“IsEncrypted”: false,

“Values”: {

“AzureWebJobsStorage”: “DefaultEndpointsProtocol=……”,

“FUNCTIONS_WORKER_RUNTIME”: “dotnet”,

“keda-test_SERVICEBUS”: “Endpoint=sb://…..

}

}

4.现在,我们将重点关注集群中的KEDA安装。在这里,我们将使用我前面提到的集成。在终端级别,我们剩下的唯一事情就是调用以下请求:

func kubernetes install — namespace keda-test

在KEDA的GitHub上,您还将找到其他安装方法(例如Helm)。但是,我们对Azure Function Core Tools感兴趣。

接下来让我们看看在我们的环境中部署了那些组件:

您可以在此处立即发现一个新组件。除KEDA外,我们还安装了 Osiris

这是一个独立的组件,负责扩展HTTP请求调用的功能。 KEDA答复除HTTP之外的所有其余请求。

5.下一步,我们必须准备要在容器中工作的功能。同样,这是KEDA的一项琐碎任务,简化为一行:

func init –docker

结果,新的Dockerfile出现在项目中。

6.现在,建议您编译整个项目并在Visual Studio Code中分析错误列表窗口。如果没有错误,我们可以进入最后一个阶段:运行我们的函数。

7.要部署该功能,请运行以下命令:

func kubernetes deploy \

--name keda-service-bus-function \

--namespace keda-test \

--registry kedatest.azurecr.io/keda-service-bus-function

--pull-secret regcred

接下来我们分析一下配置参数:

name
namespace
registry
pull-secret

请记住,在执行此命令之前,您必须登录到远程Docker注册表的终端。

KEDA 配置

让我们看看集群中的KEDA配置是否正确。

我的函数有一个触发队列-服务总线。因此,我必须使用一种将在队列中生成消息的机制。在这里,我可以建议以下三种解决方案之一(我选择了最后一种):

  • 在门户中创建Azure函数
  • 使用Visual Studio Code或Visual Studio为.NET项目中的服务总线队列编写一个简单的消息生成器
  • 使用服务总线资源管理器( https://github.com/paolosalvat ... lorer

在将消息添加到队列时,我多次运行以下命令:

kubectl get pods — namespace keda-test | grep ‘keda-service-bus-function’

如下图所示,我们的解决方案非常有魅力。该功能首先由KEDA缩放(从0到1),然后HPA负责进一步的POD缩放。

总结

KEDA目前已经release,可以在生产中部署。尽管如此,我还是建议您跟随该项目并了解其工作原理,尤其是因为基于事件的体系结构在Azure中非常流行。

毫无疑问,KEDA中的scaler在逐步增多,这将大大增加该项目的应用程序数量。

KEDA 是一个社区项目,不仅仅对Azure有很好的支持,对于AWS和GCP以及其他的常用消息队列都有很好的支持。松耦合的架构,也很方便扩展自己的Scaler。

可以预见,KEDA 是未来Kubernetes体系中,基于事件扩缩的生产级别的方案。非常有竞争力。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章