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

译者 | 李睿

10年积累的成都网站建设、网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先做网站后付款的网站建设流程，更有潼南免费网站建设让你可以放心的选择与我们合作。

审校 | 孙淑娟

如果你正在使用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.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

在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

名称栏目：如何使用KEDA自动缩放Azure管道代理
分享地址：http://www.shufengxianlan.com/qtweb/news29/295029.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容