Partilhar via


Dimensione com segurança seus aplicativos usando o complemento KEDA e a identidade de carga de trabalho no Serviço de Kubernetes do Azure (AKS)

Este artigo mostra como dimensionar com segurança seus aplicativos com o complemento Dimensionamento Automático controlado por Eventos do Kubernetes (KEDA) e a identidade de carga de trabalho no Serviço de Kubernetes do Azure (AKS).

Importante

A versão do cluster do Kubernetes determina a versão do KEDA que será instalada no cluster do AKS. Para visualizar qual versão do KEDA é mapeada para cada versão do AKS, consulte a coluna de complementos gerenciados do AKS da tabela de versão do componente do Kubernetes.

Para as versões GA do Kubernetes, o AKS dá suporte completo à versão secundária do KEDA correspondente na tabela. As versões prévias do Kubernetes e o último patch do KEDA são parcialmente cobertos pelo suporte ao cliente com base no melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Antes de começar

Criar um grupo de recursos

  • Crie um grupo de recursos usando o comando az group create. Substitua os valores de espaço reservado por seus próprios valores.

    LOCATION=<azure-region>
    RG_NAME=<resource-group-name>
    
    az group create --name $RG_NAME --location $LOCATION
    

Criar um cluster AKS

  1. Crie um cluster do AKS com o complemento KEDA, a identidade da carga de trabalho e o emissor OIDC habilitados usando o comando az aks create com os sinalizadores --enable-workload-identity, --enable-keda e --enable-oidc-issuer. Substitua o valor do espaço reservado pelo seu próprio valor.

    AKS_NAME=<cluster-name>
    
    az aks create \
        --name $AKS_NAME \
        --resource-group $RG_NAME \
        --enable-workload-identity \
        --enable-oidc-issuer \
        --enable-keda \
        --generate-ssh-keys 
    
  2. Valide se a implantação foi bem-sucedida e verifique se o cluster tem KEDA, identidade de carga de trabalho e emissor OIDC habilitados usando o comando az aks show com o sinalizador --query definido como "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".

    az aks show \
        --name $AKS_NAME \
        --resource-group $RG_NAME \
        --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
    
  3. Conecte-se ao cluster usando o comando az aks get-credentials.

    az aks get-credentials \
        --name $AKS_NAME \
        --resource-group $RG_NAME \
        --overwrite-existing
    

Criar uma instância do Barramento de Serviço do Azure

  1. Crie um namespace do Barramento de Serviço do Azure usando o comando az servicebus namespace create. Substitua o valor do espaço reservado pelo seu próprio valor.

    SB_NAME=<service-bus-name>
    SB_HOSTNAME="${SB_NAME}.servicebus.windows.net"
    
    az servicebus namespace create \
        --name $SB_NAME \
        --resource-group $RG_NAME \
        --disable-local-auth
    
  2. Crie uma fila do Barramento de Serviço do Azure usando o comando az servicebus queue create. Substitua o valor do espaço reservado pelo seu próprio valor.

    SB_QUEUE_NAME=<service-bus-queue-name>
    
    az servicebus queue create \
        --name $SB_QUEUE_NAME \
        --namespace $SB_NAME \
        --resource-group $RG_NAME
    

Criar uma identidade gerenciada

  1. Crie uma identidade gerenciada usando o comando az identity create. Substitua o valor do espaço reservado pelo seu próprio valor.

    MI_NAME=<managed-identity-name>
    
    MI_CLIENT_ID=$(az identity create \
        --name $MI_NAME \
        --resource-group $RG_NAME \
        --query "clientId" \
        --output tsv)
    
  2. Obtenha a URL do emissor do OIDC usando o comando az aks show com o sinalizador --query definido como oidcIssuerProfile.issuerUrl.

    AKS_OIDC_ISSUER=$(az aks show \
        --name $AKS_NAME \
        --resource-group $RG_NAME \
        --query oidcIssuerProfile.issuerUrl \
        --output tsv)
    
  3. Crie uma credencial federada entre a identidade gerenciada e o namespace e a conta de serviço usada pela carga de trabalho usando o comando az identity federated-credential create. Substitua o valor do espaço reservado pelo seu próprio valor.

    FED_WORKLOAD=<federated-credential-workload-name>
    
    az identity federated-credential create \
        --name $FED_WORKLOAD \
        --identity-name $MI_NAME \
        --resource-group $RG_NAME \
        --issuer $AKS_OIDC_ISSUER \
        --subject system:serviceaccount:default:$MI_NAME \
        --audience api://AzureADTokenExchange
    
  4. Crie uma segunda credencial federada entre a identidade gerenciada e o namespace e a conta de serviço usada pelo operador keda usando o comando az identity federated-credential create. Substitua o valor do espaço reservado pelo seu próprio valor.

    FED_KEDA=<federated-credential-keda-name>
    
    az identity federated-credential create \
        --name $FED_KEDA \
        --identity-name $MI_NAME \
        --resource-group $RG_NAME \
        --issuer $AKS_OIDC_ISSUER \
        --subject system:serviceaccount:kube-system:keda-operator \
        --audience api://AzureADTokenExchange
    

Criar atribuições de função

  1. Obtenha a ID do objeto para a identidade gerenciada usando o comando az identity show com o sinalizador --query definido como "principalId".

    MI_OBJECT_ID=$(az identity show \
        --name $MI_NAME \
        --resource-group $RG_NAME \
        --query "principalId" \
        --output tsv)
    
  2. Obtenha a ID do recurso do namespace do Barramento de Serviço usando o comando az servicebus namespace show com o sinalizador --query definido como "id".

    SB_ID=$(az servicebus namespace show \
        --name $SB_NAME \
        --resource-group $RG_NAME \
        --query "id" \
        --output tsv)
    
  3. Atribua a função Proprietário de Dados do Barramento de Serviço do Azure à identidade gerenciada usando o comando az role assignment create.

    az role assignment create \
        --role "Azure Service Bus Data Owner" \
        --assignee-object-id $MI_OBJECT_ID \
        --assignee-principal-type ServicePrincipal \
        --scope $SB_ID
    

Habilitar identidade de carga de trabalho no operador KEDA

  1. Depois de criar a credencial federada para a keda-operator ServiceAccount, você precisará reiniciar manualmente os pods keda-operator para garantir que as variáveis de ambiente do Workload Identity sejam injetadas no pod.

    kubectl rollout restart deploy keda-operator -n kube-system
    
  2. Confirmar a reinicialização dos pods do operador keda

    kubectl get pod -n kube-system -lapp=keda-operator -w
    
  3. Depois de confirmar que os pods do operador keda terminaram de rolar Ctrl+c para quebrar o comando de inspeção anterior, confirme se as variáveis de ambiente de Identidade de Carga de Trabalho foram injetadas.

    KEDA_POD_ID=$(kubectl get po -n kube-system -l app.kubernetes.io/name=keda-operator -ojsonpath='{.items[0].metadata.name}')
    kubectl describe po $KEDA_POD_ID -n kube-system
    
  4. Você deverá ver uma saída semelhante à seguinte em Ambiente.

    ---
    AZURE_CLIENT_ID:
    AZURE_TENANT_ID:               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
    AZURE_FEDERATED_TOKEN_FILE:    /var/run/secrets/azure/tokens/azure-identity-token
    AZURE_AUTHORITY_HOST:          https://login.microsoftonline.com/
    ---
    
  5. Implante um recurso KEDA TriggerAuthentication que inclui a ID do cliente da Identidade Gerenciada Atribuída pelo Usuário.

    kubectl apply -f - <<EOF
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: azure-servicebus-auth
      namespace: default  # this must be same namespace as the ScaledObject/ScaledJob that will use it
    spec:
      podIdentity:
        provider:  azure-workload
        identityId: $MI_CLIENT_ID
    EOF
    

    Observação

    Com o TriggerAuthentication em vigor, o KEDA poderá se autenticar por meio da identidade da carga de trabalho. Os Pods keda-operator usam a autenticação identityId em recursos do Azure ao avaliar gatilhos de dimensionamento.

Publicar mensagens no Barramento de Serviço do Azure

Neste ponto, tudo está configurado para dimensionamento com KEDA e Identidade de Carga de Trabalho do Microsoft Entra. Testaremos isso implantando cargas de trabalho de produtor e consumidor.

  1. Crie um novo ServiceAccount para as cargas de trabalho.

    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      annotations:
        azure.workload.identity/client-id: $MI_CLIENT_ID
      name: $MI_NAME
    EOF
    
  2. Implante um trabalho para publicar 100 mensagens.

    kubectl apply -f - <<EOF
    apiVersion: batch/v1
    kind: Job
    metadata:
      name: myproducer
    spec:
      template:
        metadata:
          labels:
            azure.workload.identity/use: "true"
        spec:
          serviceAccountName: $MI_NAME
          containers:
          - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
            name: myproducer
            resources: {}
            env:
            - name: OPERATION_MODE
              value: "producer"
            - name: MESSAGE_COUNT
              value: "100"
            - name: AZURE_SERVICEBUS_QUEUE_NAME
              value: $SB_QUEUE_NAME
            - name: AZURE_SERVICEBUS_HOSTNAME
              value: $SB_HOSTNAME
          restartPolicy: Never
    EOF
    

Consumir mensagens do Barramento de Serviço do Azure

Agora que publicamos mensagens na fila do Barramento de Serviço do Azure, implantaremos um ScaledJob para consumir as mensagens. Esse ScaledJob usará o recurso KEDA TriggerAuthentication para autenticar-se na fila do Barramento de Serviço do Azure usando a identidade da carga de trabalho e expandir a cada 10 mensagens.

  1. Implante um recurso ScaledJob para consumir as mensagens. O gatilho de escala será configurado para escalar horizontalmente a cada 10 mensagens. O dimensionador KEDA criará 10 trabalhos para consumir as 100 mensagens.

    kubectl apply -f - <<EOF
    apiVersion: keda.sh/v1alpha1
    kind: ScaledJob
    metadata:
      name: myconsumer-scaledjob
    spec:
      jobTargetRef:
        template:
          metadata:
            labels:
              azure.workload.identity/use: "true"
          spec:
            serviceAccountName: $MI_NAME
            containers:
            - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
              name: myconsumer
              env:
              - name: OPERATION_MODE
                value: "consumer"
              - name: MESSAGE_COUNT
                value: "10"
              - name: AZURE_SERVICEBUS_QUEUE_NAME
                value: $SB_QUEUE_NAME
              - name: AZURE_SERVICEBUS_HOSTNAME
                value: $SB_HOSTNAME
            restartPolicy: Never
      triggers:
      - type: azure-servicebus
        metadata:
          queueName: $SB_QUEUE_NAME
          namespace: $SB_NAME
          messageCount: "10"
        authenticationRef:
          name: azure-servicebus-auth
    EOF
    

    Observação

    O ScaledJob cria um recurso de trabalho do Kubernetes sempre que ocorre um evento de dimensionamento e, portanto, um modelo de trabalho precisa ser passado ao criar o recurso. À medida que novos trabalhos são criados, os Pods serão implantados com bits de identidade de carga de trabalho para consumir mensagens.

  2. Verifique se o dimensionador KEDA funcionou conforme o esperado.

    kubectl describe scaledjob myconsumer-scaledjob
    
  3. Você deve ver eventos semelhantes aos seguintes.

    Events:
    Type     Reason              Age   From           Message
    ----     ------              ----  ----           -------
    Normal   KEDAScalersStarted  10m   scale-handler  Started scalers watch
    Normal   ScaledJobReady      10m   keda-operator  ScaledJob is ready for scaling
    Warning  KEDAScalerFailed    10m   scale-handler  context canceled
    Normal   KEDAJobsCreated     10m   scale-handler  Created 10 jobs
    

Limpar os recursos

Depois de verificar se a implantação foi bem-sucedida, você pode limpar os recursos para evitar incorrer em custos do Azure.

  1. Exclua o grupo de recursos do Azure e todos os recursos nele usando o comando [az group delete][az-group-delete].

    az group delete --name $RG_NAME --yes --no-wait
    

Próximas etapas

Este artigo mostrou como dimensionar com segurança seus aplicativos usando o complemento KEDA e a identidade da carga de trabalho no AKS.

Para obter informações sobre a solução de problemas do KEDA, confira Solucionar problemas do complemento KEDA (dimensionamento automático controlado por eventos do Kubernetes).

Para saber mais sobre o KEDA, veja a documentação upstream do KEDA.