Nasazení úlohy pracovního postupu řízeného událostmi AWS (EDW) do Azure

V tomto článku nasadíte úlohu AWS EDW do Azure.

Přihlaste se k Azure pomocí az login příkazu.
```
az login
```
Pokud má váš účet Azure více předplatných, nezapomeňte vybrat správné předplatné. Pomocí příkazu vypíšete az account list názvy a ID vašich předplatných.
```
az account list --query "[].{id: id, name:name }" --output table
```
Pomocí příkazu vyberte konkrétní předplatné az account set .
```
az account set --subscription $subscriptionId
```

Skript nasazení úloh EDW

Zkontrolujte proměnné prostředí v souboru deployment/environmentVariables.sh a pak pomocí deploy.sh skriptu v deployment/infra/ adresáři úložiště GitHub nasaďte aplikaci do Azure.

Skript nejprve zkontroluje, že jsou nainstalovány všechny požadované nástroje . Pokud ne, skript se ukončí a zobrazí chybovou zprávu s informacemi o chybějících požadavcích. Pokud k tomu dojde, zkontrolujte požadavky, nainstalujte všechny chybějící nástroje a spusťte skript znovu. Příznak funkce AKS pro automatické zřízení uzlu (NAP) musí být zaregistrovaný ve vašem předplatném Azure. Pokud ještě není zaregistrovaný, skript spustí příkaz Azure CLI pro registraci příznaku funkce.

Skript zaznamenává stav nasazení do souboru s názvem deploy.state, který se nachází v deployment adresáři. Tento soubor můžete použít k nastavení proměnných prostředí při nasazování aplikace.

Když skript spustí příkazy pro konfiguraci infrastruktury pro pracovní postup, zkontroluje, že se každý příkaz úspěšně spustí. Pokud dojde k nějakým problémům, zobrazí se chybová zpráva a spuštění se zastaví.

Skript při spuštění zobrazí protokol. Protokol můžete zachovat přesměrováním výstupu informací protokolu a jeho uložením do install.log souboru v logs adresáři pomocí následujících příkazů:

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

Další informace najdete ./deployment/infra/deploy.sh ve skriptu v našem úložišti GitHub.

Prostředky úloh

Skript nasazení vytvoří následující prostředky Azure:

Skupina prostředků Azure: Skupina prostředků Azure, která ukládá prostředky vytvořené skriptem nasazení.
Účet Služby Azure Storage: Účet Azure Storage, který obsahuje frontu, ve které se zprávy odesílají aplikací producenta, a přečte ji aplikace příjemce a tabulku, ve které aplikace příjemce ukládá zpracovávané zprávy.
Registr kontejneru Azure: Registr kontejneru poskytuje úložiště pro kontejner, který nasadí refaktorovaný kód aplikace příjemce.
Cluster Azure Kubernetes Service (AKS): Cluster AKS poskytuje orchestraci Kubernetes pro kontejner aplikace příjemce a má povolené následující funkce:
- Automatické zřizování uzlů (NAP):: Implementace automatického škálování uzlu Karpenter v AKS.
- Automatické škálování řízené událostmi Kubernetes (KEDA):KEDA umožňuje škálování podů na základě událostí, jako je překročení zadané prahové hodnoty hloubky fronty.
- Identita úloh: Umožňuje připojit zásady přístupu na základě role k identitám podů pro lepší zabezpečení.
- Připojený registr kontejneru Azure: Tato funkce umožňuje clusteru AKS načíst image z úložišť v zadané instanci ACR.
Fond aplikačních a systémových uzlů: Skript také vytvoří fond aplikací a systémových uzlů v clusteru AKS, který má taint, aby se zabránilo naplánování podů aplikací ve fondu systémových uzlů.
Spravovaná identita clusteru AKS: Skript přiřadí acrPull této spravované identitě roli, která usnadňuje přístup k připojenému registru kontejneru Azure pro vyžádání imagí.
Identita úlohy: Skript přiřazuje roli Přispěvatel dat fronty úložiště a Přispěvatel dat tabulky úložiště za účelem zajištění přístupu na základě role (RBAC) k této spravované identitě, která je přidružená k účtu služby Kubernetes, který se používá jako identita pro pody, na kterých jsou nasazené kontejnery aplikací příjemce.
Dvě federované přihlašovací údaje: Jedna přihlašovací údaje umožňují spravované identitě implementovat identitu podu a další přihlašovací údaje se používají pro účet služby operátora KEDA k poskytnutí přístupu ke škálovacímu nástroji KEDA za účelem shromáždění metrik potřebných k řízení automatického škálování podů.

Ověření nasazení a spuštění úlohy

Po dokončení skriptu nasazení můžete úlohu nasadit v clusteru AKS.

Nastavte zdroj pro shromažďování a aktualizaci proměnných prostředí pro ./deployment/environmentVariables.sh použití následujícího příkazu:
```
source ./deployment/environmentVariables.sh
```

K nastavení proměnných prostředí pro názvy prostředků vytvořených v nasazení potřebujete informace v ./deployment/deploy.state souboru. Pomocí následujícího cat příkazu zobrazte obsah souboru:

cat ./deployment/deploy.state

Výstup by měl obsahovat následující proměnné:

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=

Pomocí následujících příkazů si přečtěte soubor a vytvořte proměnné prostředí pro názvy prostředků Azure vytvořených skriptem nasazení:
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```
Pomocí příkazu získejte přihlašovací údaje clusteru az aks get-credentials AKS.
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME
```
Pomocí příkazu ověřte, že pody operátoru KEDA běží v kube-system oboru názvů v clusteru kubectl get AKS.
```
kubectl get pods --namespace kube-system | grep keda
```
Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

Generování simulovaného zatížení

Teď pomocí aplikace producenta vygenerujete simulované zatížení k naplnění fronty zprávami.

V samostatném okně terminálu přejděte do adresáře projektu.
Nastavte proměnné prostředí pomocí kroků v předchozí části. 1. Spusťte aplikaci producenta pomocí následujícího příkazu:
```
python3 ./app/keda/aqs-producer.py
```
Jakmile aplikace začne posílat zprávy, přepněte zpátky do druhého okna terminálu.

Kontejner aplikace příjemce nasaďte do clusteru AKS pomocí následujících příkazů:

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

Skript nasazení (deploy-keda-app-workload-id.sh) provádí šablonování specifikace YAML manifestu aplikace za účelem předání proměnných prostředí podu. Projděte si následující výňatek z tohoto skriptu:

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

Popisek azure.workload.identity/use v oddílu spec/template je šablona podu pro nasazení. Nastavením popisku určíte true , že používáte identitu úlohy. Ve serviceAccountName specifikaci podu určuje účet služby Kubernetes, který se má přidružit k identitě úlohy. Specifikace podu sice obsahuje odkaz na image v privátním úložišti, ale není zadaná žádná imagePullSecret hodnota.

Pomocí příkazu ověřte, že se skript úspěšně kubectl get spustil.
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
Ve výstupu by se měl zobrazit jeden pod.
Ověřte, že byl vytvořen fond uzlů Karpenter. Proveďte to pomocí kubectl get nodepool příkazu. Odpověď příkazu bude vypadat takto:

Pomocí příkazu ověřte, že výchozí fond uzlů je fond kubectl describe nodepool uzlů Karpenter. V odpovědi příkazu můžete ověřit, že fond uzlů je fond uzlů Karpenter. Měli byste vidět přibližně toto:

Monitorování horizontálního navýšení kapacity podů a uzlů pomocí k9s

K ověření provozu aplikací nasazených do AKS, včetně webu Azure Portal a k9s, můžete použít různé nástroje. Další informace o k9s najdete v přehledu k9s.

Nainstalujte do clusteru AKS k9s odpovídající pokyny pro vaše prostředí v přehledu instalace k9s.
Vytvořte dvě okna, jedno s zobrazením podů a druhou s zobrazením uzlů v oboru názvů, který jste zadali v AQS_TARGET_NAMESPACE proměnné prostředí (výchozí hodnota je aqs-demo) a spusťte v každém okně k9s.

Mělo by se zobrazit něco podobného:
Jakmile potvrdíte, že je kontejner aplikace příjemce nainstalovaný a spuštěný v clusteru AKS, nainstalujte ScaledObject a aktivujte ověřování používané nástrojem KEDA pro automatické škálování podů spuštěním instalačního skriptu škálovaného objektu (keda-scaleobject-workload-id.sh). pomocí následujících příkazů:
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
Skript také provede šablonování pro vložení proměnných prostředí tam, kde je to potřeba. Projděte si následující výňatek z tohoto skriptu:
```
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
```
Manifest popisuje dva prostředky: TriggerAuthentication objekt, který určuje KEDA, že škálovaný objekt používá identitu podu pro ověřování, a identityID vlastnost, která odkazuje na spravovanou identitu použitou jako identitu úlohy.

Když je škálovaný objekt správně nainstalovaný a KEDA zjistí překročení prahové hodnoty škálování, začne plánovat pody. Pokud používáte k9s, měli byste vidět něco takového:

Pokud producentovi povolíte vyplnit frontu dostatečným množství zpráv, možná bude potřeba naplánovat více podů, než mají uzly obsluhovat. Aby to bylo možné, Karpenter začne s plánováním uzlů. Pokud používáte k9s, měli byste vidět něco takového:

V těchto dvou obrázcích si všimněte, jak se počet uzlů, jejichž názvy obsahují, zvětšily aks-default z jednoho na tři uzly. Pokud aplikaci producenta zastavíte ve vkládání zpráv do fronty, příjemci nakonec sníží hloubku fronty pod prahovou hodnotu a keDA i Karpenter se škálují. Pokud používáte k9s, měli byste vidět něco takového:
Nakonec můžete zobrazit aktivitu automatického škálování Karpenteru kubectl get events pomocí příkazu, jak je znázorněno tady:

Vyčištění prostředků

Pomocí skriptu vyčištění (/deployment/infra/cleanup.sh) v našem úložišti GitHub můžete odebrat všechny prostředky, které jste vytvořili.

Další kroky

Další informace o vývoji a spouštění aplikací v AKS najdete v následujících zdrojích informací:

Přispěvatelé

Microsoft udržuje tento článek. Následující přispěvatelé ho původně napsali:

Ken Kilty | Hlavní čip TPM
Russell de Pina | Hlavní čip TPM
Jenny Hayes | Vedoucí vývojář obsahu
Carol Smith | Vedoucí vývojář obsahu
Erin Schaffer | Content Developer 2

Váš názor

Byla tato stránka užitečná?

Poslední aktualizace v 2024-11-01