LINEA BASE (2026-04-10, rutas-norte-pre, 4 replicas de api-reservas)

Peticiones por segundo sostenidas:      340 rps
Latencia p50:                            42 ms
Latencia p95:                           287 ms
Latencia p99:                           891 ms
Tasa de error:                          0,02 %
CPU media por replica:                  310m de 412m (75 %)
Conexiones activas a PostgreSQL:         78 de 200

// pruebas/carga/puente-mayo.js
import http from 'k6/http';
import { check, sleep, group } from 'k6';
import { Rate, Trend, Counter } from 'k6/metrics';

// ---------------------------------------------------------------------------
// METRICAS PERSONALIZADAS
// Las metricas de k6 por defecto miden peticiones HTTP. Estas miden
// OPERACIONES DE NEGOCIO, que es lo que le importa a Rutas Norte.
// ---------------------------------------------------------------------------
const errorReservas = new Rate('errores_reserva');
const duracionBusqueda = new Trend('duracion_busqueda_rutas', true);
const duracionReserva = new Trend('duracion_confirmar_reserva', true);
const reservasConfirmadas = new Counter('reservas_confirmadas');

// ---------------------------------------------------------------------------
// CONFIGURACION DEL ESCENARIO
// ---------------------------------------------------------------------------
export const options = {
  scenarios: {
    // ESCENARIO 1: la avalancha de la apertura de la venta.
    // Reproduce lo que ocurre el 25 de abril a las 10:00.
    apertura_venta: {
      executor: 'ramping-arrival-rate',
      // ramping-arrival-rate mantiene una TASA DE LLEGADA constante,
      // independientemente de si el sistema responde rapido o lento.
      // Es la diferencia critica con ramping-vus: los usuarios reales NO
      // esperan a que termines de atender al anterior para llegar.
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 3000,
      stages: [
        { duration: '2m',  target: 20   },  // Calma previa. Linea base.
        { duration: '40s', target: 500  },  // LA AVALANCHA: x25 en 40 segundos
        { duration: '10m', target: 500  },  // Meseta: dos horas comprimidas
        { duration: '5m',  target: 120  },  // Descenso gradual
        { duration: '3m',  target: 20   },  // Vuelta a la calma
      ],
      gracefulStop: '30s',
    },
  },

  // ---------------------------------------------------------------------------
  // UMBRALES: si no se cumplen, k6 termina con codigo de error.
  // Esto convierte la prueba en algo que puede FALLAR en un pipeline de CI.
  // ---------------------------------------------------------------------------
  thresholds: {
    // El SLO de Rutas Norte: p95 por debajo de 300 ms.
    'http_req_duration': ['p(95)<300', 'p(99)<1000'],
    // Menos del 1 % de errores en las reservas. Es lo que cuesta dinero.
    'errores_reserva': ['rate<0.01'],
    // La busqueda de rutas es la operacion mas frecuente: mas exigente.
    'duracion_busqueda_rutas': ['p(95)<200'],
    // Confirmar una reserva escribe en PostgreSQL: se le permite mas.
    'duracion_confirmar_reserva': ['p(95)<800'],
    // Menos del 0,5 % de fallos HTTP en total.
    'http_req_failed': ['rate<0.005'],
  },
};

// ---------------------------------------------------------------------------
// DATOS DE PRUEBA (ficticios)
// ---------------------------------------------------------------------------
const ORIGENES = ['BIL', 'SDR', 'OVD', 'GIJ', 'SAN', 'VIT', 'LOG', 'PAM'];
const DESTINOS = ['MAD', 'BCN', 'ZAZ', 'VLC', 'SVQ', 'BIO', 'LCG'];

const BASE = __ENV.URL_BASE || 'http://api-reservas.rutas-norte-pre.svc.cluster.local';

function aleatorio(lista) {
  return lista[Math.floor(Math.random() * lista.length)];
}

function fechaPuente() {
  // Las reservas del puente se concentran en tres dias concretos.
  const dias = ['2026-04-30', '2026-05-01', '2026-05-02', '2026-05-03'];
  return aleatorio(dias);
}

// ---------------------------------------------------------------------------
// EL RECORRIDO DEL USUARIO
// Reproduce lo que hace una persona de verdad: busca, mira, elige, confirma.
// ---------------------------------------------------------------------------
export default function () {
  const origen = aleatorio(ORIGENES);
  const destino = aleatorio(DESTINOS);
  const fecha = fechaPuente();

  let idRuta = null;

  // PASO 1: buscar rutas. Es la operacion MAS FRECUENTE (todo el mundo busca).
  group('01_buscar_rutas', function () {
    const inicio = Date.now();
    const res = http.get(
      `${BASE}/rutas?origen=${origen}&destino=${destino}&fecha=${fecha}`,
      { tags: { operacion: 'buscar_rutas' } }
    );
    duracionBusqueda.add(Date.now() - inicio);

    const ok = check(res, {
      'busqueda devuelve 200': (r) => r.status === 200,
      'busqueda devuelve rutas': (r) => {
        try {
          return JSON.parse(r.body).rutas !== undefined;
        } catch (e) {
          return false;
        }
      },
    });

    if (ok && res.status === 200) {
      try {
        const rutas = JSON.parse(res.body).rutas;
        if (rutas && rutas.length > 0) {
          idRuta = aleatorio(rutas).id;
        }
      } catch (e) { /* cuerpo malformado: se contabiliza en el check */ }
    }
  });

  // PAUSA: el usuario mira los resultados. Entre 2 y 6 segundos.
  // ESTE SLEEP ES ESENCIAL. Sin el, la prueba genera un patron de carga
  // que no se parece en nada al real, y las conclusiones no valen.
  sleep(Math.random() * 4 + 2);

  if (!idRuta) {
    // No hay rutas para esa combinacion. El usuario se va. Es realista:
    // no todo el mundo encuentra lo que busca.
    return;
  }

  // PASO 2: consultar la disponibilidad de plazas.
  // Esta consulta DEBERIA servirse desde redis-cache.
  group('02_consultar_plazas', function () {
    const res = http.get(
      `${BASE}/rutas/${idRuta}/plazas`,
      { tags: { operacion: 'consultar_plazas' } }
    );
    check(res, { 'plazas devuelve 200': (r) => r.status === 200 });
  });

  sleep(Math.random() * 3 + 1);

  // PASO 3: confirmar la reserva.
  // Solo el 18 % de las busquedas terminan en reserva. Es la tasa de
  // conversion real de Rutas Norte, medida en produccion.
  if (Math.random() > 0.18) {
    return;
  }

  group('03_confirmar_reserva', function () {
    const inicio = Date.now();
    const carga = JSON.stringify({
      idRuta: idRuta,
      asiento: Math.floor(Math.random() * 54) + 1,
      pasajero: {
        nombre: `Cliente Prueba ${__VU}-${__ITER}`,
        documento: `00000000${(__VU % 10)}X`,
        correo: `prueba-${__VU}-${__ITER}@ejemplo.example`,
      },
    });

    const res = http.post(`${BASE}/reservas`, carga, {
      headers: { 'Content-Type': 'application/json' },
      tags: { operacion: 'confirmar_reserva' },
    });

    duracionReserva.add(Date.now() - inicio);

    const ok = check(res, {
      'reserva devuelve 201': (r) => r.status === 201,
      'reserva devuelve localizador': (r) => {
        try {
          return JSON.parse(r.body).localizador !== undefined;
        } catch (e) {
          return false;
        }
      },
    });

    errorReservas.add(!ok);
    if (ok) reservasConfirmadas.add(1);
  });

  sleep(1);
}

// ---------------------------------------------------------------------------
// RESUMEN FINAL
// ---------------------------------------------------------------------------
export function handleSummary(data) {
  const m = data.metrics;
  const linea = (etiqueta, valor) => `  ${etiqueta.padEnd(38)} ${valor}\n`;

  let salida = '\n=== PRUEBA DE CARGA: PUENTE DE MAYO ===\n\n';
  salida += linea('Peticiones totales', m.http_reqs.values.count);
  salida += linea('Peticiones por segundo (media)', m.http_reqs.values.rate.toFixed(1));
  salida += linea('Reservas confirmadas', m.reservas_confirmadas ? m.reservas_confirmadas.values.count : 0);
  salida += '\n  --- LATENCIA GLOBAL ---\n';
  salida += linea('p50', m.http_req_duration.values['p(50)'].toFixed(1) + ' ms');
  salida += linea('p95', m.http_req_duration.values['p(95)'].toFixed(1) + ' ms');
  salida += linea('p99', m.http_req_duration.values['p(99)'].toFixed(1) + ' ms');
  salida += linea('maximo', m.http_req_duration.values.max.toFixed(1) + ' ms');
  salida += '\n  --- ERRORES ---\n';
  salida += linea('Tasa de fallo HTTP', (m.http_req_failed.values.rate * 100).toFixed(3) + ' %');

  return {
    'stdout': salida,
    'resultados/puente-mayo.json': JSON.stringify(data, null, 2),
  };
}

export const options = {
  vus: 3,
  duration: '2m',
  thresholds: {
    'http_req_failed': ['rate<0.01'],
    'http_req_duration': ['p(95)<500'],
  },
};

export const options = {
  scenarios: {
    carga_normal: {
      executor: 'constant-arrival-rate',
      rate: 120,               // 120 peticiones por segundo, el trafico habitual
      timeUnit: '1s',
      duration: '20m',
      preAllocatedVUs: 100,
      maxVUs: 500,
    },
  },
  thresholds: {
    'http_req_duration': ['p(95)<300'],
    'http_req_failed': ['rate<0.001'],
  },
};

export const options = {
  scenarios: {
    estres: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 5000,
      stages: [
        { duration: '3m', target: 100  },
        { duration: '3m', target: 200  },
        { duration: '3m', target: 400  },
        { duration: '3m', target: 600  },
        { duration: '3m', target: 800  },
        { duration: '3m', target: 1200 },
        { duration: '5m', target: 0    },   // Recuperacion: ¿se recupera solo?
      ],
    },
  },
  // SIN thresholds: queremos que llegue hasta el final aunque falle.
};

export const options = {
  scenarios: {
    punta: {
      executor: 'ramping-arrival-rate',
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 3000,
      stages: [
        { duration: '2m',  target: 20  },   // Calma
        { duration: '30s', target: 800 },   // PUNTA BRUTAL
        { duration: '3m',  target: 800 },   // Sostenido
        { duration: '2m',  target: 20  },   // Vuelta a la calma
      ],
    },
  },
};

export const options = {
  scenarios: {
    resistencia: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s',
      duration: '8h',            // OCHO HORAS
      preAllocatedVUs: 100,
      maxVUs: 300,
    },
  },
};

# k8s/pruebas/job-carga-puente-mayo.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: script-carga
  namespace: rutas-norte-pre
data:
  puente-mayo.js: |
    // (el contenido del script del apartado 2)
---
apiVersion: batch/v1
kind: Job
metadata:
  name: carga-puente-mayo
  namespace: rutas-norte-pre
  labels:
    app: prueba-carga
    app.kubernetes.io/part-of: rutas-norte
spec:
  backoffLimit: 0        # Si falla, NO reintentar: falsearia los resultados
  ttlSecondsAfterFinished: 86400
  template:
    metadata:
      labels:
        app: prueba-carga
    spec:
      restartPolicy: Never

      # El generador de carga NO debe competir por recursos con lo que mide.
      # Lo mandamos a un nodo dedicado con taint y toleration (06-05).
      tolerations:
        - key: rol
          operator: Equal
          value: pruebas
          effect: NoSchedule
      nodeSelector:
        rol: pruebas

      containers:
        - name: k6
          image: grafana/k6:0.52.0
          command: ["k6", "run"]
          args:
            - "--out"
            - "experimental-prometheus-rw"     # Envia metricas a Prometheus
            - "--tag"
            - "prueba=puente-mayo"
            - "/scripts/puente-mayo.js"
          env:
            - name: URL_BASE
              value: "http://api-reservas.rutas-norte-pre.svc.cluster.local"
            - name: K6_PROMETHEUS_RW_SERVER_URL
              value: "http://prometheus-operated.monitorizacion.svc.cluster.local:9090/api/v1/write"
            - name: K6_PROMETHEUS_RW_TREND_STATS
              value: "p(50),p(95),p(99),max"
          resources:
            # GENEROSO A PROPOSITO. Si k6 se queda sin CPU, no genera la carga
            # pedida y la prueba MIENTE: mediras un sistema que aguanta bien
            # porque nunca recibio la carga que creias.
            requests:
              cpu: "2"
              memory: 2Gi
            limits:
              cpu: "4"
              memory: 4Gi
          volumeMounts:
            - name: scripts
              mountPath: /scripts
      volumes:
        - name: scripts
          configMap:
            name: script-carga

kubectl apply -f k8s/pruebas/job-carga-puente-mayo.yaml
kubectl logs -f job/carga-puente-mayo -n rutas-norte-pre

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: carga-puente-mayo
  namespace: rutas-norte-pre
spec:
  parallelism: 4          # Cuatro pods generando carga en paralelo
  script:
    configMap:
      name: script-carga
      file: puente-mayo.js
  runner:
    resources:
      requests: {cpu: "2", memory: 2Gi}
      limits: {cpu: "2", memory: 2Gi}

     ✓ busqueda devuelve 200
     ✓ busqueda devuelve rutas
     ✗ reserva devuelve 201
      ↳  97% — ✓ 8214 / ✗ 254

     checks.........................: 98.42% ✓ 47892     ✗ 768
     data_received..................: 1.2 GB  1.8 MB/s
     data_sent......................: 89 MB   134 kB/s
     duracion_busqueda_rutas........: avg=98.4ms  min=12ms  med=71ms   max=4.2s   p(95)=241ms  p(99)=892ms
     duracion_confirmar_reserva.....: avg=421ms   min=89ms  med=302ms  max=8.9s   p(95)=1.4s   p(99)=4.1s
     errores_reserva................: 2.96%  ✓ 254       ✗ 8214
     http_req_blocked...............: avg=1.2ms   min=0s    med=2µs    max=1.1s   p(95)=4µs
     http_req_connecting............: avg=0.9ms   min=0s    med=0s     max=892ms  p(95)=0s
   ✗ http_req_duration..............: avg=142ms   min=8ms   med=68ms   max=8.9s   p(95)=487ms  p(99)=2.1s
       { expected_response:true }...: avg=131ms   min=8ms   med=66ms   max=6.2s   p(95)=443ms
   ✗ http_req_failed................: 1.34%  ✓ 892       ✗ 65432
     http_reqs......................: 66324  99.4/s
     iteration_duration.............: avg=6.8s    min=3.1s  med=6.4s   max=22s    p(95)=12.4s
     iterations.....................: 14204  21.3/s
     vus............................: 187    min=20      max=1240
     vus_max........................: 3000   min=3000    max=3000

     reservas_confirmadas...........: 8214   12.3/s

ERRO[0942] thresholds on metrics 'http_req_duration, http_req_failed, errores_reserva' have been crossed

http_req_duration: avg=142ms   med=68ms   p(95)=487ms   p(99)=2.1s   max=8.9s

Tiempo de espera ≈ TiempoServicio × (utilizacion / (1 - utilizacion))

Utilizacion 50 %:  espera = 1,0 x tiempo de servicio
Utilizacion 80 %:  espera = 4,0 x tiempo de servicio
Utilizacion 90 %:  espera = 9,0 x tiempo de servicio
Utilizacion 95 %:  espera = 19,0 x tiempo de servicio
Utilizacion 99 %:  espera = 99,0 x tiempo de servicio

http_req_failed: 1.34%  ✓ 892  ✗ 65432
errores_reserva: 2.96%  ✓ 254  ✗ 8214

Configuracion "razonable" de api-reservas (Node.js con pg-pool):
  pool.max = 20 conexiones

Situacion normal: 4 replicas.
  Conexiones totales: 4 x 20 = 80.
  postgres-reservas: max_connections = 200.
  80 < 200. Todo bien.

PUENTE DE MAYO: el HPA escala a 30 replicas.
  Conexiones totales: 30 x 20 = 600.
  max_connections = 200.

  400 conexiones RECHAZADAS.

1. Las replicas 11 a 30 no consiguen conexion.
2. Sus peticiones fallan con "too many connections" o esperan hasta timeout.
3. api-reservas devuelve 500. La CPU SUBE (manejo de errores, reintentos).
4. El HPA ve mas CPU y quiere escalar MAS. maxReplicas lo corta en 30.
5. Las 10 replicas que SI tienen conexion reciben todo el trafico.
6. PostgreSQL, con 200 conexiones activas, dedica mas tiempo a cambiar de
   contexto entre procesos que a ejecutar consultas.
7. Las consultas se ralentizan. Las conexiones se retienen mas tiempo.
8. Colapso total.

replicas_maximas x pool_por_replica  <=  max_connections x 0,8

maxReplicas de api-reservas: 30
max_connections de postgres-reservas: 200
Reserva del 20 %: 200 x 0,8 = 160

pool_por_replica <= 160 / 30 = 5,33  ->  5 conexiones por replica

Concurrencia = Tasa de llegada x Tiempo de servicio

Con 5 conexiones y una consulta media de 8 ms:
  Consultas por segundo = 5 / 0,008 = 625 consultas/s por replica

Si cada peticion HTTP hace 2 consultas de media:
  Peticiones por segundo = 625 / 2 = 312 rps por replica

# ConfigMap de api-reservas
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-reservas-config
  namespace: rutas-norte-pro
data:
  # POOL DE CONEXIONES A POSTGRESQL
  #
  # Calculo: maxReplicas (30) x POOL_MAX <= max_connections (200) x 0,8 = 160
  #          POOL_MAX <= 160 / 30 = 5,33  ->  5
  #
  # Verificacion de capacidad (ley de Little):
  #   5 conexiones / 8 ms por consulta = 625 consultas/s por replica
  #   Con 2 consultas por peticion: 312 rps por replica.
  #   Punto de inflexion medido: 112 rps por replica.
  #   El pool NO es el limitante. Sobra con 5.
  #
  # NO SUBIR sin recalcular. Con 30 replicas, cada conexion extra por replica
  # son 30 conexiones mas contra un limite de 200.
  PG_POOL_MAX: "5"
  PG_POOL_MIN: "2"

  # Timeout de espera por una conexion libre. 3 segundos: preferimos fallar
  # rapido (el usuario reintenta) a acumular peticiones esperando.
  PG_POOL_ACQUIRE_TIMEOUT_MS: "3000"

  # Cerrar conexiones ociosas a los 30 s: libera recursos en PostgreSQL
  # cuando el HPA baja replicas.
  PG_POOL_IDLE_TIMEOUT_MS: "30000"

  # Reciclar conexiones cada 30 minutos: evita conexiones zombis y fugas
  # de memoria del lado del servidor.
  PG_POOL_MAX_LIFETIME_MS: "1800000"

# k8s/base/deployment-pgbouncer.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: rutas-norte-pro
  labels:
    app: pgbouncer
    app.kubernetes.io/part-of: rutas-norte
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pgbouncer
  template:
    metadata:
      labels:
        app: pgbouncer
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: pgbouncer
      containers:
        - name: pgbouncer
          image: bitnami/pgbouncer:1.22.1
          env:
            - name: PGBOUNCER_POOL_MODE
              # TRANSACTION: la conexion al servidor se asigna solo durante
              # una transaccion. Es lo que permite la multiplexacion masiva.
              # ADVERTENCIA: incompatible con sentencias preparadas de sesion,
              # cursores con nombre y LISTEN/NOTIFY. La aplicacion debe estar
              # escrita teniendolo en cuenta.
              value: "transaction"
            - name: PGBOUNCER_MAX_CLIENT_CONN
              # 1000 conexiones de CLIENTE. Con 30 replicas x 20 = 600. Sobra.
              value: "1000"
            - name: PGBOUNCER_DEFAULT_POOL_SIZE
              # Solo 25 conexiones al SERVIDOR por base de datos y usuario.
              # Con 3 replicas de pgbouncer: 75 conexiones totales a PostgreSQL,
              # muy por debajo de las 200. Y estables: no dependen del HPA.
              value: "25"
            - name: PGBOUNCER_RESERVE_POOL_SIZE
              value: "5"
          resources:
            requests: {cpu: 100m, memory: 128Mi}
            limits: {cpu: 500m, memory: 256Mi}

// MAL: una consulta para las rutas, y una MAS por cada ruta. N+1.
const rutas = await db.query(
  'SELECT id, origen, destino, hora_salida FROM rutas WHERE origen=$1 AND destino=$2',
  [origen, destino]
);

for (const ruta of rutas) {
  // Si hay 30 rutas, esto son 30 consultas ADICIONALES.
  ruta.plazasLibres = await db.query(
    'SELECT COUNT(*) FROM plazas WHERE ruta_id=$1 AND estado=$2',
    [ruta.id, 'libre']
  );
}
// TOTAL: 31 consultas para responder UNA peticion.

// BIEN: UNA sola consulta con agregacion.
const rutas = await db.query(`
  SELECT
    r.id, r.origen, r.destino, r.hora_salida,
    COUNT(p.id) FILTER (WHERE p.estado = 'libre') AS plazas_libres
  FROM rutas r
  LEFT JOIN plazas p ON p.ruta_id = r.id
  WHERE r.origen = $1 AND r.destino = $2 AND r.fecha = $3
  GROUP BY r.id, r.origen, r.destino, r.hora_salida
  ORDER BY r.hora_salida
`, [origen, destino, fecha]);
// TOTAL: 1 consulta.

-- Diagnostico: ¿como ejecuta PostgreSQL esta consulta?
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM rutas WHERE origen = 'BIL' AND destino = 'MAD' AND fecha = '2026-05-01';

Seq Scan on rutas  (cost=0.00..18432.00 rows=12 width=84) (actual time=0.031..89.412 rows=8 loops=1)
  Filter: ((origen = 'BIL') AND (destino = 'MAD') AND (fecha = '2026-05-01'))
  Rows Removed by Filter: 847992
  Buffers: shared hit=2841 read=5591
Planning Time: 0.184 ms
Execution Time: 89.487 ms

-- El indice compuesto que resuelve la consulta
CREATE INDEX CONCURRENTLY idx_rutas_busqueda
  ON rutas (origen, destino, fecha)
  INCLUDE (hora_salida, precio_base);

Index Scan using idx_rutas_busqueda on rutas  (cost=0.42..8.61 rows=12 width=84)
                                              (actual time=0.024..0.041 rows=8 loops=1)
  Index Cond: ((origen = 'BIL') AND (destino = 'MAD') AND (fecha = '2026-05-01'))
  Buffers: shared hit=5
Planning Time: 0.211 ms
Execution Time: 0.068 ms

-- Requiere la extension pg_stat_statements
SELECT
  substring(query, 1, 80) AS consulta,
  calls,
  round(mean_exec_time::numeric, 2) AS media_ms,
  round(total_exec_time::numeric / 1000, 1) AS total_s,
  rows / GREATEST(calls, 1) AS filas_por_llamada
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO stats | grep keyspace

keyspace_hits:1284729
keyspace_misses:8471203

Tasa de aciertos = 1.284.729 / (1.284.729 + 8.471.203) = 13,2 %

// MAL: la clave incluye la marca de tiempo exacta de la peticion.
// CADA peticion genera una clave distinta. Tasa de aciertos ~0 %.
const clave = `plazas:${rutaId}:${Date.now()}`;

// MAL: incluye el identificador del usuario, que no afecta al resultado.
const clave = `rutas:${origen}:${destino}:${fecha}:${usuarioId}`;

// BIEN: solo los parametros que determinan el resultado.
const clave = `rutas:${origen}:${destino}:${fecha}`;

Sin cache: 500 consultas/s a PostgreSQL.
Con TTL de 10 s: 1 consulta cada 10 s = 0,1 consultas/s a PostgreSQL.

Reduccion: 5.000 veces.
Coste: los datos pueden estar hasta 10 segundos desactualizados.

# ConfigMap de redis-cache
maxmemory 1500mb
maxmemory-policy allkeys-lru
# allkeys-lru: al llenarse, expulsa las claves menos usadas recientemente.
# SIN esto, Redis crece hasta el OOMKilled (lo vimos en 09-02).

# ConfigMap de tienda-web: /etc/nginx/conf.d/rutas-norte.conf

# --- COMPRESION ---
gzip on;
gzip_vary on;
gzip_min_length 1024;          # No comprimir lo pequeno: el coste de CPU no compensa
gzip_comp_level 5;             # 5 de 9: buen equilibrio. El 9 gasta mucha CPU
                               # para un 2-3 % mas de compresion
gzip_types
    text/plain text/css text/javascript
    application/javascript application/json
    application/xml image/svg+xml;

# Brotli comprime un 15-20 % mejor que gzip para texto.
# PRECOMPRIMIDO en el build: coste de CPU CERO en tiempo de ejecucion.
brotli_static on;
gzip_static on;

# --- CACHE DE ACTIVOS ---
# Los ficheros con hash en el nombre (app.4f8a2c.js) son INMUTABLES:
# si cambia el contenido, cambia el nombre. Se pueden cachear un ano.
location ~* \.(js|css|woff2|png|jpg|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;            # No registrar activos: reduce E/S un 80 %
}

# El HTML NO se cachea: es el que apunta a los ficheros con hash.
location = /index.html {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

# --- CONEXIONES PERSISTENTES HACIA api-reservas ---
upstream api_reservas {
    server api-reservas.rutas-norte-pro.svc.cluster.local:8080;
    # 64 conexiones persistentes reutilizadas. Sin esto, nginx abre y cierra
    # una conexion TCP por peticion: 3 paquetes de handshake mas el cierre.
    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

location /api/ {
    proxy_pass http://api_reservas/;
    # OBLIGATORIO para que keepalive funcione: HTTP/1.1 y sin cabecera
    # Connection heredada del cliente.
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Coste de una conexion TCP nueva (dentro del cluster):
  SYN -> SYN/ACK -> ACK:  ~0,4 ms (3 paquetes)
  Cierre (FIN/ACK x2):    ~0,2 ms
  Total: ~0,6 ms de latencia anadida por peticion

Con 500 peticiones/s: 300 ms/s de latencia acumulada.

Y peor: los puertos efimeros del lado de nginx se agotan.
El rango tipico son ~28.000 puertos. Con TIME_WAIT de 60 s:
  28.000 / 60 = 466 conexiones nuevas por segundo COMO MAXIMO.
Por encima de eso: errores de "cannot assign requested address".

// api-reservas: agente HTTP con conexiones persistentes
const http = require('http');
const agente = new http.Agent({
  keepAlive: true,
  keepAliveMsecs: 30000,
  maxSockets: 50,
  maxFreeSockets: 10,
  timeout: 5000,
});

cfs_period_us = 100.000 (100 ms)
cfs_quota_us  = 100.000 (100 ms de CPU por cada 100 ms de reloj)

cfs_period_us = 100.000 (100 ms)
cfs_quota_us  =  50.000 (50 ms de CPU por cada 100 ms de reloj)

api-reservas con limits.cpu: 1  ->  cuota de 100 ms por periodo de 100 ms.

Node.js con 4 hilos activos (el bucle de eventos + 3 del pool de libuv
para criptografia, compresion y DNS):

Periodo de 100 ms:
  t=0 ms:   los 4 hilos empiezan a trabajar
  t=25 ms:  4 hilos x 25 ms = 100 ms de CPU consumidos. CUOTA AGOTADA.
  t=25 ms:  el kernel PARA todos los hilos.
  t=100 ms: nuevo periodo. Se reanudan.

RESULTADO: el contenedor solo trabaja 25 ms de cada 100.
           Esta parado el 75 % DEL TIEMPO DE RELOJ.

Y sin embargo, kubectl top muestra:
  CPU: 1000m (100 % del limite)

Consumio exactamente su cuota. Parece "al limite" y no "estrangulado".
Pero cualquier peticion que llegue en t=30 ms ESPERA 70 ms sin hacer nada.

t=12,5 ms: cuota agotada.
El contenedor trabaja 12,5 ms de cada 100: el 12,5 % del tiempo.
Una peticion que llegue en t=20 ms espera 80 ms.

Y kubectl top mostraria 500m: "al 100 % de su limite".

# Porcentaje de periodos en los que el contenedor fue estrangulado
rate(container_cpu_cfs_throttled_periods_total{
  namespace="rutas-norte-pro", container="api"
}[5m])
/
rate(container_cpu_cfs_periods_total{
  namespace="rutas-norte-pro", container="api"
}[5m])
* 100

# Segundos de estrangulamiento por segundo: cuanto tiempo REAL se pierde
rate(container_cpu_cfs_throttled_seconds_total{
  namespace="rutas-norte-pro", container="api"
}[5m])

api-reservas, limits.cpu: 1, 4 replicas, 340 rps:
  Periodos estrangulados: 18,4 %
  Tiempo estrangulado: 0,31 s/s
  Latencia p95: 287 ms
  Latencia p99: 891 ms

resources:
  requests:
    cpu: 412m         # Reserva garantizada
    memory: 800Mi
  limits:
    # SIN limits.cpu
    memory: 1600Mi    # El limite de memoria SI se mantiene

# api-reservas: SIN limite de CPU
resources:
  requests:
    cpu: 412m          # Reserva garantizada. Peso en el reparto.
    memory: 800Mi
  limits:
    # SIN limits.cpu DELIBERADAMENTE.
    #
    # Motivo: con limits.cpu: 1 mediamos un 18,4 % de periodos estrangulados
    # y un p99 de 891 ms. Node.js usa varios hilos (bucle de eventos + pool de
    # libuv) y agota la cuota de 100 ms en ~25 ms de reloj.
    #
    # Sin limite:
    #   - Estrangulamiento: 0 %
    #   - p99: 891 ms -> 340 ms
    #   - Arranque: 25 s -> 9 s (relevante para el autoescalado, 09-01)
    #
    # Riesgo asumido: un pod defectuoso puede consumir la CPU sobrante del
    # nodo. Mitigaciones:
    #   - El requests garantiza el minimo de todos los demas pods.
    #   - LimitRange del namespace impone un techo de 4 nucleos por contenedor.
    #   - Alerta si un pod supera 3x su requests durante 10 minutos.
    #
    # El LIMITE DE MEMORIA SI SE MANTIENE: la memoria NO es compresible y
    # un pod sin limite de memoria puede tumbar el nodo entero.
    memory: 1600Mi

# Un pod que consume mas del triple de su requests de forma sostenida
(
  rate(container_cpu_usage_seconds_total{namespace="rutas-norte-pro"}[10m])
  /
  on(pod, container) kube_pod_container_resource_requests{resource="cpu"}
) > 3

Nodo de 16 GiB. Contenedor con limits.memory: 1Gi.

Node.js (segun version y configuracion) puede decidir un heap maximo
basandose en los 16 GiB del host, no en el 1 GiB del contenedor.

Resultado: el recolector de basura no se activa con urgencia porque cree
que tiene memoria de sobra. El heap crece hasta rozar el GiB del contenedor.

El kernel: OOMKilled.

Y lo peor: el proceso muere SIN aviso ni traza. Solo aparece "OOMKilled"
en el estado del pod. Node.js ni se entera.

env:
  # --max-old-space-size fija el tamano maximo del heap de objetos antiguos
  # en MEGABYTES.
  #
  # Calculo para un limits.memory de 1600Mi:
  #   Heap de JavaScript:  1024 MB   (--max-old-space-size=1024)
  #   Buffers y ArrayBuffer:  ~200 MB (fuera del heap)
  #   Codigo nativo y bibliotecas: ~150 MB
  #   Pila y estructuras internas:  ~80 MB
  #   Margen de seguridad:         ~146 MB
  #   -------------------------------------
  #   TOTAL:                       1600 MB
  #
  # REGLA PRACTICA: heap = 65-70 % del limits.memory. El resto NO es
  # desperdicio: es memoria que Node.js necesita fuera del heap.
  - name: NODE_OPTIONS
    value: "--max-old-space-size=1024"

# Uso de memoria frente al limite
container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}
/
on(pod, container) kube_pod_container_resource_limits{resource="memory"}

# OOMKilled recientes: la senal inequivoca
increase(kube_pod_container_status_restarts_total{namespace="rutas-norte-pro"}[1h]) > 0
and on(pod, container)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

Presupuesto: 12 nucleos y 24 GiB para api-reservas.

Opcion A: 30 pods de 400m y 800Mi
Opcion B: 12 pods de 1 nucleo y 2 GiB
Opcion C:  6 pods de 2 nucleos y 4 GiB

Pod de api-reservas con 4 nucleos:
  - El bucle de eventos usa 1 nucleo como maximo.
  - El pool de libuv (4 hilos por defecto) usa algo mas para E/S de ficheros,
    DNS, criptografia y compresion.
  - En la practica, un proceso de Node.js aprovecha ~1,3 nucleos.

Los otros 2,7 nucleos ESTAN DESPERDICIADOS.

# api-reservas: 12 pods de 1 nucleo (opcion B), no 30 de 400m ni 6 de 2 nucleos.
#
# Contra la opcion A (30 pods de 400m):
#   - 30 pools de conexiones contra PostgreSQL (ver apartado 6).
#   - 30 sidecars exportadores: 30 x 6m = 180m solo en observabilidad.
#   - 400m es poco para el ARRANQUE de Node.js, que consume mucha CPU
#     compilando: el arranque pasaria de 9 s a mas de 30 s.
#
# Contra la opcion C (6 pods de 2 nucleos):
#   - Node.js no aprovecha 2 nucleos con un solo proceso.
#   - Perder 1 de 6 replicas es perder el 16,7 % de la capacidad.
#   - Granularidad de escalado demasiado gruesa.
#
# 1 nucleo es el punto dulce: suficiente para el bucle de eventos y el pool
# de libuv, con margen para el arranque, y granularidad fina para el HPA.
resources:
  requests:
    cpu: 412m           # Del VPA (09-02): consumo real en regimen permanente
    memory: 800Mi
  limits:
    memory: 1600Mi      # Sin limits.cpu (apartado 10)

El HPA detecta la sobrecarga y pide replicas nuevas.
Tiempo hasta que una replica nueva atiende trafico:

  Decision del HPA:                       0-15 s (ciclo de 15 s)
  Planificacion:                            1 s
  Descarga de la imagen:                  0-60 s (0 si esta cacheada)
  Arranque del contenedor:               5-30 s
  Sonda de readiness OK:                 3-10 s
  ----------------------------------------------
  TOTAL:                                 9-116 s

# --- Etapa de construccion ---
FROM node:20.15-bookworm AS constructor
WORKDIR /app
COPY package*.json ./
# npm ci con --omit=dev: solo dependencias de produccion
RUN npm ci --omit=dev
COPY . .
RUN npm run build

# --- Etapa final: SOLO lo necesario para ejecutar ---
FROM node:20.15-alpine
WORKDIR /app
# Usuario sin privilegios (08-02)
RUN addgroup -g 10001 rutasnorte && adduser -u 10001 -G rutasnorte -D rutasnorte
COPY --from=constructor --chown=10001:10001 /app/node_modules ./node_modules
COPY --from=constructor --chown=10001:10001 /app/dist ./dist
COPY --from=constructor --chown=10001:10001 /app/package.json ./
USER 10001
EXPOSE 8080
CMD ["node", "dist/servidor.js"]

# k8s/entornos/pro/daemonset-precarga-imagenes.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: precarga-imagenes
  namespace: rutas-norte-pro
  labels:
    app: precarga-imagenes
    app.kubernetes.io/part-of: rutas-norte
spec:
  selector:
    matchLabels:
      app: precarga-imagenes
  template:
    metadata:
      labels:
        app: precarga-imagenes
    spec:
      # Prioridad baja: si hace falta el hueco, que se vaya.
      priorityClassName: relleno-capacidad
      # Los initContainers DESCARGAN las imagenes en el nodo y terminan.
      # A partir de ahi quedan en la cache local de containerd.
      initContainers:
        - name: precargar-api
          image: registry.rutasnorte.example/api-reservas:1.14.2
          command: ["/bin/true"]
        - name: precargar-web
          image: registry.rutasnorte.example/tienda-web:3.2.0
          command: ["/bin/true"]
        - name: precargar-worker
          image: registry.rutasnorte.example/worker-notificaciones:2.3.0
          command: ["/bin/true"]
      containers:
        - name: pausa
          image: registry.k8s.io/pause:3.9
          resources:
            requests: {cpu: 5m, memory: 8Mi}
            limits: {cpu: 10m, memory: 16Mi}

# MAL: el pod tarda 20 s de mas en recibir trafico sin ninguna razon.
readinessProbe:
  httpGet: {path: /preparado, port: 8080}
  initialDelaySeconds: 30       # <- Espera 30 s incluso si esta listo en 5
  periodSeconds: 10             # <- Comprueba cada 10 s: pierde hasta 10 s mas
  failureThreshold: 3

# BIEN: startupProbe para el arranque, readinessProbe agresiva despues.
startupProbe:
  httpGet: {path: /salud, port: 8080}
  # Comprueba cada segundo desde el segundo 0. En cuanto arranque, listo.
  periodSeconds: 1
  # 40 intentos x 1 s = 40 segundos de margen maximo para el arranque.
  # Si tarda mas, algo va mal y queremos saberlo.
  failureThreshold: 40

readinessProbe:
  httpGet: {path: /preparado, port: 8080}
  # SIN initialDelaySeconds: la startupProbe ya cubre el arranque.
  periodSeconds: 2              # Comprobacion frecuente: reacciona rapido
  timeoutSeconds: 1
  failureThreshold: 2
  successThreshold: 1

livenessProbe:
  httpGet: {path: /salud, port: 8080}
  periodSeconds: 10
  timeoutSeconds: 3
  # failureThreshold alto: NO matar el pod por un pico de latencia temporal.
  # Una livenessProbe agresiva bajo carga alta produce reinicios en cascada:
  # el pod va lento -> falla la sonda -> se reinicia -> menos capacidad ->
  # los demas van mas lentos -> se reinician tambien. Espiral de muerte.
  failureThreshold: 6

ANTES:
  Descarga de imagen (1,1 GB, sin cachear):        48 s
  Arranque de Node.js (con limits.cpu: 1):         25 s
  initialDelaySeconds de la readiness:             30 s
  Ciclos de sonda hasta pasar:                     10 s
  ----------------------------------------------------
  TOTAL:                                          113 s

DESPUES:
  Descarga (94 MB, precargada por DaemonSet):       0 s
  Arranque de Node.js (sin limits.cpu):             9 s
  startupProbe (comprueba cada segundo):            1 s
  readinessProbe (periodo de 2 s):                  2 s
  ----------------------------------------------------
  TOTAL:                                           12 s

nameserver 10.96.0.10
search rutas-norte-pro.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

1. api.correos-externos.example.rutas-norte-pro.svc.cluster.local  -> NXDOMAIN
2. api.correos-externos.example.svc.cluster.local                  -> NXDOMAIN
3. api.correos-externos.example.cluster.local                      -> NXDOMAIN
4. api.correos-externos.example                                    -> OK

CUATRO consultas DNS para resolver un nombre.
Y como el resolutor de glibc consulta A y AAAA: OCHO consultas en total.

300 resoluciones/s x 8 consultas = 2.400 consultas DNS/s a CoreDNS.

Si cada resolucion anade 3 ms de latencia (4 idas y vueltas fallidas):
  300 x 3 ms = 900 ms/s de latencia acumulada desperdiciada.

Y CoreDNS con 2.400 consultas/s de las cuales el 75 % son NXDOMAIN inutiles.

// MAL: 4 consultas por el ndots:5
const servidor = 'smtp.correos-externos.example';

// BIEN: el punto final marca el nombre como ABSOLUTO.
// El resolutor NO prueba los sufijos de search. UNA sola consulta.
const servidor = 'smtp.correos-externos.example.';

spec:
  dnsConfig:
    options:
      - name: ndots
        # Con ndots: 2, cualquier nombre con 2 o mas puntos se prueba
        # primero como absoluto. Los nombres internos como
        # "postgres-reservas.rutas-norte-pro" (1 punto) siguen funcionando
        # con los sufijos de search.
        value: "2"
      # Fallar rapido si el DNS no responde.
      - name: timeout
        value: "1"
      - name: attempts
        value: "2"

# ConfigMap de CoreDNS (kube-system/coredns)
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health { lameduck 5s }
        ready

        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }

        prometheus :9153

        forward . /etc/resolv.conf {
            max_concurrent 1000
            # Politica de reparto entre servidores DNS externos.
            policy sequential
        }

        # CACHE: la optimizacion mas importante de CoreDNS.
        #   3600 s (1 h) para respuestas positivas del cluster
        #     30 s para respuestas negativas (NXDOMAIN)
        # El TTL corto para negativas es DELIBERADO: cuando se crea un
        # Service nuevo, no queremos que los pods sigan recibiendo NXDOMAIN
        # durante una hora.
        cache 3600 {
            success 9984 3600
            denial 9984 30
        }

        loop
        reload
        loadbalance
    }

Regla practica: 1 replica de CoreDNS por cada 8-10 nodos, con un minimo de 2.

Cluster de Rutas Norte: 9-12 nodos en el pico.
Replicas: 3 (una por zona, ver 09-05).

Si las metricas muestran latencia de DNS alta:
  histogram_quantile(0.99,
    sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le)
  ) > 0.05

...la solucion suele ser NodeLocal DNSCache, no mas replicas de CoreDNS.

# Activar IPVS en minikube
minikube start -p rutas-norte --extra-config=kube-proxy.mode=ipvs

# Verificar
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i "proxy mode"

I0501 09:14:22.847 server_others.go: Using ipvs Proxier.

Sobrecarga por nodo (kubelet, sistema, DaemonSets): ~0,95 nucleos y 2 GiB.

Nodos de 4 nucleos:  0,95 / 4  = 23,8 % de sobrecarga
Nodos de 8 nucleos:  0,95 / 8  = 11,9 %
Nodos de 16 nucleos: 0,95 / 16 =  5,9 %

Con 12 nucleos utiles necesarios:
  Con nodos de 4:  12 / 3,05 = 3,93 -> 4 nodos = 16 nucleos comprados (33 % de exceso)
  Con nodos de 8:  12 / 7,05 = 1,70 -> 2 nodos = 16 nucleos comprados (33 % de exceso)
  Con nodos de 16: 12 / 15,05 = 0,80 -> 1 nodo = 16 nucleos comprados (33 % de exceso)

Coinciden por casualidad en este caso, pero el nodo de 16 tiene TODO en una
maquina: un fallo se lleva la plataforma entera. Y el CA no puede ajustar
con granularidad menor a 16 nucleos.

StorageClass rutasnorte-rapida: SSD con 3.000 IOPS aprovisionadas.

Una escritura de reserva en PostgreSQL implica:
  - Escritura en el WAL (write-ahead log):      1 IOPS
  - fsync del WAL (obligatorio para durabilidad): 1 IOPS
  - Actualizacion de paginas de datos (diferida): ~0,3 IOPS amortizadas
  - Actualizacion de indices:                    ~0,5 IOPS
  TOTAL: ~2,8 IOPS por reserva

Reservas por segundo maximas por IOPS:
  3.000 / 2,8 = 1.071 reservas/s

Y las lecturas que NO estan en shared_buffers ni en la cache del sistema
tambien consumen IOPS.

-- Tasa de aciertos de la cache de PostgreSQL
SELECT
  datname,
  blks_hit,
  blks_read,
  round(100.0 * blks_hit / GREATEST(blks_hit + blks_read, 1), 2) AS tasa_aciertos
FROM pg_stat_database
WHERE datname = 'reservas';

 datname  | blks_hit  | blks_read | tasa_aciertos
----------+-----------+-----------+---------------
 reservas | 892471203 |  18472941 |         97.97

# IOPS de lectura y escritura del volumen
rate(node_disk_reads_completed_total{device="nvme1n1"}[5m])
+ rate(node_disk_writes_completed_total{device="nvme1n1"}[5m])

# LA METRICA CLAVE: tiempo que el disco esta ocupado.
# Si supera 0,8 (80 %), el disco esta saturado.
rate(node_disk_io_time_seconds_total{device="nvme1n1"}[5m])

# ConfigMap de postgres-reservas
data:
  postgresql.conf: |
    # --- MEMORIA (limits.memory del pod: 8 GiB) ---
    # shared_buffers: el 25 % de la memoria del contenedor. Es la
    # recomendacion clasica y sigue siendo buena.
    shared_buffers = 2GB
    # effective_cache_size: estimacion de la cache TOTAL disponible
    # (shared_buffers + cache de paginas del sistema). NO reserva memoria:
    # solo informa al planificador de consultas para que prefiera indices.
    effective_cache_size = 6GB
    # work_mem por operacion de ordenacion o hash. CUIDADO: se multiplica
    # por el numero de operaciones concurrentes. Con 200 conexiones y
    # 3 operaciones cada una: 200 x 3 x 16MB = 9,6 GB. MAS QUE EL LIMITE.
    # Por eso 16MB y no mas.
    work_mem = 16MB
    maintenance_work_mem = 512MB

    # --- ESCRITURA A DISCO ---
    # Repartir los fsync del checkpoint a lo largo del 90 % del intervalo,
    # en lugar de hacerlos de golpe. Evita picos de latencia periodicos.
    checkpoint_completion_target = 0.9
    # 15 minutos entre checkpoints: menos escrituras, mas tiempo de
    # recuperacion tras una caida. Compromiso razonable.
    checkpoint_timeout = 15min
    max_wal_size = 4GB
    min_wal_size = 1GB

    # --- COSTES DE ACCESO (para el planificador) ---
    # random_page_cost = 1.1 en SSD (por defecto es 4.0, pensado para discos
    # mecanicos). Sin este ajuste, el planificador EVITA los indices creyendo
    # que el acceso aleatorio es caro, y hace escaneos secuenciales inutiles.
    # ES UNO DE LOS AJUSTES MAS RENTABLES EN SSD.
    random_page_cost = 1.1
    effective_io_concurrency = 200

    # --- CONEXIONES ---
    max_connections = 200

    # --- ESTADISTICAS ---
    shared_preload_libraries = 'pg_stat_statements'
    pg_stat_statements.max = 10000
    track_io_timing = on

# api-reservas (tiempo propio, sin dependencias)
histogram_quantile(0.95,
  sum(rate(api_reservas_duracion_propia_segundos_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 35

# postgres-reservas (tiempo de consulta visto desde la API)
histogram_quantile(0.95,
  sum(rate(api_reservas_duracion_consulta_bd_segundos_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 45

# motor-precios (el mayor consumidor: alerta prioritaria)
histogram_quantile(0.95,
  sum(rate(motor_precios_duracion_segundos_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 80

# Y el objetivo global, que es el que le importa al negocio
histogram_quantile(0.95,
  sum(rate(ingress_nginx_request_duration_seconds_bucket{
    ingress="rutas-norte-publico", path="/rutas"
  }[5m])) by (le)
) * 1000 > 300

Suma de los presupuestos de los componentes  <=  75 % del objetivo total.
El 25 % restante es margen.

Sin el ajuste de rendimiento:
  Capacidad por replica: 85 rps.
  Para 2.680 rps: 2.680 / 85 = 32 replicas.
  CPU necesaria: 32 x 412m = 13,2 nucleos.
  Nodos: 5 nodos de 8 nucleos solo para api-reservas.

Con el ajuste:
  Capacidad por replica: 224 rps.
  Para 2.680 rps: 2.680 / 224 = 12 replicas.
  CPU necesaria: 12 x 412m = 4,9 nucleos.
  Nodos: 2 nodos de 8 nucleos.

AHORRO: 3 nodos en el pico. Y, mas importante, el pico CABE en un cluster
que no requiere reconfigurar los grupos de nodos ni renegociar cuotas.

     ✓ busqueda devuelve 200
     ✗ reserva devuelve 201
      ↳  91% — ✓ 6142 / ✗ 607

     checks.........................: 94.21% ✓ 38921  ✗ 2391
     duracion_busqueda_rutas........: avg=142ms  min=18ms  med=94ms   max=8.1s   p(95)=387ms  p(99)=2.4s
     duracion_confirmar_reserva.....: avg=891ms  min=112ms med=612ms  max=14.2s  p(95)=3.1s   p(99)=9.8s
     errores_reserva................: 9.00%  ✓ 607  ✗ 6142
     http_req_duration..............: avg=284ms  min=12ms  med=118ms  max=14.2s  p(95)=982ms  p(99)=4.2s
     http_req_failed................: 3.42%  ✓ 1621  ✗ 45782
     http_reqs......................: 47403  158.0/s
     iterations.....................: 9847   32.8/s
     vus............................: 412    min=50   max=1800

CPU media por replica de api-reservas:     680m de 1000m limit (68 %)
Periodos de CPU estrangulados:             31,2 %
Memoria media:                             620Mi de 1600Mi (39 %)
Conexiones activas a PostgreSQL:           118 de 200
Tasa de aciertos de redis-cache:           22,4 %
Consultas a PostgreSQL por segundo:        3.840
Latencia p95 de las consultas a PostgreSQL: 41 ms
IOPS del disco de postgres:                2.847 de 3.000 aprovisionadas
Tiempo de E/S del disco (io_time):          0,91

http_req_duration p95: 982 ms   (objetivo: 300 ms)   -> 3,3 veces peor
duracion_busqueda_rutas p95: 387 ms                  -> 1,3 veces peor
duracion_confirmar_reserva p95: 3.100 ms             -> 10,3 veces peor

errores_reserva: 9,00 %  ->  9 de cada 100 reservas FALLAN.

IOPS del disco: 2.847 de 3.000 aprovisionadas  ->  94,9 % de la capacidad
Tiempo de E/S del disco (io_time): 0,91        ->  91 % del tiempo ocupado

Espera ≈ TiempoServicio x (0,91 / (1 - 0,91)) = 10,1 x TiempoServicio

Tasa de aciertos de redis-cache: 22,4 %
-> El 77,6 % de las consultas de disponibilidad van a PostgreSQL.

Consultas a PostgreSQL: 3.840/s con 158 peticiones/s
-> 24,3 consultas por peticion HTTP.

1. La cache de Redis no funciona (22,4 % de aciertos).
2. Hay un problema N+1: 24 consultas por peticion.
3. 3.840 consultas/s contra PostgreSQL.
4. La cache de PostgreSQL no da abasto: muchas van a disco.
5. El disco al 91 % de ocupacion: cada operacion espera 10 veces su tiempo.
6. Las consultas se ralentizan (el p95 de 41 ms ya lo refleja).
7. Las conexiones se retienen mas tiempo: 118 de 200 activas.
8. Las escrituras (reservas) sufren mas que las lecturas: 3,1 s de p95.
9. Los timeouts producen el 9 % de errores en las reservas.

CPU: 680m de 1000m (68 %)              -> hay margen
Memoria: 620Mi de 1600Mi (39 %)        -> hay mucho margen
Conexiones: 118 de 200 (59 %)          -> hay margen

"CPU 680m de 1000m (68 %)" es la MEDIA sobre el intervalo de medicion.
"31,2 % de periodos estrangulados" cuenta periodos de 100 ms individuales.

Que ocurre realmente dentro de cada periodo de 100 ms:

  Periodo A (69 % de los casos): el pod usa 40 ms de sus 100 ms de cuota.
                                  No se estrangula.
  Periodo B (31 % de los casos): llega una rafaga. Node.js usa varios hilos
                                  (bucle de eventos + libuv para la
                                  serializacion JSON y la compresion).
                                  4 hilos x 25 ms = 100 ms. CUOTA AGOTADA
                                  en 25 ms de reloj.
                                  El pod esta PARADO 75 ms.

Media ponderada: 0,69 x 40 + 0,31 x 100 = 27,6 + 31 = 58,6...
Ajustando por la distribucion real de rafagas: ~68 %. Coincide.

-- Antes: 1 consulta de rutas + 23 consultas de plazas y precios
-- Despues: 1 consulta con agregacion
SELECT
  r.id, r.origen, r.destino, r.hora_salida, r.precio_base,
  COUNT(p.id) FILTER (WHERE p.estado = 'libre') AS plazas_libres
FROM rutas r
LEFT JOIN plazas p ON p.ruta_id = r.id
WHERE r.origen = $1 AND r.destino = $2 AND r.fecha = $3
GROUP BY r.id, r.origen, r.destino, r.hora_salida, r.precio_base
ORDER BY r.hora_salida;

Consultas: 3.840/s -> 316/s (division por 12)
IOPS del disco: 2.847 -> ~240 (por debajo del 10 % de la capacidad)
io_time: 0,91 -> ~0,12
p95 de las consultas: 41 ms -> ~6 ms

p95 global estimado: 982 ms -> ~250 ms
Errores de reserva: 9,0 % -> < 0,5 %

# Diagnostico primero
kubectl exec -n rutas-norte-pre redis-cache-0 -- redis-cli INFO stats
kubectl exec -n rutas-norte-pre redis-cache-0 -- redis-cli --scan --count 20

// Clave: solo los parametros que determinan el resultado
const clave = `plazas:${rutaId}`;
const ttl = 10;   // 10 segundos: absorbe el 95 % de las lecturas

resources:
  requests:
    cpu: 500m
    memory: 800Mi
  limits:
    # Sin limits.cpu: elimina el 31,2 % de periodos estrangulados
    memory: 1600Mi

Estrangulamiento: 31,2 % -> 0 %
p99: 4,2 s -> ~1,5 s (elimina las esperas de 75 ms)
p95: mejora del 10-15 %

Con 6 replicas: 3.840 consultas/s. Disco al 91 %.
Con 12 replicas: 7.680 consultas/s. Disco al... no puede pasar del 100 %.

Resultado: las consultas se encolan. La latencia SUBE.
Las conexiones se agotan (12 replicas x pool). Mas errores.
Coste: el doble. Rendimiento: peor.

max_connections de postgres-reservas:              200
Reserva para mantenimiento, copias y metricas:      40 (20 %)
Disponible para aplicaciones:                      160
Ya usadas por api-reservas (via PgBouncer):         75
------------------------------------------------------
Disponible para api-empresas:                       85

maxReplicas de api-empresas: 20
Pool maximo por replica: 85 / 20 = 4,25  ->  4 conexiones

Concurrencia = Tasa de llegada x Tiempo de servicio

Cada peticion hace 6 consultas de 14 ms = 84 ms de tiempo de base de datos.

Consultas por segundo que sostiene una replica con 4 conexiones:
  4 conexiones / 0,014 s = 285,7 consultas/s

Peticiones por segundo por replica:
  285,7 / 6 consultas = 47,6 peticiones/s

Con 20 replicas: 20 x 47,6 = 952 peticiones/s

Trafico del pico: 180 peticiones/s
Capacidad con 20 replicas: 952 peticiones/s

952 >> 180.  EL POOL BASTA CON MUCHISIMO MARGEN.

180 peticiones/s / 47,6 por replica = 3,78  ->  4 replicas

20 replicas x 4 conexiones = 80 conexiones.
Disponibles para api-empresas: 85.
80 < 85. CABE, con 5 de margen.

Suma de los componentes (sin margen): 685 ms
685 / 900 = 76,1 %  <=  75 %... justo en el limite.

Aceptable, pero ajustado. Conviene vigilarlo.

MEDIDO en rutas-norte-pre con 4 replicas:
  p95 total:                640 ms
  De los cuales, PostgreSQL: 310 ms
  Resto (aplicacion, red, motor-precios): 330 ms

PRESUPUESTADO:
  PostgreSQL: 300 ms   ->  medido 310 ms. DESVIACION: +10 ms (+3,3 %)
  Resto:      385 ms   ->  medido 330 ms. Por debajo. BIEN.
  Total:      900 ms   ->  medido 640 ms. MARGEN: 260 ms (28,9 %)

310 ms medidos / 6 consultas = 51,7 ms por consulta.
Presupuesto: 50 ms por consulta.

Y el enunciado dice que la duracion media de cada consulta es 14 ms.
310 ms medidos / 6 = 51,7 ms de p95 por consulta, frente a 14 ms de media.

RATIO p95/media = 3,7. Es alto.

SELECT
  substring(query, 1, 60),
  calls,
  round(mean_exec_time::numeric, 2) AS media,
  round(stddev_exec_time::numeric, 2) AS desviacion,
  round(max_exec_time::numeric, 2) AS maximo
FROM pg_stat_statements
WHERE query LIKE '%billetes%'
ORDER BY total_exec_time DESC;

Capacidad medida por replica: 47,6 peticiones/s (limitada por el pool).

Pero hay que verificar cual es el limitante REAL:
  - Por pool: 47,6 rps
  - Por CPU: hay que medirlo con la prueba de estres

Tomamos el mas restrictivo. Supongamos que la prueba de estres da un punto
de inflexion en 42 rps por replica (la CPU limita antes que el pool).

Aplicamos el margen del 30 % para cubrir el tiempo de arranque:
  42 x 0,7 = 29,4  ->  threshold: 29 rps por replica

Verificacion en el pico:
  180 rps / 29 = 6,2  ->  7 replicas.
  7 replicas x 4 conexiones = 28 conexiones a PostgreSQL. Muy holgado.

# k8s/entornos/pro/scaledobject-api-empresas.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-empresas
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: api-empresas

  # 3 replicas de suelo: una por zona (09-05). Es una API B2B con contrato
  # de servicio; no puede tener arranques en frio.
  minReplicaCount: 3

  # 20 replicas de techo.
  # VERIFICACION DE CONEXIONES: 20 x 4 = 80 <= 85 disponibles. Cabe.
  # NO SUBIR sin recalcular el pool (ver ConfigMap).
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    replicas: 7        # La capacidad del pico: numero seguro conocido

  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 0
          policies:
            - type: Pods
              value: 4
              periodSeconds: 30
        scaleDown:
          stabilizationWindowSeconds: 600
          policies:
            - type: Percent
              value: 25
              periodSeconds: 120

  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        metricName: api_empresas_peticiones_por_segundo
        query: |
          sum(rate(api_empresas_peticiones_total{namespace="rutas-norte-pro"}[2m]))
        # 29 peticiones/s por replica.
        #
        # Calculo:
        #   Punto de inflexion medido (prueba de estres): 42 rps por replica.
        #   Margen del 30 % para cubrir el arranque: 42 x 0,7 = 29,4 -> 29.
        #
        # Verificacion del pool (ley de Little):
        #   4 conexiones / 14 ms = 285,7 consultas/s por replica
        #   285,7 / 6 consultas por peticion = 47,6 rps por replica
        #   El POOL soporta 47,6 rps; la CPU limita antes en 42.
        #   El pool NO es el limitante. Correcto.
        threshold: "29"
        activationThreshold: "2"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-empresas-config
  namespace: rutas-norte-pro
data:
  # POOL DE CONEXIONES: 4 por replica.
  #
  # Calculo:
  #   max_connections de postgres-reservas:        200
  #   Reserva para mantenimiento y metricas (20 %): -40
  #   Usadas por api-reservas (via PgBouncer):      -75
  #   Disponibles para api-empresas:                 85
  #   maxReplicas de api-empresas:                   20
  #   Pool = 85 / 20 = 4,25  ->  4
  #
  # NO SUBIR el pool ni el maxReplicas sin rehacer este calculo.
  # Con 20 replicas, cada conexion extra por replica son 20 conexiones mas.
  PG_POOL_MAX: "4"
  PG_POOL_MIN: "1"
  PG_POOL_ACQUIRE_TIMEOUT_MS: "2000"

1. Hay una fuga de memoria en api-reservas. La memoria crece ~40Mi/dia.
   (620Mi -> 1.480Mi en 21 dias = 41Mi/dia)

2. Al llegar a ~1.500Mi de un limite de 1.600Mi, el pod es OOMKilled.

3. CADA REINICIO POR OOMKilled VACIA LA CACHE EN MEMORIA DEL PROCESO.
   Si api-reservas mantiene una cache local (ademas de Redis), se pierde.

4. Y MAS IMPORTANTE: los reinicios rompen el patron de acceso a Redis.
   Un pod recien arrancado hace consultas "frias": pide claves que no
   estan cacheadas porque el trabajo de poblar la cache lo hacia el pod
   anterior con sus datos de sesion.

5. La tasa de aciertos de Redis cae del 94,7 % al 71,2 %.

6. El 28,8 % de fallos (frente al 5,3 % anterior) se traduce en
   5,4 veces mas consultas a PostgreSQL: 340 -> 1.890/s.

7. Mas consultas -> mas latencia por peticion (aunque cada consulta
   individual siga tardando 8 ms, ahora hay muchas mas por peticion).

8. La latencia p95 sube: 94 ms -> 280 ms.

9. KEDA detecta mas latencia o mas peticiones por replica y escala:
   4 -> 9 replicas.

10. MAS REPLICAS EMPEORAN LA CACHE: mas pods, cada uno con menos
    peticiones, patrones de acceso mas dispersos, y mas pods acumulando
    la fuga en paralelo.

    ES UN CICLO QUE SE REALIMENTA.

# 1. Confirmar los OOMKilled y su frecuencia
kubectl get pods -n rutas-norte-pro -l app=api-reservas \
  -o custom-columns='NOMBRE:.metadata.name,REINICIOS:.status.containerStatuses[0].restartCount,ULTIMO:.status.containerStatuses[0].lastState.terminated.reason'

NOMBRE                          REINICIOS   ULTIMO
api-reservas-7c9d4f8b6d-2mkjp   3           OOMKilled
api-reservas-7c9d4f8b6d-4nqzx   2           OOMKilled
api-reservas-7c9d4f8b6d-7wtrv   0           <none>

# 2. Confirmar el crecimiento monotono de la memoria (la prueba definitiva)
# En Prometheus:
#   container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}
# Rango: 30 dias.
#
# Si la linea SUBE Y NUNCA BAJA, ni siquiera en los valles nocturnos,
# es una fuga. Si baja por las noches, es comportamiento normal del GC.

# 3. Comprobar la configuracion del heap de Node.js
kubectl get deployment api-reservas -n rutas-norte-pro \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="NODE_OPTIONS")].value}{"\n"}'

# 4. Ver la composicion de la memoria del proceso
kubectl exec -n rutas-norte-pro api-reservas-7c9d4f8b6d-7wtrv -c api -- \
  node -e "const m = process.memoryUsage();
    console.log('rss:', (m.rss/1048576).toFixed(0), 'MB');
    console.log('heapTotal:', (m.heapTotal/1048576).toFixed(0), 'MB');
    console.log('heapUsed:', (m.heapUsed/1048576).toFixed(0), 'MB');
    console.log('external:', (m.external/1048576).toFixed(0), 'MB');
    console.log('arrayBuffers:', (m.arrayBuffers/1048576).toFixed(0), 'MB');"

rss: 1412 MB
heapTotal: 1180 MB
heapUsed: 1094 MB
external: 89 MB
arrayBuffers: 34 MB

# 5. Investigar Redis: ¿que ha cambiado?
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO stats | grep -E "keyspace|expired|evicted"
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO memory | grep -E "used_memory_human|maxmemory"
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli DBSIZE

# 6. Correlacionar reinicios con caidas de la tasa de aciertos.
# En Grafana, superponer:
#   - kube_pod_container_status_restarts_total{container="api"}
#   - redis_keyspace_hits_total / (hits + misses)
#
# Si cada reinicio coincide con una caida de la tasa de aciertos,
# la cadena causal queda CONFIRMADA.

# 7. Capturar una instantanea del heap para encontrar la fuga
kubectl exec -n rutas-norte-pro api-reservas-7c9d4f8b6d-7wtrv -c api -- \
  kill -USR2 1
# (requiere que la aplicacion tenga el manejador de heapdump)

// EL PATRON SOSPECHOSO
const cacheRutas = new Map();          // <- Sin limite de tamano

app.get('/rutas', async (req, res) => {
  const clave = `${req.query.origen}:${req.query.destino}:${req.query.fecha}`;
  if (cacheRutas.has(clave)) return res.json(cacheRutas.get(clave));
  const rutas = await consultarRutas(req.query);
  cacheRutas.set(clave, rutas);        // <- CRECE PARA SIEMPRE
  res.json(rutas);
});

# 1. Subir el limite de memoria para detener los OOMKilled mientras se
#    investiga. NO es una solucion: es una tirita.
resources:
  requests:
    memory: 800Mi
  limits:
    memory: 2560Mi     # De 1600Mi a 2560Mi
env:
  # Y ajustar el heap coherentemente: 65 % de 2560 = 1664
  - name: NODE_OPTIONS
    value: "--max-old-space-size=1664"

# 2. Reinicio ordenado de todas las replicas para volver al punto de partida
kubectl rollout restart deployment/api-reservas -n rutas-norte-pro

// Sustituir el Map sin limite por una cache LRU acotada
const { LRUCache } = require('lru-cache');

const cacheRutas = new LRUCache({
  // TECHO DURO: 500 entradas. Con ~50 KB por entrada, unos 25 MB maximo.
  max: 500,
  // TTL de 5 minutos: los horarios no cambian, pero acota el crecimiento.
  ttl: 1000 * 60 * 5,
  // Techo por tamano tambien, por si alguna entrada es enorme
  maxSize: 50 * 1024 * 1024,   // 50 MB
  sizeCalculation: (valor) => JSON.stringify(valor).length,
  updateAgeOnGet: false,
});

Cache en memoria del proceso:
  + Mas rapida (0,001 ms frente a 1 ms de Redis)
  - Se duplica en cada replica: 9 replicas = 9 copias de los mismos datos
  - Se pierde en cada reinicio
  - Fragmenta la tasa de aciertos: cada replica cachea lo suyo
  - Es la causa de esta fuga

Cache en Redis:
  + Compartida entre TODAS las replicas: mucha mejor tasa de aciertos
  + Sobrevive a los reinicios
  + Un solo punto donde ajustar TTL y politica de expulsion
  - 1 ms de latencia de red

RECOMENDACION: eliminar la cache en memoria y usar solo Redis.
El milisegundo de diferencia es irrelevante frente al presupuesto de
latencia de 300 ms, y elimina la fuga, la fragmentacion y el problema
de los reinicios de una vez.

# ALERTA 1: crecimiento monotono de memoria (la que habria detectado esto
# en el dia 3, no en el dia 21).
# deriv() calcula la pendiente: si es positiva durante 6 horas seguidas,
# la memoria solo sube.
deriv(
  container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}[6h]
) > 0

# ALERTA 2: cualquier OOMKilled
increase(kube_pod_container_status_restarts_total{namespace="rutas-norte-pro"}[1h]) > 0
and on(pod, container)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

# ALERTA 3: caida de la tasa de aciertos de la cache
(
  rate(redis_keyspace_hits_total[10m])
  /
  (rate(redis_keyspace_hits_total[10m]) + rate(redis_keyspace_misses_total[10m]))
) < 0.85

export const options = {
  scenarios: {
    resistencia: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s',
      duration: '8h',            // OCHO HORAS de carga constante
      preAllocatedVUs: 100,
      maxVUs: 300,
    },
  },
};

# Si la memoria sube y NO baja en 8 horas de carga CONSTANTE, hay fuga.
container_memory_working_set_bytes{namespace="rutas-norte-pre", container="api"}

# Si las conexiones a PostgreSQL crecen sin liberarse, hay fuga de conexiones.
pg_stat_activity_count{datname="reservas"}

# Si la latencia p95 crece un 5 % cada hora, hay degradacion progresiva.
histogram_quantile(0.95, sum(rate(api_reservas_duracion_segundos_bucket[10m])) by (le))