Intégrer KEDA à votre cluster Azure Kubernetes Service
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_NAMESPACEKEDA et le compte de service doivent se trouver dans le même espace de noms.USER_ASSIGNED_IDENTITY_NAMEest le nom de l’identité Microsoft Entra créée pour KEDA.FEDERATED_IDENTITY_CREDENTIAL_NAMEest 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.workloadIdentityPour 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-issuerStockez 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 $SUBSCRIPTIONVous devez obtenir un résultat semblable à ce qui suit :
{ "clientId": "abcd1234-abcd-abcd-abcd-9876543210ab", "id": "/subscriptions/abcdef01-2345-6789-0abc-def012345678/resourcegroups/rg-keda-integration/providers/Microsoft. ManagedIdentity/userAssignedIdentities/keda-int-identity", "location": "eastus", "name": "keda-int-identity", "principalId": "12345678-abcd-abcd-abcd-1234567890ab", "resourceGroup": "rg-keda-integration", "systemData": null, "tags": {}, "tenantId": "1234abcd-9876-9876-9876-abcdef012345", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }Stockez
clientIdettenantIddans 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 EOFVé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://AzureADTokenExchangeNotes
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
serverAddressest 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 PromQLmetricNameest le nom de la métrique sur laquelle vous souhaitez effectuer une mise à l’échelle.queryest la requête utilisée pour récupérer la métrique.thresholdest la valeur à laquelle le déploiement est mis à l’échelle.- Définissez
podIdentity.provideren 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: 12dd9ea0-3a65-408f-a41f-5d0403a25100\\r\\nCorrelation ID: 8a2dce68-17f1-4f11-bed2-4bcf9577f2af\\r\\nTimestamp: 2023-05-30 11:11:53Z\",
\"error_codes\": [\n 70021\n ],\n \"timestamp\": \"2023-05-30 11:11:53Z\",
\"trace_id\": \"12345678-3a65-408f-a41f-5d0403a25100\",
\"correlation_id\": \"12345678-17f1-4f11-bed2-4bcf9577f2af\",
\"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/abcdef01-2345-6789-0abc-def012345678/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.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour