如何使用KEDA自动缩放Azure管道代理动缩代理在默认情况下

2024-05-16 21:54:43 [百科] 来源：避面尹邢网

如何使用KEDA自动缩放Azure管道代理

译文作者：李睿 2023-02-27 08:00:00开发前端 KEDA是何使一个事件驱动的自动缩放器，它通过根据需要处理的动缩代理事件数量添加额外的HPA。

译者 | 李睿

审校 | 孙淑娟

如何使用KEDA自动缩放Azure管道代理动缩代理在默认情况下

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

如何使用KEDA自动缩放Azure管道代理动缩代理在默认情况下

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

如何使用KEDA自动缩放Azure管道代理动缩代理在默认情况下

当人们谈到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.yaml
apiVersion: v1
kind: Secret
metadata:
name: azp-agent-secret
type: Opaque
data:
vstsToken: BASE64-OF-PAT-TOKEN
---
apiVersion: v1
kind: Service
metadata:
name: azp-agent
labels:
app.kubernetes.io/instance: azp-agent
app.kubernetes.io/name: azp-agent
spec:
clusterIP: None
selector:
app.kubernetes.io/instance: azp-agent
app.kubernetes.io/name: azp-agent
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/instance: azp-agent
app.kubernetes.io/name: azp-agent
name: azp-agent
spec:
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