rightsizing-check: quais requests do seu cluster estão inflados

O que ele faz

• Offline por padrão

  Lê manifests e um arquivo de uso exportado (JSON do Prometheus, kubectl top ou CSV). Serve para CI, para revisar o cluster de um cliente a partir de arquivos e para ambientes isolados. Se você tem um Prometheus, --prometheus e --window buscam o uso, só com requisições GET.

• 11 regras

  Request inflado de CPU e de memória, uso acima do request, memória perto do limit, request ausente, dados faltando, um aviso quando um HPA ou KEDA escalaria para fora com o request recomendado e outro quando um VPA vai sobrescrever a mudança. Cada workload é oversized, undersized, ok ou sem dados.

• Recomendação com folga

  CPU: uso p95 mais 15%. Memória: máximo mais 20%. Um request é inflado acima de 1,5 vez a recomendação. Tudo configurável por flag.

• O que dá para recuperar

  Soma a vCPU e os GiB recuperáveis em requests, com uma linha de custo opcional com os seus preços. Só vira economia quando os nós consolidam.

• Cluster vivo e GitHub Action

  Com --cluster, lê workloads, HPAs, ScaledObjects do KEDA, VPAs e Argo Rollouts direto do cluster, só com chamadas list, e o uso do metrics-server. A Action comenta no pull request e falha na pipeline.

• A réplica mais ocupada decide

  Com várias réplicas, o pod mais quente define o request: uma réplica ocupada precisa da reserva mesmo que as outras fiquem ociosas.

Como obter o uso

Com um Prometheus, --prometheus e --window (por exemplo 7d) buscam o uso por você, uma query de cada vez. A janela precisa incluir o seu período mais cheio. Janela longa é pesada: a query de CPU é uma subquery sobre a janela inteira, e acima de 7d a ferramenta recusa, a menos que você passe --prom-allow-long-window. Sem Prometheus, aceita também as duas exportações à mão, um CSV e a saída de kubectl top, que é a mais fraca: um instante só.

# let the tool read it, over a window you choose (up to 7d):
rightsizing-check scan ./k8s --prometheus http://prometheus:9090 --window 7d

# or export it by hand, with the same two queries:
PROM=http://prometheus:9090

# CPU: the 95th percentile of the per-container usage, in cores
curl -sG "$PROM/api/v1/query" --data-urlencode \
  'query=max by (namespace, pod, container) (quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[5m])[7d:5m]))' > cpu.json

# Memory: the maximum working set, in bytes
curl -sG "$PROM/api/v1/query" --data-urlencode \
  'query=max by (namespace, pod, container) (max_over_time(container_memory_working_set_bytes{container!="",container!="POD"}[7d]))' > mem.json

Exemplo de saída

$ rightsizing-check scan ./k8s --prometheus https://prometheus.example.com --window 7d
STATUS      WORKLOAD                     CONTAINER  REPLICAS  CPU REQ  CPU USE  CPU REC  MEM REQ  MEM USE  MEM REC  FINDINGS
oversized   shop/deployment/api          app        3         1000m    120m     140m     2Gi      600Mi    720Mi    RC001,RC002
oversized   kube-system/daemonset/agent  agent      -         500m     40m      50m      512Mi    120Mi    144Mi    RC001,RC002
undersized  shop/deployment/worker       worker     2         100m     320m     370m     256Mi    576Mi    692Mi    RC003,RC004,RC005
undersized  shop/statefulset/db          db         1         -        450m     520m     -        1.5Gi    1844Mi   RC006
ok          shop/deployment/web          web        2         150m     120m     140m     200Mi    144Mi    176Mi    -
no-data     shop/cronjob/report          report     -         -        ?        ?        -        ?        ?        RC007

6 workloads: 2 oversized, 2 undersized, 1 ok, 1 without data
Reclaimable requests: 2.6 vCPU (73% of the 3.5 requested) and 3.9 GiB (56% of 6.9).

O que ele não faz

• A recomendação é um ponto de partida: vale o que vale a janela dos seus dados. Um job mensal ou um pico que você não capturou faz um request parecer inflado.
• HPA: um HorizontalPodAutoscaler que escala por utilização usa o request como denominador. A ferramenta lê HPAs e ScaledObjects do KEDA dos manifests e avisa (RC009) quando o request recomendado faria o HPA escalar para fora. Um HPA que só existe no cluster não é visto: exporte e passe o arquivo.
• Memória não é compressível: um limit abaixo do uso mata o container. Não reduza um container marcado com RC005 antes de entender por que ele está perto do limit.
• Janela longa é pesada: a query de CPU é uma subquery sobre a janela inteira, e num Prometheus pequeno uma janela de 14 dias chegou a fazer o pod ser despejado por falta de memória. Acima de 7d a ferramenta recusa, a menos que você passe --prom-allow-long-window.
• Os pods são casados com os workloads pelo nome. Jobs, CronJobs e CRDs que criam pods ficam de fora.

Quer ajuda para ler o resultado no seu cluster?

Eu reviso o seu ambiente, valido as recomendações com os seus dados e monto um plano de redução de custo.