Compartir a través de


Integración de KEDA con el clúster de Azure Kubernetes Service

KEDA es un escalador automático controlado por eventos basado en Kubernetes. KEDA le permite controlar el escalado de cualquier contenedor de Kubernetes en función de la carga que se va a procesar mediante la consulta de métricas de sistemas como Prometheus. Integre KEDA con el clúster de Azure Kubernetes Service (AKS) para escalar las cargas de trabajo en función de las métricas de Prometheus del área de trabajo de Azure Monitor.

Para integrar KEDA en Azure Kubernetes Service, debe implementar y configurar una identidad de carga de trabajo o una identidad de pod en el clúster. La identidad permite que KEDA se autentique con Azure y recupere métricas para el escalado desde el área de trabajo de Monitor.

En este artículo, se describen los pasos para integrar KEDA en el clúster de AKS mediante una identidad de carga de trabajo.

Nota:

Se recomienda usar Microsoft Entra Workload ID. Este método de autenticación reemplaza la identidad administrada por pod (versión preliminar), que se integra con las funcionalidades nativas de Kubernetes para federarse con cualquier proveedor de identidades externo en beneficio de la aplicación.

La identidad administrada por pods de Microsoft Entra de código abierto (versión preliminar) en Azure Kubernetes Service ha quedado en desuso desde el 24/10/2022 y el proyecto se archivará en septiembre de 2023. Para obtener más información, consulte el aviso de desuso. El complemento administrado de AKS comienza a quedar en desuso en septiembre de 2023.

La compatibilidad con Azure Managed Prometheus comienza a partir de KEDA v2.10. Si tiene instalada una versión anterior de KEDA, debe realizar una actualización para poder trabajar con Azure Managed Prometheus.

Requisitos previos

Configuración de una identidad de carga de trabajo

  1. Empiece por configurar algunas variables de entorno. Cambie los valores para que se adapten a su clúster de 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 debe usar la cuenta de servicio que se ha usado para crear credenciales federadas. Puede ser cualquier nombre definido por el usuario.
    • AKS_CLUSTER_NAME: el nombre del clúster de AKS donde desea implementar KEDA.
    • SERVICE_ACCOUNT_NAMESPACE Tanto KEDA como la cuenta de servicio deben estar en el mismo espacio de nombres.
    • USER_ASSIGNED_IDENTITY_NAME es el nombre de la identidad de Microsoft Entra que se crea para KEDA.
    • FEDERATED_IDENTITY_CREDENTIAL_NAME es el nombre de la credencial que se crea para que KEDA se use para autenticarse con Azure.
  2. Si el clúster de AKS no se ha creado con workload-identity u oidc-issuer habilitado, deberá habilitarlo. Si no está seguro, puede ejecutar el siguiente comando para comprobar si está habilitado.

    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
    

    Para habilitar la identidad de carga de trabajo y oidc-issuer, ejecute el siguiente comando.

    az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer
    
  3. Almacene la dirección URL del emisor de OIDC en una variable de entorno que se usará más adelante.

    export AKS_OIDC_ISSUER="$(az aks show -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv)"
    
  4. Cree una identidad asignada por el usuario para KEDA. KEDA usa esta identidad para autenticarse con Azure Monitor.

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

    El resultado será similar al siguiente:

    {
      "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"
    }
    
  5. Almacene clientId y tenantId en variables de entorno para usarlos más adelante.

    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)"
    
  6. Asigne el rol Lector de datos de supervisión a la identidad del área de trabajo de Azure Monitor. Este rol permite que la identidad lea las métricas del área de trabajo. Reemplace el grupo de recursos del área de trabajo de Azure Monitor y el nombre del área de trabajo de Azure Monitor por el grupo de recursos y el nombre del área de trabajo de Azure Monitor que se ha configurado para recopilar métricas del clúster de 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>
    
  7. Cree el espacio de nombres KEDA y, después, cree una cuenta de servicio de Kubernetes. KEDA usa esta cuenta de servicio para autenticarse con 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
    
  8. Compruebe la cuenta de servicio mediante la ejecución de

    kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda
    
  9. Establezca una credencial federada entre la cuenta de servicio y la identidad asignada por el usuario. La credencial federada permite que la cuenta de servicio use la identidad asignada por el usuario para autenticarse con 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
    

    Nota

    La credencial de identidad federada tarda unos segundos en propagarse después de agregarse inicialmente. Si una solicitud de token se realiza inmediatamente después de agregar la credencial de identidad federada, podría provocar un error durante un par de minutos, ya que la memoria caché se rellena en el directorio con datos antiguos. Para evitar este problema, puede agregar un ligero retraso después de agregar la credencial de identidad federada.

Implementación de KEDA

KEDA se puede implementar mediante manifiestos de YAML, gráficos de Helm o centro de operadores. En este artículo, se usan gráficos de Helm. Para más información sobre la implementación de KEDA, consulte Implementación de KEDA

Agregar repositorio de Helm:

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

Implemente KEDA con el siguiente comando:

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

Para comprobar la implementación, ejecute el siguiente comando.

kubectl get pods -n keda

El resultado será similar al siguiente:

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

Escaladores

Los escaladores definen cómo y cuándo KEDA debe escalar una implementación. KEDA admite una variedad de escaladores. Para más información sobre los escaladores, consulte Escaladores. Prometheus administrado por Azure usa el escalador de Prometheus existente para recuperar las métricas de Prometheus del área de trabajo de Azure Monitor. El siguiente archivo YAML es un ejemplo del uso de 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 es el punto de conexión de consulta del área de trabajo de Azure Monitor. Para más información, consulte Consulta de métricas de Prometheus mediante la API y PromQL
  • metricName es el nombre de la métrica en la que desea escalar.
  • query es la consulta que se usa para recuperar la métrica.
  • threshold es el valor en el que se escala la implementación.
  • Establezca podIdentity.provider según el tipo de identidad que está usando.

Solución de problemas

En la sección siguiente, se proporcionan sugerencias para solucionar problemas comunes.

Credenciales federadas

Las credenciales federadas pueden tardar hasta 10 minutos en propagarse. Si tiene problemas con la autenticación de KEDA con Azure, pruebe los pasos siguientes.

El siguiente extracto de registro muestra un error con las credenciales federadas.

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

Compruebe los valores usados para crear la ServiceAccount y las credenciales creadas con az identity federated-credential create y asegúrese de que el valor subject coincide con el valor system:serviceaccount.

Permisos del área de trabajo de Azure Monitor

Si tiene problemas con la autenticación de KEDA con Azure, compruebe los permisos para el área de trabajo de Azure Monitor. En el siguiente extracto de registro, se muestra que la identidad no tiene permisos de lectura para el área de trabajo de 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\"}"}

Asegúrese de que la identidad tiene el rol Monitoring Data Reader en el área de trabajo de Azure Monitor.