CPU: de RPS para milicores
O cálculo de CPU requests parte do princípio de que cada request ocupa a CPU pelo tempo de resposta. A fórmula RPS x Latência (s) x 1000 converte tráfego em milicores necessários. Um fator de ajuste por stack compensa overhead do runtime (ex: JVM consome mais CPU em GC que Go).
Para CPU limits, em cargas burstable usamos 4x o request (absorvendo picos sem throttling). Em cargas estáveis, 2x é suficiente. Muitas equipes de SRE preferem não definir CPU limits para evitar throttling desnecessário.
Memória: runtime base + overhead por request
Cada stack tem uma memória base diferente: Java/JVM (~350Mi com heap padrão), Node.js (~70Mi com V8), Go (~30Mi, muito leve) e Python (~100Mi). A cada request simultâneo, buffers, alocações e contextos adicionam memória proporcional ao RPS.
O limits.memory é definido como request + 30%. Se o Pod ultrapassar esse limite, o Kubernetes o encerra com OOMKilled, protegendo os outros workloads no Node.
Estimativa de custo: quanto cada Pod pesa na fatura
O custo é estimado com base em preços médios de instâncias AWS on-demand (~$0.04/vCPU/h e ~$0.005/GB/h). Em 730 horas/mês, um Pod com 500m de CPU e 256Mi de RAM custa aproximadamente $15/mês. Multiplique pelo número de réplicas para ter o custo total do serviço.