Sizing & Capacity Planning¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: sizing para procurement enterprise além da heurística de "até ~50 agents" dos quickstarts. Os números estão ancorados nos tetos de HPA shipados e na ResourceQuota; trate-os como defaults de planejamento e valide contra um pilot run usando os critérios de invalidação em
MONITORING_TEST_VALIDITY.md.
1. Tetos da frota (como shipado)¶
| Componente | min | max (HPA) | Reconciliado com |
|---|---|---|---|
| Agentes Playwright | 1 | 80 | ResourceQuota de 320 pods (k8s/05-resource-quota.yaml) |
| Agentes k6 | 1 | 200 | mesma quota (cap de blast-radius) |
| Personas | fixo | 100 | 20 países × 5 |
Subir um teto de HPA sem subir a quota é um no-op (os pods ficam Pending). A quota é o cap deliberado de blast-radius — mude os dois juntos.
2. Footprint de recursos por pod (requests)¶
| Workload | CPU req | Mem req | Notas |
|---|---|---|---|
| Agente Playwright | ~0.5–1 vCPU | ~512 Mi–1 Gi | Chromium é pesado; auto-throttle ciente de cgroup |
| Agente k6 | ~0.25–0.5 vCPU | ~256–512 Mi | Gerador de volume, mais leve |
| Persona (Caddy + backend) | ~0.3–2 vCPU | ~512 Mi–2 Gi | real-app (Saleor/Ghost/Gitea) no topo da faixa |
| Dashboard / Postgres / PgBouncer | ~1–2 vCPU cada | ~512 Mi–2 Gi | control plane |
3. Sizing de nodes por modo de deployment¶
| Modo | Nodes UCS | Por node (mín) | Comporta |
|---|---|---|---|
| Single-node (lab/eval) | 1 | 16 vCPU / 64 GB / NVMe | ~50 agents + persona set reduzido |
| Dual-node | 2 | 32 vCPU / 128 GB | agents no UCS-1, personas+services no UCS-2 |
| Tri-node | 3 | 32 vCPU / 128 GB | split Playwright / k6 / personas+services |
| Multi-node (máx) | 4 | 48+ vCPU / 192+ GB | frota completa de 80+200 agents + 100 personas |
O tuning de kernel do host (DaemonSet 85-node-tuning) é obrigatório para QUIC sob carga:
UDP rmem_max/wmem_max = 64 MB, BBR + fq qdisc, CPU governor performance.
4. Classes de throughput (o que um run consegue dirigir)¶
CPS/throughput reais dependem do DUT e da frota de nodes. Classifique o alvo antes do sizing:
| Classe | Intenção | Orientação de frota |
|---|---|---|
| Functional | correção decrypt-on/off, mixes pequenos | single/dual-node, ≤50 agents |
| Capacity | CPS sustentado + throughput para um NGFW mid-range | tri/multi-node, frota k6 100–200 |
| HTTP/3 pressure | taxa de handshake QUIC (modo cps) | réplicas de h3loadgen dimensionadas aos test plans H3-ONLY; use um replica count FIXO casado ao CPS alvo — nunca um HPA (gerador de carga não pode autoescalar no meio do run; ver pkg/h3loadgen/README.md) |
5. Storage & crescimento¶
| Dado | Local | Driver de crescimento |
|---|---|---|
| Postgres (controle) | PVC do StatefulSet | audit log (WORM, append-only), ledger de tokens, tickets |
| Conteúdo de cloned-persona | NFS (dut-system) |
ações de clone do operador (limitado pelo número de slots) |
| Prometheus | PVC do TSDB | cardinalidade de scrape × retenção |
Orce o audit log WORM para crescimento por append constante; ele nunca é truncado in place (a retenção é um passo separado de arquivamento).
6. Método¶
- Escolha uma classe de throughput (§4).
- Dimensione os nodes (§3) para a frota de agents que essa classe precisa.
- Rode um pilot; se qualquer sinal de invalidação disparar
(
HostUDPBufferOverflow, conntrack > 80%, CPU > 85% + p99, HPA pinado), o test bed — não o DUT — é o gargalo; escale e re-rode.