部署 AWS 事件驅動工作流程 (EDW) 工作負載部署至 Azure

在本文中，您會將 AWS EDW 工作負載部署至 Azure。

使用 az login 命令登入 Azure。
```
az login
```
如果您的 Azure 帳戶有多個訂用帳戶，請確保選取正確的訂用帳戶。使用 az account list 命令列出訂用帳戶的名稱和識別碼。
```
az account list --query "[].{id: id, name:name }" --output table
```
使用 az account set 命令選取特定訂用帳戶。
```
az account set --subscription $subscriptionId
```

EDW 工作負載部署指令碼

檢閱檔案 deployment/environmentVariables.sh 中的環境變數，然後使用 deploy.shdeployment/infra/ 目錄中的指令碼，將應用程式部署至 Azure。

指令碼會先檢查是否已安裝所有必要條件工具。如果未安裝，指令碼會終止並顯示錯誤訊息，讓您了解缺少的必要條件。如果發生此情況，請檢閱必要條件、安裝任何缺少的工具，然後再次執行指令碼。必須在 Azure 訂用帳戶上註冊 [AKS 的節點自動佈建 (NAP)] 功能旗標。如果尚未註冊，指令碼會執行 Azure CLI 命令以註冊功能旗標。

指令碼會在名為 deploy.state 的檔案中記錄部署狀態，您可在 deployment 目錄中找到該檔案。部署應用程式時，您可以使用此檔案以設定環境變數。

指令碼執行命令以設定工作流程的基礎結構時，會檢查每個命令是否成功執行。如果發生問題，便會顯示錯誤訊息並停止執行。

指令碼會在執行時顯示記錄。您可以使用下列命令，將記錄資訊輸出重新導向並儲存至 install.log 目錄中的 logs 檔案以保存記錄：

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

如需詳細資訊，請參閱 ./deployment/infra/deploy.sh中的指令碼。

工作負載資源

部署指令碼會建立下列 Azure 資源：

Azure 資源群組：Azure 資源群組，用於儲存部署指令碼所建立的資源。
Azure 儲存體帳戶：Azure 儲存體帳戶，其中包含產生者應用程式傳送和取用者應用程式讀取訊息所在的佇列，以及取用者應用程式儲存已處理訊息所在的資料表。
Azure container registry：容器登錄為部署重構取用者應用程式程式碼的容器提供存放庫。
Azure Kubernetes Service (AKS) 叢集：AKS 叢集為取用者應用程式容器提供 Kubernetes 協調流程，並已啟用下列功能：
- 節點自動佈建 (NAP)：在 AKS 上實作 Karpenter 節點自動調整程式。
- Kubernetes 事件驅動自動調整 (KEDA)：KEDA 會根據事件 (例如超過指定佇列深度閾值) 來啟用 Pod 調整。
- 工作流程身分識別：允許您將角色型存取原則連結至 Pod 身分識別，藉此增強安全性。
- 連結的 Azure 容器登錄：此功能可讓 AKS 叢集從指定 ACR 執行個體上的存放庫提取映像。
應用程式和系統節點集區：指令碼也會在具有汙點的 AKS 叢集中建立應用程式和系統節點集區，藉此防止在系統節點集區中排程應用程式 Pod。
AKS 叢集受控識別：指令碼會將 acrPull 角色指派給此受控識別，以便可存取連結的 Azure 容器登錄來提取映像。
工作負載身分識別：指令碼會指派儲存體佇列資料參與者和儲存體資料表資料參與者角色以提供此受控識別的角色型存取控制 (RBAC) 存取權，此受控識別與 Kubernetes 服務帳戶相關聯並針對部署取用者應用程式容器的 Pod 作為身分識別使用。
兩個同盟認證：一個認證可讓受控識別實作 Pod 身分識別，而另一個認證用於 KEDA 運算子服務帳戶以提供 KEDA 調整程式的存取權，進而收集控制 Pod 自動調整所需的計量。

驗證部署並執行工作負載

完成部署指令碼後，您可以在 AKS 叢集上部署工作負載。

使用下列命令設定收集和更新 ./deployment/environmentVariables.sh 環境變數的來源：
```
source ./deployment/environmentVariables.sh
```

您需要 ./deployment/deploy.state 檔案中的資訊，才能針對部署中建立的資源名稱設定環境變數。使用下列 cat 命令以顯示檔案的內容：

cat ./deployment/deploy.state

您的輸出應顯示下列變數：

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=

使用下列命令以讀取檔案，並針對部署指令碼建立的 Azure 資源名稱建立環境變數：
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```

使用 az aks get-credentials 命令以取得 ASK 叢集認證。

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

使用 kube-system 命令以驗證 KEDA 運算子 Pod 正在 AKS 叢集的 kubectl get 命名空間中執行。
```
kubectl get pods --namespace kube-system | grep keda
```
您的輸出看起來應類似下列的範例輸出：

產生模擬負載

您現在會使用生產者應用程式產生模擬負載以將訊息填入佇列。

在不同的終端視窗中，瀏覽至專案目錄。
使用上一節中的步驟以設定環境變數。 1. 使用下列命令以執行生產者應用程式：
```
python3 ./app/keda/aqs-producer.py
```
應用程式開始傳送應用程式後，請切換回其他終端視窗。

使用下列命令以將取用者應用程式部署至 AKS 叢集：

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

部署指令碼 (deploy-keda-app-workload-id.sh) 會在應用程式資訊清單 YAML 規格上執行範本化以將環境變數傳遞至 Pod。檢閱下列此指令碼的摘錄：

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

azure.workload.identity/use 區段中的 spec/template 標籤是部署的 Pod 範本。將標籤設定為 true 會說明您正在使用工作負載身分識別。 Pod 規格中的 serviceAccountName 會指定與工作負載身分識別建立關聯的 Kubernetes 服務帳戶。即使 Pod 規格包含私人存放庫中映像的參考，則不會指定 imagePullSecret。

使用 kubectl get 命令以驗證成功執行指令碼。
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
您應在輸出中看到單一 Pod。
確認已建立 Karpenter 節點集區。使用 kubectl get nodepool 命令執行此動作。命令回應看起來會像這樣：

使用 kubectl describe nodepool 命令確認預設節點集區是 Karpenter 節點集區。在命令回應中，您可以確認節點集區是 Karpenter 節點集區。您應該會看到類似這樣的畫面︰

使用 k9s 監視 Pod 和節點的向外延展

您可以使用各種工具以驗證部署至 AKS 的應用程式作業，包含 Azure 入口網站和 k9s。如需 k9s 的詳細資訊，請參閱k9s 概觀。

使用 k9s 安裝概觀中適當的環境指引，於 AKS 叢集上安裝 k9s。
建立兩個視窗，一個用於檢視 Pod，另一個用於檢視 AQS_TARGET_NAMESPACE 環境變數 (預設值為 aqs-demo) 中指定命名空間的節點，並在各視窗中啟動 k9s。

您應該會看到類似下面的內容：
確認在 AKS 叢集上安裝並執行取用者應用程式容器之後，請透過執行調整物件安裝指令碼 (ScaledObject) 以安裝 KEDA 用於 Pod 自動調整的 keda-scaleobject-workload-id.sh 並觸發驗證。使用下令命令：
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
指令碼也會執行範本化以視需要插入環境變數。檢閱下列此指令碼的摘錄：
```
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
```
資訊清單描述兩個資源：TriggerAuthentication 物件可向 KEDA 指定調整物件正在使用 Pod 身分識別進行驗證，而 identityID 屬性指的是作為工作負載身分識別的受控識別。

正確安裝調整物件且 KEDA 偵測到超過調整閾值時，則會開始排程 Pod。如果您使用 k9s，您應會看到如下的內容：

如果您允許生產者將足夠訊息填入佇列，則 KEDA 必須排程的節點可能大於要服務的節點。為了配合此作業，Karpenter 將開始排程節點。如果您使用 k9s，您應會看到如下的內容：

在這兩個映像中，請注意名稱中包含 aks-default 的節點數目如何從一個節點增加至三個節點。如果您防止生產者應用程式將訊息放置佇列，則取用者最終將會降低低於閾值的佇列深度，且 KEDA 和 Karpenter 將縮減。如果您使用 k9s，您應會看到如下的內容：
最後，您可以使用命令來檢視 Karpenter 自動調整活動 kubectl get events ，如下所示：