Integrieren von KEDA in Ihren Azure Kubernetes Service-Cluster

Artikel
11/05/2024

KEDA ist ein Kubernetes-basiertes ereignisgesteuertes Tool für Autoskalierung. MIT KEDA können Sie die Skalierung eines beliebigen Containers in Kubernetes basierend auf der zu verarbeitenden Last steuern, indem Sie Metriken von Systemen wie Prometheus abfragen. Integrieren Sie KEDA in Ihren Azure Kubernetes Service (AKS)-Cluster, um Ihre Workloads basierend auf Prometheus-Metriken aus Ihrem Azure Monitor-Arbeitsbereich heraus zu skalieren.

Um KEDA in Azure Kubernetes Service zu integrieren, müssen Sie eine Workload- oder Podidentität in Ihrem Cluster bereitstellen und konfigurieren. Die Identität ermöglicht KEDA, sich bei Azure zu authentifizieren und Metriken für die Skalierung aus Ihrem Monitor-Arbeitsbereich heraus abzurufen.

In diesem Artikel werden die Schritte zum Integrieren von KEDA in Ihren AKS-Cluster mithilfe einer Workloadidentität beschrieben.

Hinweis

Wir empfehlen die Verwendung der Microsoft Entra Workload ID. Diese Authentifizierungsmethode ersetzt verwaltete Podidentitäten (Vorschauversion), die in die nativen Kubernetes-Funktionen integriert werden, um im Namen der Anwendung einen Verbund mit externen Identitätsanbietern einzugehen.

Die über Pods verwaltete Open-Source-Identität von Microsoft Entra (Vorschau) in Azure Kubernetes Service wurde zum 24.10.2022 eingestellt, und das Projekt wird im September 2023 archiviert. Weitere Informationen finden Sie im Hinweis zur Einstellung. Das Add-On für verwaltete Identitäten in AKS wird im September 2023 eingestellt.

Azure Managed Prometheus wird ab KEDA v2.10 unterstützt. Wenn Sie eine ältere Version von KEDA installiert haben, müssen Sie ein Upgrade durchführen, um mit Azure Managed Prometheus arbeiten zu können.

Voraussetzungen

AKS-Cluster (Azure Kubernetes Service)
Prometheus sendet Metriken an einen Azure Monitor-Arbeitsbereich. Weitere Informationen finden Sie unter Verwalteter Azure Monitor-Dienst für Prometheus.

Einrichten einer Workload-Identität

Richten Sie zunächst einige Umgebungsvariablen ein. Ändern Sie die Werte so, dass Sie Ihrem AKS-Cluster entsprechen.
```
export RESOURCE_GROUP="rg-keda-integration"
export LOCATION="eastus"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="keda-int-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="kedaFedIdentity" 
export SERVICE_ACCOUNT_NAMESPACE="keda"
export SERVICE_ACCOUNT_NAME="keda-operator"
export AKS_CLUSTER_NAME="aks-cluster-name"
```
- SERVICE_ACCOUNT_NAME – KEDA muss das Dienstkonto verwenden, das zum Erstellen von Verbundanmeldeinformationen verwendet wurde. Dabei kann es sich um einen beliebigen benutzerdefinierten Namen handeln.
- AKS_CLUSTER_NAME– Der Name des AKS-Clusters, in dem Sie KEDA bereitstellen möchten.
- SERVICE_ACCOUNT_NAMESPACE Sowohl KEDA als auch das Dienstkonto müssen sich im selben Namespace befinden.
- USER_ASSIGNED_IDENTITY_NAME ist der Name der Microsoft Entra-Identität, die für KEDA erstellt wird.
- FEDERATED_IDENTITY_CREDENTIAL_NAME ist der Name der Anmeldeinformationen, die für KEDA erstellt werden, um sich bei Azure zu authentifizieren.
Wenn Ihr AKS-Cluster nicht mit aktivierter Workloadidentität oder dem OICD-Zertifikataussteller erstellt wurde, müssen Sie ihn aktivieren. Wenn Sie sich nicht sicher sind, können Sie den folgenden Befehl ausführen, um zu überprüfen, ob er aktiviert ist.
```
az aks show --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query oidcIssuerProfile
az aks show --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query securityProfile.workloadIdentity
```
Führen Sie den folgenden Befehl aus, um die Workloadidentität und den OICD-Zertifikataussteller zu aktivieren.
```
az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer
```

Speichern Sie die OIDC-Zertifikataussteller-URL in einer Umgebungsvariable, um sie später verwenden zu können.

export AKS_OIDC_ISSUER="$(az aks show -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv)"

Erstellen Sie eine benutzerseitig zugewiesene Identität für KEDA. Diese Identität wird von KEDA verwendet, um sich bei Azure Monitor zu authentifizieren.

 az identity create --name $USER_ASSIGNED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --location $LOCATION --subscription $SUBSCRIPTION

Die Ausgabe sieht etwa wie folgt aus:

{
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-keda-integration/providers/Microsoft.    ManagedIdentity/userAssignedIdentities/keda-int-identity",
  "location": "eastus",
  "name": "keda-int-identity",
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "resourceGroup": "rg-keda-integration",
  "systemData": null,
  "tags": {},
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Speichern Sie die clientId und tenantId in Umgebungsvariablen, um sie später verwenden zu können.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query 'clientId' -otsv)"
export TENANT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query 'tenantId' -otsv)"

Weisen Sie der Identität für Ihren Azure Monitor-Arbeitsbereich die Rolle Überwachungsdatenleser zu. Mit dieser Rolle kann die Identität Metriken aus Ihrem Arbeitsbereich lesen. Ersetzen Sie die Ressourcengruppe des Azure Monitor-Arbeitsbereichs und den Namen des Azure Monitor-Arbeitsbereichs durch die Ressourcengruppe und den Namen des Azure Monitor-Arbeitsbereichs, der zum Sammeln von Metriken aus dem AKS-Cluster konfiguriert ist.
```
az role assignment create \
--assignee $USER_ASSIGNED_CLIENT_ID \
--role "Monitoring Data Reader" \
--scope /subscriptions/$SUBSCRIPTION/resourceGroups/<Azure Monitor Workspace resource group>/providers/microsoft.monitor/accounts/<Azure monitor workspace name>
```

Erstellen Sie den KEDA-Namespace, und erstellen Sie dann ein Kubernetes-Dienstkonto. Dieses Dienstkonto wird von KEDA zur Authentifizierung bei Azure verwendet.


az aks get-credentials -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP

kubectl create namespace keda

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $USER_ASSIGNED_CLIENT_ID
  name: $SERVICE_ACCOUNT_NAME
  namespace: $SERVICE_ACCOUNT_NAMESPACE
EOF

Überprüfen Sie Ihr Dienstkonto, indem Sie Folgendes ausführen
```
kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda
```
Richten Sie Verbundanmeldeinformationen zwischen dem Dienstkonto und der benutzerseitig zugewiesenen Identität ein. Die Verbundanmeldeinformationen ermöglichen es dem Dienstkonto, die benutzerseitig zugewiesene Identität für die Authentifizierung bei Azure zu verwenden.
```
az identity federated-credential create --name $FEDERATED_IDENTITY_CREDENTIAL_NAME --identity-name $USER_ASSIGNED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --issuer $AKS_OIDC_ISSUER --subject     system:serviceaccount:$SERVICE_ACCOUNT_NAMESPACE:$SERVICE_ACCOUNT_NAME --audience api://AzureADTokenExchange
```
Hinweis

Es dauert einige Sekunden, bis die Verbundidentitäts-Anmeldeinformationen nach dem erstmaligen Hinzufügen weitergegeben werden. Wenn eine Tokenanforderung unmittelbar nach dem Hinzufügen der Verbundidentitäts-Anmeldeinformationen erfolgt, kann dies einige Minuten lang zu Fehlern führen, da der Cache im Verzeichnis noch mit alten Daten gefüllt wird. Um dieses Problem zu vermeiden, können Sie eine kleine Verzögerung nach dem Hinzufügen der Verbundidentitäts-Anmeldeinformationen hinzufügen.

Bereitstellen von KEDA

KEDA kann mithilfe von YAML-Manifesten, Helm-Diagrammen oder Operator Hub bereitgestellt werden. In diesem Artikel werden Helm-Diagramme verwendet. Weitere Informationen zum Bereitstellen von KEDA finden Sie unter Bereitstellen von KEDA.

Hinzufügen des Helm-Repositorys:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

Bereitstellen von KEDA mithilfe des folgenden Befehls:

helm install keda kedacore/keda --namespace keda \
--set serviceAccount.create=false \
--set serviceAccount.name=keda-operator \
--set podIdentity.azureWorkload.enabled=true \
--set podIdentity.azureWorkload.clientId=$USER_ASSIGNED_CLIENT_ID \
--set podIdentity.azureWorkload.tenantId=$TENANT_ID

Überprüfen Sie Ihre Bereitstellung, indem Sie den folgenden Befehl ausführen.

kubectl get pods -n keda

Die Ausgabe sieht etwa wie folgt aus:

NAME                                               READY   STATUS    RESTARTS       AGE
keda-admission-webhooks-ffcb8f688-kqlxp            1/1     Running   0              4m
keda-operator-5d9f7d975-mgv7r                      1/1     Running   1 (4m ago)     4m
keda-operator-metrics-apiserver-7dc6f59678-745nz   1/1     Running   0              4m

Skalierungsmodule

Skalierungsmodule definieren, wie und wann KEDA eine Bereitstellung skalieren soll. KEDA unterstützt eine Vielzahl von Skalierungsmodulen. Weitere Informationen zu Skalierungsmodulen finden Sie unter Skalierungsmodule. Azure Managed Prometheus nutzt ein bereits vorhandenes Prometheus-Skalierungsmodul, um Prometheus-Metriken aus dem Azure Monitor-Arbeitsbereich abzurufen. Die folgende YAML-Datei ist ein Beispiel für die Verwendung von Azure Managed Prometheus.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-managed-prometheus-trigger-auth
spec:
  podIdentity:
      provider: azure-workload | azure # use "azure" for pod identity and "azure-workload" for workload identity
      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-managed-prometheus-scaler
spec:
  scaleTargetRef:
    name: deployment-name-to-be-scaled
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://test-azure-monitor-workspace-name-1234.eastus.prometheus.monitor.azure.com
      metricName: http_requests_total
      query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response
      threshold: '100.50'
      activationThreshold: '5.5'
    authenticationRef:
      name: azure-managed-prometheus-trigger-auth

serverAddress ist der Abfrageendpunkt Ihres Azure Monitor-Arbeitsbereichs. Weitere Informationen finden Sie unter Abfragen von Prometheus-Metriken mithilfe der API und PromQL.
metricName ist der Name der Metrik, auf die Sie skalieren möchten.
query ist die Abfrage, die zum Abrufen der Metrik verwendet wird.
threshold ist der Wert, mit dem die Bereitstellung skaliert wird.
Legen Sie podIdentity.provider entsprechend dem Typ der verwendeten Identität fest.

Problembehandlung

Der folgende Abschnitt enthält Tipps zur Behandlung gängiger Probleme.

Verbundanmeldeinformationen

Die Verbreitung von Verbundanmeldeinformationen kann bis zu 10 Minuten dauern. Wenn Sie Probleme mit der KEDA-Authentifizierung bei Azure haben, führen Sie die folgenden Schritte aus.

Der folgende Protokollauszug zeigt einen Fehler bei den Verbundanmeldeinformationen.

kubectl logs -n keda keda-operator-5d9f7d975-mgv7r

{
 \"error\": \"unauthorized_client\",\n  \"error_description\": \"AADSTS70021: No matching federated identity record found for presented assertion. 
Assertion Issuer: 'https://eastus.oic.prod-aks.azure.com/abcdef01-2345-6789-0abc-def012345678/12345678-abcd-abcd-abcd-1234567890ab/'.
Assertion Subject: 'system:serviceaccount:keda:keda-operator'. 
Assertion Audience: 'api://AzureADTokenExchange'. https://docs.microsoft.com/azure/active-directory/develop/workload-identity-federation
Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\\r\\nCorrelation ID: 1111bbbb-22cc-dddd-ee33-ffffff444444\\r\\nTimestamp: 2023-05-30 11:11:53Z\",
\"error_codes\": [\n    70021\n  ],\n  \"timestamp\": \"2023-05-30 11:11:53Z\",
\"trace_id\": \"2222cccc-33dd-eeee-ff44-aaaaaa555555\",
\"correlation_id\": \"aaaa0000-bb11-2222-33cc-444444dddddd\",
\"error_uri\": \"https://login.microsoftonline.com/error?code=70021\"\n}
\n--------------------------------------------------------------------------------\n"}

Überprüfen Sie die Werte, die zum Erstellen des ServiceAccounts und der mit az identity federated-credential create erstellten Anmeldeinformationen verwendet werden, und stellen Sie sicher, dass der subject-Wert dem system:serviceaccount-Wert entspricht.

Azure Monitor-Arbeitsbereich (Berechtigungen)

Wenn Sie Probleme mit der KEDA-Authentifizierung bei Azure haben, überprüfen Sie die Berechtigungen für den Azure Monitor-Arbeitsbereich. Der folgende Protokollauszug zeigt, dass die Identität keine Leseberechtigungen für den Azure Monitor-Arbeitsbereich hat.

kubectl logs -n keda keda-operator-5d9f7d975-mgv7r

2023-05-30T11:15:45Z    ERROR   scale_handler   error getting metric for scaler 
{"scaledObject.Namespace": "default", "scaledObject.Name": "azure-managed-prometheus-scaler", "scaler": "prometheusScaler", 
"error": "prometheus query api returned error. status: 403 response: {\"status\":\"error\",
\"errorType\":\"Forbidden\",\"error\":\"User \\u0027abc123ab-1234-1234-abcd-abcdef123456
\\u0027 does not have access to perform any of the following actions 
\\u0027microsoft.monitor/accounts/data/metrics/read, microsoft.monitor/accounts/data/metrics/read
\\u0027 on resource \\u0027/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-azmon-ws-01/providers/microsoft.monitor/accounts/azmon-ws-01\\u0027. RequestId: 123456c427f348258f3e5aeeefef834a\"}"}

Stellen Sie sicher, dass die Identität die RolleMonitoring Data Reader im Azure Monitor-Arbeitsbereich hat.

Freigeben über