Sizing & Capacity Planning¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: sizing para procurement enterprise más allá de la heurística de "hasta ~50 agents" de los quickstarts. Los números están anclados en los techos de HPA shippeados y en la ResourceQuota; trátelos como defaults de planificación y valídelos contra un pilot run usando los criterios de invalidación en
MONITORING_TEST_VALIDITY.md.
1. Techos de la flota (como se shippea)¶
| Componente | min | max (HPA) | Reconciliado con |
|---|---|---|---|
| Agentes Playwright | 1 | 80 | ResourceQuota de 320 pods (k8s/05-resource-quota.yaml) |
| Agentes k6 | 1 | 200 | misma quota (tope de blast-radius) |
| Personas | fijo | 100 | 20 países × 5 |
Subir un techo de HPA sin subir la quota es un no-op (los pods quedan Pending). La quota es el tope deliberado de blast-radius — cambie ambos 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 es pesado; auto-throttle consciente de cgroup |
| Agente k6 | ~0.25–0.5 vCPU | ~256–512 Mi | Generador de volumen, más liviano |
| Persona (Caddy + backend) | ~0.3–2 vCPU | ~512 Mi–2 Gi | real-app (Saleor/Ghost/Gitea) en el tope del rango |
| Dashboard / Postgres / PgBouncer | ~1–2 vCPU cada uno | ~512 Mi–2 Gi | control plane |
3. Sizing de nodes por modo de deployment¶
| Modo | Nodes UCS | Por node (mín) | Soporta |
|---|---|---|---|
| Single-node (lab/eval) | 1 | 16 vCPU / 64 GB / NVMe | ~50 agents + persona set reducido |
| Dual-node | 2 | 32 vCPU / 128 GB | agents en UCS-1, personas+services en UCS-2 |
| Tri-node | 3 | 32 vCPU / 128 GB | split Playwright / k6 / personas+services |
| Multi-node (máx) | 4 | 48+ vCPU / 192+ GB | flota completa de 80+200 agents + 100 personas |
El tuning de kernel del host (DaemonSet 85-node-tuning) es obligatorio para QUIC bajo carga:
UDP rmem_max/wmem_max = 64 MB, BBR + fq qdisc, CPU governor performance.
4. Clases de throughput (lo que un run puede impulsar)¶
CPS/throughput reales dependen del DUT y de la flota de nodes. Clasifique el objetivo antes del sizing:
| Clase | Intención | Guía de flota |
|---|---|---|
| Functional | corrección decrypt-on/off, mixes pequeños | single/dual-node, ≤50 agents |
| Capacity | CPS sostenido + throughput hacia un NGFW mid-range | tri/multi-node, flota k6 100–200 |
| HTTP/3 pressure | tasa de handshake QUIC (modo cps) | réplicas de h3loadgen dimensionadas a los test plans H3-ONLY; use un replica count FIJO acorde al CPS objetivo — nunca un HPA (un generador de carga no debe autoescalar a mitad de run; ver pkg/h3loadgen/README.md) |
5. Storage & crecimiento¶
| Dato | Ubicación | Driver de crecimiento |
|---|---|---|
| Postgres (control) | PVC del StatefulSet | audit log (WORM, append-only), ledger de tokens, tickets |
| Contenido de cloned-persona | NFS (dut-system) |
acciones de clone del operador (limitado por el número de slots) |
| Prometheus | PVC del TSDB | cardinalidad de scrape × retención |
Presupueste el audit log WORM para crecimiento por append constante; nunca se trunca in place (la retención es un paso separado de archivado).
6. Método¶
- Elija una clase de throughput (§4).
- Dimensione los nodes (§3) para la flota de agents que esa clase necesita.
- Corra un pilot; si cualquier señal de invalidación se dispara
(
HostUDPBufferOverflow, conntrack > 80%, CPU > 85% + p99, HPA clavado), el test bed — no el DUT — es el cuello de botella; escale y re-corra.