Mettre à l’échelle vos applications en toute sécurité à l’aide du module complémentaire KEDA et d’une identité de charge de travail sur Azure Kubernetes Service (AKS)

Article
08/02/2024

Cet article vous montre comment mettre à l’échelle vos applications en toute sécurité avec le module complémentaire KEDA (Kubernetes Event-driven Autoscaling) et une identité de charge de travail sur Azure Kubernetes Service (AKS).

Important

La version Kubernetes de votre cluster détermine la version KEDA installée sur votre cluster AKS. Pour voir la version KEDA mappée à chaque version AKS, consultez la colonne Modules complémentaires gérés par AKS du tableau des versions de composant Kubernetes.

Pour les versions Kubernetes GA, AKS offre une prise en charge complète de la version mineure KEDA correspondante dans le tableau. Les préversions de Kubernetes et le dernier patch KEDA sont partiellement couverts par le service client, dans la mesure du possible. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Avant de commencer

Vous avez besoin d’un abonnement Azure. Si vous n’avez pas d’abonnement Azure, vous pouvez créer un compte gratuit.
Vous devez avoir installé Azure CLI.
Assurez-vous que les règles de pare-feu sont configurées pour autoriser l’accès au serveur d’API Kubernetes. Pour plus d'informations, voir Règles de réseau sortant et de FQDN pour les clusters Azure Kubernetes Service (AKS).

Créer un groupe de ressources

Créez un groupe de ressources avec la commande az group create. Veillez à remplacer les valeurs d’espace réservé par vos propres valeurs.
```
LOCATION=<azure-region>
RG_NAME=<resource-group-name>

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

Créer un cluster AKS

Créez un cluster AKS avec le module complémentaire KEDA, une identité de charge de travail et un émetteur OIDC activés en utilisant la commande az aks create avec les indicateurs --enable-workload-identity, --enable-keda et --enable-oidc-issuer. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.
```
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 
```
Vérifiez que le déploiement a réussi et que le cluster a KEDA, une identité de charge de travail et un émetteur OIDC activés en utilisant la commande az aks show avec l’indicateur --query défini sur "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".
```
az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
```

Connectez-vous au cluster en utilisant la commande az aks get-credentials.

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

Créer une instance Azure Service Bus

Créez un espace de noms Azure Service Bus à l’aide de la commande az servicebus namespace create. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.

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

Créez une file d’attente Azure Service Bus à l’aide de la commande az servicebus queue create. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.
```
SB_QUEUE_NAME=<service-bus-queue-name>

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

Créer une identité managée

Créez une identité managée à l’aide de la commande az identity create. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.

MI_NAME=<managed-identity-name>

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

Obtenez l’URL de l’émetteur OIDC en utilisant la commande az aks show avec l’indicateur --query défini sur oidcIssuerProfile.issuerUrl.

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

Créez des informations d’identification fédérées entre l’identité managée et l’espace de noms et le compte de service utilisés par la charge de travail à l’aide de la commande az identity federated-credential create. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.

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

Créez d’autres informations d’identification fédérées entre l’identité managée et l’espace de noms et le compte de service utilisés par keda-operator à l’aide de la commande az identity federated-credential create. Veillez à remplacer la valeur d’espace réservé par votre propre valeur.

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

Créer des attributions de rôles

Obtenez l’ID d’objet de l’identité managée en utilisant la commande az identity show avec l’indicateur --query défini sur "principalId".
```
MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)
```
Obtenez l’ID de ressource de l’espace de noms Service Bus en utilisant la commande az servicebus namespace show avec l’indicateur --query défini sur "id".
```
SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)
```

Attribuez le rôle Propriétaire de données Azure Service Bus à l’identité managée en utilisant la commande 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

Activer l’identité de charge de travail sur l’opérateur KEDA

Après avoir créé les informations d’identification fédérées pour le ServiceAccount keda-operator, vous devez redémarrer manuellement les pods keda-operator pour vous assurer que les variables d’environnement de l’identité de charge de travail sont injectées dans le pod.
```
kubectl rollout restart deploy keda-operator -n kube-system
```

Confirmer le redémarrage des pods keda-operator

kubectl get pod -n kube-system -lapp=keda-operator -w

Une fois que vous avez confirmé que les pods keda-operator ont fini de redémarrer, appuyez sur Ctrl+c pour arrêter la commande espion précédente, puis confirmez que les variables d’environnement de l’identité de charge de travail ont été injectées.
```
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
```

Vous devriez obtenir une sortie similaire à la suivante sous Environnement.

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

Déployez une ressource KEDA TriggerAuthentication qui inclut l’ID client de l’identité managée affectée par l’utilisateur.
```
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
```
Remarque

Avec triggerAuthentication en place, KEDA pourra s’authentifier via l’identité de charge de travail. Les pods keda-operator utilisent identityId pour s’authentifier auprès des ressources Azure lors de l’évaluation des déclencheurs de mise à l’échelle.

Publier des messages dans Azure Service Bus

À ce stade, tout est configuré pour la mise à l’échelle avec KEDA et l’identité de charge de travail Microsoft Entra. Nous allons tester cela en déployant des charges de travail de producteur et de consommateur.

Créez un ServiceAccount pour les charges de travail.

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

Déployez un travail pour publier 100 messages.

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

Consommer des messages dans Azure Service Bus

Maintenant que nous avons publié des messages dans la file d’attente Azure Service Bus, nous allons déployer un ScaledJob pour consommer les messages. Ce ScaledJob utilise la ressource KEDA TriggerAuthentication pour s’authentifier auprès de la file d’attente Azure Service Bus à l’aide de l’identité de la charge de travail et effectuer un scale-out tous les 10 messages.

Déployez une ressource ScaledJob pour consommer les messages. Le déclencheur de mise à l’échelle est configuré pour effectuer un scale-out tous les 10 messages. Le scaler KEDA crée 10 travaux pour consommer les 100 messages.

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

Remarque

ScaledJob crée une ressource de travail Kubernetes chaque fois qu’un événement de mise à l’échelle se produit, donc un modèle de travail doit être transmis lors de la création de la ressource. À mesure que de nouveaux travaux sont créés, les pods sont déployés avec les données de l’identité de charge de travail pour consommer les messages.

Vérifiez que le scaler KEDA a fonctionné comme prévu.
```
kubectl describe scaledjob myconsumer-scaledjob
```

Vous devriez voir des événements similaires à ce qui suit.

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

Nettoyer les ressources

Après avoir vérifié que le déploiement est effectué, vous pouvez nettoyer les ressources pour éviter les coûts liés à Azure.

Supprimez le groupe de ressources Azure et toutes ses ressources à l’aide de la commande [az group delete][az-group-delete].
```
az group delete --name $RG_NAME --yes --no-wait
```

Étapes suivantes

Cet article vous a montré comment mettre à l’échelle vos applications en toute sécurité à l’aide du module complémentaire KEDA et d’une identité de charge de travail dans AKS.

Pour plus d’informations sur la résolution des problèmes KEDA, consultez Résoudre les problèmes du module complémentaire Kubernetes Event-driven Autoscaling (KEDA).

Pour en savoir plus sur KEDA, consultez la documentation KEDA en amont.

Partager via