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 mapeia para cada versão do AKS, consulte a coluna de complementos gerenciados pelo AKS da 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 visualização do Kubernetes e o patch KEDA mais recente são parcialmente cobertos pelo suporte ao cliente com base no 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 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 do AKS
Crie um cluster AKS com o complemento KEDA, a identidade da carga de trabalho e o emissor OIDC habilitados usando o
az aks create
comando com os--enable-workload-identity
sinalizadores ,--enable-keda
e--enable-oidc-issuer
. Certifique-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
Valide se a implantação foi bem-sucedida e verifique se o cluster tem o KEDA, a identidade da carga de trabalho e o emissor OIDC habilitados usando o
az aks show
comando com o--query
sinalizador definido como"[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
.az aks show \ --name $AKS_NAME \ --resource-group $RG_NAME \ --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
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
Crie um namespace do Barramento de Serviço do Azure usando o
az servicebus namespace create
comando. 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
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
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)
Obtenha o URL do emissor OIDC usando o
az aks show
comando com o--query
sinalizador definido comooidcIssuerProfile.issuerUrl
.AKS_OIDC_ISSUER=$(az aks show \ --name $AKS_NAME \ --resource-group $RG_NAME \ --query oidcIssuerProfile.issuerUrl \ --output tsv)
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
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 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
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)
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)
Atribua a função de Proprietário de Dados do Barramento de Serviço do Azure à identidade gerenciada usando o
az role assignment create
comando.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
Depois de criar a credencial federada para ServiceAccount
keda-operator
, você precisará reiniciar manualmente oskeda-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
Confirme a reinicialização dos pods do operador keda
kubectl get pod -n kube-system -lapp=keda-operator -w
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
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/ ---
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 por meio da identidade da carga de trabalho. Os
keda-operator
Pods usam oidentityId
para autenticar 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 Microsoft Entra Workload Identity. Vamos testar isso implantando cargas de trabalho de produtor e consumidor.
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
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. Este ScaledJob usará o recurso KEDA TriggerAuthentication para autenticar na fila do Barramento de Serviço do Azure usando a identidade da carga de trabalho e dimensionar a cada 10 mensagens.
Implante um recurso ScaledJob para consumir as mensagens. O gatilho de escala será configurado para expandir a cada 10 mensagens. O escalador KEDA criará 10 empregos 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 trabalhos são criados, os Pods serão implantados com bits de identidade de carga de trabalho para consumir mensagens.
Verifique se o escalador KEDA funcionou como pretendido.
kubectl describe scaledjob myconsumer-scaledjob
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
Clean up resources (Limpar recursos)
Depois de verificar se a implantação foi bem-sucedida, você pode limpar os recursos para evitar incorrer em custos do Azure.
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.
Azure Kubernetes Service