AWS eseményvezérelt munkafolyamat (EDW) számítási feladat üzembe helyezése az Azure-ban

Ebben a cikkben egy AWS EDW számítási feladatot fog üzembe helyezni az Azure-ban.

Bejelentkezés az Azure-ba

1. Jelentkezzen be az Azure-ba a az login paranccsal.

   az login
   

2. Ha az Azure-fiókja több előfizetéssel is rendelkezik, győződjön meg arról, hogy a megfelelő előfizetést választja ki. A parancs használatával az account list listázhatja az előfizetések nevét és azonosítóit.

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

3. Válasszon ki egy adott előfizetést a az account set paranccsal.

   az account set --subscription $subscriptionId
   

EDW számítási feladatok üzembehelyezési szkriptje

Tekintse át a fájl deployment/environmentVariables.sh környezeti változóit, majd a deploy.sh GitHub-adattárdeployment/infra/található szkripttel helyezze üzembe az alkalmazást az Azure-ban.

A szkript először ellenőrzi, hogy az összes előfeltétel-eszköz telepítve van-e. Ha nem, a szkript leáll, és hibaüzenetet jelenít meg, amely tájékoztatja arról, hogy mely előfeltételek hiányoznak. Ha ez történik, tekintse át az előfeltételeket, telepítse a hiányzó eszközöket, majd futtassa újra a szkriptet. Az AKS szolgáltatásjelzőjéhez tartozó csomópont-automatikus fejlesztési (NAP) jelzőt regisztrálni kell az Azure-előfizetésben. Ha még nincs regisztrálva, a szkript végrehajt egy Azure CLI-parancsot a funkciójelző regisztrálásához.

A szkript egy, a könyvtárban található fájlban deploy.staterögzíti az deployment üzembe helyezés állapotát. Ezzel a fájllal környezeti változókat állíthat be az alkalmazás telepítésekor.

Ahogy a szkript végrehajtja a parancsokat a munkafolyamat infrastruktúrájának konfigurálásához, ellenőrzi, hogy az egyes parancsok sikeresek-e. Ha bármilyen probléma merül fel, hibaüzenet jelenik meg, és a végrehajtás leáll.

A szkript futás közben megjeleníti a naplót. A naplót úgy őrizheti meg, hogy átirányítja a naplóinformáció kimenetét, és menti a install.log könyvtárban lévő logs fájlba az alábbi parancsokkal:

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

További információkért tekintse meg a szkriptet a ./deployment/infra/deploy.sh GitHub-adattárban.

Terheléselosztási erőforrások

Az üzembehelyezési szkript a következő Azure-erőforrásokat hozza létre:

• Azure-erőforráscsoport: Az üzembe helyezési szkript által létrehozott erőforrásokat tároló Azure-erőforráscsoport .

• Azure Storage-fiók: Az Az Azure Storage-fiók, amely azt az üzenetsort tartalmazza, amelyben az üzeneteket a gyártó alkalmazás küldi el, és amelyet a fogyasztói alkalmazás olvas be, valamint azt a táblát, amelyben a fogyasztói alkalmazás tárolja a feldolgozott üzeneteket.

• Azure Container Registry: A tárolóregisztrációs adatbázis egy adattárat biztosít ahhoz a tárolóhoz, amely üzembe helyezi az újrabontású fogyasztói alkalmazás kódját.

• Azure Kubernetes Service-fürt (AKS): Az AKS-fürt Kubernetes-vezénylést biztosít a felhasználói alkalmazás konténer számára, és a következő funkciók vannak engedélyezve:

  • Node autoprovisioning (NAP): A Karpenter-csomópont automatikus skálázási eszközének megvalósítása az AKS-en.
  • Kubernetes eseményvezérelt automatikus skálázás (KEDA): A KEDA lehetővé teszi az események alapján történő podok skálázását, például ha túllép egy meghatározott üzenetsormélységi küszöbértéket.
  • Workload identity: Lehetővé teszi a szerepköralapú hozzáférési szabályzatok pod identitásokhoz való csatolását a fokozott biztonság érdekében.
  • Csatolt Azure-tárolóregisztrációs adatbázis: Ez a funkció lehetővé teszi, hogy az AKS-fürt lekérje a rendszerképeket a megadott ACR-példány adattáraiból.

• Alkalmazási és rendszercsomópontkészlet: A szkript létrehoz egy alkalmazási és egy rendszercsomópont-készletet az AKS-fürtben, amelynek van egy "taint" jellemzője, ami megakadályozza, hogy az alkalmazási podok a rendszercsomópont-készletben ütemeződjenek.

• AKS-fürt felügyelt azonosítója: A szkript hozzárendeli a szerepkört ehhez a acrPull felügyelt azonosítóhoz, amely megkönnyíti a csatolt Azure-konténerregisztrációhoz való hozzáférést a képfájlok letöltéséhez.

• Számítási feladatok identitása: A szkript hozzárendeli a Storage Queue Data Contributor és a Storage Table Data Contributor szerepköröket, hogy szerepköralapú hozzáférés-vezérlési (RBAC) hozzáférést biztosítson ehhez a felügyelt identitáshoz, amely a Kubernetes szolgáltatásfiókhoz van társítva, amely identitásként szolgál azon podokhoz, amelyeken a fogyasztói alkalmazás tárolói telepítve vannak.

• Két összevont hitelesítő adat: Az egyik hitelesítő adat lehetővé teszi a felügyelt identitás számára a pod-identitás implementálását, a másik hitelesítő adatot pedig a KEDA operátori szolgáltatásfiókja használja, hogy hozzáférést biztosítson a KEDA-skálázóhoz a pod automatikus skálázásának szabályozásához szükséges metrikák összegyűjtéséhez.

Az üzembe helyezés ellenőrzése és a számítási feladat futtatása

Az üzembe helyezési szkript befejeződése után üzembe helyezheti a számítási feladatot az AKS-fürtön.

1. Állítsa be a környezeti változók gyűjtésének és frissítésének ./deployment/environmentVariables.sh forrását a következő parancs használatához:

   source ./deployment/environmentVariables.sh
   

2. A fájlban található információkra szüksége van az ./deployment/deploy.state üzembe helyezés során létrehozott erőforrások nevének környezeti változóinak beállításához. A fájl tartalmának megjelenítése a következő cat paranccsal:

   cat ./deployment/deploy.state
   

   A kimenetnek a következő változókat kell megjelenítenie:

   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. Olvassa el a fájlt, és hozzon létre környezeti változókat az üzembehelyezési szkript által létrehozott Azure-erőforrások nevéhez az alábbi parancsokkal:

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

4. Kérje le az AKS-fürt hitelesítő adatait a az aks get-credentials paranccsal.

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

5. Ellenőrizze, hogy az AKS-fürt kube-system névterében futnak-e a KEDA operátor podok a kubectl get paranccsal.

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

   A kimenetnek a következő példakimenethez hasonlóan kell kinéznie:

   

Szimulált terhelés létrehozása

Most szimulált terhelést generálsz a producer alkalmazás segítségével, hogy feltöltsd az üzenetsort üzenetekkel.

1. Egy külön terminálablakban navigáljon a projektkönyvtárba.

2. Állítsa be a környezeti változókat az előző szakaszban ismertetett lépésekkel. 1. Futtassa a gyártó alkalmazást a következő paranccsal:

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

3. Miután az alkalmazás megkezdte az üzenetek küldését, váltson vissza a másik terminálablakra.

4. Helyezze üzembe a fogyasztói alkalmazás tárolóját az AKS-fürtön az alábbi parancsokkal:

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

   Az üzembehelyezési szkript (deploy-keda-app-workload-id.sh) templatingot hajt végre az alkalmazásjegyzék YAML-specifikációján, hogy környezeti változókat adjon át a podnak. Tekintse át a szkript alábbi részletét:

   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
   

   A azure.workload.identity/use szakaszban található spec/template címke az üzembe helyezés podsablonja. A true címke beállítása azt jelzi, hogy a számítási feladat-azonosítást használja. A serviceAccountName pod specifikációjában a számítási feladat identitásához társítandó Kubernetes-szolgáltatásfiókot adja meg. Bár a pod specifikációja tartalmaz egy magánadattárban lévő rendszerképre vonatkozó hivatkozást, nincs imagePullSecret megadva.

5. Ellenőrizze, hogy a szkript sikeresen futott-e a kubectl get parancs használatával.

   kubectl get pods --namespace $AQS_TARGET_NAMESPACE
   

   A kimenetben egyetlen podnak kell megjelennie.

6. Ellenőrizze, hogy létrejött-e Karpenter-csomópontkészlet. Ezt a kubectl get nodepool parancs használatával teheti meg. A parancs válasza így fog kinézni:

   

   Ellenőrizze, hogy az alapértelmezett csomópontkészlet Karpenter-csomópontkészlet-e a kubectl describe nodepool paranccsal. A parancsválaszban ellenőrizheti, hogy a csomópontkészlet Karpenter-csomópontkészlet-e. Ennek nagyjából a következőképpen kell kinéznie:

   

Podok és csomópontok horizontális felskálázásának monitorozása k9-ekkel

Különböző eszközökkel ellenőrizheti az AKS-ben üzembe helyezett alkalmazások működését, beleértve az Azure Portalt és a k9-eket. A k9-ekkel kapcsolatos további információkért tekintse meg a k9s áttekintését.

1. Telepítse a k9s-t az AKS-fürtre a k9s telepítésének áttekintésében található, a környezetének megfelelő útmutatás szerint.

2. Hozzon létre két ablakot, az egyiket a podok nézetével, a másikat pedig a környezeti változóban AQS_TARGET_NAMESPACE megadott névtér csomópontjainak nézetével (az alapértelmezett érték aqs-demo) és az egyes ablakban k9-eket kezdjen el.

   A következőhöz hasonlót kell látnia:

   

3. Miután meggyőződött arról, hogy a fogyasztói alkalmazás tárolója telepítve van, és fut az AKS-fürtön, telepítse a ScaledObject-t, és indítsa el a KEDA által a pod automatikus skálázásához használt hitelesítést a skálázott objektumtelepítési szkript (keda-scaleobject-workload-id.sh) futtatásával. a következő parancsok használatával:

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

   A szkript emellett templatálást is végez a környezeti változók szükség szerinti injektálásához. Tekintse át a szkript alábbi részletét:

   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
   

   A jegyzék két erőforrást ír le: az objektumotTriggerAuthentication KEDA számára, hogy a skálázott objektum pod-identitást használ a hitelesítéshez, és a identityID tulajdonság, amely a számítási feladat identitásaként használt felügyelt identitásra hivatkozik.

   Ha a skálázott objektum megfelelően van telepítve, és a KEDA észleli a méretezési küszöbérték túllépését, megkezdi a podok ütemezését. K9s használata esetén valami ilyesmit fog látni:

   

   Ha engedélyezi a gyártónak, hogy elegendő üzenettel töltse ki az üzenetsort, előfordulhat, hogy a KEDA-nak több podot kell ütemeznie, mint amennyi csomópontot kiszolgálni kell. Ennek érdekében Karpenter elindítja és elkezdi a csomópontok ütemezését. K9s használata esetén valami ilyesmit fog látni:

   

   Ebben a két képen figyelje meg, hogy a névvel aks-default rendelkező csomópontok száma egyről három csomópontra nőtt. Ha megakadályozza, hogy a producer alkalmazás üzeneteket helyezzen az üzenetsorra, a fogyasztók végül csökkentik az üzenetsor mélységét a küszöbérték alá, és mind a KEDA, mind a Karpenter visszaskálázódik. K9s használata esetén valami ilyesmit fog látni:

   

4. Végül megtekintheti a Karpenter automatikus skálázási tevékenységét az kubectl get events itt látható paranccsal:

   

Az erőforrások tisztítása

A GitHub-adattárban található /deployment/infra/cleanup.sh szkript () használatával eltávolíthatja az összes létrehozott erőforrást.

Következő lépések

Az alkalmazások AKS-ben történő fejlesztésével és futtatásával kapcsolatos további információkért tekintse meg az alábbi forrásokat:

• Meglévő alkalmazások telepítése a Helmrel az AKS-ben
• Kubernetes-alkalmazás üzembe helyezése és kezelése az Azure Marketplace-ről az AKS-ben
• OpenAI-t használó alkalmazás üzembe helyezése az AKS-en

Közreműködők

A Microsoft fenntartja ezt a cikket. Eredetileg a következő közreműködők írták:

• Ken Kilty | Vezető TPM
• Russell de Pina | Vezető TPM
• Jenny Hayes | Vezető tartalomfejlesztő
• Carol Smith | Vezető tartalomfejlesztő
• Erin Schaffer | Tartalomfejlesztő 2