Интеграция KEDA с кластером Служба Azure Kubernetes

KEDA — это средство автомасштабирования на основе Kubernetes. KEDA позволяет управлять масштабированием любого контейнера в Kubernetes на основе загрузки, запрашивая метрики из таких систем, как Prometheus. Интеграция KEDA с кластером Служба Azure Kubernetes (AKS) для масштабирования рабочих нагрузок на основе метрик Prometheus из рабочей области Azure Monitor.

Чтобы интегрировать KEDA в Служба Azure Kubernetes, необходимо развернуть и настроить удостоверение рабочей нагрузки или удостоверение pod в кластере. Удостоверение позволяет KEDA проходить проверку подлинности в Azure и получать метрики для масштабирования из рабочей области Monitor.

В этой статье описывается, как интегрировать KEDA в кластер AKS с помощью удостоверения рабочей нагрузки.

Примечание.

Мы рекомендуем использовать Идентификация рабочей нагрузки Microsoft Entra. Этот метод проверки подлинности заменяет управляемое pod удостоверение (предварительная версия), которое интегрируется с собственными возможностями Kubernetes для федерации с любыми внешними поставщиками удостоверений от имени приложения.

Открытый код управляемое модулем Microsoft Entra pod (предварительная версия) в Служба Azure Kubernetes устарело с 10.24.2022, и проект будет архивирован в сентябре 2023 года. Дополнительные сведения см. в уведомлении об отмене. В сентябре 2023 г. в управляемой надстройке AKS начинается отключение.

Поддержка Управляемого Prometheus Azure начинается с KEDA версии 2.10. Если у вас установлена более ранняя версия KEDA, необходимо обновить для работы с Управляемым Prometheus Azure.

Необходимые компоненты

Настройка удостоверения рабочей нагрузки

  1. Начните с настройки некоторых переменных среды. Измените значения, чтобы соответствовать кластеру 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 должен использовать учетную запись службы, которая использовалась для создания федеративных учетных данных. Это может быть любое определяемое пользователем имя.
    • AKS_CLUSTER_NAME— Имя кластера AKS, в котором требуется развернуть KEDA.
    • SERVICE_ACCOUNT_NAMESPACE Как KEDA, так и учетная запись службы должны находиться в одном пространстве имен.
    • USER_ASSIGNED_IDENTITY_NAME — это имя удостоверения Microsoft Entra, созданного для KEDA.
    • FEDERATED_IDENTITY_CREDENTIAL_NAME — это имя учетных данных, созданных для KEDA для проверки подлинности в Azure.
  2. Если кластер AKS не был создан с включенным идентификатором рабочей нагрузки или издателем oidc,необходимо включить его. Если вы не уверены, выполните следующую команду, чтобы проверка, если она включена.

    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
    

    Чтобы включить удостоверение рабочей нагрузки и издателя oidc, выполните следующую команду.

    az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer
    
  3. Сохраните URL-адрес издателя OIDC в переменной среды, которая будет использоваться позже.

    export AKS_OIDC_ISSUER="$(az aks show -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv)"
    
  4. Создайте удостоверение, назначаемое пользователем для KEDA. Это удостоверение используется KEDA для проверки подлинности с помощью Azure Monitor.

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

    Результат будет выглядеть примерно так:

    {
      "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"
    }
    
  5. Сохраните clientIdtenantId и в переменных среды, которые будут использоваться позже.

    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. Назначьте роль средства чтения данных мониторинга удостоверения рабочей области Azure Monitor. Эта роль позволяет удостоверению считывать метрики из рабочей области. Замените группу ресурсов Azure Monitor и имя рабочей области Azure Monitor на группу ресурсов и имя рабочей области Azure Monitor, настроенную для сбора метрик из кластера 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. Создайте пространство имен KEDA, а затем создайте учетную запись службы Kubernetes. Эта учетная запись службы используется KEDA для проверки подлинности в 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. Проверьте учетную запись службы, выполнив команду

    kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda
    
  9. Установите федеративные учетные данные между учетной записью службы и назначенным пользователем удостоверением. Федеративные учетные данные позволяют учетной записи службы использовать назначенное пользователем удостоверение для проверки подлинности в 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
    

    Примечание.

    Для распространения учетных данных федеративного удостоверения после первоначального добавления потребуется несколько секунд. Если запрос маркера выполняется сразу после добавления учетных данных федеративного удостоверения, он может привести к сбою в течение нескольких минут, так как кэш заполняется в каталоге старыми данными. Чтобы избежать этой проблемы, можно добавить небольшую задержку после добавления учетных данных федеративного удостоверения.

Развертывание KEDA

KEDA можно развернуть с помощью манифестов YAML, диаграмм Helm или Концентратора операторов. В этой статье используются диаграммы Helm. Дополнительные сведения о развертывании KEDA см. в разделе "Развертывание KEDA"

Добавьте репозиторий helm:

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

Разверните KEDA с помощью следующей команды:

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

Проверьте развертывание, выполнив следующую команду.

kubectl get pods -n keda

Результат будет выглядеть примерно так:

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

Масштабировщики

Масштабировщики определяют, как и когда KEDA должен масштабировать развертывание. KEDA поддерживает множество масштабируемых средств. Дополнительные сведения о масштабировщиках см. в разделе Scalers. Управляемый Prometheus Azure использует уже существующий масштабировщик Prometheus для получения метрик Prometheus из рабочей области Azure Monitor. Следующий yaml-файл является примером использования Управляемого Prometheus Azure.

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 — это конечная точка запроса рабочей области Azure Monitor. Дополнительные сведения см. в разделе "Метрики запроса Prometheus" с помощью API и PromQL
  • metricName — это имя метрики, которую вы хотите масштабировать.
  • query — это запрос, используемый для получения метрики.
  • threshold — это значение, с помощью которого масштабируется развертывание.
  • Задайте в podIdentity.provider соответствии с типом используемого удостоверения.

Устранение неполадок

В следующем разделе приведены советы по устранению распространенных проблем.

Федеративные учетные данные

Федеративные учетные данные могут занять до 10 минут. Если у вас возникли проблемы с проверкой подлинности KEDA в Azure, выполните следующие действия.

В следующем фрагменте журнала отображается ошибка с федеративными учетными данными.

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

Проверьте значения, используемые для создания ServiceAccount и учетных данных, созданных с az identity federated-credential create помощью, и убедитесь, что subject значение соответствует значению system:serviceaccount .

Разрешения рабочей области Azure Monitor

Если у вас возникли проблемы с проверкой подлинности KEDA с помощью Azure, проверка разрешения для рабочей области Azure Monitor. В следующем фрагменте журнала показано, что удостоверение не имеет разрешений на чтение для рабочей области 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\"}"}

Убедитесь, что удостоверение имеет Monitoring Data Reader роль в рабочей области Azure Monitor.