KEDA をAzure Kubernetes Service クラスターと統合する

[アーティクル]
2024/10/15

KEDA とは Kubernetes-based Event Driven Autoscaler のことです。 KEDA は、Prometheus などのシステムのメトリックにクエリを実行することで、処理する負荷に基づいて Kubernetes 内の任意のコンテナーのスケーリングの実行を可能とします。 KEDA を Azure Kubernetes Service (AKS) クラスターと統合して、Azure Monitor ワークスペースの Prometheus メトリックに基づいてワークロードをスケーリングします。

KEDA をAzure Kubernetes Service に統合するには、クラスターにワークロード ID またはポッド ID をデプロイして構成する必要があります。この ID によって、KEDA は Azure で認証を行い、Monitor ワークスペースからスケーリングのためのメトリックを取得できるようになります。

この記事では、ワークロード ID を使用して KEDA を AKS クラスターに統合する手順について説明します。

注意

Microsoft Entra ワークロード ID を使用することをお勧めします。この認証方法により、ポッドマネージド ID (プレビュー) が置き換えられます。これにより、Kubernetes のネイティブ機能と統合され、アプリケーションに代わって任意の外部 ID プロバイダーとフェデレーションされます。

Azure Kubernetes Service のオープンソースの Microsoft Entra ポッドマネージド ID (プレビュー) は、2022 年 10 月 24 日の時点で非推奨となり、プロジェクトは 2023 年 9 月にアーカイブされます。詳細については、非推奨に関する通知を参照してください。 AKS マネージドアドオンは、2023 年 9 月に非推奨となります。

Azure Managed Prometheus のサポートは、KEDA v2.10 から開始されます。古いバージョンの KEDA がインストールされている場合は、Azure Managed Prometheus を使用するためにアップグレードする必要があります。

前提条件

Azure Kubernetes Service (AKS) クラスター
Azure Monitor ワークスペースにメトリックを送信している Prometheus。詳細については、「Prometheus 用 Azure Monitor マネージドサービス」を参照してください。

ワークロード ID を設定する

まず、いくつかの環境変数を設定します。 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- KEDA をデプロイする AKS クラスターの名前。
- SERVICE_ACCOUNT_NAMESPACE KEDA とサービスアカウントの両方が同じ名前空間に存在する必要があります。
- USER_ASSIGNED_IDENTITY_NAME は、KEDA 用に作成された Microsoft Entra ID の名前です。
- FEDERATED_IDENTITY_CREDENTIAL_NAME は、KEDA が Azure での認証に使用するために作成された資格情報の名前です。
AKS クラスターが、ワークロード ID または OIDC Issuer を有効にして作成されていない場合は、それを有効にする必要があります。どちらか分からない場合は、次のコマンドを実行して、有効になっているかどうかをチェックできます。
```
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
```
ワークロード ID と OIDC Issuer を有効にするには、次のコマンドを実行します。
```
az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer
```

OIDC Issuer の URL を環境変数に格納して、後で使用します。

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

KEDA 用のユーザー割り当て ID を作成します。この ID は、KEDA が Azure Monitor での認証に使用します。

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

出力は次のようになります。

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

clientId と tenantId を環境変数に格納して、後で使用します。

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

Azure Monitor ワークスペースの ID に監視データ閲覧者ロールを割り当てます。このロールにより、ID はワークスペースからメトリックを読み取ることができるようになります。 "Azure Monitor ワークスペースリソースグループ" と "Azure Monitor ワークスペース名" を、AKS クラスターからメトリックを収集するように構成されている Azure Monitor ワークスペースのリソースグループと名前に置き換えます。
```
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>
```

KEDA 名前空間を作成し、Kubernetes サービスアカウントを作成します。このサービスアカウントは、KEDA が Azure Monitor での認証に使用します。


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

実行してサービスアカウントを確認する

kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda

サービスアカウントとユーザー割り当て ID の間のフェデレーション資格情報を確立します。このフェデレーション資格情報によって、サービスアカウントはユーザー割り当て ID を使用して 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
```
注意

フェデレーション ID 資格情報が最初に追加された後に反映されるまでに数秒かかります。フェデレーション ID 資格情報を追加した直後にトークン要求が行われると、古いデータがあるディレクトリにキャッシュが設定されるため、数分失敗する可能性があります。このイシューを回避するには、フェデレーション ID 資格情報を追加した後に若干の遅延を追加できます。

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 では、さまざまなスケーラーがサポートされています。スケーラーの詳細については、「スケーラー」を参照してください。 Azure Managed Prometheus は、既存の Prometheus スケーラーを利用して、Azure Monitor ワークスペースから Prometheus メトリックを取得します。次の YAML ファイルは、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 は、Azure Monitor ワークスペースのクエリエンドポイントです。詳細については、「API と PromQL を使用して Prometheus メトリックのクエリを実行する」を参照してください
metricName は、スケーリングを実行したいメトリックの名前です。
query は、メトリックを取得するために使用されるクエリです。
threshold は、デプロイがスケーリングを実行する値です。
使用している ID の種類に応じて 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: 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"}

ServiceAccount の作成に使用される値と、az identity federated-credential create を使用して作成された資格情報を確認し、subject 値が system:serviceaccount 値と一致していることを確認します。

Azure Monitor ワークスペースアクセス許可

KEDA の Azure での認証に問題がある場合は、Azure Monitor ワークスペースのアクセス許可を確認します。次のログの抜粋は、ID に 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\"}"}

ID に Azure Monitor ワークスペースの Monitoring Data Reader ロールがあることを確認します。

ドキュメント

Kubernetes Event-driven Autoscaling (KEDA) アドオンとワークロード ID を使用してアプリケーションを安全にスケーリングする - Azure Kubernetes Service

Azure Kubernetes Service (AKS) で KEDA アドオンとワークロード ID を使用して、アプリケーションを安全にスケーリングする方法について説明します。
Azure CLI を使用して Kubernetes Event-driven Autoscaling (KEDA) アドオンをインストールする - Azure Kubernetes Service

Azure CLI を使用して、Kubernetes Event-driven Autoscaling (KEDA) アドオンを Azure Kubernetes Service (AKS) にデプロイします。
Kubernetes Event-driven Autoscaling (KEDA) - Azure Kubernetes Service

Kubernetes Event-driven Autoscaling (KEDA) アドオンを使用したアプリケーションの自動スケーリングの簡略化。
既存の AKS クラスターで Kubernetes イベントドリブン自動スケール (KEDA) アドオンを有効にする - Azure Kubernetes Service

Azure portal を使用して、既存の Azure Kubernetes Service (AKS) クラスターで Kubernetes イベントドリブン自動スケール (KEDA) アドオンを有効にします。
Kubernetes イベントドリブン自動スケール (KEDA) アドオンのトラブルシューティング - Azure

Azure Kubernetes Service (AKS) への Kubernetes イベントドリブン自動スケール (KEDA) アドオンのトラブルシューティングを行う方法について説明します。
ARM テンプレートを使って Kubernetes Event-driven Autoscaling (KEDA) アドオンをインストールする - Azure Kubernetes Service

ARM テンプレートを使用して、Kubernetes Event-driven Autoscaling (KEDA) アドオンを Azure Kubernetes Service (AKS) にデプロイします。
Azure Kubernetes Service (AKS) での Kubernetes Event-Driven Autoscaling (KEDA) との統合 - Azure Kubernetes Service

Azure Kubernetes Service (AKS) での Kubernetes Event-Driven Autoscaling (KEDA) との統合。
KEDA 2.15 および 2.14 の破壊的変更用に AKS クラスターを準備するためのガイド - Azure

KEDA 2.15 および 2.14 で導入された重要な破壊的変更について説明し、これらの更新のために Azure Kubernetes Service (AKS) クラスターを準備するためのガイドを提供します。

次の方法で共有

KEDA をAzure Kubernetes Service クラスターと統合する

前提条件

ワークロード ID を設定する

KEDA をデプロイする

スケーラー

トラブルシューティング

フェデレーション資格情報

Azure Monitor ワークスペースアクセス許可

フィードバック

その他のリソース

次の方法で共有

KEDA をAzure Kubernetes Service クラスターと統合する

前提条件

ワークロード ID を設定する

KEDA をデプロイする

スケーラー

トラブルシューティング

フェデレーション資格情報

Azure Monitor ワークスペース アクセス許可

フィードバック

その他のリソース

Azure Monitor ワークスペースアクセス許可