O Helm chart do KEDA é a forma oficial de instalar o KEDA, o Kubernetes Event-Driven Autoscaler, no seu cluster. Um único helm install implanta tudo o que o KEDA precisa para escalar seus workloads com base em eventos: o operator, o servidor de métricas, os admission webhooks e os custom resources que você usa para definir as regras de escalonamento.
Este guia cobre o chart em profundidade. Você vai aprender o que ele implanta, como instalar e verificar a instalação, os principais parâmetros do values.yaml, como executar o KEDA em alta disponibilidade, como fazer hardening e monitoramento, como gerenciá-lo via GitOps e como fazer upgrade ou desinstalar sem deixar recursos quebrados no cluster.
O que é o Helm chart do KEDA?
O KEDA escala seus pods com base em eventos, como o tamanho de uma fila, o lag de um tópico Kafka, o número de requisições HTTP ou um agendamento cron. O Horizontal Pod Autoscaler (HPA) nativo só consegue escalar com base em CPU e memória. O KEDA acrescenta todas essas fontes de eventos e ainda consegue reduzir um workload a zero pods quando não há nada para fazer.
O KEDA não substitui o HPA. Ele lê sua fonte de eventos e cria um HPA que faz o escalonamento de fato, alimentando-o com métricas externas. Você descreve o que escalar em um custom resource chamado ScaledObject.
O Helm chart instala o KEDA e seus componentes de apoio em uma única etapa — e é por isso que ele é a forma recomendada de implantação.
O que o chart implanta no seu cluster?
Ao instalar o Helm chart do KEDA no seu cluster, os seguintes componentes são instalados:
a. KEDA operator: o controller principal do KEDA. Ele observa seus recursos ScaledObject e ScaledJob e gerencia o HPA responsável pelo escalonamento. É a parte central do KEDA.
b. Metrics API server: disponibiliza suas métricas baseadas em eventos para o Kubernetes por meio da API external.metrics.k8s.io. Isso permite que o HPA escale com base em coisas como o tamanho de uma fila, em vez de apenas CPU ou memória.
c. Admission webhooks: validam seus recursos do KEDA no momento da criação. Eles detectam erros de configuração logo de início, como dois recursos ScaledObject tentando escalar o mesmo workload.
Por fim, o chart instala os CRDs, que adicionam os tipos de recurso do KEDA com os quais você trabalha: ScaledObject, ScaledJob, TriggerAuthentication e ClusterTriggerAuthentication. Ele também instala as permissões RBAC de que esses componentes precisam.
Pré-requisitos e compatibilidade de versões
Antes de instalar o KEDA, verifique os seguintes pré-requisitos e requisitos de versão:
a. O KEDA 2.20 exige Kubernetes 1.30 ou mais recente, então primeiro verifique a versão do seu cluster com kubectl version. Você também precisa do Helm 3, porque o chart do KEDA só oferece suporte ao Helm 3.
b. Garanta que o cluster tenha recursos disponíveis suficientes para executar os componentes do KEDA. O chart também baixa imagens de contêiner do ghcr.io, portanto seus nós precisam de acesso de rede ao registry de imagens.
c. O metrics server do KEDA também cria um APIService de escopo de cluster, então quaisquer network policies no namespace keda precisam permitir o tráfego que o KEDA exige. Se o seu cluster for restrito ou isolado da internet (air-gapped), garanta que o acesso de rede e as imagens necessárias estejam disponíveis antes de instalar.
Instalando o Helm chart do KEDA
Primeiro, adicione o repositório oficial do KEDA e atualize-o:
helm repo add kedacore https://kedacore.github.io/chartshelm repo updateInstale em um namespace dedicado e fixe a versão do chart em vez de usar a mais recente disponível:
helm install keda kedacore/keda \ --namespace keda \ --create-namespace \ --version <chart-version>Fixar a versão é importante porque a versão do chart corresponde a uma versão específica da aplicação KEDA, e você quer exatamente a versão que testou. Você pode ver as versões disponíveis com helm search repo kedacore/keda --versions.
Depois de instalar, verifique as três partes que precisam estar saudáveis. Confira se os pods estão em execução:
kubectl get pods -n kedaEm seguida, confirme que os CRDs estão presentes e que o APIService de métricas externas está registrado e disponível:
kubectl get crd | grep keda.shkubectl get apiservice v1beta1.external.metrics.k8s.ioSe os pods estiverem em execução e o APIService mostrar True em Available, o KEDA foi instalado corretamente.
Outras formas de implantar o KEDA
O Helm chart é a forma recomendada de instalar o KEDA, mas não é a única opção. A escolha certa depende de como você gerencia seu cluster. As outras opções são:
a. OpenShift: você pode instalar o KEDA pelo OperatorHub e pelo Operator Lifecycle Manager (OLM). O OLM gerencia o operator do KEDA e seus upgrades em vez do Helm.
b. Manifestos YAML puros: se você não puder usar Helm, o KEDA fornece manifestos YAML para cada release que podem ser aplicados com kubectl apply. Nessa abordagem, você mesmo gerencia os CRDs e os upgrades.
c. MicroK8s: o KEDA está disponível como um add-on nativo que pode ser habilitado com um único comando.
Seja qual for o método escolhido, os componentes principais e os CRDs do KEDA são os mesmos. A principal diferença está em como o KEDA é empacotado e gerenciado.
Parâmetros principais do values.yaml
Estes são os parâmetros essenciais para conhecer no values.yaml:
a. Registries, repositórios e tags de imagens: cada componente do KEDA (image.keda, image.metricsApiServer e image.webhooks) tem seu próprio registry, repositório e tag. Se você deixar a tag vazia, o chart usa a versão da aplicação KEDA. Em ambientes restritos, você pode definir esses valores para usar seu próprio registry de imagens ou mirror.
b. crds.install e propriedade dos CRDs: por padrão, o chart instala e gerencia os CRDs. Se outra ferramenta, como uma ferramenta de GitOps, já os gerencia, defina crds.install: false para que os dois sistemas não tentem gerenciar os mesmos CRDs.
c. watchNamespace e escopo de namespace: por padrão, o KEDA observa todos os namespaces. Definir watchNamespace limita o KEDA a um namespace específico. Isso pode ser útil em um cluster compartilhado quando você quer limitar onde o KEDA opera.
d. Requests e limits de recursos: você pode definir recursos separadamente para o operator, o metrics server e os webhooks usando resources.operator, resources.metricServer e resources.webhooks. Defina requests e limits apropriados para que o KEDA tenha recursos suficientes para funcionar com confiabilidade, mesmo quando o cluster estiver sob pressão.
Configurando o KEDA para alta disponibilidade
Em produção, você não quer que o KEDA pare de funcionar se um nó cair. Execute os componentes com múltiplas réplicas e distribua-os entre nós diferentes.
O operator oferece suporte a múltiplas réplicas via operator.replicaCount. Ele usa eleição de líder, então apenas uma instância do operator fica ativa por vez, enquanto as demais ficam prontas para assumir se necessário.
O metrics API server também pode executar múltiplas réplicas via metricsServer.replicaCount. Isso ajuda a manter as métricas externas disponíveis se uma réplica falhar.
Você também deve usar pod anti-affinity para distribuir as réplicas entre nós diferentes e um PodDisruptionBudget (PDB) para garantir que um drain de nó não derrube todas as réplicas de uma vez.
Um values.yaml de produção pode ficar assim:
operator: replicaCount: 2metricsServer: replicaCount: 2podDisruptionBudget: operator: minAvailable: 1 metricServer: minAvailable: 1affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: app: keda-operatorAjustando as configurações de HTTP e TLS dos scalers
Muitos scalers do KEDA se conectam a sistemas externos via HTTP. Em um ambiente restrito, pode ser necessário controlar como essas conexões funcionam. O KEDA oferece configurações para HTTP, TLS e conexões via proxy:
a. Timeout HTTP: KEDA_HTTP_DEFAULT_TIMEOUT define o timeout padrão para scalers que usam o cliente HTTP interno do KEDA. O valor é em milissegundos. Alguns scalers usam SDKs dos próprios fornecedores, então essa configuração não se aplica a eles.
b. Versão mínima de TLS: KEDA_HTTP_MIN_TLS_VERSION define a versão mínima de TLS para as conexões HTTP de saída do KEDA. KEDA_SERVICE_MIN_TLS_VERSION define a versão mínima de TLS para os serviços TLS do próprio KEDA, como os serviços de webhook e gRPC. O padrão é TLS 1.3.
c. Lista de cifras TLS: KEDA_HTTP_TLS_CIPHER_LIST permite restringir quais cifras TLS o KEDA pode usar. No entanto, essa configuração não afeta o TLS 1.3, porque a biblioteca TLS do Go não permite configurar essas cifras para o TLS 1.3.
d. Proxy HTTP e HTTPS: se o KEDA precisar se conectar a sistemas externos por meio de um proxy corporativo, configure as variáveis de ambiente padrão HTTP_PROXY, HTTPS_PROXY e NO_PROXY no operator do KEDA.
Fazendo o hardening da instalação
Existem duas configurações que podem melhorar a segurança do KEDA em produção: limitar o acesso a secrets e gerenciar certificados. Vamos a elas:
a. Limitar o acesso a secrets: por padrão, o KEDA pode ler secrets em todos os namespaces que observa. As configurações de permissions.operator permitem restringir esse acesso para que o operator leia secrets apenas no seu próprio namespace de release ou apenas secrets específicos nomeados. Isso reduz o que um operator comprometido poderia acessar.
b. Gerenciar certificados: o KEDA gera seus próprios certificados autoassinados, armazena-os em um secret chamado kedaorg-certs e os monta em seus componentes. O KEDA também rotaciona esses certificados automaticamente e atualiza os recursos necessários do Kubernetes para que eles sejam confiáveis.
c. Se a sua organização exigir certificados de uma autoridade certificadora gerenciada, habilite certificates.certManager.enabled para que o cert-manager emita e rotacione os certificados no lugar do KEDA. Para a maioria das instalações, os certificados gerados automaticamente são suficientes.
Implantando o chart via GitOps
Se você gerencia seu cluster com Argo CD ou Flux, pode implantar o chart do KEDA via GitOps. O ponto que exige mais cuidado são os CRDs.
Os CRDs do KEDA são grandes, e um apply normal do Kubernetes pode falhar porque a annotation gerada fica grande demais. Para evitar isso, configure sua ferramenta de GitOps para substituir os CRDs em vez de fazer merge. No Flux: defina crds: CreateReplace no HelmRelease. No Argo CD: use Replace=true ou server-side apply para os CRDs, para que sejam aplicados corretamente.
Se os CRDs não estiverem configurados corretamente, a instalação do KEDA gerenciada via GitOps pode falhar.
Você também pode usar helm template para renderizar o chart em arquivos YAML comuns do Kubernetes e versioná-los no Git, caso seu fluxo de trabalho prefira gerenciar manifestos renderizados em vez de uma release Helm ativa.
Seja qual for a abordagem, mantenha o label app.kubernetes.io/managed-by consistente para que sua ferramenta de GitOps e o Helm não entrem em conflito pela propriedade dos recursos.
Criando seu primeiro ScaledObject após a instalação
Com o KEDA instalado, um ScaledObject permite verificar se o KEDA consegue realmente escalar um workload. O exemplo abaixo usa um trigger cron, então não precisa de um sistema externo. Ele aumenta as réplicas de um Deployment durante o horário agendado e as reduz quando o período termina.
Primeiro, crie um Deployment para escalar e depois aplique o ScaledObject:
apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: nginx-cron namespace: defaultspec: scaleTargetRef: name: nginx pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 5 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 9 * * * end: 0 17 * * * desiredReplicas: "5"pollingInterval informa ao KEDA com que frequência, em segundos, verificar o trigger. minReplicaCount: 0 habilita o scale-to-zero. Fora da janela das 9h às 17h, o Deployment pode reduzir para zero pods. Durante a janela agendada, ele escala para cinco réplicas.
Aplique o ScaledObject e verifique o que o KEDA criou:
kubectl get scaledobjectkubectl get hpaVocê deve ver um HPA chamado keda-hpa-nginx-cron. O KEDA cria e gerencia esse HPA para executar o escalonamento de fato. Isso confirma que o KEDA está conectado ao workload e que a configuração de escalonamento agendado está funcionando.
Monitorando a instalação do KEDA
Com o KEDA em execução, você deve verificar se ele está saudável e funcionando como esperado.
O KEDA fornece métricas Prometheus tanto para o operator quanto para o metrics server. Essas métricas mostram a atividade dos scalers, erros e os valores que o KEDA reporta.
Se você usa o Prometheus Operator, o chart do KEDA pode criar um ServiceMonitor para o metrics server e um PodMonitor para o operator. Você pode habilitá-los pelas configurações de prometheus no values.yaml, para que o Prometheus colete as métricas automaticamente.
Os logs do operator também são úteis quando um ScaledObject específico não está funcionando como esperado. Eles mostram como o scaler está lendo o trigger e quaisquer erros encontrados.
Você pode visualizar os logs do operator com:
kubectl logs -n keda deploy/keda-operatorRight-sizing dos workloads que o KEDA escala
O KEDA é ótimo em escalar o número de pods com base na demanda. Mas ele não decide quanto de CPU e memória cada pod deve solicitar.
Adicionar mais réplicas não corrige requests de recursos incorretos. Se cada pod solicita muito mais CPU ou memória do que realmente usa, o KEDA pode multiplicar esse desperdício conforme adiciona réplicas. Se cada pod solicita pouco demais, as novas réplicas podem sofrer OOMKill ou throttling de CPU quando o tráfego aumenta.
É aí que ferramentas de otimização de recursos podem ajudar. A PerfectScale monitora como os workloads realmente usam CPU e memória e fornece recomendações automatizadas de right-sizing que você pode aplicar manual ou automaticamente.
Em conjunto com o KEDA, você tem os dois lados do autoscaling: o KEDA ajusta o número de pods conforme a demanda, enquanto a PerfectScale ajuda a garantir que cada pod tenha a quantidade certa de CPU e memória. Isso pode ajudar a evitar o superprovisionamento sem comprometer a confiabilidade dos workloads. Você pode experimentar ou agendar uma sessão técnica.
Outras ferramentas, como o Vertical Pod Autoscaler (VPA), que pode ajustar requests de recursos com base no uso, o Goldilocks, que ajuda a visualizar as recomendações do VPA, e o Karpenter, se concentram em escolher e gerenciar os nós que executam seus workloads.
Fazendo upgrade e desinstalando o chart
Há alguns pontos importantes a verificar ao fazer upgrade ou desinstalar o KEDA.
Para fazer o upgrade do KEDA, primeiro atualize o repositório Helm e depois faça o upgrade para uma versão fixada do chart:
helm repo updatehelm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>O ponto de atenção durante um upgrade são os CRDs. Como o chart os gerencia, um helm upgrade os atualiza junto com todo o resto, mas versões minor do KEDA ocasionalmente alteram campos de CRDs ou o comportamento de scalers. Por isso, leia as release notes antes de fazer upgrade em um cluster de produção e verifique se a nova versão do KEDA ainda oferece suporte à sua versão do Kubernetes.
Desinstalar o KEDA também exige cuidado, porque a remoção pode deixar recursos residuais no cluster.
Primeiro, exclua os recursos ScaledObject e ScaledJob:
kubectl delete scaledobject --all --all-namespaceskubectl delete scaledjob --all --all-namespacesDepois desinstale a release Helm:
helm uninstall keda --namespace kedaExcluir primeiro os recursos ScaledObject e ScaledJob permite que o KEDA limpe os HPAs que criou. Também dá aos workloads que foram reduzidos a zero a chance de voltar à contagem normal de réplicas antes da remoção do KEDA.
Se um recurso ficar travado durante a exclusão por causa de um finalizer, você pode removê-lo com:
kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=mergeTroubleshooting de problemas comuns do chart
Há dois problemas comuns a investigar quando o KEDA não está escalando como esperado:
a. API de métricas externas indisponível ou falhando na verificação de TLS: se kubectl get apiservice v1beta1.external.metrics.k8s.io não mostrar Available, o HPA não consegue obter métricas externas, então os workloads não podem escalar com base nelas. As causas comuns incluem um metrics server com problemas, uma NetworkPolicy bloqueando o tráfego ou um proxy interferindo na conexão entre o API server do Kubernetes e o metrics server. Verifique primeiro o pod do metrics server. Se você usa proxy, garanta que o IP de cluster do metrics server esteja incluído na lista no_proxy do API server.
b. Um ScaledObject foi criado, mas as réplicas não mudam: comece com kubectl describe scaledobject <name> e verifique o status e os eventos. Depois verifique os logs do operator do KEDA. As causas podem ser um trigger mal configurado, autenticação ausente para a fonte de eventos ou um HPA já existente apontando para o mesmo workload. O HPA existente pode entrar em conflito com o HPA que o KEDA cria e gerencia.
Boas práticas para executar o Helm chart do KEDA
As práticas a seguir ajudam a manter uma instalação do KEDA estável e segura:
a. Fixe a versão do chart e associe-a a uma versão testada da aplicação KEDA: não instale nem faça upgrade simplesmente para a versão mais recente disponível. Fixe o chart, teste aquela versão do KEDA e faça o rollout com cuidado, para sempre saber o que está em execução.
b. Mantenha o KEDA em um namespace próprio com sua própria resource quota: um namespace dedicado mantém o KEDA isolado e facilita aplicar uma ResourceQuota e uma NetworkPolicy específicas para ele.
c. Defina requests e limits explícitos nos três componentes do KEDA: você deve definir recursos apropriados para o operator, o metrics server e os webhooks, para que o próprio KEDA não sofra throttling nem eviction quando o cluster estiver sob pressão.
d. Use TriggerAuthentication em vez de colocar credenciais diretamente no ScaledObject: mantenha as credenciais fora dos seus manifestos de ScaledObject referenciando um TriggerAuthentication ou ClusterTriggerAuthentication. Isso ajuda a manter credenciais fora do controle de versão e permite reutilizá-las.
e. Evite combinar um ScaledObject com um HPA criado manualmente no mesmo workload: dois controllers tentando escalar o mesmo workload podem entrar em conflito. Deixe o KEDA gerenciar o HPA dos workloads que ele escala.
f. Teste os upgrades em um cluster de não produção antes do rollout: versões minor do KEDA podem incluir mudanças nos CRDs, então teste o upgrade primeiro em um ambiente seguro. Isso ajuda a detectar problemas de compatibilidade antes que afetem workloads de produção.