Uw toepassingen veilig schalen met behulp van de KEDA-invoegtoepassing en workloadidentiteit op Azure Kubernetes Service (AKS)

In dit artikel leest u hoe u uw toepassingen veilig kunt schalen met de invoegtoepassing Kubernetes Event-driven AutoScaling (KEDA) en de workloadidentiteit op Azure Kubernetes Service (AKS).

Belangrijk

De Kubernetes-versie van uw cluster bepaalt welke KEDA-versie op uw AKS-cluster wordt geïnstalleerd. Als u wilt zien welke KEDA-versie aan elke AKS-versie wordt toegewezen, raadpleegt u de kolom met door AKS beheerde invoegtoepassingen van de versietabel van het Kubernetes-onderdeel.

Voor GA Kubernetes-versies biedt AKS volledige ondersteuning voor de bijbehorende KEDA minor versie in de tabel. Kubernetes Preview-versies en de nieuwste KEDA-patch worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Zodoende zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

Voordat u begint

U hebt een Azure-abonnement nodig. Als u geen Azure-abonnement hebt, kunt u een gratis account maken.
U moet de Azure CLI hebben geïnstalleerd.
Zorg ervoor dat u firewallregels hebt geconfigureerd om toegang tot de Kubernetes-API-server toe te staan. Zie Regels voor uitgaand netwerk en FQDN voor AKS-clusters (Azure Kubernetes Service) voor meer informatie.

Een brongroep maken

Maak een resourcegroep met behulp van de az group create opdracht. Zorg ervoor dat u de waarden van de tijdelijke aanduiding vervangt door uw eigen waarden.
```
LOCATION=<azure-region>
RG_NAME=<resource-group-name>

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

Een AKS-cluster maken

Maak een AKS-cluster met de KEDA-invoegtoepassing, workloadidentiteit en OIDC-verlener ingeschakeld met behulp van de az aks create opdracht met de --enable-workload-identity--enable-keda, en --enable-oidc-issuer vlaggen. Zorg ervoor dat u de tijdelijke aanduidingswaarde vervangt door uw eigen waarde.
```
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 
```
Valideer of de implementatie is geslaagd en controleer of het cluster KEDA, workload identity, en de OIDC-issuer zijn ingeschakeld met behulp van de az aks show opdracht waarbij de --query vlag is ingesteld op "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".
```
az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
```

Maak verbinding met het cluster met behulp van de az aks get-credentials opdracht.

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

Een Azure Service Bus maken

Maak een Azure Service Bus-naamruimte met behulp van de az servicebus namespace create opdracht. Zorg ervoor dat u de waarde van de tijdelijke aanduiding vervangt door uw eigen waarde.

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

Maak een Azure Service Bus-wachtrij met behulp van de az servicebus queue create opdracht. Zorg ervoor dat u de waarde van de tijdelijke aanduiding vervangt door uw eigen waarde.
```
SB_QUEUE_NAME=<service-bus-queue-name>

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

Een beheerde identiteit maken

Maak een beheerde identiteit met behulp van de az identity create opdracht. Zorg ervoor dat u de waarde van de tijdelijke aanduiding vervangt door uw eigen waarde.

MI_NAME=<managed-identity-name>

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

Haal de URL van de OIDC-verlener op met behulp van de az aks show opdracht, waarbij de --query vlag is ingesteld op oidcIssuerProfile.issuerUrl.

AKS_OIDC_ISSUER=$(az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query oidcIssuerProfile.issuerUrl \
    --output tsv)

Maak een federatieve referentie tussen de beheerde identiteit en de naamruimte en het serviceaccount dat door de workload wordt gebruikt met behulp van de az identity federated-credential create opdracht. Zorg ervoor dat u de waarde van de tijdelijke aanduiding vervangt door uw eigen waarde.

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

Maak een tweede federatieve referentie tussen de beheerde identiteit en de naamruimte en het serviceaccount dat door de keda-operator wordt gebruikt met behulp van de az identity federated-credential create opdracht. Zorg ervoor dat u de waarde van de tijdelijke aanduiding vervangt door uw eigen waarde.

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

Maak roltoewijzingen

Haal de object-id voor de beheerde identiteit op met behulp van de az identity show opdracht met de --query vlag ingesteld op "principalId".

MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)

Haal de resource-id van de Service Bus naamruimte op met behulp van de opdracht az servicebus namespace show met de parameter --query geconfigureerd als "id".
```
SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)
```

Wijs met behulp van de opdracht az role assignment create de rol 'Azure Service Bus Gegevenseigenaar' toe aan de beheerde identiteit.

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

Workload-Identiteit activeren op KEDA-Operator

Nadat u de federatieve referentie voor het keda-operator ServiceAccount hebt gemaakt, annoteert u het ServiceAccount met de client ID van de beheerde identiteit. Dit vertelt de workload-identiteitswebhook welke identiteit aan de keda-operator pods moet worden gekoppeld.
```
kubectl annotate serviceaccount keda-operator \
    azure.workload.identity/client-id=$MI_CLIENT_ID \
    -n kube-system
```
Start de keda-operator pods opnieuw om ervoor te zorgen dat omgevingsvariabelen voor workloadidentiteit worden geïnjecteerd in de pod.
```
kubectl rollout restart deploy keda-operator -n kube-system
```
Bevestig dat de keda-operator-pods opnieuw worden opgestart
```
kubectl get pod -n kube-system -lapp=keda-operator -w
```
Nadat u hebt bevestigd dat de keda-operator-pods klaar zijn met rolling hit Ctrl+c om de vorige controleopdracht te verbreken, controleert u of de omgevingsvariabelen voor workloadidentiteit zijn geïnjecteerd.
```
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
```

De uitvoer ziet er ongeveer als volgt uit onder Omgeving.

---
AZURE_CLIENT_ID:               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
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/
---

Implementeer een KEDA TriggerAuthentication-resource die de client-id van de User-Assigned Managed Identity bevat.
```
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
```
Opmerking

Als de TriggerAuthentication is ingesteld, kan KEDA zich authenticeren via de workload-identiteit. De keda-operator Pods gebruiken de identityId om te authentiseren voor Azure resources bij het evalueren van schaaltriggers.

Berichten publiceren naar Azure Service Bus

Op dit moment is alles geconfigureerd om te schalen met KEDA en Microsoft Entra Workloadidentiteit. We gaan dit testen door workloads van producenten en consumenten te implementeren.

Maak een nieuw ServiceAccount voor de workloads.

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

Implementeer een taak om 100 berichten te publiceren.

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

Berichten van Azure Service Bus gebruiken

Nu we berichten hebben gepubliceerd naar de Azure Service Bus wachtrij, implementeren we een ScaledJob om de berichten te gebruiken. Deze ScaledJob maakt gebruik van de KEDA TriggerAuthentication resource om zich te authentiseren tegen de Azure Service Bus-queue met de workloadidentiteit en schaalt uit na elke 10 berichten.

Implementeer een ScaledJob-resource om de berichten te gebruiken. De schaaltrigger wordt geconfigureerd om elke 10 berichten uit te schalen. De KEDA-scaler maakt 10 taken om de 100 berichten te verwerken.

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

Opmerking

ScaledJob maakt een Kubernetes-taakresource wanneer er een schaalgebeurtenis optreedt en dus moet een taaksjabloon worden doorgegeven bij het maken van de resource. Wanneer er nieuwe taken worden gemaakt, worden Pods geïmplementeerd met workload identity bits om berichten te ontvangen.

Controleer of de KEDA-scaler werkt zoals bedoeld.

kubectl describe scaledjob myconsumer-scaledjob

U zou gebeurtenissen moeten zien die er ongeveer als volgt uitzien.

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

De hulpbronnen opschonen

Nadat u hebt gecontroleerd of de implementatie is geslaagd, kunt u de resources opschonen om te voorkomen dat Azure-kosten in rekening worden gebracht.

Verwijder de Azure resourcegroep en alle resources erin met behulp van de opdracht [az group delete][az-group-delete].
```
az group delete --name $RG_NAME --yes --no-wait
```

Volgende stappen

Dit artikel heeft u laten zien hoe u uw toepassingen op een veilige manier kunt schalen met behulp van de KEDA-add-on en workloadidentiteit in AKS.

Zie Troubleshoot de Kubernetes Event-driven Autoscaling (KEDA) add-on voor meer informatie over het oplossen van problemen met KEDA.

Zie de upstream KEDA-documenten voor meer informatie over KEDA.

Feedback

Is deze pagina nuttig?

Last updated on 2026-05-08