KEDA是一个事件驱动的自动缩放器，它通过根据需要处理的事件数量添加额外的HPA。

译者 | 李睿

(相关资料图)

审校 | 孙淑娟

如果你正在使用Kubernetes解决方案作为一个平台，并在任何公共云中托管容器应用程序，那么迟早会面临高昂的帐单。Kubernetes计费在很大程度上取决于节点的数量，而节点数量是由集群的工作负载数量决定的。

众所周知，自动缩放是Kubernetes最受欢迎的特性之一。因此，在根本没有进行工作的情况下，减少一些工作负载并降低云计算成本将更为明智。

当人们谈到Kubernetes的自动缩放功能时，可能会想到水平Pod自动缩放器(HPA)。在默认情况下，HPA可以使用基本指标(如CPU或内存使用情况)实现自动缩放。然而，当复杂的分布式应用程序与Kubernetes集群之外的不同组件集成时(例如：Kafka topic lag、Redis Stream、Azure Pipeline Queue、Azure Service Bus、PubSub topic等)，HPA本身无法基于这些组件的指标来缩放pod。

HPA可以使用自定义指标并以此为基础进行缩放，但它需要设置一个指标适配器和一个额外的配置层，以便将数据正确地映射到Kubernetes。

这就是KEDA让用户的工作变得轻松的地方。

为了克服这类问题，KEDA在HPA之上提供了缩放功能。KEDA是一个事件驱动的自动缩放器，它根据需要处理的事件数量添加额外的HPA。它自动缩放不同类型的Kubernetes资源，例如部署、状态集、作业和自定义资源。

架构和概念

KEDA由两个组件组成，用于控制pods/工作负载的自动缩放。

（1）代理：它负责激活和取消激活Kubernetes部署、状态集或任何其他目标，以便在没有事件时缩放到零，在有事件时缩放到零。

（2）度量服务器：它作为Kubernetes度量服务器，将从事件源收集的事件(Azure管道队列、Kafka主题消息等)公开到HPA。

缩放器：KEDA的真正力量在于大量的缩放器。缩放器是一个丰富的信息源，因为它提供外部数据/事件，并允许基于外部数据进行缩放。如今，它支持50多个具有特定支持触发器的缩放器，如Azure Pipeline（触发器：Azure Pipeline）和Kafka（触发器：Kafka Topics），并且还有更多功能。

ScaledObject：它们被部署为Kubernetes CRD，带来了将部署/状态集与事件源链接起来的功能，并定义了可缩放元数据。ScaledObject使用触发器响应事件源中发生的事件，并根据需要缩放工作负载。

KEDA使用另一个名为Trigger Authentication(名称空间)或ClusterTriggerAutnetication (集群作用域)的CRD对事件源进行身份验证。

现在有足够的理论，以下来看一些实际用例，如何利用KEDA在代理池中管理Azure管道代理。

用例

首先，需要花费时间来理解场景。例如一个ADO(Azure DevOps)项目，它使用持续集成(CI)/持续交付（CD)解决方案。在这一基础上，已经构建了构建/发布管道。这些管道使用自托管的容器化代理来执行所有任务。这些自托管的容器化代理作为状态集部署在GKE集群上。

下面的截图描述了在StatefulSet下只有一个pod代理，并且一个管道作业正在同一个pod代理上运行。如果创建更多的版本，它们(作业)将进入队列，等待单个pod代理空闲。有了KEDA，每当队列中有一个新作业时，将会看到pod的数量得到增加。

先决条件

采用ADO项目(已建立代理池)作为持续集成(CI)/持续交付（CD)解决方案。 在代理池下创建Azure管道代理所需的ADO项目权限。 Kubernetes集群将Azure管道代理部署为状态集。 必须为K8S集群中的应用程序建立必要的GCP网络连接，以便能够访问互联网。

安装Azure管道代理

使用以下YAML在K8S集群上安装自托管的容器化Azure管道代理。

现在验证代理已成功注册到ADO代理池，可以看到代理也出现在Azure管道上。

azp-gent.yamlapiVersion: v1kind: Secretmetadata:  name: azp-agent-secrettype: Opaquedata:  vstsToken: BASE64-OF-PAT-TOKEN---apiVersion: v1kind: Servicemetadata:  name: azp-agent  labels:    app.kubernetes.io/instance: azp-agent    app.kubernetes.io/name: azp-agentspec:  clusterIP: None  selector:    app.kubernetes.io/instance: azp-agent    app.kubernetes.io/name: azp-agent---apiVersion: apps/v1kind: StatefulSetmetadata:  labels:    app.kubernetes.io/instance: azp-agent    app.kubernetes.io/name: azp-agent  name: azp-agentspec:  replicas: 1  selector:    matchLabels:      app.kubernetes.io/instance: azp-agent      app.kubernetes.io/name: azp-agent  serviceName: azp-agent  template:    metadata:      labels:        app.kubernetes.io/instance: azp-agent        app.kubernetes.io/name: azp-agent    spec:      containers:      - env:        - name: POD_NAME          valueFrom:            fieldRef:              apiVersion: v1              fieldPath: metadata.name        - name: AZP_TOKEN          valueFrom:            secretKeyRef:              key: vstsToken              name: azp-agent-secret        - name: AZP_POOL          value: POOL-NAME        - name: AZP_URL          value: https://dev.azure.com/YOUR-ORG-NAME/        - name: AZP_WORK          value: /var/vsts        - name: AZP_AGENT_NAME          value: $(POD_NAME)        image: AZURE-PIPELINE-AGENT-IMAGE        imagePullPolicy: Always        name: azp-agent        resources:          limits:            cpu: 500m            memory: 1Gi          requests:            cpu: 100m            memory: 500Mi        volumeMounts:        - mountPath: /var/vsts          name: workspace        - mountPath: /vsts/agent          name: agent-dir        - mountPath: /var/run/docker.sock          name: docker-socket      volumes:      - hostPath:          path: /var/run/docker.sock          type: ""        name: docker-socket  volumeClaimTemplates:  - apiVersion: v1    kind: PersistentVolumeClaim    metadata:      name: workspace    spec:      accessModes:      - ReadWriteOnce      resources:        requests:          storage: 50Gi      storageClassName: standard      volumeMode: Filesystem  - apiVersion: v1    kind: PersistentVolumeClaim    metadata:      name: agent-dir    spec:      accessModes:      - ReadWriteOnce      resources:        requests:          storage: 5Gi      storageClassName: standard      volumeMode: Filesystem

在Kubernetes集群上安装KEDA

可以通过多种方式在Kubernetes集群上安装KEDA。例如使用Helm chart在集群上安装KEDA，其他方法可以参考官方Helm图表。

KEDA在行动

如上所述，ScaledObject是在事件源和部署之间创建映射的对象。现在，将使用Azure管道触发器和TriggerAuthentication创建ScaledObject，以允许KEDA在状态集中缩放pod。

参考官方页面可以了解ScaledObject的所有参数。

一旦创建了ScaledObject，KEDA将自动同步配置，并开始监视上面创建的azp-agent Statefulset。KEDA使用所需的配置无缝地创建一个HPA对象，并基于通过ScaledObject提供的触发器规则(在本例中，它的队列长度为‘1’)缩放副本。

现在，将对回购进行一些提交，以排队一些构建。

因此，可以看到KEDA在azp-agent Statefulset中缩放了pod的数量，这些pod将被注册到代理池中，并承担队列上的挂起作业

KEDA拥有50多个缩放器，可以使用不同类型的事件源事件来驱动自动缩放，并且它还在继续添加更多的缩放器。因此，它绝对是一个可用于基于事件的自动缩放的生产级应用程序。

原文标题：​​Autoscale Azure Pipeline Agents With KEDA​​，作者：Basudeba Mandal

标签：