Partilhar via

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

Este artigo mostra como dimensionar com segurança seus aplicativos com o complemento Kubernetes Event-driven Autoscaling (KEDA) e a identidade da carga de trabalho no Serviço Kubernetes do Azure (AKS).

Importante

A versão do Kubernetes do cluster determina qual versão do KEDA será instalada no cluster AKS. Para ver qual versão do KEDA corresponde a cada versão do AKS, consulte a coluna de complementos geridos pelo AKS na tabela de versões do componente Kubernetes.

Para as versões do GA Kubernetes, o AKS oferece suporte total da versão secundária KEDA correspondente na tabela. As versões de pré-visualização do Kubernetes e o patch mais recente do KEDA são parcialmente cobertos pelo suporte ao cliente com base no princípio de melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Antes de começar

  • Precisa de uma subscrição do Azure. Se não tiver uma subscrição do Azure, pode criar uma conta gratuita.
  • Você precisa da CLI do Azure instalada.
  • Certifique-se de ter regras de firewall configuradas para permitir o acesso ao servidor de API do Kubernetes. Para obter mais informações, consulte Rede de saída e regras FQDN para clusters do Serviço Kubernetes do Azure (AKS).

Criar um grupo de recursos

  • Crie um grupo de recursos usando o az group create comando. Certifique-se de substituir os valores do marcador de posição pelos seus próprios valores.

    LOCATION=<azure-region>
RG_NAME=<resource-group-name>

az group create --name $RG_NAME --location $LOCATION

Criar um cluster do AKS

  1. Crie um cluster AKS com o complemento KEDA, identidade da carga de trabalho e emissor OIDC habilitados, usando o comando az aks create com os sinalizadores --enable-workload-identity, --enable-keda e --enable-oidc-issuer. Assegure-se de substituir 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 certifique-se de que o cluster tenha KEDA, identidade de carga de trabalho, e emissor OIDC ativados 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 az aks get-credentials comando.

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

Criar um Barramento de Serviço do Azure

  1. Crie um namespace do Barramento de Serviço do Azure usando o comando az servicebus namespace create. Certifique-se de substituir 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 az servicebus queue create comando. Certifique-se de substituir 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 az identity create comando. Certifique-se de substituir 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 o URL do emissor OIDC usando o comando az aks show com o parâmetro --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 usados pela carga de trabalho usando o az identity federated-credential create comando. Certifique-se de substituir 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 usados pelo operador keda usando o az identity federated-credential create comando. Certifique-se de substituir o valor do marcador de posição 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 o ID do objeto para a identidade gerenciada usando o az identity show comando 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 de namespace do Service Bus usando o az servicebus namespace show comando 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 de Proprietário de Dados do Barramento de Serviço do Azure à identidade gerida 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 ServiceAccount keda-operator , você precisará reiniciar manualmente os keda-operator pods para garantir que as variáveis de ambiente Workload Identity sejam injetadas no pod.

    kubectl rollout restart deploy keda-operator -n kube-system

  2. Confirme 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 hit Ctrl+c para quebrar o comando watch anterior, confirme se as variáveis de ambiente Workload Identity 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ê 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 inclua 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

    Nota

    Com o TriggerAuthentication em vigor, o KEDA poderá autenticar através da identidade da carga de trabalho. Pods keda-operator usam o identityId para autenticar contra 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 Microsoft Entra Workload Identity. Vamos testar isso implantando cargas de trabalho de produtor e consumidor.

  1. Crie uma nova 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. Execute uma tarefa para enviar 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 Serviço de Bus do Azure

Agora que publicámos mensagens na fila do Azure Service Bus, vamos implementar uma ScaledJob para consumir as mensagens. Este ScaledJob usará o recurso KEDA TriggerAuthentication para autenticar-se junto à fila do Azure Service Bus utilizando a identidade da carga de trabalho e escalar a cada 10 mensagens.

  1. Implante um recurso ScaledJob para consumir as mensagens. O gatilho de escala será configurado para expandir a cada 10 mensagens. O escalador KEDA gerará 10 tarefas 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

    Nota

    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 Jobs são criados, os Pods serão implantados com bits de identidade de carga de trabalho para consumir mensagens.

  2. Verifique se o escalador KEDA funcionou como pretendido.

    kubectl describe scaledjob myconsumer-scaledjob

  3. Você 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 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óximos passos

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, consulte Solucionar problemas do complemento Kubernetes Event-driven Autoscaling (KEDA).

Para saber mais sobre o KEDA, consulte os documentos KEDA upstream.

  • Last updated on