La lección anterior puso cuotas a los tres entornos de Rutas Norte y dejó dos cabos sueltos muy concretos. El primero es práctico y molesta cada día: desde que rutas-norte-dev tiene cuota de cómputo, un simple kubectl run falla con must specify requests.cpu, y cualquier manifiesto de un tercero que no declare recursos es inaplicable. El segundo es más profundo: sabemos que cuando a un nodo le falta memoria alguien tiene que morir, pero no sabemos quién, y esa decisión no es aleatoria en absoluto. Esta lección cierra los dos: el LimitRange inyecta valores por defecto y pone topes por contenedor dentro del namespace, y las clases de calidad de servicio —Guaranteed, Burstable y BestEffort— determinan el orden exacto en que el kubelet desaloja y en que el kernel mata. Al final asignarás una clase razonada a cada componente de Rutas Norte y provocarás un desalojo real en tu minikube para verlo con tus propios ojos.

1. Qué resuelve un LimitRange
2. Los campos: default, defaultRequest, min, max, maxLimitRequestRatio
3. Demostración: un pod sin recursos sale con recursos
4. Los tipos: Container, Pod y PersistentVolumeClaim
5. Interacción exacta entre LimitRange y ResourceQuota
6. Las tres clases de QoS y la regla que las determina
7. Consultar la clase de un pod
8. Consecuencia 1: oom_score_adj y el OOM killer del kernel
9. Consecuencia 2: el orden de desalojo del kubelet
10. La clase de QoS de cada componente de Rutas Norte
11. El LimitRange de los tres entornos
12. Experimento: provocar un desalojo y ver quién cae primero

El LimitRange es un objeto con namespace que hace dos cosas distintas sobre cada contenedor que se cree en él:

1. Inyecta valores por defecto en los contenedores que no declaran requests o limits.
2. Valida topes: rechaza los contenedores que piden menos de un mínimo o más de un máximo.

La diferencia con la ResourceQuota es el ámbito, y conviene tenerla clarísima porque se confunden constantemente:

Una analogía con Rutas Norte: la ResourceQuota es el presupuesto anual del departamento (no se pueden gastar más de X euros entre todos). El LimitRange es la política de gastos por persona (nadie puede pedir un billete de más de Y euros, y si no se especifica clase, se asume turista).

Los tres problemas concretos que resuelve:

Problema 1: la cuota rompe todo lo cómodo. Ya lo vimos:

Problema 2: un solo contenedor puede acaparar la cuota entera. Sin LimitRange, alguien puede desplegar un pod con requests.memory: 4Gi en rutas-norte-dev y agotar de golpe toda la cuota de memoria del entorno, dejando sin sitio a los cinco componentes.

Problema 3: valores absurdos. Un contenedor con requests.memory: 4Mi no arrancará nunca de forma estable, pero nada lo impide.

Campo por campo:

Reglas de resolución que hay que conocer con precisión:

Regla 1: lo declarado siempre gana. El LimitRange nunca sobrescribe un valor que el contenedor declara. Solo rellena huecos.

Regla 2: si declaras limits pero no requests, la request toma el valor del limit, no el de defaultRequest. Este comportamiento pilla a mucha gente:

Con el LimitRange de arriba (defaultRequest.memory: 128Mi) uno esperaría requests: 128Mi. Pero el resultado es:

La regla de Kubernetes de "si solo hay limits, la request iguala al limit" tiene prioridad. Consecuencia práctica: reservas 1 GiB del presupuesto del namespace sin quererlo.

Regla 3: si declaras requests pero no limits, se aplica default. Aquí sí funciona como uno espera... salvo que default sea menor que tu request, en cuyo caso el pod se rechaza por incoherente.

Regla 4: maxLimitRequestRatio limita el sobrecompromiso individual. Con memory: "4", un contenedor con requests.memory: 128Mi no puede tener limits.memory mayor de 512Mi. Es la herramienta para impedir que alguien reserve poco y luego consuma mucho, que es justo el patrón que provoca desalojos.

Tabla de los seis escenarios posibles, con el LimitRange del ejemplo:

Nada convence tanto como verlo. Partimos de rutas-norte-dev con su cuota y aplicamos el LimitRange:

Ahora el mismo kubectl run que antes fallaba:

Funciona. Y lo interesante es ver qué recursos tiene realmente:

El manifiesto que enviamos no tenía resources y el objeto guardado en etcd sí los tiene. El LimitRange los ha inyectado.

¿Quién hace esa inyección? Un controlador de admisión (admission controller) llamado LimitRanger, que forma parte del apiserver. Recuerda el flujo del módulo 1: una petición pasa por autenticación, autorización y admisión antes de escribirse en etcd. La admisión tiene dos fases:

El orden es crucial y explica todo lo del apartado 5: el LimitRange muta primero, la ResourceQuota valida después. Cuando la cuota mira el pod, este ya tiene sus recursos inyectados.

Y una consecuencia que hay que tener presente: el objeto en el clúster ya no es igual al fichero YAML de tu repositorio. Es la primera vez en el curso que esto pasa, y conviene saberlo para no desconcertarse en un kubectl diff. También la deja anotada el propio pod:

Comprobemos también los topes. Un contenedor pidiendo demasiado:

Y uno pidiendo demasiado poco:

Los tres comportamientos verificados: inyecta, pone techo y pone suelo.

Un LimitRange puede tener varias entradas en spec.limits, cada una con su type:

Diferencias entre los tres:

El tipo Pod es útil cuando llegue el módulo 6 con los sidecars e init containers: un pod puede tener tres o cuatro contenedores, cada uno dentro del max de Container, pero sumando entre todos una cantidad desmesurada. El límite de Pod corta eso.

El tipo PersistentVolumeClaim cobrará sentido en el módulo 5. Con max: storage: 200Gi nadie puede pedir un disco de 2 TiB por error de tecleo, algo que en la nube se traduce en una factura desagradable a fin de mes.

Este es el punto donde todo encaja. La secuencia, para un pod que llega sin resources a un namespace con ambos objetos:

Las cuatro consecuencias de este orden:

Consecuencia 1: el LimitRange salva a la ResourceQuota de su propio rigor. Sin LimitRange, la cuota obliga a declarar recursos a mano en todo. Con LimitRange, el valor por defecto se inyecta y la cuota lo contabiliza sin que nadie escriba nada.

Consecuencia 2: los valores inyectados consumen cuota. Esto no es gratis y hay que dimensionarlo. Si defaultRequest.memory es 128Mi y alguien lanza 20 pods de depuración sin recursos, se comen 2,5 GiB del presupuesto del namespace. Por eso los valores por defecto deben ser modestos: son para pods que nadie ha calibrado.

Consecuencia 3: un pod puede pasar el LimitRange y fallar en la cuota. Son validaciones independientes y hay que cumplir las dos:

Ese pod cumplía el max del LimitRange (2Gi), pero no cabía en lo que quedaba de cuota.

Consecuencia 4: cambiar un LimitRange no afecta a los pods existentes. La admisión actúa solo en la creación. Si subes el defaultRequest, los pods que ya corren conservan lo que se les inyectó. Para aplicar los nuevos valores hay que recrearlos:

Y una regla de coherencia entre ambos objetos que evita un problema desagradable: el max del LimitRange nunca debe superar la cuota del namespace. Si max.memory es 8Gi pero la cuota de requests.memory es 4Gi, alguien puede escribir un manifiesto que pase el LimitRange y sea imposible de desplegar. Es mejor que el rechazo llegue con el mensaje claro del LimitRange ("maximum memory usage per Container is 2Gi") que con el de la cuota, más difícil de interpretar.

Cambiamos de tema y llegamos a la parte más interesante. Cuando se crea un pod, Kubernetes le asigna automáticamente una clase de calidad de servicio en status.qosClass. No se declara: se deduce de cómo estén puestos los recursos.

La regla exacta, en orden de evaluación:

En palabras precisas:

Guaranteed — se asigna si y solo si, para todos los contenedores del pod (incluidos los init containers):

• Se declaran limits de CPU y de memoria.
• Se declaran requests de CPU y de memoria (o se omiten, en cuyo caso igualan a los limits).
• requests es exactamente igual a limits en ambos recursos.

BestEffort — se asigna si ningún contenedor del pod declara ninguna request ni ningún limit, de ningún recurso.

Burstable — todo lo demás. Es el cajón por defecto: al menos un contenedor declara algo, pero no se cumple la condición estricta de Guaranteed.

Ejemplos que aclaran los casos frontera:

Tres trampas que conviene memorizar:

Trampa 1: basta un contenedor para arruinar la clase. Si un pod tiene la aplicación con requests == limits y un sidecar de registro sin recursos, el pod entero es Burstable. La clase es del pod, no del contenedor.

Trampa 2: con LimitRange activo, BestEffort es casi imposible. El LimitRanger inyecta valores por defecto, así que ningún pod llega a BestEffort. Es un efecto secundario importante y en general deseable.

Trampa 3: defaultRequest distinto de default impide Guaranteed. Si el LimitRange inyecta requests: 100m y limits: 300m, todos los pods sin recursos serán Burstable. Para que un pod sea Guaranteed hay que declararlo explícitamente.

Para todos los pods del namespace de un vistazo:

Un recuento rápido por clase:

Esos seis BestEffort merecen una mirada: en un clúster de producción son los primeros candidatos a morir, así que conviene saber quiénes son y si eso es intencionado.

describe también la muestra:

Aquí está la primera consecuencia real de la clase, y es de vida o muerte, literalmente.

Cuando el kernel de Linux se queda sin memoria, ejecuta el OOM killer, que elige una víctima. La elección se basa en una puntuación por proceso, oom_score, que combina la memoria que consume con un ajuste manual llamado oom_score_adj, un valor entre -1000 y 1000. Cuanto mayor sea, antes muere.

El kubelet establece ese ajuste según la clase de QoS:

La fórmula para Burstable es la que da todo el matiz:

Léela despacio: cuanto mayor sea tu request de memoria, menor es tu puntuación y más tarde mueres. Un pod Burstable que pide mucha memoria está casi tan protegido como uno Guaranteed; uno que pide muy poca está casi tan expuesto como un BestEffort.

Comprobémoslo en un nodo con 8 GiB asignables. Para api-reservas con requests.memory: 512Mi:

Exactamente lo previsto. Y la conclusión de negocio es directa:

Cuando al nodo le falte memoria, el kernel matará api-reservas mucho antes que postgres-reservas. Y eso es justamente lo que queremos: perder un pod de la API significa perder unas peticiones que el cliente puede reintentar; perder la base de datos significa que toda la plataforma deja de vender billetes y, en el peor caso, que una transacción a medias corrompe datos.

Hay que distinguir dos situaciones distintas que se confunden a menudo:

El segundo caso es el desconcertante: un pod muere y sus métricas muestran que estaba muy por debajo de su límite. La causa está en un vecino que se descontroló, y la clase de QoS es lo que determinó que la víctima fuera él y no otro.

Antes de que el kernel llegue a matar procesos, el kubelet tiene su propio mecanismo, más ordenado: el desalojo por presión de recursos (eviction).

El kubelet vigila los recursos del nodo cada 10 segundos. Cuando cruza un umbral, marca la condición correspondiente (MemoryPressure, DiskPressure, PIDPressure) y empieza a desalojar pods para recuperar recursos.

Los umbrales por defecto:

Y el criterio de selección de las víctimas, en este orden estricto:

1. Primero, si el pod excede sus requests. Los que consumen más de lo que reservaron son candidatos antes que los que se mantienen dentro.
2. Segundo, la clase de QoS: BestEffort primero, luego Burstable, y Guaranteed en último lugar.
3. Tercero, la PriorityClass, si está definida.
4. Cuarto, cuánto excede el uso sobre la request. Entre dos candidatos iguales, cae el que más se ha pasado.

Dicho de forma operativa:

El primer pod en caer es un BestEffort. Si no hay ninguno, cae el Burstable que más se haya pasado de su request. Un pod Guaranteed que se mantiene dentro de sus recursos es prácticamente intocable.

Un pod desalojado se ve así:

Ese mensaje lo dice todo: request is 0 porque era BestEffort, y por tanto cualquier consumo excede su reserva. Fue el candidato perfecto.

Dos apuntes prácticos importantes:

Los pods desalojados no se borran solos. Quedan en Failed ocupando espacio en etcd. Conviene limpiarlos:

Un pod desalojado que pertenece a un Deployment se recrea. El ReplicaSet del módulo 2 ve que falta una réplica y crea otra, posiblemente en otro nodo. Un pod suelto desalojado, en cambio, no vuelve nunca. Otro motivo más para no desplegar pods sueltos.

Ahora la decisión de diseño, que es lo que da sentido a todo lo anterior. La pregunta es, para cada componente: ¿qué pasa si este pod muere de repente?

Los manifiestos concretos. postgres-reservas como Guaranteed:

api-reservas como Burstable:

El análisis puntual como BestEffort:

Ojo: con un LimitRange activo en rutas-norte-dev, ese resources: {} no producirá BestEffort, porque el LimitRanger inyectará los valores por defecto. Para conseguir un pod BestEffort de verdad hay que usar un namespace sin LimitRange, y por eso el experimento del apartado 12 usa uno aparte.

Un caso que merece comentario: redis-cache es Burstable aunque tenga estado. ¿No debería protegerse como postgres-reservas? No, y la diferencia es el valor del dato. redis-cache guarda la disponibilidad de plazas cacheada: si se pierde, se recalcula consultando la base de datos. El impacto es un pico de latencia y de carga sobre postgres-reservas, no una pérdida de información. Lo que determina la clase no es si el componente tiene estado, sino qué se pierde si muere.

Cerramos la parte de configuración con los tres objetos, coherentes con las cuotas de la lección anterior.

Comparativa de las decisiones:

Toca comprobar la teoría. Vamos a crear un namespace sin LimitRange (para poder tener pods BestEffort de verdad), desplegar tres pods de las tres clases, y presionar la memoria del nodo hasta que el kubelet empiece a desalojar.

Aviso: hazlo en tu minikube de prácticas, nunca en un clúster compartido. Vamos a provocar deliberadamente presión de memoria en un nodo.

Paso 1: preparar el terreno.

Unos 7,7 GiB asignables.

Paso 2: los tres pods.

Las tres clases confirmadas. Verifiquemos también sus oom_score_adj:

El 975 de victima-burstable sale de la fórmula del apartado 8: 1000 - (1000 × 200Mi / 7751Mi) = 1000 - 25 = 975. Pide poquísimo, así que está casi tan expuesto como el BestEffort.

Paso 3: apretar hasta provocar la presión.

Paso 4: observar.

El orden es exactamente el previsto: primero el BestEffort, después el Burstable que más se había pasado de su request, y el Guaranteed sigue en pie.

Paso 5: leer los mensajes de desalojo.

Compara las dos últimas frases: el BestEffort excedía una reserva de 0 (todo lo que use excede), y el Burstable excedía su reserva de 200Mi en 505Mi. Ambos eran candidatos; el BestEffort primero por clase.

Paso 6: la condición del nodo y los eventos.

Paso 7: limpiar.

Lo que este experimento demuestra, traducido a Rutas Norte: si un puente de agosto provoca presión de memoria en el nodo donde vive postgres-reservas, la base de datos no será la que caiga. Caerán antes los pods de análisis puntual, después las réplicas de api-reservas que se hayan pasado de su reserva —y el Service seguirá repartiendo entre las que queden—, y la plataforma seguirá vendiendo billetes. Esa cadena de supervivencia no es casualidad: la has diseñado tú al asignar las clases.

Consejos:

1. Cuota y LimitRange van siempre juntos. Trátalos como una sola decisión al crear un namespace.
2. Valores por defecto modestos, max generoso. El valor por defecto es para lo no calibrado; el max es una red de seguridad contra los ceros de más.
3. Guaranteed solo para lo verdaderamente crítico. Cuesta capacidad real: reservas el máximo todo el tiempo. En Rutas Norte, solo postgres-reservas.
4. Vigila los Burstable con relación alta. Un pod con request de 200Mi y limit de 4Gi es un candidato permanente al desalojo. maxLimitRequestRatio lo previene desde el namespace.
5. Añade la clase de QoS a tus revisiones de manifiestos. Es una línea en la revisión de una pull request y evita descubrir en un incidente que la base de datos era Burstable.

Con el LimitRange limites-dev del apartado 11 aplicado en rutas-norte-dev:

1. Crea seis pods, uno por cada fila de la tabla del apartado 2 (sin nada, solo requests de CPU, solo limits de memoria de 1Gi, ambos completos, requests.memory: 16Mi, y requests: 128Mi con limits: 1Gi).
2. Para los que se creen, muestra los resources efectivos y su clase de QoS.
3. Para los que fallen, copia el mensaje de error exacto.
4. Explica en particular por qué el tercero acaba con requests.memory: 1Gi en lugar de 128Mi, y qué consecuencia tiene sobre la cuota del namespace.
5. Calcula cuánta cuota consumirían entre todos si se hubieran creado los seis.

1. Lista todos los pods de los tres namespaces de Rutas Norte con su clase de QoS en una sola tabla.
2. Comprueba si postgres-reservas es Guaranteed en los tres entornos. Si no lo es en alguno, identifica por qué.
3. Modifica el manifiesto de postgres-reservas para que sea Guaranteed en rutas-norte-pro, verifica el cambio y comprueba su oom_score_adj.
4. Calcula a mano el oom_score_adj esperado de api-reservas con requests.memory: 512Mi en un nodo con 7751Mi asignables, y compáralo con el valor real.
5. Añade un sidecar sin recursos a postgres-reservas y observa qué le pasa a la clase del pod. Explica el resultado y revierte el cambio.

1. Reproduce el experimento del apartado 12 en tu minikube.
2. Anota el orden exacto de los desalojos y los mensajes de describe.
3. Modifica victima-burstable para que su requests.memory sea 1Gi (en lugar de 200Mi) manteniendo el mismo consumo, y repite el experimento. ¿Cambia el orden? Explica por qué usando la fórmula del oom_score_adj.
4. Explica qué habría pasado si postgres-reservas de Rutas Norte hubiera estado en ese nodo como Burstable con requests.memory: 256Mi y un consumo real de 1,8 GiB.
5. Propón dos medidas adicionales, más allá de la clase de QoS, para proteger postgres-reservas de este escenario, e indica en qué lección del curso se estudia cada una.

Solución 1

El caso p3 es el interesante: declaramos solo limits.memory: 1Gi y el resultado es requests.memory: 1Gi, no los 128Mi del defaultRequest. La razón es el orden de resolución: Kubernetes aplica primero su regla general de "si hay limit y no hay request, la request iguala al limit", y el defaultRequest del LimitRange solo rellena lo que sigue vacío después de eso.

La consecuencia sobre la cuota es seria: este pod, que probablemente consuma 4 MiB de memoria real, ha comprometido 1 GiB del presupuesto de 4 GiB del namespace. Con cuatro pods así, rutas-norte-dev se queda sin cuota de memoria sin que nadie esté usando nada. Es un error muy caro y muy invisible.

Consumo total si se hubieran creado los seis (solo cuentan los cuatro válidos):

p3 solo es el 25 % de los pods y consume el 67 % de la memoria comprometida.

Solución 2

postgres-reservas no es Guaranteed en ningún entorno. Motivo:

La memoria coincide pero la CPU no (500m frente a 2). Basta un recurso desigual para perder Guaranteed. Es un error clásico: se iguala la memoria pensando en el OOM y se olvida la CPU.

El cálculo de api-reservas:

Coincide. La diferencia de 1931 puntos con postgres-reservas es enorme: en la práctica, el kernel sacrificará todas las réplicas de la API antes de tocar la base de datos.

El sidecar:

El pod ha perdido Guaranteed por culpa de un sidecar sin recursos. En rutas-norte-pro el LimitRange le inyecta requests: 200m/256Mi y limits: 500m/512Mi, que son distintos entre sí, y eso basta. La corrección es dar al sidecar requests == limits también:

Con eso el pod recupera Guaranteed. Lección: en un pod que debe ser Guaranteed, todos sus contenedores deben serlo, incluidos los sidecars y los init containers.

Solución 3

El orden observado es BestEffort → Burstable → el Guaranteed sobrevive, con los mensajes del apartado 12.

Con requests.memory: 1Gi en victima-burstable y el mismo consumo de 700Mi:

El Burstable ya no cae. Dos motivos que actúan a la vez:

1. Su oom_score_adj bajó de 975 a 868, así que el kernel lo prioriza menos como víctima.
2. Y sobre todo, ya no excede su request: consume 700Mi y reservó 1Gi. El primer criterio de selección del kubelet (apartado 9) es precisamente "pods que exceden sus requests", y este ya no está en ese grupo.

La moraleja operativa es contundente: declarar una request de memoria realista es la protección más barata que existe contra el desalojo. No cambia lo que consumes; cambia si eres candidato o no.

4. Si postgres-reservas hubiera sido Burstable con requests.memory: 256Mi y un consumo real de 1,8 GiB:

Un 967, casi tan expuesto como un BestEffort, y excediendo su request en más de 1,5 GiB, lo que lo pone en el primer grupo de candidatos. Habría sido de los primeros en caer. Para Rutas Norte eso significa: la base de datos se cae en el pico de venta de un puente, api-reservas empieza a devolver errores de conexión, tienda-web muestra errores a los clientes, y en el peor caso una transacción de reserva a medias deja plazas bloqueadas sin billete emitido. Un Recreate de PostgreSQL además implica recuperación del WAL al arrancar, con minutos de indisponibilidad.

Todo eso lo evita una línea: requests == limits.

5. Dos medidas adicionales:

Y una tercera, la más importante a medio plazo: convertir postgres-reservas en un StatefulSet con volumen persistente y copias de seguridad verificadas, de modo que la supervivencia del dato no dependa de la supervivencia del pod. Es el trabajo de los módulos 5 y 6.

Has cerrado los dos cabos sueltos que dejó la lección anterior. El LimitRange convierte una cuota estricta en algo llevable: inyecta default y defaultRequest en los contenedores que no declaran nada, pone suelo y techo con min y max, y limita el sobrecompromiso individual con maxLimitRequestRatio. Sabes que actúa como controlador de admisión mutante antes de que la ResourceQuota valide, que por tanto los valores inyectados consumen cuota, que no es retroactivo, y que los tres tipos —Container, Pod y PersistentVolumeClaim— cubren desde el contenedor suelto hasta el coste de un disco. Y conoces la regla que más dinero cuesta cuando se ignora: si declaras solo limits, la request copia el limit, no el defaultRequest, y con ello reservas mucho más de lo que crees.

Dominas también las clases de calidad de servicio y la regla exacta que las determina: Guaranteed exige requests == limits de CPU y memoria en todos los contenedores del pod, BestEffort exige que ninguno declare nada, y Burstable es todo lo demás. Sabes consultarla con -o jsonpath='{.status.qosClass}' y, sobre todo, sabes qué consecuencias tiene: el oom_score_adj que el kubelet escribe en cada proceso (-997 para Guaranteed, hasta 1000 para BestEffort, y una fórmula proporcional a la request de memoria para Burstable) y el orden de desalojo del kubelet, que mira primero quién excede sus requests y después la clase. Has distinguido el OOM del cgroup —mueres por tu propio límite, sin importar la clase— del OOM del nodo, donde la clase lo decide todo.

Rutas Norte tiene ahora un diseño razonado: postgres-reservas es Guaranteed porque guarda las reservas y los datos personales de los clientes y su muerte para la venta; api-reservas, tienda-web, redis-cache y worker-notificaciones son Burstable porque tienen réplicas, son recuperables y necesitan ráfaga en los puentes; y el análisis exploratorio es BestEffort porque debe ser lo primero en caer. Los tres entornos tienen su LimitRange coherente con su cuota. Y lo has comprobado provocando un desalojo real en el minikube, viendo caer el BestEffort primero, el Burstable que se había pasado de su reserva después, y sobrevivir al Guaranteed; y descubriendo de paso que subir una request a un valor realista es la protección más barata que existe contra el desalojo.

Queda una última pieza del módulo, y es de otra naturaleza. Hemos dado a nuestros componentes su configuración, sus credenciales y sus recursos, pero no les hemos dado identidad. Todos los pods de Rutas Norte están usando ahora mismo la ServiceAccount default de su namespace, con un token montado que ninguno de ellos necesita, y ninguno tiene forma de decirle a la API de Kubernetes quién es. La lección siguiente, ServiceAccounts y Acceso a la API desde los Pods, lo resuelve: verás la diferencia entre usuarios y ServiceAccounts, por qué usar la default es mala idea, cómo han cambiado los tokens (de secretos eternos a tokens proyectados de vida limitada que el kubelet rota), qué hay exactamente en /var/run/secrets/kubernetes.io/serviceaccount/, por qué automountServiceAccountToken: false debe ser tu opción por defecto, y hablarás con la API desde dentro de un pod con curl para ver tanto una respuesta autorizada como un 403 Forbidden bien merecido.