P0.0 · Auditoria de capacidade do cluster

Antes de qualquer deploy novo. Skills: `/k8s-ecomsmart`.

Por que este prompt existe

Levantamento de 17/09/2026 registrado na skill /firecrawl-ecomsmart: os quatro nós do cluster estavam com 98 a 99% da CPU alocada em requests, e vários volumes Longhorn apareceram faulted com ReplicaSchedulingFailure: insufficient storage mesmo com mais de 100 GB livres.

A aplicação deste projeto pede cerca de 1100m de CPU em requests. Ela não cabe hoje. Precisamos saber exatamente onde está a folga antes de escrever a primeira linha.

O prompt

Leia a skill /k8s-ecomsmart e faça uma auditoria de capacidade do cluster ecomsmart-hostinger. Não altere nada ainda — o objetivo é um diagnóstico com recomendação.

1. Capacidade

Levante e me apresente em tabela:

Por nó: CPU alocável, CPU em requests, CPU em uso real, memória alocável, memória em requests, memória em uso real
Percentual de alocação e percentual de uso real, lado a lado

kubectl top nodes
kubectl describe nodes | grep -A 8 "Allocated resources"

2. Onde está o desperdício

Liste todos os pods do cluster ordenados por requests.cpu, com o uso real ao lado. A coluna que interessa é a diferença: pod que pede 500m e usa 20m está segurando capacidade de graça.

kubectl get pods -A -o custom-columns=\
'NS:.metadata.namespace,POD:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory'
kubectl top pods -A --sort-by=cpu

Monte uma tabela com as 20 maiores diferenças entre pedido e uso, e classifique cada uma:

Classificação	Critério
Superdimensionado	usa menos de 20% do que pede, de forma estável
Adequado	usa entre 20% e 80%
Apertado	usa mais de 80%, ou já teve throttling

Para detectar throttling, olhe container_cpu_cfs_throttled_periods_total no Prometheus — o cluster já tem Grafana.

3. Longhorn

Investigue o problema de volumes faulted:

kubectl -n longhorn-system get volumes.longhorn.io
kubectl -n longhorn-system get nodes.longhorn.io -o wide
kubectl get pvc -A | grep -v Bound

Descubra se é falta de espaço real, política de réplicas (número de réplicas maior que nós elegíveis), storageOverProvisioningPercentage, ou disco não marcado como agendável. Me diga a causa provável com a evidência, não um palpite.

4. Recomendação

Entregue três coisas:

Quanto de CPU e memória dá para liberar reduzindo requests de pods superdimensionados, com a lista exata e o valor novo sugerido para cada um
Se, depois disso, a aplicação deste projeto cabe (cerca de 1100m de CPU e 6 Gi de memória). Se não couber, quanto falta
Se vale mais a pena adicionar um worker — com estimativa de custo na Hostinger e comparação com o esforço de redimensionar

5. Plano de ação

Escreva docs/CAPACIDADE.md neste repositório com o diagnóstico, a tabela de pods, a causa do problema do Longhorn e a recomendação. Esse arquivo entra no site pelo build.

Critérios de aceite

Tabela por nó com alocação e uso real, lado a lado
Tabela das 20 maiores diferenças entre pedido e uso, classificadas
Causa provável do Longhorn com a evidência que a sustenta
Número concreto de quanto dá para liberar
Recomendação clara: redimensionar, adicionar nó, ou os dois
docs/CAPACIDADE.md commitado

Não altere requests de nenhum serviço existente nesta etapa. Diagnóstico primeiro, mudança depois de eu aprovar.