Menyebarkan beban kerja alur kerja berbasis peristiwa (EDW) AWS ke Azure

Artikel
02/08/2024

Dalam artikel ini, Anda akan menyebarkan beban kerja AWS EDW ke Azure.

Masuk ke Azure menggunakan az login perintah .
```
az login
```
Jika akun Azure Anda memiliki beberapa langganan, pastikan untuk memilih langganan yang benar. Cantumkan nama dan ID langganan Anda menggunakan az account list perintah .
```
az account list --query "[].{id: id, name:name }" --output table
```
Pilih langganan tertentu menggunakan az account set perintah .
```
az account set --subscription $subscriptionId
```

Skrip penyebaran beban kerja EDW

Tinjau variabel lingkungan dalam file deployment/environmentVariables.sh lalu Anda menggunakan deploy.sh skrip di deployment/infra/ direktori repositori GitHub untuk menyebarkan aplikasi ke Azure.

Skrip pertama-tama memeriksa bahwa semua alat prasyarat diinstal. Jika tidak, skrip mengakhiri dan menampilkan pesan kesalahan yang memberi tahu Anda prasyarat mana yang hilang. Jika ini terjadi, tinjau prasyarat, instal alat yang hilang, lalu jalankan skrip lagi. Bendera fitur Node autoprovisioning (NAP) untuk AKS harus didaftarkan di langganan Azure Anda. Jika belum terdaftar, skrip menjalankan perintah Azure CLI untuk mendaftarkan bendera fitur.

Skrip merekam status penyebaran dalam file yang disebut deploy.state, yang terletak di deployment direktori. Anda dapat menggunakan file ini untuk mengatur variabel lingkungan saat menyebarkan aplikasi.

Saat skrip menjalankan perintah untuk mengonfigurasi infrastruktur untuk alur kerja, skrip memeriksa bahwa setiap perintah berhasil dijalankan. Jika terjadi masalah, pesan kesalahan ditampilkan, dan eksekusi berhenti.

Skrip menampilkan log saat berjalan. Anda dapat mempertahankan log dengan mengalihkan output informasi log dan menyimpannya ke install.log file di logs direktori menggunakan perintah berikut:

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

Untuk informasi selengkapnya, lihat ./deployment/infra/deploy.sh skrip di repositori GitHub kami.

Sumber daya beban kerja

Skrip penyebaran membuat sumber daya Azure berikut:

Grup sumber daya Azure: Grup sumber daya Azure yang menyimpan sumber daya yang dibuat oleh skrip penyebaran.
Akun Azure Storage: Akun Azure Storage yang berisi antrean tempat pesan dikirim oleh aplikasi produsen dan dibaca oleh aplikasi konsumen, dan tabel tempat aplikasi konsumen menyimpan pesan yang diproses.
Registri kontainer Azure: Registri kontainer menyediakan repositori untuk kontainer yang menyebarkan kode aplikasi konsumen yang direfaktor.
Kluster Azure Kubernetes Service (AKS): Kluster AKS menyediakan orkestrasi Kubernetes untuk kontainer aplikasi konsumen dan memiliki fitur berikut yang diaktifkan:
- Provisi otomatis simpul (NAP): Implementasi autoscaler simpul Karpenter pada AKS.
- Autoscaling berbasis Peristiwa (KEDA) Kubernetes: KEDA memungkinkan penskalakan pod berdasarkan peristiwa, seperti melebihi ambang batas kedalaman antrean yang ditentukan.
- Identitas beban kerja: Memungkinkan Anda melampirkan kebijakan akses berbasis peran ke identitas pod untuk keamanan yang ditingkatkan.
- Registri kontainer Azure terlampir: Fitur ini memungkinkan kluster AKS untuk menarik gambar dari repositori pada instans ACR yang ditentukan.
Kumpulan simpul aplikasi dan sistem: Skrip juga membuat kumpulan simpul aplikasi dan sistem di kluster AKS yang memiliki taint untuk mencegah pod aplikasi dijadwalkan di kumpulan simpul sistem.
Identitas terkelola kluster AKS: Skrip menetapkan peran ke identitas terkelola ini, yang memfasilitasi akses ke registri acrPull kontainer Azure yang terpasang untuk menarik gambar.
Identitas beban kerja: Skrip menetapkan peran Kontributor Data Antrean Penyimpanan dan Kontributor Data Tabel Penyimpanan untuk menyediakan akses kontrol akses berbasis peran (RBAC) ke identitas terkelola ini, yang terkait dengan akun layanan Kubernetes yang digunakan sebagai identitas untuk pod tempat kontainer aplikasi konsumen disebarkan.
Dua kredensial federasi: Satu kredensial memungkinkan identitas terkelola untuk mengimplementasikan identitas pod, dan kredensial lainnya digunakan untuk akun layanan operator KEDA untuk menyediakan akses ke penskala KEDA untuk mengumpulkan metrik yang diperlukan untuk mengontrol penskalaan otomatis pod.

Memvalidasi penyebaran dan menjalankan beban kerja

Setelah skrip penyebaran selesai, Anda dapat menyebarkan beban kerja pada kluster AKS.

Atur sumber untuk mengumpulkan dan memperbarui variabel lingkungan untuk ./deployment/environmentVariables.sh menggunakan perintah berikut:
```
source ./deployment/environmentVariables.sh
```

Anda memerlukan informasi dalam ./deployment/deploy.state file untuk mengatur variabel lingkungan untuk nama sumber daya yang dibuat dalam penyebaran. Tampilkan konten file menggunakan perintah berikut cat :

cat ./deployment/deploy.state

Output Anda harus menampilkan variabel berikut:

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=

Baca file dan buat variabel lingkungan untuk nama sumber daya Azure yang dibuat oleh skrip penyebaran menggunakan perintah berikut:
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```

Dapatkan kredensial kluster AKS menggunakan az aks get-credentials perintah .

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

Verifikasi bahwa pod operator KEDA berjalan di kube-system namespace pada kluster AKS menggunakan kubectl get perintah .
```
kubectl get pods --namespace kube-system | grep keda
```
Output Anda akan terlihat mirip dengan contoh output berikut:

Hasilkan beban yang disimulasikan

Sekarang, Anda menghasilkan beban simulasi menggunakan aplikasi produsen untuk mengisi antrean dengan pesan.

Di jendela terminal terpisah, navigasikan ke direktori proyek.
Atur variabel lingkungan menggunakan langkah-langkah di bagian sebelumnya. 1. Jalankan aplikasi produsen menggunakan perintah berikut:
```
python3 ./app/keda/aqs-producer.py
```
Setelah aplikasi mulai mengirim pesan, beralih kembali ke jendela terminal lainnya.

Sebarkan kontainer aplikasi konsumen ke kluster AKS menggunakan perintah berikut:

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

Skrip penyebaran (deploy-keda-app-workload-id.sh) melakukan templat pada spesifikasi YAML manifes aplikasi untuk meneruskan variabel lingkungan ke pod. Tinjau kutipan berikut dari skrip ini:

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

Label azure.workload.identity/use di bagian spec/template adalah templat pod untuk penyebaran. Mengatur label untuk true menentukan bahwa Anda menggunakan identitas beban kerja. Dalam serviceAccountName spesifikasi pod menentukan akun layanan Kubernetes untuk dikaitkan dengan identitas beban kerja. Meskipun spesifikasi pod berisi referensi untuk gambar di repositori privat, tidak imagePullSecret ada yang ditentukan.

Verifikasi bahwa skrip berhasil dijalankan menggunakan kubectl get perintah .
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
Anda akan melihat satu pod dalam output.
Verifikasi bahwa kumpulan simpul Karpenter telah dibuat. Lakukan ini menggunakan kubectl get nodepool perintah . Respons perintah akan terlihat seperti ini:

Verifikasi bahwa kumpulan simpul default adalah kumpulan simpul Karpenter menggunakan kubectl describe nodepool perintah . Dalam respons perintah, Anda dapat memverifikasi bahwa kumpulan simpul adalah kumpulan simpul Karpenter. Anda seharusnya melihat sesuatu seperti berikut:

Memantau peluasan skala untuk pod dan node dengan k9

Anda dapat menggunakan berbagai alat untuk memverifikasi pengoperasian aplikasi yang disebarkan ke AKS, termasuk portal Azure dan k9. Untuk informasi selengkapnya tentang k9, lihat gambaran umum k9.

Instal k9 pada kluster AKS Anda menggunakan panduan yang sesuai untuk lingkungan Anda dalam gambaran umum penginstalan k9s.
Buat dua jendela, satu dengan tampilan pod dan yang lain dengan tampilan simpul di namespace yang Anda tentukan dalam AQS_TARGET_NAMESPACE variabel lingkungan (nilai default adalah aqs-demo) dan mulai k9 di setiap jendela.

Anda akan melihat sesuatu yang mirip dengan contoh berikut:
Setelah Anda mengonfirmasi bahwa kontainer aplikasi konsumen diinstal dan berjalan pada kluster AKS, instal ScaledObject dan picu autentikasi yang digunakan oleh KEDA untuk penskalaan otomatis pod dengan menjalankan skrip penginstalan objek yang diskalakan (keda-scaleobject-workload-id.sh). menggunakan perintah berikut:
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
Skrip juga melakukan templat untuk menyuntikkan variabel lingkungan jika diperlukan. Tinjau kutipan berikut dari skrip ini:
```
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
```
Manifes menjelaskan dua sumber daya: TriggerAuthentication objek , yang menentukan keDA bahwa objek yang diskalakan menggunakan identitas pod untuk autentikasi, dan identityID properti , yang mengacu pada identitas terkelola yang digunakan sebagai identitas beban kerja.

Ketika objek yang diskalakan dipasang dengan benar dan KEDA mendeteksi ambang penskalaan terlampaui, objek mulai menjadwalkan pod. Jika Anda menggunakan k9, Anda akan melihat sesuatu seperti ini:

Jika Anda mengizinkan produser untuk mengisi antrean dengan pesan yang cukup, KEDA mungkin perlu menjadwalkan lebih banyak pod daripada simpul yang akan dilayani. Untuk mengakomodasi hal ini, Karpenter akan menendang dan mulai menjadwalkan simpul. Jika Anda menggunakan k9, Anda akan melihat sesuatu seperti ini:

Dalam kedua gambar ini, perhatikan bagaimana jumlah simpul yang namanya berisi aks-default meningkat dari satu menjadi tiga simpul. Jika Anda menghentikan aplikasi produsen untuk menempatkan pesan pada antrean, akhirnya konsumen akan mengurangi kedalaman antrean di bawah ambang batas, dan KEDA dan Karpenter akan menskalakan masuk. Jika Anda menggunakan k9, Anda akan melihat sesuatu seperti ini:
Terakhir, Anda dapat melihat aktivitas autoscaling Karpenter menggunakan perintah seperti yang ditunjukkan kubectl get events di sini:

Membersihkan sumber daya

Anda dapat menggunakan skrip pembersihan (/deployment/infra/cleanup.sh) di repositori GitHub kami untuk menghapus semua sumber daya yang Anda buat.

Langkah berikutnya

Untuk informasi selengkapnya tentang mengembangkan dan menjalankan aplikasi di AKS, lihat sumber daya berikut:

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut awalnya menulisnya:

Ken Kilty | TPM Utama
Russell de Pina | TPM Utama
Jenny Hayes | Pengembang Konten Senior
Carol Smith | Pengembang Konten Senior
Erin Schaffer | Pengembang Konten 2

Microsoft Learn Challenge

Bagikan melalui

Menyebarkan beban kerja alur kerja berbasis peristiwa (EDW) AWS ke Azure

Skrip penyebaran beban kerja EDW

Sumber daya beban kerja

Memvalidasi penyebaran dan menjalankan beban kerja

Hasilkan beban yang disimulasikan

Memantau peluasan skala untuk pod dan node dengan k9

Membersihkan sumber daya

Langkah berikutnya

Kontributor

Sumber Daya Tambahan:

Microsoft Learn Challenge

Bagikan melalui

Menyebarkan beban kerja alur kerja berbasis peristiwa (EDW) AWS ke Azure

Masuk ke Azure

Skrip penyebaran beban kerja EDW

Sumber daya beban kerja

Memvalidasi penyebaran dan menjalankan beban kerja

Hasilkan beban yang disimulasikan

Memantau peluasan skala untuk pod dan node dengan k9

Membersihkan sumber daya

Langkah berikutnya

Kontributor

Sumber Daya Tambahan: