AWS olay odaklı iş akışı (EDW) iş yükünü Azure'a dağıtma

Bu makalede Azure'a bir AWS EDW iş yükü dağıtacaksınız.

Azure'da oturum açma

1. komutunu kullanarak Azure'da az login oturum açın.

   az login
   

2. Azure hesabınızın birden çok aboneliği varsa doğru aboneliği seçtiğinizden emin olun. komutunu kullanarak aboneliklerinizin adlarını ve kimliklerini listeleyin az account list .

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

3. komutunu kullanarak az account set belirli bir aboneliği seçin.

   az account set --subscription $subscriptionId
   

EDW iş yükü dağıtım betiği

Dosyadaki deployment/environmentVariables.sh ortam değişkenlerini gözden geçirin ve uygulamayı Azure'a dağıtmak için GitHub deposunun deploy.sh dizinindeki deployment/infra/ betiği kullanın.

Betik önce tüm önkoşul araçlarının yüklenip yüklenmediğini denetler. Aksi takdirde betik sonlandırılır ve hangi önkoşulların eksik olduğunu bildiren bir hata iletisi görüntüler. Böyle bir durumda önkoşulları gözden geçirin, eksik araçları yükleyin ve betiği yeniden çalıştırın. AKS için Düğüm otomatik sağlama (NAP) özellik bayrağıNın Azure aboneliğinize kaydedilmesi gerekir. Henüz kaydedilmemişse, betik özellik bayrağını kaydetmek için bir Azure CLI komutu yürütür.

Betik, dağıtımın durumunu dizininde bulunan adlı deploy.statebir dosyaya deployment kaydeder. Uygulamayı dağıtırken ortam değişkenlerini ayarlamak için bu dosyayı kullanabilirsiniz.

Betik, iş akışı için altyapıyı yapılandırma komutlarını yürütürken, her komutun başarıyla yürütüldüğünü denetler. Herhangi bir sorun oluşursa bir hata iletisi görüntülenir ve yürütme durdurulur.

Betik, çalıştırılırken bir günlük görüntüler. Aşağıdaki komutları kullanarak günlük bilgileri çıkışını yeniden yönlendirip dizindeki install.log dosyaya logs kaydederek günlüğü kalıcı hale getirmeniz gerekir:

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

Daha fazla bilgi için GitHub depomuzdaki ./deployment/infra/deploy.shbetike bakın.

İş yükü kaynakları

Dağıtım betiği aşağıdaki Azure kaynaklarını oluşturur:

• Azure kaynak grubu: Dağıtım betiği tarafından oluşturulan kaynakları depolayan Azure kaynak grubu .

• Azure Depolama hesabı: İletilerin üretici uygulama tarafından gönderildiği ve tüketici uygulaması tarafından okunduğu kuyruğu içeren Azure Depolama hesabı ve tüketici uygulamasının işlenen iletileri depoladığı tablo.

• Azure kapsayıcı kayıt defteri: Kapsayıcı kayıt defteri, yeniden düzenlenmiş tüketici uygulama kodunu dağıtan kapsayıcı için bir depo sağlar.

• Azure Kubernetes Service (AKS) kümesi: AKS kümesi, tüketici uygulaması kapsayıcısı için Kubernetes düzenlemesi sağlar ve aşağıdaki özellikleri etkinleştirmiştir:

  • Düğüm otomatik sağlama (NAP): AKS'de Karpenter düğüm otomatik ölçeklendiricisinin uygulanması.
  • Kubernetes Olay Odaklı Otomatik Ölçeklendirme (KEDA):KEDA, belirtilen kuyruk derinliği eşiğini aşma gibi olaylara göre pod ölçeklendirmeyi etkinleştirir.
  • İş yükü kimliği: Gelişmiş güvenlik için pod kimliklerine rol tabanlı erişim ilkeleri eklemenize olanak tanır.
  • Ekli Azure kapsayıcı kayıt defteri: Bu özellik AKS kümesinin belirtilen ACR örneğindeki depolardan görüntü çekmesine olanak tanır.

• Uygulama ve sistem düğümü havuzu: Betik ayrıca AKS kümesinde uygulama podlarının sistem düğümü havuzunda zamanlanmasını önlemek için bir taint içeren bir uygulama ve sistem düğümü havuzu da oluşturur.

• AKS kümesi yönetilen kimliği: Betik, rolü bu yönetilen kimliğe atar acrPull ve bu da görüntüleri çekmek için ekli Azure kapsayıcı kayıt defterine erişimi kolaylaştırır.

• İş yükü kimliği: Betik, tüketici uygulaması kapsayıcılarının dağıtıldığı podlar için kimlik olarak kullanılan Kubernetes hizmet hesabıyla ilişkili olan bu yönetilen kimliğe rol tabanlı erişim denetimi (RBAC) erişimi sağlamak için Depolama Kuyruğu Veri Katkıda Bulunanı ve Depolama Tablosu Veri Katkıda Bulunanı rollerini atar.

• İki federasyon kimlik bilgisi: Bir kimlik bilgisi, yönetilen kimliğin pod kimliği uygulamasına olanak tanırken, diğer kimlik bilgisi keda işleci hizmet hesabının pod otomatik ölçeklendirmesini denetlemek için gereken ölçümleri toplamak üzere KEDA ölçekleyicisine erişim sağlaması için kullanılır.

Dağıtımı doğrulama ve iş yükünü çalıştırma

Dağıtım betiği tamamlandıktan sonra iş yükünü AKS kümesine dağıtabilirsiniz.

1. Aşağıdaki komutu kullanarak ortam değişkenlerini toplamak ve güncelleştirmek için ./deployment/environmentVariables.sh kaynağı ayarlayın:

   source ./deployment/environmentVariables.sh
   

2. Dağıtımda ./deployment/deploy.state oluşturulan kaynakların adları için ortam değişkenlerini ayarlamak için dosyadaki bilgilere ihtiyacınız vardır. Aşağıdaki cat komutu kullanarak dosyanın içeriğini görüntüleyin:

   cat ./deployment/deploy.state
   

   Çıkışınız aşağıdaki değişkenleri göstermelidir:

   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. Aşağıdaki komutları kullanarak dosyayı okuyun ve dağıtım betiği tarafından oluşturulan Azure kaynaklarının adları için ortam değişkenleri oluşturun:

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

4. komutunu kullanarak az aks get-credentials AKS kümesi kimlik bilgilerini alın.

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

5. komutunu kullanarak kube-system AKS kümesindeki ad alanında kubectl get KEDA işleç podlarının çalıştığını doğrulayın.

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

   Çıkışınız aşağıdaki örnek çıkışa benzer olmalıdır:

   

Sanal yük oluşturma

Şimdi, kuyruğu iletilerle doldurmak için üretici uygulamasını kullanarak sanal yük oluşturacaksınız.

1. Ayrı bir terminal penceresinde proje dizinine gidin.

2. Önceki bölümdeki adımları kullanarak ortam değişkenlerini ayarlayın. 1. Aşağıdaki komutu kullanarak üretici uygulamasını çalıştırın:

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

3. Uygulama ileti göndermeye başladıktan sonra diğer terminal penceresine geri dönün.

4. Aşağıdaki komutları kullanarak tüketici uygulaması kapsayıcısını AKS kümesine dağıtın:

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

   Dağıtım betiği (deploy-keda-app-workload-id.sh), ortam değişkenlerini pod'a geçirmek için uygulama bildirimi YAML belirtiminde şablon oluşturma gerçekleştirir. Bu betikten aşağıdaki alıntıyı gözden geçirin:

   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 bölümündeki etiketspec/template, dağıtımın pod şablonudur. Etiketi olarak true ayarlamak, iş yükü kimliğini kullandığınızı belirtir. serviceAccountName pod belirtiminde, iş yükü kimliğiyle ilişkilendirilecek Kubernetes hizmet hesabını belirtir. Pod belirtimi özel depodaki bir görüntü için başvuru içeriyor olsa da, belirtilmemiş imagePullSecret .

5. komutunu kullanarak kubectl get betiğin başarıyla çalıştığını doğrulayın.

   kubectl get pods --namespace $AQS_TARGET_NAMESPACE
   

   Çıktıda tek bir pod görmeniz gerekir.

6. Karpenter düğüm havuzunun oluşturulduğunu doğrulayın. Komutunu kullanarak kubectl get nodepool bunu yapın. Komut yanıtı şöyle görünür:

   

   komutunu kullanarak kubectl describe nodepool varsayılan düğüm havuzunun bir Karpenter düğüm havuzu olduğunu doğrulayın. Komut yanıtında düğüm havuzunun bir Karpenter düğüm havuzu olduğunu doğrulayabilirsiniz. Şuna benzer bir şey görmeniz gerekir:

   

K9'larla podlar ve düğümler için ölçeği genişletmeyi izleme

Azure portalı ve k9'lar dahil olmak üzere AKS'ye dağıtılan uygulamaların çalışmasını doğrulamak için çeşitli araçları kullanabilirsiniz. K9'lar hakkında daha fazla bilgi için bkz . k9'lara genel bakış.

1. K9s yüklemesine genel bakış bölümünde ortamınız için uygun yönergeleri kullanarak AKS kümenize k9'ları yükleyin.

2. Biri podların, diğeri ise ortam değişkeninde belirttiğiniz AQS_TARGET_NAMESPACE ad alanında düğümlerin görünümünü içeren (varsayılan değer: aqs-demo) iki pencere oluşturun ve her pencerede k9'ları başlatın.

   Aşağıdakine benzer bir şey görmeniz gerekir:

   

3. Tüketici uygulaması kapsayıcısının AKS kümesinde yüklendiğini ve çalıştığını onayladıktan sonra, ölçeklendirilmiş nesne yükleme betiğini (ScaledObject) çalıştırarak POD otomatik ölçeklendirmesi için KEDA tarafından kullanılan ve kimlik doğrulamasını yükleyinkeda-scaleobject-workload-id.sh. aşağıdaki komutları kullanarak:

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

   Betik ayrıca gerektiğinde ortam değişkenlerini eklemek için şablon oluşturma gerçekleştirir. Bu betikten aşağıdaki alıntıyı gözden geçirin:

   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
   

   Bildirimde iki kaynak açıklanır: TriggerAuthenticationKEDA'ya ölçeklendirilmiş nesnenin kimlik doğrulaması için pod kimliği kullandığını belirten nesnesi ve identityID iş yükü kimliği olarak kullanılan yönetilen kimliğe başvuran özelliği.

   Ölçeklendirilmiş nesne doğru şekilde yüklendiğinde ve KEDA ölçeklendirme eşiğinin aşıldığını algıladığında podları zamanlamaya başlar. K9s kullanıyorsanız aşağıdakine benzer bir şey görmeniz gerekir:

   

   Üreticinin kuyruğu yeterli iletiyle doldurmasına izin verirseniz, KEDA'nın hizmet verecek düğümlerden daha fazla pod zamanlaması gerekebilir. Buna uyum sağlamak için Karpenter devreye girip düğümleri zamanlamaya başlayacaktır. K9s kullanıyorsanız aşağıdakine benzer bir şey görmeniz gerekir:

   

   Bu iki görüntüde, adları içeren aks-default düğüm sayısının bir düğümden üç düğüme nasıl arttığına dikkat edin. Üretici uygulamasının kuyruğa ileti yerleştirmesini durdurursanız, sonunda tüketiciler kuyruk derinliğini eşiğin altına indirir ve hem KEDA hem de Karpenter ölçeği daraltacaktır. K9s kullanıyorsanız aşağıdakine benzer bir şey görmeniz gerekir:

   

4. Son olarak, burada gösterildiği gibi komutunu kullanarak kubectl get events Karpenter otomatik ölçeklendirme etkinliğini görüntüleyebilirsiniz:

   

Kaynakları temizleme

Oluşturduğunuz tüm kaynakları kaldırmak için GitHub depomuzdaki /deployment/infra/cleanup.sh temizleme betiğini () kullanabilirsiniz.

Sonraki adımlar

AKS'de uygulama geliştirme ve çalıştırma hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

• AKS'de Helm ile mevcut uygulamaları yükleme
• AKS'de Azure Market kubernetes uygulaması dağıtma ve yönetme
• AKS üzerinde OpenAI kullanan bir uygulama dağıtma

Katkıda Bulunanlar

Microsoft bu makaleyi korur. Başlangıçta aşağıdaki katkıda bulunanlar yazdı:

• Ken Kilty | Asıl TPM
• Russell de Pina | Asıl TPM
• Jenny Hayes | Kıdemli İçerik Geliştirici
• Carol Smith | Kıdemli İçerik Geliştirici
• Erin Schaffer | İçerik Geliştirici 2