Implantar uma carga de trabalho de EDW (fluxo de trabalho controlado por eventos) da AWS no Azure

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

Entrar no Azure

1. Entre no Azure usando o comando az login.

   az login
   

2. Se sua conta do Azure tem várias assinaturas, selecione a assinatura correta. Liste os nomes e as IDs de suas assinaturas usando o comando az account list.

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

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

   az account set --subscription $subscriptionId
   

Script de implantação de carga de trabalho de EDW

Examine as variáveis de ambiente no arquivo deployment/environmentVariables.sh e, em seguida, use o script deploy.sh no diretório deployment/infra/ do repositório do 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 termina e exibe uma mensagem de erro informando quais pré-requisitos estão ausentes. Se isso acontecer, examine os pré-requisitos, instale as ferramentas ausentes e execute o script novamente. O sinalizador de recurso NAP (node autoprovisioning) para AKS deve ser registrado em sua assinatura 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 diretório deployment. 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 ocorrerem problemas, uma mensagem de erro será exibida e a execução será interrompida.

O script exibe um log à medida que é executado. Você pode manter o log redirecionando a saída das informações do 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 script ./deployment/infra/deploy.sh em nosso repositório do 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.

• Contade Armazenamento do Azure: a conta de Armazenamento do Azure que contém a fila em que as mensagens são enviadas pelo aplicativo produtor e lidas pelo aplicativo consumidor e a tabela em que 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.

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

  • NAP (autoprovisionamento de nó): a implementação do dimensionador automático do nó Karpenter no AKS.
  • KEDA (dimensionamento automático controlado por eventos) do Kubernetes: 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 uma segurança aprimorada.
  • Registrode contêiner do Azure anexado: esse recurso permite que o cluster do AKS efetue pull de imagens de repositórios na instância do ACR especificada.

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

• Identidade gerenciada do cluster do AKS: o script atribui a função acrPull a essa identidade gerenciada, o que facilita o acesso ao registro de contêiner do Azure anexado para efetuar pull de 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 com RBAC (controle de acesso baseado em função) a essa identidade gerenciada, que está associada à conta de serviço do Kubernetes usada como a identidade para pods nos quais os contêineres do aplicativo consumidor estã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 do KEDA forneça acesso ao dimensionador do KEDA para coletar as métricas necessárias para controlar o dimensionamento automático do pod.

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

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

1. Defina a origem para coletar 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 do arquivo ./deployment/deploy.state para definir variáveis de ambiente para os nomes dos recursos criados na implantação. Veja o conteúdo do arquivo usando o seguinte comando cat:

   cat ./deployment/deploy.state
   

   A 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 de cluster do AKS usando o comando az aks get-credentials.

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

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

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

   Seu resultado deve ser semelhante ao seguinte exemplo de saída:

   

Gerar carga simulada

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

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

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

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

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

4. Implante o contêiner do aplicativo consumidor no cluster do 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) executa a modelagem na especificação YAML do manifesto do aplicativo para passar variáveis de ambiente para o pod. Examine 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 rótulo azure.workload.identity/use na seção spec/template é o modelo de pod para a implantação. Definir o rótulo como true especifica que você está usando a identidade da carga de trabalho. A serviceAccountName na especificação do pod determina a conta de serviço do Kubernetes a ser associada à identidade da carga 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 comando kubectl get.

   kubectl get pods --namespace $AQS_TARGET_NAMESPACE
   

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

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

   

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

   

Monitorar a expansão de pods e nós com o 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 cluster do AKS usando as diretrizes apropriadas para seu ambiente na visão geral da instalação do k9s.

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

   Você deverá ver algo semelhante ao seguinte:

   

3. Depois de confirmar se o contêiner do aplicativo consumidor está instalado e em execução no cluster do AKS, instale a ScaledObject e dispare a 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 a modelagem para injetar variáveis de ambiente quando necessário. Examine 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 objeto TriggerAuthentication, que especifica ao KEDA que o objeto dimensionado está usando a identidade do pod para autenticação e a propriedade identityID, que se refere à identidade gerenciada usada como a identidade da carga de trabalho.

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

   

   Se você permitir que o produtor preencha a fila com mensagens suficientes, o KEDA talvez precise agendar mais pods do que os nós disponíveis para atender. Para atender essa situação, o Karpenter entrará em ação e iniciará o agendamento de nós. Se você estiver usando o k9s, deverá ver algo assim:

   

   Nessas 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 você impedir que o aplicativo produtor coloque mensagens na fila, os consumidores vão acabar reduzindo a profundidade da fila abaixo do limite, e tanto o KEDA quanto o Karpenter reduzirão horizontalmente. Se você estiver usando o k9s, deverá ver algo assim:

   

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

   

Limpar os recursos

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

Próximas etapas

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

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

Colaboradores

A Microsoft atualiza este artigo. Os seguintes colaboradores o escreveram originalmente:

• Ken Kilty | Diretor de TPM
• Russell de Pina | Diretor de TPM
• Jenny Hayes | Desenvolvedora sênior de conteúdo
• Carol Smith | Desenvolvedora sênior de conteúdo
• Erin Schaffer | Desenvolvedora de conteúdo 2