A Dor Real: Quando o Kubernetes te promete o impossível
Se você já recebeu aquele alerta de “latência inexplicável” em horário de pico, sabe o que vou dizer: **seu cluster não está lento — ele está saturado**. Só que a maioria corre para tunar autoscaling, mexer em readiness probe ou aumentar CPU como quem troca vela do carro esperando que o motor vire V8.
A verdade é simples: Kubernetes não foi projetado para **tempo real justo**. Ele mascara picos, mas não os resolve. E quando a fila cresce, a latência explode. Exatamente como mostrado na vida real (e muito bem explicado no material sobre Teoria das Filas listado nas fontes).
A Solução Pragmática: Modele a fila, estabilize o throughput, pare de brigar com o cluster
O caminho é direto: **controle a taxa de entrada**, **reduza variância de processamento**, e **orquestre scaling com parcimônia**, subindo pods devagar para não criar rajadas de cold starts.
É feio? É simples? É. Mas funciona.
Implementação de Senior: Como estabilizar latência usando fila + limites bem definidos
Abaixo um exemplo real de como restringir throughput no próprio serviço para impedir avalanche de requisições sobre o cluster. Aqui uso um rate limiter simples acoplado ao handler HTTP (Go):
package main
import (
"golang.org/x/time/rate"
"net/http"
"log"
)
var limiter = rate.NewLimiter(50, 100) // 50 req/s com burst máximo de 100
func limited(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
w.WriteHeader(http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/process", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("OK"))
})
log.Fatal(http.ListenAndServe(":8080", limited(mux)))
}
Agora o serviço responde dentro de limites previsíveis. O cluster deixa de ser o gargalo e vira apenas o executor.
O Custo da Escolha: Determinismo não é grátis
Adotar controle rígido de throughput significa dizer “não” a picos. Significa rejeitar requisições quando necessário. Significa expor limites que muitos times têm medo político de admitir.
Mas a alternativa é pior: **latência fantasma** em produção e dashboards mentindo sobre o real impacto da saturação.
Direto das Trincheiras
- Latência nunca é linear. Sempre modele fila antes de escalar pod.
- Reinicio automático de container, como o pessoal lembrou no Reddit, cria buracos de desempenho. Evite que isso aconteça em rajadas.
- Autoscaling agressivo é um convite a cold starts simultâneos. Suba pods com calma.
Fontes
Quanto tempo você gasta aprendendo fora do horário de trabalho?, Como a Teoria das Filas explica latências ‘inexplicáveis’ em produção., Sem amor pelo Systemd? : r/devops – Reddit
Obrigado por acompanhar essa reflexão até o fim! Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog reymaster.dev.br, onde descascamos outros hypes da nossa área. Valeu e até a próxima! 😉
