Requests y limits de recursos en Kubernetes: planificación, throttling y OOM kills

Qué es

Cada contenedor de un Pod puede declarar resources.requests y resources.limits para CPU y memoria. La documentación de Kubernetes (citada) distingue los dos papeles: el scheduler usa los requests para elegir un nodo con capacidad sin reservar suficiente, y el kubelet reserva para el contenedor al menos la cantidad solicitada; los limits los aplican el kubelet y el runtime de contenedores y, en última instancia, el kernel a través de cgroups. La forma de aplicarlos depende del recurso: los límites de CPU se aplican mediante throttling (limitación), de modo que un contenedor nunca obtiene más CPU que su límite; los límites de memoria se aplican de forma reactiva mediante terminaciones por falta de memoria (OOM kills), que según la documentación solo ocurren cuando el kernel detecta presión de memoria, por lo que un contenedor puede usar durante un tiempo más memoria que su límite y ser terminado después. Si se define un limit sin request, Kubernetes copia el limit en el request.

La página sobre QoS (citada) deriva una clase a partir de estos campos: Guaranteed cuando todos los contenedores tienen requests y limits iguales tanto en CPU como en memoria, Burstable cuando al menos un contenedor tiene un request o un limit pero no se cumplen los criterios de Guaranteed, y BestEffort cuando no se define nada. Bajo presión en el nodo, los Pods BestEffort son los primeros en ser desalojados, luego los Burstable y por último los Guaranteed, y solo los Pods que superan sus requests son candidatos al desalojo.

Por qué importa

Los requests determinan el empaquetado (bin-packing) y, por tanto, el coste; los limits determinan el modo de fallo. Un límite de CPU cercano al uso típico convierte los picos de latencia en throttling que no se ve en los logs de la aplicación; un límite de memoria por debajo del working set real convierte una fuga lenta en reinicios periódicos con código de salida 137. Los Pods sin requests se colocan donde haya espacio y son los primeros en ser desalojados.

Cómo aplicarlo

• Define siempre requests y limits de memoria; para los servicios cuyo desalojo sería un incidente, hazlos iguales, lo que da la clase Guaranteed.
• Fija los requests de CPU a partir del uso observado; decide con criterio los límites de CPU, porque el coste de superarlos es el throttling y no el desalojo.
• Vigila el contador de reinicios del contenedor y el último motivo de terminación (OOMKilled), además de las métricas de throttling de CPU del runtime, y no solo la latencia de la aplicación.
• Aplica valores por defecto por namespace con LimitRange para que los campos olvidados no generen Pods BestEffort sin que nadie lo note, y limita los totales con ResourceQuota.
• Dimensiona los requests para el proceso real de JVM, Node.js o Python, incluida la configuración de heap de su runtime, y no para el contenedor en reposo.

Trampas

Un límite de memoria no es una reserva de memoria en el nodo: la suma de los limits de todos los Pods puede superar la capacidad del nodo. Cambiar requests o limits ha implicado históricamente recrear el Pod; la página citada describe el redimensionamiento in situ, cuya disponibilidad depende de la versión del clúster.

Límites de CPU: normalmente conviene omitirlos

Un request de CPU se traduce en el peso de CPU del cgroup, que ya garantiza al contenedor su parte cuando el nodo está saturado; un límite de CPU solo añade throttling. La cuota de CFS se concede por periodo de 100 ms, así que un contenedor limitado a una CPU cuyos cuatro hilos se activan a la vez consume la cuota del periodo en 25 ms y espera los 75 ms restantes, en cada periodo, lo que se manifiesta como latencia mientras las gráficas de CPU parecen tranquilas. Compara container_cpu_cfs_throttled_periods_total con container_cpu_cfs_periods_total antes de culpar al código. Mantén los límites de CPU donde hagan falta: con la política estática del CPU manager (QoS Guaranteed con CPUs enteras), en un clúster multi-tenant donde la capacidad ociosa no deba poder consumirse, o en un Pod que necesita la clase QoS Guaranteed, que exige límites de CPU iguales a los requests. Define siempre límites de memoria.