Intégrer KEDA à votre cluster Azure Kubernetes Service

Article
11/05/2024

KEDA est un outil de mise à l’échelle automatique en fonction des événements basé sur Kubernetes. KEDA vous permet de piloter la mise à l’échelle de n’importe quel conteneur dans Kubernetes en fonction de la charge à traiter, et cela en interrogeant les métriques à partir de systèmes tels que Prometheus. Intégrez KEDA à votre cluster Azure Kubernetes Service (AKS) pour mettre à l’échelle vos charges de travail en fonction des métriques Prometheus de votre espace de travail Azure Monitor.

Pour intégrer KEDA à votre Azure Kubernetes Service, vous devez déployer et configurer une identité de charge de travail ou de pod sur votre cluster. L’identité permet à KEDA de s’authentifier auprès d’Azure et de récupérer des métriques pour la mise à l’échelle à partir de votre espace de travail Monitor.

Cet article vous guide tout au long des étapes d’intégration de KEDA à votre cluster AKS à l’aide d’une identité de charge de travail.

Remarque

Nous vous recommandons d’utiliser l’identifiant de charge de travail Microsoft Entra. Cette méthode d’authentification remplace l’identité managée par pod (préversion), qui s’intègre avec les fonctionnalités natives Kubernetes pour opérer une fédération avec tout fournisseur d’identité externe, au nom de l’application.

L’identité managée par pod Microsoft Entra open source (préversion) dans Azure Kubernetes Service est déconseillée depuis le 10/24/2022 et le projet sera archivé en septembre 2023. Si vous souhaitez obtenir plus d’informations, voir l’avis de dépréciation officiel. Le module complémentaire managé AKS commence à être déprécié en septembre 2023.

La prise en charge d’Azure Managed Prometheus commence à partir de KEDA v2.10. Si vous avez installé une version antérieure de KEDA, vous devez effectuer une mise à niveau pour pouvoir utiliser Azure Managed Prometheus.

Prérequis

Un cluster Azure Kubernetes Service (AKS)
Prometheus envoie des métriques à un espace de travail Azure Monitor. Pour plus d'informations, consultez le service de gestion Azure Monitor pour Prometheus.

Configurer une identité de charge de travail

Commencez par configurer certaines variables d’environnement. Modifiez les valeurs en fonction de votre cluster AKS.
```
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 doit utiliser le compte de service qui a servi pour créer des informations d’identification fédérées. Il peut s’agir de n’importe quelle valeur définie par l’utilisateur.
- AKS_CLUSTER_NAME- Nom du cluster AKS dans lequel vous souhaitez déployer KEDA.
- SERVICE_ACCOUNT_NAMESPACE KEDA et le compte de service doivent se trouver dans le même espace de noms.
- USER_ASSIGNED_IDENTITY_NAME est le nom de l’identité Microsoft Entra créée pour KEDA.
- FEDERATED_IDENTITY_CREDENTIAL_NAME est le nom des informations d’identification créées par KEDA pour l’authentification auprès d’Azure.
Si votre cluster AKS n’a pas été créé avec workload-identity ou oidc-issuer activé, vous devez l’activer. Si vous n’en êtes pas sûr, vous pouvez exécuter la commande suivante pour vérifier s’il est activé.
```
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
```
Pour activer l’identité de charge de travail et oidc-issuer, exécutez la commande suivante.
```
az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer
```

Stockez l’URL de l’émetteur OIDC dans une variable d’environnement à utiliser ultérieurement.

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

Créez une identité affectée par l’utilisateur pour KEDA. Cette identité est utilisée par KEDA pour s’authentifier auprès d’Azure Monitor.

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

Vous devez obtenir un résultat semblable à ce qui suit :

{
  "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"
}

Stockez clientId et tenantId dans des variables d’environnement à utiliser ultérieurement.

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)"

Attribuez le rôle Lecteur de données de surveillance à l’identité de votre espace de travail Azure Monitor. Ce rôle permet à l’identité de lire les métriques de votre espace de travail. Remplacez le groupe de ressources de l’espace de travail Azure Monitor et le nom de l’espace de travail Azure Monitor par le groupe de ressources et le nom de l’espace de travail Azure Monitor configurés pour collecter des métriques à partir du cluster AKS.
```
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>
```

Créez l’espace de noms KEDA, puis un compte de service Kubernetes. Ce compte de service est utilisé par KEDA pour s’authentifier auprès d’Azure.


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

Vérifier votre compte de service en exécutant

kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda

Établissez des informations d’identification fédérées entre le compte de service et l’identité affectée par l’utilisateur. Les informations d’identification fédérées permettent au compte de service d’utiliser l’identité affectée par l’utilisateur pour s’authentifier auprès d’Azure.
```
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
```
Notes

Il faut quelques secondes pour que les informations d’identification d’identité fédérée soient propagées après avoir été ajoutées initialement. Si une requête de jeton est effectuée immédiatement après l’ajout des informations d’identification d’identité fédérée, cela peut entraîner un échec pendant quelques minutes, car le cache est rempli dans le répertoire avec d’anciennes données. Pour éviter ce problème, vous pouvez ajouter un léger délai après l’ajout des informations d’identification d’identité fédérée.

Déployer KEDA

KEDA peut être déployé à l’aide de manifestes YAML, de graphiques Helm ou du hub opérateur. Cet article utilise des graphiques Helm. Pour plus d’informations sur le déploiement de KEDA, consultez Déploiement de KEDA

Ajoutez un référentiel Helm :

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

Déployez KEDA à l’aide de la commande suivante :

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

Vérifiez votre déploiement en exécutant la commande suivante.

kubectl get pods -n keda

Vous devez obtenir un résultat semblable à ce qui suit :

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

Outils de mise à l’échelle

Les outils de mise à l'échelle définissent comment et quand KEDA doit mettre à l’échelle un déploiement. KEDA prend en charge divers outils de mise à l'échelle. Pour plus d’informations sur les outils de mise à l’échelle, consultez Outils de mise à l’échelle. Azure Managed Prometheus utilise l’outil de mise à l'échelle Prometheus existant pour récupérer des métriques Prometheus à partir de l’espace de travail Azure Monitor. Le fichier yaml suivant est un exemple d’utilisation d’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 est le point de terminaison de requête de votre espace de travail Azure Monitor. Pour plus d’informations, consultez Interroger les métriques Prometheus avec l’API et PromQL
metricName est le nom de la métrique sur laquelle vous souhaitez effectuer une mise à l’échelle.
query est la requête utilisée pour récupérer la métrique.
threshold est la valeur à laquelle le déploiement est mis à l’échelle.
Définissez podIdentity.provider en fonction du type d’identité que vous utilisez.

Dépannage

La section suivante fournit des conseils de résolution des problèmes courants.

Informations d’identification fédérées

La propagation des informations d’identification fédérées peut prendre jusqu’à 10 minutes. Si vous rencontrez des problèmes avec l’authentification KEDA auprès d’Azure, essayez les étapes suivantes.

L’extrait de journal suivant montre une erreur avec les informations d’identification fédérées.

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"}

Vérifiez les valeurs utilisées pour créer le ServiceAccount et les informations d’identification créées avec az identity federated-credential create et vérifiez que la valeur de subject correspond à celle de system:serviceaccount.

Autorisations d’espace de travail Azure Monitor

Si vous rencontrez des problèmes avec l’authentification KEDA auprès d’Azure, vérifiez les autorisations de l’espace de travail Azure Monitor. L’extrait de journal suivant montre que l’identité n’a pas d’autorisations de lecture pour l’espace de travail Azure Monitor.

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\"}"}

Vérifiez que l’identité a le rôle Monitoring Data Reader dans l’espace de travail Azure Monitor.

Partager via