譯者 | 李睿

審校 | 孫淑娟

如果你正在使用Kubernetes解決方案作為一個(gè)平臺(tái)，并在任何公共云中托管容器應(yīng)用程序，那么遲早會(huì)面臨高昂的帳單。Kubernetes計(jì)費(fèi)在很大程度上取決于節(jié)點(diǎn)的數(shù)量，而節(jié)點(diǎn)數(shù)量是由集群的工作負(fù)載數(shù)量決定的。

眾所周知，自動(dòng)縮放是Kubernetes最受歡迎的特性之一。因此，在根本沒有進(jìn)行工作的情況下，減少一些工作負(fù)載并降低云計(jì)算成本將更為明智。

當(dāng)人們談到Kubernetes的自動(dòng)縮放功能時(shí)，可能會(huì)想到水平Pod自動(dòng)縮放器(HPA)。在默認(rèn)情況下，HPA可以使用基本指標(biāo)(如CPU或內(nèi)存使用情況)實(shí)現(xiàn)自動(dòng)縮放。然而，當(dāng)復(fù)雜的分布式應(yīng)用程序與Kubernetes集群之外的不同組件集成時(shí)(例如：Kafka topic lag、Redis Stream、Azure Pipeline Queue、Azure Service Bus、PubSub topic等)，HPA本身無法基于這些組件的指標(biāo)來縮放pod。  

HPA可以使用自定義指標(biāo)并以此為基礎(chǔ)進(jìn)行縮放，但它需要設(shè)置一個(gè)指標(biāo)適配器和一個(gè)額外的配置層，以便將數(shù)據(jù)正確地映射到Kubernetes。  

這就是KEDA讓用戶的工作變得輕松的地方。  

為了克服這類問題，KEDA在HPA之上提供了縮放功能。KEDA是一個(gè)事件驅(qū)動(dòng)的自動(dòng)縮放器，它根據(jù)需要處理的事件數(shù)量添加額外的HPA。它自動(dòng)縮放不同類型的Kubernetes資源，例如部署、狀態(tài)集、作業(yè)和自定義資源。  

架構(gòu)和概念

KEDA由兩個(gè)組件組成，用于控制pods/工作負(fù)載的自動(dòng)縮放。  

（1）代理：它負(fù)責(zé)激活和取消激活Kubernetes部署、狀態(tài)集或任何其他目標(biāo)，以便在沒有事件時(shí)縮放到零，在有事件時(shí)縮放到零。  

（2）度量服務(wù)器：它作為Kubernetes度量服務(wù)器，將從事件源收集的事件(Azure管道隊(duì)列、Kafka主題消息等)公開到HPA。  

縮放器：KEDA的真正力量在于大量的縮放器?？s放器是一個(gè)豐富的信息源，因?yàn)樗峁┩獠繑?shù)據(jù)/事件，并允許基于外部數(shù)據(jù)進(jìn)行縮放。如今，它支持50多個(gè)具有特定支持觸發(fā)器的縮放器，如Azure Pipeline（觸發(fā)器：Azure Pipeline）和Kafka（觸發(fā)器：Kafka Topics），并且還有更多功能。

ScaledObject：它們被部署為Kubernetes CRD，帶來了將部署/狀態(tài)集與事件源鏈接起來的功能，并定義了可縮放元數(shù)據(jù)。ScaledObject使用觸發(fā)器響應(yīng)事件源中發(fā)生的事件，并根據(jù)需要縮放工作負(fù)載。  

KEDA使用另一個(gè)名為Trigger Authentication(名稱空間)或ClusterTriggerAutnetication (集群作用域)的CRD對(duì)事件源進(jìn)行身份驗(yàn)證。

現(xiàn)在有足夠的理論，以下來看一些實(shí)際用例，如何利用KEDA在代理池中管理Azure管道代理。

用例

首先，需要花費(fèi)時(shí)間來理解場(chǎng)景。例如一個(gè)ADO(Azure DevOps)項(xiàng)目，它使用持續(xù)集成(CI)/持續(xù)交付（CD)解決方案。在這一基礎(chǔ)上，已經(jīng)構(gòu)建了構(gòu)建/發(fā)布管道。這些管道使用自托管的容器化代理來執(zhí)行所有任務(wù)。這些自托管的容器化代理作為狀態(tài)集部署在GKE集群上。  

下面的截圖描述了在StatefulSet下只有一個(gè)pod代理，并且一個(gè)管道作業(yè)正在同一個(gè)pod代理上運(yùn)行。如果創(chuàng)建更多的版本，它們(作業(yè))將進(jìn)入隊(duì)列，等待單個(gè)pod代理空閑。有了KEDA，每當(dāng)隊(duì)列中有一個(gè)新作業(yè)時(shí)，將會(huì)看到pod的數(shù)量得到增加。  

先決條件

• 采用ADO項(xiàng)目(已建立代理池)作為持續(xù)集成(CI)/持續(xù)交付（CD)解決方案。  
• 在代理池下創(chuàng)建Azure管道代理所需的ADO項(xiàng)目權(quán)限。
• Kubernetes集群將Azure管道代理部署為狀態(tài)集。  
• 必須為K8S集群中的應(yīng)用程序建立必要的GCP網(wǎng)絡(luò)連接，以便能夠訪問互聯(lián)網(wǎng)。

安裝Azure管道代理  

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

現(xiàn)在驗(yàn)證代理已成功注冊(cè)到ADO代理池，可以看到代理也出現(xiàn)在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在行動(dòng)  

如上所述，ScaledObject是在事件源和部署之間創(chuàng)建映射的對(duì)象。現(xiàn)在，將使用Azure管道觸發(fā)器和TriggerAuthentication創(chuàng)建ScaledObject，以允許KEDA在狀態(tài)集中縮放pod。  

參考官方頁面可以了解ScaledObject的所有參數(shù)。

一旦創(chuàng)建了ScaledObject，KEDA將自動(dòng)同步配置，并開始監(jiān)視上面創(chuàng)建的azp-agent Statefulset。KEDA使用所需的配置無縫地創(chuàng)建一個(gè)HPA對(duì)象，并基于通過ScaledObject提供的觸發(fā)器規(guī)則(在本例中，它的隊(duì)列長(zhǎng)度為‘1’)縮放副本。  

現(xiàn)在，將對(duì)回購進(jìn)行一些提交，以排隊(duì)一些構(gòu)建。

因此，可以看到KEDA在azp-agent Statefulset中縮放了pod的數(shù)量，這些pod將被注冊(cè)到代理池中，并承擔(dān)隊(duì)列上的掛起作業(yè)

KEDA擁有50多個(gè)縮放器，可以使用不同類型的事件源事件來驅(qū)動(dòng)自動(dòng)縮放，并且它還在繼續(xù)添加更多的縮放器。因此，它絕對(duì)是一個(gè)可用于基于事件的自動(dòng)縮放的生產(chǎn)級(jí)應(yīng)用程序。

原文標(biāo)題：??Autoscale Azure Pipeline Agents With KEDA??，作者：Basudeba Mandal