Dimensionamento automático de aplicativos simplificado com o complemento KEDA (Dimensionamento Automático controlado por eventos) do Kubernetes no AKS (Serviço de Kubernetes do Azure)

Importante

No momento, o complemento KEDA para AKS não dá suporte à modificação das solicitações ou limites de CPU e de outros valores do Helm para o Servidor de Métricas ou Operador. Tenha essa limitação em mente ao usar o complemento. Se você tiver alguma dúvida, fique à vontade para entrar em contato aqui.

O KEDA (Dimensionamento Automático controlado por eventos) do Kubernetes é um componente de uso único e leve que simplifica o dimensionamento automático do aplicativo. É um projeto de pós-graduação da CNCF (Cloud Native Computing Foundation). A KEDA usa o dimensionamento automático controlado por eventos para dimensionar seu aplicativo para atender à demanda de maneira sustentável e econômica com escala para zero.

Para a maioria das cargas de trabalho de produção, o AKS Automatic é a experiência padrão recomendada do AKS. O AKS Automatic está pronto para produção por padrão e inclui KEDA pré-configurado no cluster. Se você usar o AKS Standard, poderá habilitar o KEDA usando o complemento KEDA gerenciado.

Para saber mais sobre o AKS Automatic, confira O que é AKS (Serviço de Kubernetes do Azure) Automático?

Observação

A versão 2.15 do KEDA apresenta uma alteração interruptiva que remove o suporte à identidade do pod. Recomendamos passar para a identidade da workload para sua autenticação, caso esteja usando a identidade do pod. Embora o complemento gerenciado keda atualmente não execute KEDA versão 2.15+, o complemento gerenciado começará a executar KEDA 2.15+ na versão prévia do AKS versão 1.32.

Para obter mais informações sobre como dimensionar seus aplicativos com segurança com a identidade da carga de trabalho, leia nosso tutorial. Para exibir a política de alteração interruptiva/substituição do KEDA, leia a documentação oficial.

KEDA no AKS Automatic e AKS Standard

O KEDA está disponível em ambos os modos de cluster do AKS, mas o caminho de instalação é diferente:

  • AKS Automático: KEDA está pré-configurado e pronto para uso.
  • AKS Standard: habilite o KEDA ativando o complemento gerenciado do AKS.

Para a maioria dos cenários de produção, comece com o AKS Automatic para usar padrões prontos para produção e reduza a sobrecarga de gerenciamento de cluster.

Arquitetura

O KEDA fornece dois componentes principais:

  • O operador KEDA permite que os usuários finais dimensionem para cima ou para baixo as cargas de trabalho de 0 para N com suporte para Implantações do Kubernetes, Trabalhos, StatefulSets ou qualquer recurso personalizado que defina o sub-recurso /scale.
  • O servidor de métricas expõe métricas externas ao HPA (Horizontal Pod Autoscaler) no Kubernetes para fins de dimensionamento automático, como mensagens em um tópico do Kafka ou o número de eventos em um hub de eventos do Azure. Devido a limitações upstream, o KEDA deve ser o único adaptador de métricas externas instalado.

Diagrama que mostra a arquitetura do KEDA e como ele estende o Kubernetes.

Saiba mais sobre como o KEDA funciona na documentação oficial do KEDA.

Instalação e habilitação

AKS Automático

KEDA é pré-configurado no AKS Automatic. Nenhuma etapa de instalação de complemento KEDA separada é necessária.

AKS Standard

Habilite o KEDA no AKS Standard usando um dos seguintes métodos:

A extensão gerenciada do KEDA fornece uma instalação do KEDA totalmente suportada e integrada ao AKS.

Funcionalidades e recursos

O KEDA fornece as seguintes funcionalidades e recursos:

  • Reduza as cargas de trabalho a zero quando a demanda diminuir.
  • Escale as cargas de trabalho de aplicativos para atender à demanda usando os escaladores do Azure KEDA.
  • Dimensione automaticamente os aplicativos usando ScaledObjects, como Deployments, StatefulSets, ou qualquer recurso personalizado que defina o sub-recurso /scale.
  • Dimensionar automaticamente cargas de trabalho similares ao trabalho usando ScaledJobs.
  • Use a segurança de nível de produção desacoplando a autenticação com dimensionamento automático das cargas de trabalho.
  • Traga seu próprio dimensionador externo para lógica de dimensionamento automático personalizada.
  • Integre-se ao ID de carga de trabalho do Microsoft Entra para autenticação.

No AKS Automatic, você obtém esses recursos de dimensionamento automático controlados por evento por padrão porque o cluster é pré-configurado com KEDA.

Observação

Se você planeja usar a identidade da carga de trabalho no AKS Standard, habilite a identidade da carga de trabalho antes de habilitar o complemento KEDA.

Diretrizes de produção

Use estas diretrizes para escolher o modo de cluster:

  • Escolha o AKS Automatic quando quiser uma experiência padrão pronta para produção com KEDA pré-configurada.
  • Escolha o AKS Standard quando precisar de uma personalização mais profunda no nível do cluster e do gerenciamento de complemento explícito.
  • Use KEDA em qualquer modo para cargas de trabalho de dimensionamento automático controladas por eventos.

Limitações do complemento

O complemento KEDA do AKS tem as seguintes limitações:

  • O complemento HTTP (versão prévia) da KEDA para escalar cargas de trabalho HTTP não é instalado com a extensão, mas pode ser implantado separadamente.
  • O dimensionador externo para Azure Cosmos DB da KEDA para escalar com base no feed de alterações do Azure Cosmos DB não é instalado com a extensão, mas pode ser implantado separadamente.
  • Somente um servidor de métricas externo é permitido no cluster do Kubernetes. Devido a isso, o complemento do KEDA deve ser o único servidor de métricas externo dentro do cluster.
    • Não há suporte para várias instalações do KEDA
  • Não é recomendável combinar o ScaledObject do KEDA com um HPA (Dimensionador automático de pod horizontal) para dimensionar a mesma carga de trabalho. Eles competem entre si porque o KEDA usa o HPA em segundo plano e resulta em um comportamento de dimensionamento ímpar.
    • Se um HPA for criado primeiro, um KEDA ScaledObject será criado e o KEDA ScaledObject não será criado.
    • Se um KEDA ScaledObject for criado primeiro e, em seguida, um HPA for criado, a criação do HPA não será bloqueada.

Para perguntas gerais sobre o KEDA, recomendamos visitar a visão geral das perguntas frequentes.

Observação

Se você estiver usando a ID de workload do Microsoft Entra e habilitar o KEDA antes da ID de workload, será necessário reiniciar os pods do operador KEDA para que as variáveis de ambiente corretas possam ser injetadas:

  1. Reinicie os pods executando kubectl rollout restart deployment keda-operator -n kube-system.

  2. Obtenha os pods do operador KEDA usando kubectl get pod -n kube-system e localizando os pods que começam com keda-operator.

  3. Verifique a injeção bem-sucedida das variáveis de ambiente executando kubectl describe pod <keda-operator-pod> -n kube-system. Em Environment, você deverá visualizar os valores para AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE e AZURE_AUTHORITY_HOST.

Versões do Kubernetes e KEDA com suporte

A versão do Kubernetes do cluster determina qual versão KEDA está instalada no cluster do AKS. Para ver a qual versão do KEDA corresponde cada versão do AKS, consulte a coluna AKS managed add-ons da tabela de versões dos componentes 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 patch do KEDA mais recente 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:

Conteúdo relacionado

  • Last updated on