Planteamiento y contexto
Un equipo de plataforma descubre que el contenedor por lotes de un tenant puede asfixiar a los servicios en línea durante un pico de carga. El nodo utiliza cgroup v2, pero el equipo configuró un solo límite de memoria y no puede distinguir entre liberación (reclaim), limitación gradual (throttling) y terminación. Diseña una política de memoria en capas con límites de protección, monitoreo de eventos y reversión.
Qué evalúa el entrevistador
- Si separas la protección de memory.min/low frente a la liberación/limitación de memory.high y la aplicación estricta de memory.max.
- Si comprendes el archivo jerárquico memory.events y el local memory.events.local.
- Si manejas la terminación por OOM grupal (OOM group killing), los cgroups secundarios (hijos), los picos repentinos (bursts) y la sobreasignación (overcommit).
- Si puedes conectar los archivos del kernel con la orquestación, las alertas y los simulacros.
Preguntas de aclaración para hacer primero
- ¿Se están protegiendo cargas de trabajo críticas, limitando a un tenant o protegiendo todo el nodo?
- ¿La carga de trabajo es sensible a la latencia, orientada a lotes o es seguro que libere memoria y reintente?
- ¿Cuál es la jerarquía de cgroups y los grupos principales (padres) contienen sidecars?
- ¿Kubernetes gestiona la carga de trabajo y cómo se asignan los requests y limits a cgroup v2?
- ¿El OOM debería matar un solo proceso, todo el cgroup o hacer que el controlador reconstruya el contenedor?
Estructura para responder en 30 segundos
Utiliza memory.min y memory.low para los niveles de protección, memory.high como un límite temprano de liberación y limitación gradual, y memory.max como el límite estricto final. memory.oom.group determina si la gestión de OOM afecta a todo el grupo. Asigna presupuestos desde el nodo hacia el tenant y la carga de trabajo, monitorea memory.current, memory.events y PSI, y valida mediante canaries, pruebas de estrés y reversión. En Kubernetes, lee los archivos reales de cgroup después del renderizado en lugar de confiar únicamente en el YAML.
Respuesta detallada paso a paso
Paso 1: Construir el modelo semántico
memory.min es un límite de protección estricto cuyo uso se libera únicamente bajo una fuerte presión; memory.low es una protección de mejor esfuerzo que puede liberarse bajo una presión severa. memory.high activa la liberación y la limitación gradual, pero no invoca directamente al OOM killer. memory.max es un límite infranqueable que puede entrar en OOM de cgroup cuando la liberación de memoria no logra satisfacerlo.
Paso 2: Asignar presupuestos principales y secundarios
Reserva capacidad del nodo para el sistema y los servicios críticos, asigna un tope a cada padre de tenant y luego establece grupos secundarios para cargas de trabajo en línea, por lotes y sidecars. La protección secundaria no puede exceder incondicionalmente el presupuesto disponible del padre. Registra el uso actual, los eventos y la versión de la política en cada nivel. Deja margen por debajo de high para picos repentinos, de modo que un pico breve no se convierta de inmediato en un OOM por max.
Paso 3: Elegir la relación entre high y max
memory.high permite que el kernel aplique primero la liberación y la limitación gradual; la aplicación puede ralentizarse tras observar la latencia, el rendimiento y los eventos. memory.max es la válvula de seguridad final y debe reflejar la capacidad de recuperación. Un high demasiado bajo causa una limitación crónica, mientras que un max demasiado alto exporta la presión hacia el padre o el nodo. Calibra ambos mediante pruebas de carga.
Paso 4: Decidir la política de OOM grupal
Para procesos estrechamente acoplados, memory.oom.group=1 hace que la gestión de OOM sea para todo el grupo, de modo que no quede un proceso auxiliar huérfano tras matar únicamente el proceso principal. Los trabajos por lotes independientes pueden preferir que termine un solo proceso y que una cola lo reintente. Para cualquiera de las dos opciones, registra la causa de salida, los reinicios y el trabajo inconcluso; un OOM no es un reintento invisible.
Paso 5: Monitorear memory.events
memory.events es jerárquico, por lo que los eventos secundarios pueden aparecer en un padre; memory.events.local solo reporta eventos locales. Monitorea los incrementos (deltas) de high, max, oom y oom_kill, correlacionados con memory.current, el working set, PSI, la latencia y la antigüedad de la cola. Analiza las claves en lugar de depender del orden del archivo, ya que pueden aparecer nuevas claves.
Paso 6: Asignar la política a la orquestación
En Kubernetes, inspecciona en conjunto los requests, limits, QoS y el modo de cgroup del nodo. Tras el renderizado, ingresa al contenedor y lee /sys/fs/cgroup para verificar los valores reales y asegurarse de que el runtime no los haya sobrescrito. Revisa la contabilidad de sidecars, init containers y emptyDir compartidos; un secundario puede parecer saludable mientras su padre alcanza high o max.
Paso 7: Realizar simulacros, despliegues y reversiones
En un canary de un solo nodo, reduce high gradualmente y observa la liberación y la limitación gradual; luego prueba max y la terminación por oom.group. Configura alertas por separado para un high sostenido, el primer max y un oom_kill real. Publica políticas versionadas que incluyan la versión anterior y una captura instantánea de eventos. Revierte primero el presupuesto y luego reconcilia los trabajos terminados y los reintentos en cola para no dejar presión residual en el nodo.
Ejemplo de respuesta de alta calidad
Usa min y low para protección, high para liberación y limitación observables, y max como el límite estricto final. Asigna presupuestos para nodo, tenant y carga de trabajo a través de la jerarquía padre-hijo, y luego elige oom.group según la capacidad de recuperación. Monitorea memory.events jerárquico frente a local junto con PSI, latencia, antigüedad de la cola y reinicios. En Kubernetes, verifica los archivos cgroup renderizados. Realiza despliegues con canary y simulacros de presión, y mantén una política de reversión versionada.
Errores comunes
- Tratar memory.high como un límite inmediato de OOM.
- Tratar memory.low como una garantía inquebrantable.
- Confiar en el YAML del contenedor sin leer los archivos cgroup en tiempo de ejecución.
- Mezclar eventos jerárquicos del padre con eventos locales.
- Reiniciar tras un OOM sin verificar la idempotencia, el trabajo parcial y las tormentas de reintentos.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué sucede después de superar memory.high?
El kernel aplica presión de liberación y limitación gradual. Los procesos pueden continuar, pero la latencia puede aumentar. No es un activador del OOM killer; correlaciona el contador high con PSI y la latencia del servicio.
Pregunta de seguimiento 2: ¿Por qué mantener memory.max si ya existe high?
High permite que una carga de trabajo ceda recursos bajo presión, mientras que max delimita el crecimiento que no se puede liberar y protege al padre o al nodo. Max debe diseñarse considerando la capacidad de recuperación y la política de reinicios.
Pregunta de seguimiento 3: ¿Por qué memory.events puede parecer que cuenta un evento dos veces?
El archivo memory.events del padre incluye por defecto los eventos del subárbol, mientras que memory.events.local es local a ese cgroup. Elige un solo nivel para cada alerta y deduplica según la jerarquía.
Pregunta de seguimiento 4: ¿Cuándo se debe habilitar memory.oom.group?
Habilítalo cuando los procesos dentro de un mismo cgroup deban vivir y reiniciarse juntos. Las tareas independientes pueden terminar individualmente. Ambas opciones requieren pruebas de limpieza, reintentos y observabilidad.
Pregunta de seguimiento 5: ¿Cómo se demuestra que la asignación en Kubernetes es correcta?
En el nodo de destino, lee memory.min, memory.low, memory.high, memory.max y los eventos para el cgroup del contenedor. Compáralos con los requests, limits, QoS y configuraciones del runtime renderizados, y luego ejecuta un simulacro de presión.