Introdução
O escalonamento tradicional baseado em CPU ou memória atende bem a diversos cenários, mas pode apresentar limitações em aplicações que sofrem bursts de requisições ou que exibem padrões de tráfego irregulares. Nesses casos, é comum que a aplicação mantenha níveis estáveis de CPU e memória ao mesmo tempo que enfrenta pressão direta no atendimento HTTP, gerando aumento de latência, formação de filas e redução de throughput antes que o autoscaler identifique a necessidade de ajuste.
O KEDA HTTP Add-on foi desenvolvido para lidar com essas situações ao permitir que o escalonamento considere o volume de requisições como métrica primária. Essa abordagem oferece uma resposta mais alinhada ao comportamento real da carga, especialmente em serviços sensíveis a variações rápidas de demanda ou que dependem de tempo de reação reduzido.
Como o Keda HTTP Add-on funciona?
O Keda HTTP Add-on é composto por quatro elementos principais, cada um com responsabilidades específicas dentro do fluxo de escalonamento baseado em requisições HTTP.
Operador – Responsável por observar eventos relacionados a HTTPScaledObjects. A partir dessas mudanças, cria, ajusta ou remove os recursos internos necessários para manter o comportamento de escalonamento.
Interceptor – Atua como ponto de entrada do tráfego HTTP. Ele recebe requisições externas, aplica o roteamento adequado e encaminha cada chamada para a aplicação interna correspondente.
Scaler – Monitora continuamente o volume de requisições pendentes associadas a uma aplicação. Com base nessa observação, reporta métricas para o KEDA utilizando o mecanismo de external scaler, permitindo que a decisão de escalonamento seja baseada diretamente no acúmulo de requisições.
KEDA – Opera como o escalador responsável por ajustar a quantidade de réplicas da aplicação HTTP. Ele utiliza os dados fornecidos pelo scaler para determinar quando aumentar ou reduzir o número de instâncias.
Como utilizar o componente?
A utilização do KEDA HTTP Add-on envolve alguns elementos dentro do ambiente Kubernetes. No contexto deste artigo, trabalharemos com o seguinte conjunto:
Aplicação PHP executando em Kubernetes
Uma aplicação HTTP, empacotada em container e implantada como um Deployment, servindo como base para observar o comportamento do escalonamento.Deployment configurado para scale-to-zero
A configuração define que a aplicação pode ser reduzida a zero réplicas quando o tráfego estiver ocioso, permitindo observar o comportamento de inicialização sob demanda.KEDA HTTP Add-on como ponto de interceptação
O add-on recebe o tráfego externo, gerencia a fila de requisições e garante que chamadas sejam corretamente encaminhadas ao serviço, independentemente do estado atual das réplicas.Escalonamento orientado à demanda
Com o scaler monitorando as requisições pendentes, o KEDA ajusta o número de réplicas conforme o acúmulo ou redução do tráfego.Atendimento de requisições mesmo com a aplicação inativa
O interceptor mantém uma fila temporária, permitindo que requisições recebam resposta mesmo quando o Deployment está em zero réplicas, enquanto o sistema inicia automaticamente novas instâncias.
Temos também alguns pré-requisitos a nível de ferramentas:
- Docker (Desktop ou Engine)
- Kubernetes configurado (kind ou Minikube)
- Kubectl instalado
- Helm instalado
Após todas instaladas e configuradas corretamente, é possível prosseguir.
1 - Criar a aplicação PHP
Crie um arquivo index.php
<?php
if ($_SERVER['REQUEST_URI'] === '/ping') {
echo "pong";
exit;
}
echo "Hello from PHP!";
Crie o Dockerfile:
FROM php:8.3-cli
COPY index.php /var/www/html/index.php
CMD ["php", "-S", "0.0.0.0:8080", "-t", "/var/www/html"]
Faça o build localmente:
eval $(minikube docker-env) # caso esteja utilizando o minikube
docker build -t keda-php-demo:latest .
2 - Criar o Deployment + Service
Arquivo deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: keda-php-demo
spec:
replicas: 0
selector:
matchLabels:
app: keda-php-demo
template:
metadata:
labels:
app: keda-php-demo
spec:
containers:
- name: keda-php-demo
image: keda-php-demo:latest
imagePullPolicy: Never
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: keda-php-demo
spec:
selector:
app: keda-php-demo
ports:
- port: 80
targetPort: 8080
Aplicar:
kubectl apply -f deployment.yaml
3 - Instalar o KEDA
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace
4 - Instalar o HTTP Add-on
helm install keda-addons-http kedacore/keda-add-ons-http \
--namespace keda
Isso instala:
- HTTP operator
- Interceptor Proxy (responsável por receber requisições)
- Scalers
5 - Criar o HTTPScaledObject
Arquivo http-scaledobject.yaml:
apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
name: keda-php-demo
spec:
hosts:
- php-demo.local
pathPrefixes:
- /
scaleTargetRef:
name: keda-php-demo
kind: Deployment
apiVersion: apps/v1
service: keda-php-demo
port: 80
replicas:
min: 1
max: 10
scaledownPeriod: 30
scalingMetric:
requestRate:
granularity: 1s
targetValue: 10
window: 1m
Aplicar:
kubectl apply -f http-scaledobject.yaml
6 - Testando a aplicação
Fazer port-forward do interceptor para acessar na máquina local:
kubectl port-forward svc/keda-add-ons-http-interceptor-proxy -n keda 8081:8080
Enviar requisição:
curl -H "Host: php-demo.local" http://localhost:8081/ping
Deve receber a resposta
pong
Mesmo com réplicas = 0.
O KEDA:
- Intercepta a requisição
- Sobe o pod automaticamente
- Encaminha a requisição quando o pod está pronto
- Escala conforme a fila de requisições
- Derruba tudo após scaledownPeriod: 30 segundos
OBS: É recomendável manter sempre réplicas ativas em ambientes de alto volume. Caso todas as réplicas cheguem a zero, o tempo necessário para que um novo POD/máquina fique saudável pode levar o solicitante a receber um Bad Gateway, o que acaba sendo contabilizado como indisponibilidade.
Analisando o dashboard do minikube
Caso tenha optado pelo minikube, é possível observar o comportamento no dashboard através do comando:
minikube dashboard
Após isso a seguinte página com os componentes do K8S será apresentada no navegador:
Como o scaling realmente funciona?
O HTTP Add-on não escala baseado em CPU e não escala baseado em RPS (Requests por Segundo).
Ele usa o número de requisições pendentes na fila interna mantida pelo interceptor.
Esse número representa quantas requisições ainda estão esperando ser atendidas pelos pods.
O algoritmo usado é o mesmo algoritmo oficial do Kubernetes HPA, só que aplicado à métrica de requisições pendentes.
A fórmula do HPA é:
desiredReplicas = ceil(
currentReplicas * ( pendingRequests / targetPendingRequests )
)
Onde:
pendingRequests -> tamanho da fila interna
targetPendingRequests -> quantas requisições 1 pod deve conseguir suportar sem saturar
currentReplicas -> número atual de pods
desiredReplicas -> número final de pods após cálculo
Suponha:
- pendingRequests = 25
- targetPendingRequests = 10
- currentReplicas = 1
Aplicando a fórmula:
desiredReplicas = ceil(1 * (25 / 10))
desiredReplicas = ceil(2.5)
desiredReplicas = 3
Ou seja: 3 réplicas são necessárias para esvaziar a fila mantendo ~10 requisições por pod.
Esse comportamento é consistente, previsível e resistente a bursts.
Considerações finais
Esse setup demonstra como o KEDA HTTP Add-on permite construir serviços:
- Eficientes e responsivos
- Econômicos (scale-to-zero real)
- Independentes de métricas como CPU e memória
Além disso, demonstra como é possível montar um ambiente completo em máquina local sem complexidade.
O único ponto de atenção é que o componente ainda está em beta release (data de publicação do artigo 11/2025), ou seja, os mantenedores não garantem um funcionamento 100% confiável em ambientes produtivos. Todavia o projeto se mostra muito promissor e logo logo (assim esperamos) estará production ready.
Top comments (0)