Een AWS-eventgestuurde werkstroom (EDW) workload implementeren in Azure

In dit artikel implementeert u een AWS EDW-workload in Azure.

Meld u aan bij Azure met behulp van de az login opdracht.
```
az login
```
Als uw Azure-account meerdere abonnementen heeft, moet u het juiste abonnement selecteren. Geef de namen en id's van uw abonnementen weer met behulp van de az account list opdracht.
```
az account list --query "[].{id: id, name:name }" --output table
```
Selecteer een specifiek abonnement met behulp van de az account set opdracht.
```
az account set --subscription $subscriptionId
```

EDW-workloadimplementatiescript

Controleer de omgevingsvariabelen in het bestand deployment/environmentVariables.sh en gebruik vervolgens het deploy.sh script in de deployment/infra/ map van de GitHub-opslagplaats om de toepassing in Azure te implementeren.

Het script controleert eerst of alle vereiste hulpprogramma's zijn geïnstalleerd. Zo niet, dan wordt het script beëindigd en wordt er een foutbericht weergegeven waarin wordt opgegeven welke vereisten ontbreken. Als dit gebeurt, controleert u de vereisten, installeert u ontbrekende hulpprogramma's en voert u het script opnieuw uit. De vlag voor automatisch inrichten van knooppunten (NAP) voor AKS-functies moet zijn geregistreerd in uw Azure-abonnement. Als dit nog niet is geregistreerd, voert het script een Azure CLI-opdracht uit om de functievlag te registreren.

Het script registreert de status van de implementatie in een bestand met de naam deploy.state, dat zich in de deployment map bevindt. U kunt dit bestand gebruiken om omgevingsvariabelen in te stellen bij het implementeren van de app.

Wanneer het script de opdrachten uitvoert om de infrastructuur voor de werkstroom te configureren, wordt gecontroleerd of elke opdracht wordt uitgevoerd. Als er problemen optreden, wordt er een foutbericht weergegeven en stopt de uitvoering.

Het script geeft een logboek weer terwijl het wordt uitgevoerd. U kunt het logboek behouden door de uitvoer van de logboekgegevens om te leiden en op te slaan in het install.log bestand in de logs map met behulp van de volgende opdrachten:

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

Zie het ./deployment/infra/deploy.sh script in onze GitHub-opslagplaats voor meer informatie.

Workloadresources

Met het implementatiescript worden de volgende Azure-resources gemaakt:

Azure-resourcegroep: de Azure-resourcegroep waarin de resources worden opgeslagen die zijn gemaakt met het implementatiescript.
Azure Storage-account: het Azure Storage-account dat de wachtrij bevat waarin berichten worden verzonden door de producent-app en worden gelezen door de consumenten-app en de tabel waarin de consumenten-app de verwerkte berichten opslaat.
Azure Container Registry: Het containerregister biedt een opslagplaats voor de container waarmee de geherstructureerde code van de consumenten-app wordt geïmplementeerd.
AKS-cluster (Azure Kubernetes Service): het AKS-cluster biedt Kubernetes-indeling voor de container voor consumenten-apps en heeft de volgende functies ingeschakeld:
- Automatisch inrichten van knooppunten (NAP): de implementatie van de Karpenter node-autoscaler op AKS.
- Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA): KEDA maakt schaalaanpassing van pods mogelijk op basis van gebeurtenissen, zoals het overschrijden van een opgegeven drempelwaarde voor de wachtrijdiepte.
- Workloadidentiteit: hiermee kunt u op rollen gebaseerd toegangsbeleid koppelen aan pod-identiteiten voor verbeterde beveiliging.
- Gekoppeld Azure-containerregister: Deze functie stelt het AKS-cluster in staat om afbeeldingen op te halen uit repositories op de gespecificeerde ACR-instantie.
Toepassings- en systeemknooppuntgroep: Het script maakt ook een toepassings- en systeemknooppuntgroep in het AKS-cluster met een taint om te voorkomen dat toepassingspods worden gepland in de systeemknooppuntgroep.
Beheerde identiteit van AKS-cluster: Het script wijst de acrPull rol toe aan de beheerde identiteit, waardoor het eenvoudiger wordt om toegang te krijgen tot het gekoppelde Azure-containerregister om afbeeldingen te downloaden.
Workloadidentiteit: Het script wijst de rollen Inzender voor opslagwachtrijgegevens en Inzender voor opslagtabelgegevens toe om op rollen gebaseerd toegangsbeheer (RBAC) toegang te bieden tot deze beheerde identiteit, die is gekoppeld aan het Kubernetes-serviceaccount dat wordt gebruikt als de identiteit voor pods waarop de containers voor consumenten-apps worden geïmplementeerd.
Twee federatieve referenties: Met één referentie kan de beheerde identiteit pod-identiteit implementeren en wordt de andere referentie gebruikt voor het serviceaccount van de KEDA-operator om toegang te bieden tot de KEDA-schaalfunctie om de metrische gegevens te verzamelen die nodig zijn om automatische schaalaanpassing van pods te beheren.

Implementatie valideren en de workload uitvoeren

Zodra het implementatiescript is voltooid, kunt u de workload implementeren op het AKS-cluster.

Stel de bron in voor het verzamelen en bijwerken van de omgevingsvariabelen voor ./deployment/environmentVariables.sh met behulp van de volgende opdracht:
```
source ./deployment/environmentVariables.sh
```

U hebt de informatie in het ./deployment/deploy.state bestand nodig om omgevingsvariabelen in te stellen voor de namen van de resources die in de implementatie zijn gemaakt. Geef de inhoud van het bestand weer met behulp van de volgende cat opdracht:

cat ./deployment/deploy.state

De uitvoer moet de volgende variabelen weergeven:

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=

Lees het bestand en maak omgevingsvariabelen voor de namen van de Azure-resources die door het implementatiescript zijn gemaakt met behulp van de volgende opdrachten:
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```

Haal de AKS-clusterreferenties op met behulp van de az aks get-credentials opdracht.

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

Controleer of de KEDA-operatorpods worden uitgevoerd in de kube-system naamruimte op het AKS-cluster met behulp van de kubectl get opdracht.
```
kubectl get pods --namespace kube-system | grep keda
```
Uw output zou eruit moeten zien zoals de volgende voorbeeldoutput.

Gesimuleerde belasting genereren

Nu genereert u een gesimuleerde werklast met de producer-app om de wachtrij te vullen met berichten.

Navigeer in een afzonderlijk terminalvenster naar de projectmap.
Stel de omgevingsvariabelen in met behulp van de stappen in de vorige sectie. 1. Voer de producer-app uit met behulp van de volgende opdracht:
```
python3 ./app/keda/aqs-producer.py
```
Zodra de app berichten gaat verzenden, gaat u terug naar het andere terminalvenster.

Implementeer de container voor de consumenten-app in het AKS-cluster met behulp van de volgende opdrachten:

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

Het implementatiescript (deploy-keda-app-workload-id.sh) voert tempering uit op de YAML-specificatie van het toepassingsmanifest om omgevingsvariabelen door te geven aan de pod. Bekijk het volgende fragment uit dit 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

Het azure.workload.identity/use label in de spec/template sectie is de podsjabloon voor de implementatie. Als u het label instelt op true geeft u aan dat u de workload-identiteit gebruikt. De serviceAccountName in de podspecificatie geeft het Kubernetes-serviceaccount op dat moet worden gekoppeld aan de workloadidentiteit. Hoewel de podspecificatie een verwijzing bevat voor een image in een privérepository, is er geen imagePullSecret opgegeven.

Controleer of het script is uitgevoerd met behulp van de kubectl get opdracht.
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
U ziet nu één pod in de uitvoer.
Controleer of er een Karpenter-knooppuntgroep is gemaakt. Doe dit met behulp van de kubectl get nodepool opdracht. Het opdrachtantwoord ziet er als volgt uit:

Controleer of de standaardknooppuntgroep een Karpenter-knooppuntgroep is met behulp van de kubectl describe nodepool opdracht. In het opdrachtantwoord kunt u controleren of de knooppuntgroep een Karpenter-knooppuntgroep is. U zou iets moeten zien dat er ongeveer zo uitziet:

Monitor schaaluitbreiding voor pods en knooppunten met k9s

U kunt verschillende hulpprogramma's gebruiken om de werking van apps te controleren die zijn geïmplementeerd in AKS, waaronder Azure Portal en k9s. Zie het overzicht van k9s voor meer informatie over k9s.

Installeer k9s op uw AKS-cluster met behulp van de juiste richtlijnen voor uw omgeving in het overzicht van de k9s-installatie.
Maak twee vensters, een met een weergave van de pods en de andere met een weergave van de knooppunten in de naamruimte die u hebt opgegeven in de AQS_TARGET_NAMESPACE omgevingsvariabele (standaardwaarde is aqs-demo) en start k9s in elk venster.

U zou iets moeten zien dat er ongeveer als volgt uitziet:
Nadat u hebt bevestigd dat de container voor de consumenten-app is geïnstalleerd en wordt uitgevoerd op het AKS-cluster, installeert u de ScaledObject en start u de verificatie die door KEDA wordt gebruikt voor automatische schaalaanpassing van pods. Voer daartoe het installatie-skript voor geschaalde objecten uit (keda-scaleobject-workload-id.sh). met behulp van de volgende opdrachten:
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
Het script voert ook templating uit om omgevingsvariabelen waar nodig te injecteren. Bekijk het volgende fragment uit dit 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
```
Het manifest beschrijft twee resources: het TriggerAuthentication object, dat aan KEDA aangeeft dat het geschaalde object gebruikmaakt van pod-identiteit voor verificatie en de identityID eigenschap, die verwijst naar de beheerde identiteit die wordt gebruikt als de workload-id.

Wanneer het geschaalde object correct is geïnstalleerd en KEDA detecteert dat de drempelwaarde voor schalen wordt overschreden, begint het met het scheduleren van pods. Als u k9s gebruikt, zou u iets als het volgende moeten zien:

Als u de producent toestaat voldoende berichten in de wachtrij te vullen, zou KEDA mogelijk meer pods moeten deployen dan er knooppunten beschikbaar zijn om te beheren. Om dit mogelijk te maken, begint Karpenter met het plannen van knooppunten. Als u k9s gebruikt, ziet u iets als volgt:

In deze twee afbeeldingen kunt u zien hoe het aantal knooppunten waarvan de namen aks-default bevatten, is toegenomen van één knooppunt naar drie knooppunten. Als u stopt dat de producer-app berichten in de wachtrij plaatst, zullen de consumenten uiteindelijk de wachtrijdiepte onder de drempelwaarde verminderen en worden zowel KEDA als Karpenter ingeschaald. Als u k9s gebruikt, ziet u iets als het volgende:
Ten slotte kunt u de activiteit voor automatisch schalen van Karpenter weergeven met behulp van de kubectl get events opdracht, zoals hier wordt weergegeven:

De hulpbronnen opschonen

U kunt het opschoonscript (/deployment/infra/cleanup.sh) in onze GitHub-opslagplaats gebruiken om alle resources te verwijderen die u hebt gemaakt.

Volgende stappen

Zie de volgende bronnen voor meer informatie over het ontwikkelen en uitvoeren van toepassingen in AKS:

Contributors

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

Ken Kilty | Hoofd TPM
Russell de Pina | Principal TPM
Jenny Hayes | Senior Content Developer
Carol Smith | Senior Content Developer
Erin Schaffer | Inhoudsontwikkelaar 2

Feedback

Is deze pagina nuttig?

Last updated on 2025-11-04