Sicheres Skalieren Ihrer Anwendungen mithilfe des KEDA-Add-Ons und der Workloadidentität in Azure Kubernetes Service (AKS)

Artikel
08/02/2024

In diesem Artikel erfahren Sie, wie Sie Ihre Anwendungen mithilfe des KEDA-Add-Ons (Kubernetes Event-Driven Autoscaling; ereignisgesteuerte automatische Kubernetes-Skalierung) und der Workloadidentität in Azure Kubernetes Service (AKS) sicher skalieren.

Wichtig

Die Kubernetes-Version Ihres Clusters bestimmt, welche KEDA-Version in Ihrem AKS-Cluster installiert wird. Informationen dazu, welche KEDA-Version welcher AKS-Version zugeordnet ist, finden Sie in der Spalte Verwaltete AKS-Add-Ons der Tabelle mit den Kubernetes-Komponentenversionen.

Für Kubernetes-Versionen mit allgemeiner Verfügbarkeit (GA) bietet AKS volle Unterstützung für die entsprechende KEDA-Nebenversion in der Tabelle. Kubernetes-Vorschauversionen und der neueste KEDA-Patch werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Voraussetzungen

Sie benötigen ein Azure-Abonnement. Falls Sie über kein Azure-Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
Die Azure CLI muss installiert sein.
Stellen Sie sicher, dass die Firewallregeln so konfiguriert sind, dass der Zugriff auf den Kubernetes-API-Server ermöglicht wird. Weitere Informationen finden Sie unter Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service-Cluster (AKS).

Erstellen einer Ressourcengruppe

Erstellen Sie mit dem Befehl az group create eine Ressourcengruppe. Ersetzen Sie die Platzhalterwerte durch Ihre eigenen Werte.
```
LOCATION=<azure-region>
RG_NAME=<resource-group-name>

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

Erstellen eines AKS-Clusters

Verwenden Sie den Befehl az aks create mit den Flags --enable-workload-identity, --enable-keda und --enable-oidc-issuer, um einen AKS-Cluster zu erstellen, in dem das KEDA-Add-On, die Workloadidentität und der OIDC-Aussteller aktiviert sind. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.
```
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 
```
Vergewissern Sie sich, dass die Bereitstellung erfolgreich war und dass KEDA, Workloadidentität und OIDC-Aussteller für den Cluster aktiviert sind, indem Sie den Befehl az aks show ausführen und dabei das Flag --query auf "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]" festlegen.
```
az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
```

Verwenden Sie den Befehl az aks get-credentials, um eine Verbindung mit dem Cluster herzustellen.

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

Erstellen einer Azure Service Bus-Instanz

Erstellen eines Azure Service Bus-Namespace mithilfe des Befehls az servicebus namespace create. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.

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

Erstellen einer Azure Service Bus-Warteschlange mithilfe des Befehls az servicebus queue create. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.

SB_QUEUE_NAME=<service-bus-queue-name>

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

Erstellen einer verwalteten Identität

Erstellen Sie mithilfe des az identity create-Befehls eine verwaltete Identität. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.

MI_NAME=<managed-identity-name>

MI_CLIENT_ID=$(az identity create \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "clientId" \
    --output tsv)

Rufen Sie die URL des OIDC-Ausstellers ab, indem Sie den Befehl az aks show ausführen und dabei das Flag --query auf oidcIssuerProfile.issuerUrlfestlegen.
```
AKS_OIDC_ISSUER=$(az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query oidcIssuerProfile.issuerUrl \
    --output tsv)
```

Erstellen Sie mithilfe des Befehls az identity federated-credential create Verbundanmeldeinformationen zwischen der verwalteten Identität und dem von der Workload verwendeten Namespace und Dienstkonto. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.

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

Erstellen Sie mithilfe des Befehls az identity federated-credential create weitere Verbundanmeldeinformationen zwischen der verwalteten Identität und dem vom KEDA-Operator verwendeten Namespace und Dienstkonto. Ersetzen Sie den Platzhalterwert durch Ihren eigenen Wert.

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

Erstellen von Rollenzuweisung

Rufen Sie die Objekt-ID für die verwaltete Identität ab, indem Sie den Befehl az identity show ausführen und dabei das Flag --query auf "principalId" festlegen.
```
MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)
```
Rufen Sie die Ressourcen-ID des Service Bus-Namespace ab, indem Sie den Befehl az servicebus namespace show ausführen und dabei das Flag --query auf "id" festlegen.
```
SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)
```

Weisen Sie der verwalteten Identität mithilfe des Befehls az role assignment create die Rolle „Azure Service Bus-Datenbesitzer“ zu.

az role assignment create \
    --role "Azure Service Bus Data Owner" \
    --assignee-object-id $MI_OBJECT_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $SB_ID

Aktivieren der Workloadidentität für den KEDA-Operator

Nachdem Sie die Verbundanmeldeinformationen für das keda-operator-Dienstkonto erstellt haben, müssen die keda-operator-Pods manuell neu gestartet werden, um sicherzustellen, dass Umgebungsvariablen für die Workloadidentität in die Pods eingefügt werden.
```
kubectl rollout restart deploy keda-operator -n kube-system
```
Vergewissern Sie sich, dass die keda-operator-Pods neu gestartet werden.
```
kubectl get pod -n kube-system -lapp=keda-operator -w
```
Nachdem Sie sich vergewissert haben, dass der Vorgang für die keda-operator-Pods abgeschlossen ist, drücken Sie Ctrl+c, um den vorherigen Überwachungsbefehl zu unterbrechen, und vergewissern Sie sich anschließend, dass die Umgebungsvariablen für die Workloadidentität eingefügt wurden.
```
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
```

Unter Umgebung sollte eine Ausgabe wie die folgende angezeigt werden:

---
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/
---

Stellen Sie eine KEDA-TriggerAuthentication-Ressource bereit, die die Client-ID der benutzerseitig zugewiesenen verwalteten Identität enthält.
```
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
```
Hinweis

Nach Einrichtung der TriggerAuthentication-Ressource kann KEDA sich über die Workloadidentität authentifizieren. Die keda-operator-Pods verwenden identityId zur Authentifizierung bei Azure-Ressourcen, wenn Skalierungstrigger ausgewertet werden.

Veröffentlichen von Nachrichten für Azure Service Bus

Nun ist alles für die Skalierung mit KEDA und der Microsoft Entra-Workloadidentität konfiguriert. Zu Testzwecken werden nun Producer- und Consumerworkloads bereitgestellt.

Erstellen Sie ein neues Dienstkonto für die Workloads.

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

Stellen Sie einen Auftrag für die Veröffentlichung von 100 Nachrichten bereit.

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

Nachrichten aus Azure Service Bus nutzen

Nachdem wir Nachrichten in der Azure Service Bus-Warteschlange veröffentlicht haben, stellen wir einen ScaledJob bereit, um die Nachrichten zu nutzen. Dieser ScaledJob verwendet die KEDA-TriggerAuthentication-Ressource, um sich mithilfe der Workloadidentität bei der Azure Service Bus-Warteschlange zu authentifizieren und alle 10 Nachrichten aufzuskalieren.

Stellen Sie eine ScaledJob-Ressource als Consumer für die Nachrichten bereit. Der Skalierungstrigger wird so konfiguriert, dass alle zehn Nachrichten eine Skalierung erfolgt. Der KEDA-Scaler erstellt zehn Aufträge, die als Consumer für die 100 Nachrichten fungieren.

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

Hinweis

ScaledJob erstellt eine Kubernetes-Auftragsressource, wenn ein Skalierungsereignis auftritt. Daher muss beim Erstellen der Ressource eine Auftragsvorlage übergeben werden. Wenn neue Aufträge erstellt werden, werden Pods mit Workloadidentitätsbits bereitgestellt, um Nachrichten zu nutzen.

Vergewissern Sie sich, dass der KEDA-Scaler wie beabsichtigt funktioniert hat.
```
kubectl describe scaledjob myconsumer-scaledjob
```

Es sollten Ereignisse wie die folgenden angezeigt werden:

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

Bereinigen von Ressourcen

Nachdem Sie überprüft haben, dass die Bereitstellung erfolgreich war, können Sie die Ressourcen bereinigen, um Azure-Kosten zu vermeiden.

Löschen Sie die Azure-Ressourcengruppe und alle zugehörigen Ressourcen mithilfe des Befehls [az group delete][az-group-delete].
```
az group delete --name $RG_NAME --yes --no-wait
```

Nächste Schritte

In diesem Artikel wurde gezeigt, wie Sie Ihre Anwendungen mithilfe des KEDA-Add-Ons und der Workloadidentität in AKS sicher skalieren.

Informationen zur KEDA-Problembehandlung finden Sie unter Problembehandlung für das Add-On für die ereignisgesteuerte automatische Skalierung in Kubernetes.

Weitere Informationen zu KEDA finden Sie in der KEDA-Upstreamdokumentation.

Freigeben über