使用 KEDA 自动缩放 Azure pipeline代理

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。

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

如果您使用Kubernetes解决方案作为在任何公共云中托管容器化应用程序的平台，那么计费就是迟早会追捕您的事情之一。Kubernetes 的计费很大程度上取决于节点的数量，而节点的数量取决于集群的工作负载数量。我们知道自动缩放是 Kubernetes 最喜欢的功能之一。因此，在根本没有工作时缩减一些工作负载并降低云成本会更明智。

当我们谈论 Kubernetes 自动缩放功能时，会自动想到 Horizontal Pod Autoscaler (HPA)。默认情况下，HPA 可以使用 CPU 或 RAM 使用率等基本指标来实现自动缩放。但是，如果复杂的分布式应用程序与 Kubernetes 集群外部的不同组件集成（例如：Kafka 主题滞后、Redis 流、Azure 管道队列、Azure 服务总线、PubSub 主题等），HPA 本身无法扩展基于这些组件的指标的 pod。

HPA 可以使用自定义指标并在此基础上进行扩展，但它需要您设置指标适配器和额外的配置层才能将数据正确映射到 Kubernetes。

这就是KEDA 让我的生活变得轻松的地方。

为了克服此类问题，KEDA 在 Horizo ntal Pod Autoscaler (HPA) 之上提供了扩展功能。KEDA 是一个事件驱动的自动缩放器，它通过根据需要处理的事件数量添加额外的 Pod 来水平缩放容器。它自动扩展不同类型的 Kubernetes 资源，例如部署、Statefulsets、作业和自定义资源。

架构和概念

在高水平。KEDA 由两个组件组成，用于控制 Pod/工作负载的自动缩放。

1. 代理：它负责激活和停用 Kubernetes 部署、状态集或任何其他目标，以便在没有事件时缩放到零或在有事件时从零缩放。
2. Metrics Server：它充当 Kubernetes 指标服务器，将从事件源收集的事件（Azure 管道队列、Kafka 主题消息等）公开给 Horizontal Pod Autoscaler (HPA)。

Scaler：KEDA的真正力量在于大量的Scaler。缩放器是丰富的信息源，因为它提供外部数据/事件并允许您根据外部数据进行缩放。今天，它支持 50 多个“缩放器”，并带有特定支持的触发器，如 Azure Pipeline（触发器：azure-pipeline）和 Kafka（触发器：Kafka 主题），并且还会有更多。

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

KEDA 使用另一个名为 TriggerAuthentication(namespaced) 或
ClusterTriggerAutnetication (Cluster Scoped) 的 CRD 对事件源进行身份验证。

现在理论足够了；让我们来看一些实际用例，看看我们如何利用 KEDA 来管理代理池中的 azure 管道代理。

用例

在开始之前，让我们花点时间了解一下我们的场景。我们有一个 ADO (Azure DevOps) 项目，它使用持续集成和部署(CICD) 解决方案。在此之下，已经构建了构建/发布管道。这些管道使用自托管的容器化代理来执行所有任务。这些自托管的容器化代理作为 statefulset 部署在 GKE 集群上。

下面的屏幕截图描述了我们在 statefulset 下只有一个 pod 代理，并且一个管道作业正在同一个 pod 代理上运行。如果我们创建更多版本，它们（作业）将进入队列并等待单个 pod 代理空闲。有了 KEDA，我们希望在队列中有新作业时看到 Pod 的数量得到扩展。

先决条件

安装 Azure 管道代理

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

现在让我们验证代理是否已成功注册到 ADO 代理池。我们可以看到代理也出现在Azure Pipelines上。

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

KEDA 可以通过多种方式安装在 Kubernetes 集群上。我已经使用 helm chart 在集群上安装了 KEDA。您可以在此处参考官方 Helm 图表。

科达在行动

如前所述，ScaledObject 是在事件源和部署之间创建映射的对象。现在，我们将使用 azure-pipeline 触发器和 TriggerAuthentication 创建 ScaledObject，以允许 KEDA 在 statefulset 中缩放 pod。

请参阅此处的官方页面以探索 ScaledObject 的所有参数。

创建 ScaledObject 后，KEDA 会自动同步配置并开始监视上面创建的 azp-agent Statefulset。KEDA 无缝创建具有所需配置的 HPA（Horizontal Pod Autoscaler）对象，并根据通过 ScaledObject 提供的触发规则（在本例中为队列长度为“1”）扩展副本。

现在，我将对我的 repo 进行一些提交以将一些构建排入队列。

结果，我们可以看到 KEDA 扩展了 azp-agent Statefulset 中的 pod 数量，这些 pod 将注册到代理池并占用队列中的待处理作业。

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