Partager via

Déployer une charge de travail de workflow basé sur les événements (EDW) AWS sur Azure

Dans cet article, vous allez déployer une charge de travail EDW AWS sur Azure.

Connexion à Azure

  1. Connectez-vous à Azure à l'aide de la commande az login.

    az login

  2. Si votre compte Azure a plusieurs abonnements, veillez à sélectionner l’abonnement approprié. Répertoriez les noms et ID de vos abonnements à l’aide de la commande az account list.

    az account list --query "[].{id: id, name:name }" --output table

  3. Sélectionnez un abonnement spécifique à l’aide de la commande az account set.

    az account set --subscription $subscriptionId

Script de déploiement de charge de travail EDW

Évaluez les variables de l’environnement dans le fichier deployment/environmentVariables.sh et puis utilisez le script deploy.sh dans le répertoire deployment/infra/ du référentiel GitHub pour déployer l’application sur Azure.

Le script vérifie d’abord que tous les outils prérequis sont installés. Si ce n’est pas le cas, le script s’arrête et affiche un message d’erreur indiquant quels prérequis sont manquants. Si cela se produit, passez en revue les prérequis, installez les outils manquants, puis réexécutez le script. L’indicateur de fonctionnalité Node auto-approvisionnement (NAP) for AKS doit être enregistré dans votre abonnement Azure. S’il n’est pas encore inscrit, le script exécute une commande Azure CLI pour inscrire l’indicateur de fonctionnalité.

Le script enregistre l’état du déploiement dans un fichier appelé deploy.state, qui se trouve dans le répertoire deployment. Vous pouvez utiliser ce fichier pour définir des variables d’environnement lors du déploiement de l’application.

Lorsque le script exécute les commandes pour configurer l’infrastructure du workflow, il vérifie que chaque commande s’exécute correctement. Si des problèmes se produisent, un message d’erreur s’affiche et l’exécution s’arrête.

Le script affiche un journal à mesure qu’il s’exécute. Vous pouvez conserver le journal en redirigeant la sortie des informations du journal et en l’enregistrant dans le fichier install.log dans le répertoire logs à l’aide des commandes suivantes :

mkdir ./logs
./deployment/infra/deploy.sh | tee ./logs/install.log

Pour plus d’informations, consultez le script ./deployment/infra/deploy.sh dans notre dépôt GitHub.

Ressources de charge de travail

Le script de déploiement crée les ressources Azure suivantes :

  • Groupe de ressources Azure : groupe de ressources Azure qui stocke les ressources créées par le script de déploiement.

  • Compte Stockage Azure : compte Stockage Azure qui contient la file d’attente où les messages sont envoyés par l’application productrice et lus par l’application consommatrice, ainsi que la table où l’application consommatrice stocke les messages traités.

  • Registre de conteneurs Azure : le registre de conteneurs fournit un référentiel pour le conteneur qui déploie le code d’application consommatrice refactorisé.

  • Cluster Azure Kubernetes Service (AKS) : le cluster AKS fournit une orchestration Kubernetes pour le conteneur d’applications consommatrices, et les fonctionnalités suivantes sont activées :

    • Approvisionnement automatique des nœuds : implémentation de l’autoscaler de nœud Karpenter sur AKS.
    • Kubernetes Event-driven Autoscaling (KEDA) : KEDA permet la mise à l’échelle des pods en fonction d’événements tels que le dépassement d’un seuil de profondeur de file d’attente spécifié.
    • Identité de charge de travail : vous permet d’attacher des stratégies d’accès en fonction du rôle aux identités de pods pour une sécurité renforcée.
    • Registre de conteneurs Azure attaché : cette fonctionnalité permet au cluster AKS d’extraire des images à partir de référentiels sur l’instance ACR spécifiée.

  • Pool de nœuds d’application et système : le script crée également un pool de nœuds d’application et système dans le cluster AKS qui a une teinte pour empêcher que les pods d’applications soient planifiés dans le pool de nœuds système.

  • Identité managée du cluster AKS : le script attribue le rôle acrPull à cette identité managée, ce qui facilite l’accès au registre de conteneurs Azure attaché pour l’extraction d’images.

  • Identité de charge de travail : le script affecte les rôles Contributeur aux données en file d’attente du stockage et Contributeur de données de table de stockage pour fournir un accès en fonction du rôle (RBAC) à cette identité managée, qui est associée au compte de service Kubernetes utilisé comme identité pour les pods sur lesquels les conteneurs d’applications consommatrices sont déployés.

  • Deux informations d’identification fédérées : une information d’identification permet à l’identité managée d’implémenter l’identité de pod, et l’autre information d’identification est utilisée pour le compte de service d’opérateur KEDA afin de fournir l’accès au scaler KEDA pour collecter les métriques nécessaires pour contrôler la mise à l’échelle automatique des pods.

Valider le déploiement et exécuter la charge de travail

Une fois le script de déploiement terminé, vous pouvez déployer la charge de travail sur le cluster AKS.

  1. Définissez la source pour collecter et mettre à jour les variables d’environnement pour ./deployment/environmentVariables.sh à l’aide de la commande suivante :

    source ./deployment/environmentVariables.sh

  2. Vous avez besoin des informations contenues dans le fichier ./deployment/deploy.state pour définir des variables d’environnement pour les noms des ressources créées dans le déploiement. Affichez le contenu du fichier à l’aide de la commande cat suivante :

    cat ./deployment/deploy.state

    La sortie doit afficher les variables suivantes :

    SUFFIX=
RESOURCE_GROUP=
AZURE_STORAGE_ACCOUNT_NAME=
AZURE_QUEUE_NAME=
AZURE_COSMOSDB_TABLE=
AZURE_CONTAINER_REGISTRY_NAME=
AKS_MANAGED_IDENTITY_NAME=
AKS_CLUSTER_NAME=
WORKLOAD_MANAGED_IDENTITY_NAME=
SERVICE_ACCOUNT=
FEDERATED_IDENTITY_CREDENTIAL_NAME=
KEDA_SERVICE_ACCT_CRED_NAME=

  3. Lisez le fichier et créez des variables d’environnement pour les noms des ressources Azure créées par le script de déploiement à l’aide des commandes suivantes :

    while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state

  4. Obtenez les informations d’identification du cluster AKS à l’aide de la commande az aks get-credentials.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME

  5. Vérifiez que les pods d’opérateur KEDA s’exécutent dans l’espace de noms kube-system sur le cluster AKS à l’aide de la commande kubectl get.

    kubectl get pods --namespace kube-system | grep keda

    Vous devez obtenir un résultat semblable à l’exemple de sortie qui suit :

    Capture d’écran montrant un exemple de réponse de la commande pour vérifier que les pods d’opérateur KEDA sont en cours d’exécution.

Générer une charge simulée

À présent, vous allez générer une charge simulée à l’aide de l’application productrice pour remplir la file d’attente avec des messages.

  1. Dans une fenêtre de terminal distincte, accédez au répertoire du projet.

  2. Définissez les variables d’environnement à l’aide des étapes de la section précédente. 1. Exécutez l’application productrice à l’aide de la commande suivante :

    python3 ./app/keda/aqs-producer.py

  3. Une fois que l’application commence à envoyer des messages, revenez à l’autre fenêtre de terminal.

  4. Déployez le conteneur d’applications consommatrices sur le cluster AKS à l’aide des commandes suivantes :

    chmod +x ./deployment/keda/deploy-keda-app-workload-id.sh
./deployment/keda/deploy-keda-app-workload-id.sh

    Le script de déploiement (deploy-keda-app-workload-id.sh) effectue un templating sur la spécification YAML du manifeste d’application pour transmettre des variables d’environnement au pod. Passez en revue l’extrait suivant de ce script :

    cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: $AQS_TARGET_DEPLOYMENT
  namespace: $AQS_TARGET_NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aqs-reader
  template:
    metadata:
      labels:
        app: aqs-reader
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
EOF

    L’étiquette azure.workload.identity/use de la section spec/template est le modèle de pod pour le déploiement. L’affectation de la valeur true à l’étiquette indique que vous utilisez l’identité de charge de travail. serviceAccountName dans la spécification de pod indique quel compte de service Kubernetes associer à l’identité de charge de travail. Bien que la spécification du pod contienne une référence pour une image dans un référentiel privé, aucun imagePullSecret n’est spécifié.

  5. Vérifiez que le script s’est exécuté correctement à l’aide de la commande kubectl get.

    kubectl get pods --namespace $AQS_TARGET_NAMESPACE

    Vous devez voir un seul pod dans la sortie.

  6. Vérifiez qu’un pool de nœuds Karpenter a été créé. Pour ce faire, utilisez la commande kubectl get nodepool. La réponse de la commande est similaire à ce qui suit :

    Capture d’écran montrant un exemple de création du pool de nœuds Karpenter.

    À l’aide de la commande kubectl describe nodepool, vérifiez que le pool de nœuds par défaut est un pool de nœuds Karpenter. Dans la réponse de la commande, vous pouvez vérifier que le pool de nœuds est un pool de nœuds Karpenter. Un résultat semblable à celui-ci doit s’afficher :

    Capture d’écran montrant la réponse du pool de nœuds, y compris la version de l’API notée comme étant Karpenter.

Surveiller le scale-out des pods et des nœuds avec k9s

Vous pouvez utiliser différents outils pour vérifier le fonctionnement des applications déployées sur AKS, notamment le portail Azure et k9s. Pour plus d’informations sur k9s, consultez la vue d’ensemble de k9s.

  1. Installez k9s sur votre cluster AKS à l’aide des instructions correspondant à votre environnement fournies dans la vue d’ensemble de l’installation de k9s.

  2. Créez deux fenêtres, une avec une vue des pods et l’autre avec une vue des nœuds dans l’espace de noms que vous avez spécifié dans la variable d’environnement AQS_TARGET_NAMESPACE (la valeur par défaut est aqs-demo), et démarrez k9s dans chaque fenêtre.

    Vous devez voir quelque chose de similaire à ce qui suit :

    Capture d’écran montrant un exemple de vue k9s dans deux fenêtres.

  3. Après avoir confirmé que le conteneur d’applications consommatrices était bien installé et en cours d’exécution sur le cluster AKS, installez le ScaledObject et déclenchez l’authentification utilisée par KEDA pour la mise à l’échelle automatique des pods en exécutant le script d’installation d’objet mis à l’échelle (keda-scaleobject-workload-id.sh) à l’aide des commandes suivantes :

    chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh

    Le script effectue également un templating pour injecter des variables d’environnement si nécessaire. Passez en revue l’extrait suivant de ce script :

    cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws2az-queue-scaleobj
  namespace: ${AQS_TARGET_NAMESPACE}
spec:
  scaleTargetRef:
    name: ${AQS_TARGET_DEPLOYMENT}     #K8s deployement to target
  minReplicaCount: 0  # We don't want pods if the queue is empty nginx-deployment
  maxReplicaCount: 15 # We don't want to have more than 15 replicas
  pollingInterval: 30 # How frequently we should go for metrics (in seconds)
  cooldownPeriod:  10 # How many seconds should we wait for downscale
  triggers:
  - type: azure-queue
    authenticationRef:
      name: keda-az-credentials
    metadata:
      queueName: ${AZURE_QUEUE_NAME}
      accountName: ${AZURE_STORAGE_ACCOUNT_NAME}
      queueLength: '5'
      activationQueueLength: '20' # threshold for when the scaler is active
      cloud: AzurePublicCloud
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-az-credentials
  namespace: $AQS_TARGET_NAMESPACE
spec:
  podIdentity:
    provider: azure-workload
    identityId: '${workloadManagedIdentityClientId}'
EOF

    Le manifeste décrit deux ressources : l’objet TriggerAuthentication, qui indique à KEDA que l’objet mis à l’échelle utilise l’identité de pod pour l’authentification, et la propriété identityID, qui fait référence à l’identité managée utilisée comme identité de charge de travail.

    Lorsque l’objet mis à l’échelle est correctement installé et que KEDA détecte que le seuil de mise à l’échelle est dépassé, il commence la planification des pods. Si vous utilisez k9s, vous devriez voir quelque chose ressemblant à ceci :

    Capture d’écran montrant un exemple de vue k9s avec planification de pods.

    Si vous autorisez le producteur à remplir la file d’attente avec suffisamment de messages, KEDA devra peut-être planifier plus de pods qu’il y a de nœuds à servir. Pour prendre cela en charge, Karpenter entre en jeu et démarre la planification des nœuds. Si vous utilisez k9s, vous devriez voir quelque chose ressemblant à ceci :

    Capture d’écran montrant un exemple de vue k9s avec planification de nœuds.

    Dans ces deux images, notez que le nombre de nœuds dont le nom contient aks-default est passé de un à trois. Si vous faites en sorte que l’application productrice cesse de placer des messages dans la file d’attente, les consommateurs finiront par réduire la profondeur de file d’attente en dessous du seuil, et KEDA et Karpenter seront mis à l’échelle. Si vous utilisez k9s, vous devriez voir quelque chose ressemblant à ceci :

    Capture d’écran montrant un exemple de vue k9s avec une profondeur de file d’attente réduite.

  4. Enfin, vous pouvez afficher l’activité de mise à l’échelle automatique Karpenter à l’aide de la commande kubectl get events comme indiqué ci-après :

    Capture d’écran montrant un exemple de la commande kubectl.

Nettoyer les ressources

Vous pouvez utiliser le script de nettoyage (/deployment/infra/cleanup.sh) dans notre dépôt GitHub pour supprimer toutes les ressources que vous avez créées.

Étapes suivantes

Pour plus d’informations sur le développement et l’exécution d’applications dans AKS, consultez les ressources suivantes :

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont rédigé sa version d’origine :

  • Ken Kitty | Responsable de programme technique principal
  • Russell de Pina | Responsable de programme technique principal
  • Jenny Hayes | Développeuse de contenu confirmée
  • Carol Smith | Développeuse de contenu confirmée
  • Erin Schaffer | Développeuse de contenu 2
  • Last updated on