Безопасное масштабирование приложений с помощью удостоверения надстройки KEDA и рабочей нагрузки на Служба Azure Kubernetes (AKS)

Статья
08/02/2024

В этой статье показано, как безопасно масштабировать приложения с помощью надстройки Kubernetes Autoscaling (KEDA) и удостоверений рабочей нагрузки на Служба Azure Kubernetes (AKS).

Внимание

Версия Kubernetes кластера определяет, какая версия KEDA будет установлена в кластере AKS. Сведения о том, какие версии KEDA сопоставляются с каждой версией AKS, см. в столбце управляемых надстроек AKS таблицы версий компонентов Kubernetes.

Для версий GA Kubernetes AKS обеспечивает полную поддержку соответствующей дополнительной версии KEDA в таблице. Предварительные версии Kubernetes и последнее исправление KEDA частично охватываются поддержкой клиентов на основе наилучших усилий. Следовательно, эти функции не предназначены для использования в рабочей среде. Дополнительные сведения доступны в следующих статьях поддержки.

Подготовка к работе

Вам требуется подписка Azure. Если у вас еще нет подписки Azure, вы можете создать бесплатную учетную запись.
Необходимо установить Azure CLI.
Убедитесь, что у вас есть правила брандмауэра, настроенные для предоставления доступа к серверу API Kubernetes. Дополнительные сведения см. в разделе "Правила исходящей сети и полное доменное имя" для кластеров Служба Azure Kubernetes (AKS).

Создание или изменение группы ресурсов

Создайте группу ресурсов с помощью az group create команды. Убедитесь, что значения заполнителей заменяются собственными значениями.
```
LOCATION=<azure-region>
RG_NAME=<resource-group-name>

az group create --name $RG_NAME --location $LOCATION
```

Создание кластера AKS

Создайте кластер AKS с надстройкой KEDA, удостоверением рабочей нагрузки и издателем OIDC, включенным с помощью az aks create команды с --enable-workload-identityфлагами , --enable-kedaи --enable-oidc-issuer флагами. Обязательно замените значение заполнителя собственным значением.
```
AKS_NAME=<cluster-name>

az aks create \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --enable-workload-identity \
    --enable-oidc-issuer \
    --enable-keda \
    --generate-ssh-keys 
```
Проверьте успешное развертывание и убедитесь, что кластер имеет KEDA, удостоверение рабочей нагрузки и издатель OIDC с включенным параметром az aks show флага --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".
```
az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
```

Подключитесь к кластеру az aks get-credentials с помощью команды.

az aks get-credentials \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --overwrite-existing

Создание служебной шины Azure

Создайте пространство имен Служебная шина Azure с помощью az servicebus namespace create команды. Обязательно замените заполнитель собственным значением.
```
SB_NAME=<service-bus-name>
SB_HOSTNAME="${SB_NAME}.servicebus.windows.net"

az servicebus namespace create \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --disable-local-auth
```
Создайте очередь Служебная шина Azure с помощью az servicebus queue create команды. Обязательно замените заполнитель собственным значением.
```
SB_QUEUE_NAME=<service-bus-queue-name>

az servicebus queue create \
    --name $SB_QUEUE_NAME \
    --namespace $SB_NAME \
    --resource-group $RG_NAME
```

Создание управляемого удостоверения

Создайте управляемое удостоверение с помощью az identity create команды. Обязательно замените заполнитель собственным значением.
```
MI_NAME=<managed-identity-name>

MI_CLIENT_ID=$(az identity create \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "clientId" \
    --output tsv)
```
Получите URL-адрес издателя OIDC, используя az aks show команду с установленным oidcIssuerProfile.issuerUrlфлагом--query.
```
AKS_OIDC_ISSUER=$(az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query oidcIssuerProfile.issuerUrl \
    --output tsv)
```
Создайте федеративные учетные данные между управляемым удостоверением и пространством имен и учетной записью службы, используемой рабочей нагрузкой с помощью az identity federated-credential create команды. Обязательно замените заполнитель собственным значением.
```
FED_WORKLOAD=<federated-credential-workload-name>

az identity federated-credential create \
    --name $FED_WORKLOAD \
    --identity-name $MI_NAME \
    --resource-group $RG_NAME \
    --issuer $AKS_OIDC_ISSUER \
    --subject system:serviceaccount:default:$MI_NAME \
    --audience api://AzureADTokenExchange
```
Создайте второй федеративные учетные данные между управляемым удостоверением и пространством имен и учетной записью службы, используемой оператором keda-operator с помощью az identity federated-credential create команды. Обязательно замените заполнитель собственным значением.
```
FED_KEDA=<federated-credential-keda-name>

az identity federated-credential create \
    --name $FED_KEDA \
    --identity-name $MI_NAME \
    --resource-group $RG_NAME \
    --issuer $AKS_OIDC_ISSUER \
    --subject system:serviceaccount:kube-system:keda-operator \
    --audience api://AzureADTokenExchange
```

Создание назначений ролей

Получите идентификатор объекта для управляемого удостоверения с помощью az identity show команды с установленным "principalId"флагом--query.
```
MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)
```
Получите идентификатор ресурса пространства имен служебная шина с помощью az servicebus namespace show команды с установленным "id"флагом--query.
```
SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)
```
Назначьте роль владельца данных Служебная шина Azure управляемому удостоверению с помощью az role assignment create команды.
```
az role assignment create \
    --role "Azure Service Bus Data Owner" \
    --assignee-object-id $MI_OBJECT_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $SB_ID
```

Включение удостоверения рабочей нагрузки в операторе KEDA

После создания федеративных учетных данных для keda-operator ServiceAccount необходимо вручную перезапустить keda-operator модули pod, чтобы убедиться, что переменные среды удостоверений рабочей нагрузки вставляются в модуль pod.
```
kubectl rollout restart deploy keda-operator -n kube-system
```
Подтверждение перезапуска модулей pod keda-operator
```
kubectl get pod -n kube-system -lapp=keda-operator -w
```
Убедившись, что модули pod keda-operator завершили последовательное нажатие Ctrl+c , чтобы разорвать предыдущую команду наблюдения, а затем подтвердите, что переменные среды удостоверений рабочей нагрузки были внедрены.
```
KEDA_POD_ID=$(kubectl get po -n kube-system -l app.kubernetes.io/name=keda-operator -ojsonpath='{.items[0].metadata.name}')
kubectl describe po $KEDA_POD_ID -n kube-system
```

Вы увидите выходные данные, аналогичные приведенным ниже в разделе "Среда".

---
AZURE_CLIENT_ID:
AZURE_TENANT_ID:               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
AZURE_FEDERATED_TOKEN_FILE:    /var/run/secrets/azure/tokens/azure-identity-token
AZURE_AUTHORITY_HOST:          https://login.microsoftonline.com/
---

Разверните ресурс триггера KEDA TriggerAuthentication, содержащий идентификатор клиента, назначаемого пользователем.
```
kubectl apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
  namespace: default  # this must be same namespace as the ScaledObject/ScaledJob that will use it
spec:
  podIdentity:
    provider:  azure-workload
    identityId: $MI_CLIENT_ID
EOF
```
Примечание.

При использовании триггераAuthentication KEDA сможет пройти проверку подлинности с помощью удостоверения рабочей нагрузки. Модули keda-operator Pod используют identityId проверку подлинности в ресурсах Azure при оценке триггеров масштабирования.

Публикация сообщений в Служебная шина Azure

На этом этапе все настроено для масштабирования с помощью KEDA и удостоверений рабочей нагрузки Microsoft Entra. Мы протестируем это путем развертывания рабочих нагрузок производителя и потребителей.

Создайте новую службу ServiceAccount для рабочих нагрузок.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $MI_CLIENT_ID
  name: $MI_NAME
EOF

Разверните задание для публикации 100 сообщений.

kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: myproducer
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: $MI_NAME
      containers:
      - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
        name: myproducer
        resources: {}
        env:
        - name: OPERATION_MODE
          value: "producer"
        - name: MESSAGE_COUNT
          value: "100"
        - name: AZURE_SERVICEBUS_QUEUE_NAME
          value: $SB_QUEUE_NAME
        - name: AZURE_SERVICEBUS_HOSTNAME
          value: $SB_HOSTNAME
      restartPolicy: Never
EOF

Использование сообщений из Служебная шина Azure

Теперь, когда мы опубликовали сообщения в очередь Служебная шина Azure, мы развернем ScaledJob для использования сообщений. Этот масштабируемый заданий будет использовать ресурс KEDA TriggerAuthentication для проверки подлинности в очереди Служебная шина Azure с помощью удостоверения рабочей нагрузки и масштабирования каждые 10 сообщений.

Разверните ресурс ScaledJob для использования сообщений. Триггер масштабирования будет настроен для масштабирования каждые 10 сообщений. Масштабировщик KEDA создаст 10 заданий для использования 100 сообщений.

kubectl apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: myconsumer-scaledjob
spec:
  jobTargetRef:
    template:
      metadata:
        labels:
          azure.workload.identity/use: "true"
      spec:
        serviceAccountName: $MI_NAME
        containers:
        - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
          name: myconsumer
          env:
          - name: OPERATION_MODE
            value: "consumer"
          - name: MESSAGE_COUNT
            value: "10"
          - name: AZURE_SERVICEBUS_QUEUE_NAME
            value: $SB_QUEUE_NAME
          - name: AZURE_SERVICEBUS_HOSTNAME
            value: $SB_HOSTNAME
        restartPolicy: Never
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: $SB_QUEUE_NAME
      namespace: $SB_NAME
      messageCount: "10"
    authenticationRef:
      name: azure-servicebus-auth
EOF

Примечание.

ScaledJob создает ресурс задания Kubernetes при каждом возникновении события масштабирования, поэтому при создании ресурса необходимо передать шаблон задания. По мере создания новых заданий модули Pod будут развернуты с битами удостоверений рабочей нагрузки для использования сообщений.

Убедитесь, что масштабировщик KEDA работал должным образом.
```
kubectl describe scaledjob myconsumer-scaledjob
```

Вы должны увидеть события, аналогичные приведенным ниже.

Events:
Type     Reason              Age   From           Message
----     ------              ----  ----           -------
Normal   KEDAScalersStarted  10m   scale-handler  Started scalers watch
Normal   ScaledJobReady      10m   keda-operator  ScaledJob is ready for scaling
Warning  KEDAScalerFailed    10m   scale-handler  context canceled
Normal   KEDAJobsCreated     10m   scale-handler  Created 10 jobs

Очистка ресурсов

Убедившись, что развертывание выполнено успешно, можно очистить ресурсы, чтобы избежать затрат Azure.

Удалите группу ресурсов Azure и все ресурсы в ней с помощью команды [][az group deleteaz-group-delete].
```
az group delete --name $RG_NAME --yes --no-wait
```

Следующие шаги

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

Дополнительные сведения об устранении неполадок KEDA см . в разделе "Устранение неполадок с автомасштабированием на основе событий Kubernetes( KEDA).

Дополнительные сведения о KEDA см. в вышестоящем документе KEDA.

Поделиться через