Calculadora de pods por nodo en Kubernetes: capacidad, número de nodos y costo
Calcula cuántos pods caben en un nodo de Kubernetes y cuántos nodos necesitas, con reservas, DaemonSets, margen y costo por réplica.
Cómo funciona
asignable = nodo − reservado para sistema/kubelet · libre = asignable − DaemonSets · pods por nodo = mín(⌊CPU libre ÷ request⌋, ⌊memoria libre ÷ request⌋, max-pods) · nodos = ⌈réplicas ÷ pods por nodo × (1 + margen)⌉ · costo por réplica = nodos × costo del nodo ÷ réplicas
El scheduler de Kubernetes solo coloca un pod donde caben tanto su request de CPU como su request de memoria. Por eso, la capacidad de un nodo para una carga dada es el menor de los dos conteos una vez que el sistema operativo, el kubelet y los agentes de cada nodo tomaron su parte, y el recurso que se acaba primero deja al otro parcialmente ocioso. Esa capacidad varada, la sobrecarga fija por nodo y el margen necesario para aguantar la caída de un nodo o un rolling update explican por qué un clúster calculado sumando requests siempre sale más grande, y por qué ajustar la proporción memoria/CPU del nodo a la de tus pods ahorra dinero de verdad. Los límites no entran en la cuenta: solo deciden qué pasa cuando los pods tienen picos.
Ejemplo resuelto
Carlos tiene nodos de 8 vCPU / 32 GiB que reservan 0.3 vCPU y 2 GiB para el sistema y 0.4 vCPU / 1 GiB para DaemonSets: quedan 7.3 vCPU y 29 GiB. Sus pods piden 0.5 vCPU y 1.5 GiB, así que caben 14 por CPU (7.3 ÷ 0.5) y 19 por memoria (29 ÷ 1.5): 14 pods por nodo, limitados por el CPU. Para 60 réplicas necesita 60 ÷ 14 ≈ 4.29 nodos, es decir 5 justos o 6 con 25% de margen: a $250 por nodo son $1,500 al mes, $25 por réplica. Un nodo optimizado para cómputo, con menos GiB por vCPU, desperdiciaría mucha menos memoria.
Preguntas frecuentes
¿Cuento los límites o los requests?
Los requests: el scheduler solo mira los requests. Los límites controlan el throttling (CPU) y los OOM kills (memoria) en ejecución. Sobreasignar límites de CPU es normal; sobreasignar límites de memoria es buscarse desalojos.
¿Cuánto margen es suficiente?
El necesario para perder un nodo (1/N de la capacidad) más el pico de un rolling update (maxSurge, por defecto 25% de un deployment). En clústeres chicos eso significa 30–50%; en grandes, 15–25%. Un cluster autoscaler reduce la necesidad de comprarlo por adelantado.
¿Cuántos pods caben como máximo en un nodo de Kubernetes?
Por defecto, el kubelet admite 110 pods por nodo, aunque algunos proveedores lo limitan según la red (CNI) o el tipo de instancia. En la práctica, casi siempre te quedas sin CPU o memoria antes de llegar a ese tope.
¿Por qué mi clúster se ve lleno si el uso de CPU es bajo?
Porque el scheduler reparte según los requests, no según el uso real. Si pides 2–3 veces más de lo que consumen tus pods, el clúster se llena de reservas vacías; mide el uso con VPA o con el p95 de tus métricas y ajusta los requests.
Calculadoras relacionadas
Las mecánicas de los juegos, las cifras del hardware y las tarifas de las plataformas cambian con parches, firmware y contratos; los valores aquí reflejan cifras publicadas comúnmente al momento de escribir. Revisa la versión actual del juego, la hoja de datos de tu unidad o el estado de cuenta de tu distribuidor para obtener cifras exactas.