Milicores
- Entrada
- 500m
- Resultado
- 0,5 núcleos
1000m es un núcleo. Un request de 100m significa que el planificador reserva una décima parte de un núcleo.
Calculadora de recursos de Kubernetes
Convierte milicores y sufijos de memoria, multiplícalos por las réplicas y comprueba la clase QoS que asignará el kubelet. La tabla de sufijos hace tangible la diferencia entre Mi y M, de donde salen el gasto silencioso y los OOMKill inesperados.
Cargas de ejemplo
Clase QoS: BurstableEl limit de CPU es 5.0× el requestEl limit de memoria es 2.0× el request
| Por pod | × 3 réplicas | |
|---|---|---|
| CPU request | 0.1 | 0.3 |
| CPU limit | 0.5 | 1.5 |
| Memoria request | 128Mi | 384Mi |
| Memoria limit | 256Mi | 768Mi |
Fragmento de manifiesto
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
# 3 replicas require
# cpu 0.3 cores requested, 1.5 at the limit
# memory 384Mi requested, 768Mi at the limitMi no es M
Kubernetes acepta sufijos binarios y decimales, y no miden lo mismo.
| Sufijo | Bytes | Sufijo | Bytes | Diferencia |
|---|---|---|---|---|
| 1Ki | 1,024 | 1k | 1,000 | +2.4% |
| 1Mi | 1,048,576 | 1M | 1,000,000 | +4.9% |
| 1Gi | 1,073,741,824 | 1G | 1,000,000,000 | +7.4% |
Así, 1G son 1G mientras que 1Gi son 1Gi: alrededor de un 7% más.
Todo ocurre en tu navegador. Esta página es un archivo estático. Lo que escribes se queda en la pestaña, nunca se envía a un servidor y desaparece al cerrarla, así que puedes pegar un token o una configuración real sin riesgo.
Cuándo la necesitas
- Al dimensionar un Deployment y necesitar saber cuánta capacidad del clúster reclamará el número de réplicas.
- Al averiguar por qué un pod es Burstable cuando lo querías Guaranteed.
- Al traducir un límite de memoria de docker-compose a las unidades que espera un manifiesto.
Ejemplos resueltos
El sufijo que cuesta dinero
- Entrada
- 1000M frente a 1Gi
- Resultado
- 1.000.000.000 frente a 1.073.741.824 bytes
Escribir M donde querías Mi da al contenedor alrededor de un 7% menos de memoria de la prevista.
QoS Guaranteed
- Entrada
- requests == limits
- Resultado
- Guaranteed
Solo cuando los requests de CPU y memoria igualan exactamente sus limits. Cualquier otra cosa es Burstable y se desaloja antes bajo presión.
Dónde suele fallar la gente
Escribir M cuando quieres decir Mi
512M son 512.000.000 bytes; 512Mi son 536.870.912. El manifiesto es válido en ambos casos, así que nada te avisa: el pod simplemente recibe menos memoria de la que sugiere el número.
Poner un limit de CPU muy por encima del request
Un limit varias veces mayor que el request deja al pod dispararse y luego lo estrangula en cuanto el nodo se llena. Muchos picos de latencia que parecen fallos de la aplicación son en realidad throttling del CFS.
Omitir los requests por completo
Un pod sin requests es BestEffort y es lo primero que se desaloja cuando un nodo se queda corto. Además no da nada al planificador con lo que trabajar, así que los nodos se llenan de forma desigual.
Preguntas frecuentes
¿Qué diferencia hay entre un request y un limit?
El request es lo que el planificador reserva al colocar el pod; el limit es el techo que el kernel impone en ejecución. Los requests deciden dónde aterriza un pod, los limits cuándo se le estrangula o se le mata por memoria.
¿Cómo se decide la clase QoS?
Guaranteed significa que cada contenedor tiene requests de CPU y memoria iguales a sus limits. BestEffort significa que no hay ni requests ni limits. Todo lo intermedio es Burstable, y eso importa porque el desalojo sigue ese orden.
¿Debería poner un limit de CPU?
Muchos equipos fijan limits de memoria pero dejan la CPU libre, porque superar un limit de memoria mata el contenedor mientras que superar el de CPU solo lo estrangula, a menudo con peor coste en latencia que dejar al pod usar capacidad ociosa.