toolbox
Inicio / Startups y negocios digitales / Estimador de capacidad necesaria para un clúster Kubernetes

Estimador de capacidad necesaria para un clúster Kubernetes

Estima cuántas réplicas de una aplicación y cuántos nodos podrían ser necesarios para atender un pico de solicitudes en Kubernetes. El modelo parte de la capacidad sostenible de cada pod, aplica un objetivo de utilización para evitar operar al límite y añade un margen adicional de seguridad.

El resultado sirve como referencia inicial para dimensionar un deployment, revisar parámetros de autoscaling o planificar capacidad de nodos. La capacidad real depende de CPU, memoria, límites, afinidad, daemonsets y comportamiento de la aplicación, por lo que debe validarse con métricas y pruebas de carga.

Demanda y capacidad del clúster

req/s
req/s
%
%
Resultado
—
Réplicas de aplicación recomendadas
Nodos estimados—
Capacidad efectiva por pod—
Réplicas sin margen adicional—

1. Introduce el pico de solicitudes
Usa la demanda máxima que el servicio debe poder atender en solicitudes por segundo.

2. Define la capacidad sostenible de un pod
Introduce el throughput observado en pruebas o producción para una réplica con la configuración de recursos prevista.

3. Fija utilización y margen
La utilización objetivo reserva holgura dentro de cada pod; el margen adicional protege frente a crecimiento o ráfagas sobre el pico estimado.

4. Indica cuántos pods caben por nodo
Usa una estimación realista después de reservar recursos para sistema, daemonsets y otras cargas.

5. Revisa réplicas y nodos
El resultado redondea hacia arriba tanto las réplicas como los nodos necesarios para no quedarse por debajo de la capacidad calculada.

Capacidad efectiva por pod = Capacidad máxima por pod × Utilización objetivo / 100

Réplicas base = redondeo hacia arriba(Pico de solicitudes ÷ Capacidad efectiva por pod)

Réplicas recomendadas = redondeo hacia arriba(Réplicas base × (1 + Margen / 100))

Nodos estimados = redondeo hacia arriba(Réplicas recomendadas ÷ Pods por nodo)

Qué significa el resultado

El resultado indica un número orientativo de réplicas de la aplicación y nodos para el pico definido, dadas la capacidad por pod y las reservas de utilización y margen.

No sustituye al scheduler ni a un cálculo de recursos por CPU y memoria. Restricciones de afinidad, zonas, PDB, requests/limits y otros pods pueden elevar el número real de nodos.

Given:
Pico = 5.000 req/s; capacidad por pod = 220 req/s; utilización objetivo = 70 %; margen = 20 %; 18 pods por nodo.

Calculation:
Capacidad efectiva = 220 × 0,70 = 154 req/s.
Réplicas base = ceil(5.000 ÷ 154) = 33.
Réplicas con margen = ceil(33 × 1,20) = 40.
Nodos = ceil(40 ÷ 18) = 3.

Result:
40 réplicas y aproximadamente 3 nodos para alojarlas.

Interpretation:
La estimación conserva capacidad dentro de cada pod y añade una reserva adicional frente al pico de 5.000 req/s.

¿Cómo obtengo la capacidad por pod?

Lo ideal es medirla con pruebas de carga o métricas de producción usando los mismos requests/limits y una versión representativa de la aplicación.

¿Por qué hay un objetivo de utilización y además un margen?

La utilización objetivo evita exigir a cada pod su capacidad máxima sostenida; el margen adicional protege el conjunto frente a incertidumbre o crecimiento sobre el pico estimado.

¿Los nodos estimados incluyen pods del sistema?

Solo de forma indirecta si el valor de pods de aplicación por nodo ya descuenta espacio para kube-system, daemonsets y otras cargas. Ajusta ese campo a tu densidad útil real.

¿Puedo usar esta cifra para configurar HPA?

Puede orientar mínimos y máximos, pero HPA depende de métricas y políticas de escalado concretas. Valida la configuración con comportamiento real y tiempos de arranque.

¿Qué diferencia hay con un cálculo basado en CPU y memoria?

Este modelo parte del throughput por pod. Un dimensionamiento por recursos calcula cuántos pods caben según requests de CPU/memoria; ambos enfoques deberían contrastarse para detectar el cuello de botella dominante.