譯者 | 李睿

審校 | 孫淑娟

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

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

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

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

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

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

架構和概念

KEDA由兩個組件組成，用于控制pods/工作負載的自動縮放。  

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

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

縮放器：KEDA的真正力量在于大量的縮放器。縮放器是一個豐富的信息源，因為它提供外部數(shù)據(jù)/事件，并允許基于外部數(shù)據(jù)進行縮放。如今，它支持50多個具有特定支持觸發(fā)器的縮放器，如Azure Pipeline（觸發(fā)器：Azure Pipeline）和Kafka（觸發(fā)器：Kafka Topics），并且還有更多功能。

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

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

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

用例

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

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

先決條件

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

安裝Azure管道代理  

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

現(xiàn)在驗證代理已成功注冊到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在行動  

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

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

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

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

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

KEDA擁有50多個縮放器，可以使用不同類型的事件源事件來驅動自動縮放，并且它還在繼續(xù)添加更多的縮放器。因此，它絕對是一個可用于基于事件的自動縮放的生產級應用程序。

原文標題：??Autoscale Azure Pipeline Agents With KEDA??，作者：Basudeba Mandal