Implantar uma carga de trabalho de fluxo de trabalho orientado a eventos (EDW) da AWS no Azure

Neste artigo, você implantará uma carga de trabalho do AWS EDW no Azure.

Iniciar sessão no Azure

1. Entre no Azure usando o comando az login.

   az login
   

2. Se a sua conta do Azure tiver várias subscrições, certifique-se de que seleciona a subscrição correta. Liste os nomes e IDs de suas assinaturas usando o az account list comando.

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

3. Selecione uma assinatura específica usando o az account set comando.

   az account set --subscription $subscriptionId
   

Script de implantação de carga de trabalho EDW

Examine as variáveis de ambiente no arquivo deployment/environmentVariables.sh e, em seguida, use o deploy.shdeployment/infra/ script no diretório do repositório GitHub para implantar o aplicativo no Azure.

O script primeiro verifica se todas as ferramentas de pré-requisito estão instaladas. Caso contrário, o script é encerrado e exibe uma mensagem de erro informando quais pré-requisitos estão faltando. Se isso acontecer, revise os pré-requisitos, instale as ferramentas ausentes e execute o script novamente. O flag de funcionalidade NAP (Node autoprovisioning) para AKS deve ser registado na subscrição do Azure. Se ainda não estiver registrado, o script executará um comando da CLI do Azure para registrar o sinalizador de recurso.

O script registra o estado da implantação em um arquivo chamado deploy.state, que está localizado no deployment diretório. Você pode usar esse arquivo para definir variáveis de ambiente ao implantar o aplicativo.

À medida que o script executa os comandos para configurar a infraestrutura para o fluxo de trabalho, ele verifica se cada comando é executado com êxito. Se ocorrer algum problema, uma mensagem de erro será exibida e a execução será interrompida.

O script exibe um log enquanto é executado. Você pode persistir o log redirecionando a saída de informações de log e salvando-a no arquivo install.log no diretório logs usando os seguintes comandos:

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

Para obter mais informações, consulte o ./deployment/infra/deploy.sh script em nosso repositório GitHub.

Recursos de carga de trabalho

O script de implantação cria os seguintes recursos do Azure:

• Grupo de recursos do Azure: o grupo de recursos do Azure que armazena os recursos criados pelo script de implantação.

• Conta de Armazenamento do Azure: a conta de Armazenamento do Azure que contém a fila onde as mensagens são enviadas pelo aplicativo produtor e lidas pelo aplicativo consumidor e a tabela onde o aplicativo consumidor armazena as mensagens processadas.

• Registro de contêiner do Azure: o registro de contêiner fornece um repositório para o contêiner que implanta o código do aplicativo consumidor refatorado.

• Cluster do Serviço Kubernetes do Azure (AKS): o cluster AKS fornece orquestração do Kubernetes para o contêiner do aplicativo consumidor e tem os seguintes recursos habilitados:

  • Autoprovisionamento de nó (NAP): A implementação do autoscaler do nó Karpenter no AKS.
  • Kubernetes Event-driven Autoscaling (KEDA): o KEDA permite o dimensionamento de pods com base em eventos, como exceder um limite de profundidade de fila especificado.
  • Identidade da carga de trabalho: Permite anexar políticas de acesso baseadas em função a identidades de pod para maior segurança.
  • Registro de contêiner anexado do Azure: esse recurso permite que o cluster AKS extraia imagens de repositórios na instância ACR especificada.

• Pool de nós de aplicativo e sistema: o script também cria um pool de nós de aplicativo e sistema no cluster AKS que tem uma mancha para impedir que pods de aplicativos sejam agendados no pool de nós do sistema.

• Identidade gerenciada do cluster AKS: o script atribui a acrPull função a essa identidade gerenciada, o que facilita o acesso ao registro de contêiner do Azure anexado para extrair imagens.

• Identidade da carga de trabalho: o script atribui as funções Colaborador de Dados da Fila de Armazenamento e Colaborador de Dados da Tabela de Armazenamento para fornecer acesso RBAC (controle de acesso baseado em função) a essa identidade gerenciada, que está associada à conta de serviço do Kubernetes usada como identidade para pods nos quais os contêineres de aplicativos de consumidor são implantados.

• Duas credenciais federadas: uma credencial permite que a identidade gerenciada implemente a identidade do pod e a outra credencial é usada para que a conta de serviço do operador KEDA forneça acesso ao escalador KEDA para reunir as métricas necessárias para controlar o dimensionamento automático do pod.

Validar a implantação e executar a carga de trabalho

Quando o script de implantação for concluído, você poderá implantar a carga de trabalho no cluster AKS.

1. Defina a origem para recolher e atualizar as variáveis de ambiente para ./deployment/environmentVariables.sh usando o seguinte comando:

   source ./deployment/environmentVariables.sh
   

2. Você precisa das informações no ./deployment/deploy.state arquivo para definir variáveis de ambiente para os nomes dos recursos criados na implantação. Exiba o conteúdo do arquivo usando o seguinte cat comando:

   cat ./deployment/deploy.state
   

   Sua saída deve mostrar as seguintes variáveis:

   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. Leia o arquivo e crie variáveis de ambiente para os nomes dos recursos do Azure criados pelo script de implantação usando os seguintes comandos:

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

4. Obtenha as credenciais do cluster AKS usando o az aks get-credentials comando.

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

5. Verifique se os pods do operador KEDA estão sendo executados no kube-system namespace no cluster AKS usando o kubectl get comando.

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

   Sua saída deve ser semelhante à saída de exemplo a seguir:

   

Gerar carga simulada

Agora, você gera carga simulada usando o aplicativo produtor para preencher a fila com mensagens.

1. Em uma janela de terminal separada, navegue até o diretório do projeto.

2. Defina as variáveis de ambiente usando as etapas na seção anterior. 1. Execute o aplicativo produtor usando o seguinte comando:

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

3. Quando o aplicativo começar a enviar mensagens, volte para a outra janela do terminal.

4. Implante o contêiner do aplicativo consumidor no cluster AKS usando os seguintes comandos:

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

   O script de implantação (deploy-keda-app-workload-id.sh) realiza a aplicação de templates na especificação YAML da aplicação para passar variáveis de ambiente para o pod. Analise o seguinte trecho deste script:

   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
   

   O azure.workload.identity/use rótulo na spec/template seção é o modelo de pod para a implementação. Ao definir o rótulo como true, especifica que está a usar a identidade da carga de trabalho. A serviceAccountName especificação do pod especifica a conta de serviço do Kubernetes a ser associada à identidade do volume de trabalho. Embora a especificação do pod contenha uma referência para uma imagem em um repositório privado, não há nenhum imagePullSecret especificado.

5. Verifique se o script foi executado com êxito usando o kubectl get comando.

   kubectl get pods --namespace $AQS_TARGET_NAMESPACE
   

   Você deve ver um único pod na saída.

6. Verifique se um pool de nós Karpenter foi criado. Faça isso usando o kubectl get nodepool comando. A resposta do comando terá esta aparência:

   

   Verifique se o pool de nós padrão é um pool de nós Karpenter usando o kubectl describe nodepool comando. Na resposta do comando, podes verificar se o pool de nós é do tipo Karpenter. Você deve ver algo assim:

   

Monitore a expansão de pods e nós com k9s

Você pode usar várias ferramentas para verificar a operação de aplicativos implantados no AKS, incluindo o portal do Azure e o k9s. Para obter mais informações sobre o k9s, consulte a visão geral do k9s.

1. Instale o k9s no seu cluster AKS usando a orientação apropriada para o seu ambiente na visão geral da instalação do k9s.

2. Crie duas janelas, uma com uma vista dos pods e outra com uma vista dos nós no namespace especificado na variável de ambiente AQS_TARGET_NAMESPACE (valor padrão é aqs-demo) e execute k9s em cada janela.

   Você deve ver algo semelhante ao seguinte:

   

3. Depois de confirmar que o contêiner do aplicativo consumidor está instalado e em execução no cluster AKS, instale a autenticação e acione a ScaledObject autenticação usada pelo KEDA para o dimensionamento automático do pod executando o script de instalação de objeto dimensionado (keda-scaleobject-workload-id.sh). usando os seguintes comandos:

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

   O script também executa modelos para injetar variáveis de ambiente onde necessário. Analise o seguinte trecho deste script:

   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
   

   O manifesto descreve dois recursos: o TriggerAuthentication objeto, que especifica para KEDA que o objeto dimensionado está usando identidade pod para autenticação, e a identityID propriedade, que se refere à identidade gerenciada usada como a identidade da carga de trabalho.

   Quando o objeto dimensionado é instalado corretamente e o KEDA deteta que o limite de dimensionamento foi excedido, ele começa a agendar pods. Se você estiver usando k9s, você verá algo assim:

   

   Se permitir que o produtor preencha a fila com mensagens suficientes, o KEDA poderá precisar agendar mais pods do que o número de nós disponíveis para atender. Para acomodar isto, o Karpenter entrará em ação e começará a agendar os nós. Se você estiver usando k9s, você verá algo assim:

   

   Nestas duas imagens, observe como o número de nós cujos nomes contêm aks-default aumentou de um para três nós. Se parar o aplicativo produtor de colocar mensagens na fila, eventualmente os consumidores reduzirão a profundidade da fila abaixo do limite, e tanto o KEDA quanto o Karpenter farão escala para dentro. Se você estiver usando k9s, você verá algo assim:

   

4. Finalmente, você pode visualizar a atividade de dimensionamento automático do Karpenter usando o comando, kubectl get events conforme mostrado aqui:

   

Limpeza de recursos

Você pode usar o script de limpeza (/deployment/infra/cleanup.sh) em nosso repositório GitHub para remover todos os recursos criados.

Próximos passos

Para obter mais informações sobre como desenvolver e executar aplicativos no AKS, consulte os seguintes recursos:

• Instale aplicativos existentes com o Helm no AKS
• Implantar e gerenciar um aplicativo Kubernetes do Azure Marketplace no AKS
• Implantar um aplicativo que usa OpenAI no AKS

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

• Ken Kilty - Brasil | Principal TPM
• Russell de Pina - Brasil | Principal TPM
• Jenny Hayes | Desenvolvedora de Conteúdo Sénior
• Carol Smith | Desenvolvedora Sénior de Conteúdos
• Erin Schaffer | Desenvolvedora de Conteúdo 2