Kubernetes: Recursos de Pod, resources.requests y resources.limits, cgroups de Linux

En este artículo explicamos en lenguaje claro y en profundidad cómo funcionan resources.requests y resources.limits en manifiestos de Kubernetes y cómo interactúan con los cgroups de Linux para asignar y limitar CPU y memoria a los contenedores.

resources.requests vs resources.limits: resources.requests indica al planificador de Kubernetes cuanta CPU y memoria debe reservar para el Pod y afecta a la selección del Worker Node y a la prioridad relativa de CPU entre grupos. resources.limits fija el consumo máximo que un contenedor puede usar: para memoria esto determina memory.max en el cgroup y si se supera puede activarse el OOM Killer; para CPU esto fija cpu.max o cpu.cfs_quota y provoca throttling si el grupo consume su cuota en un periodo.

Cgroups y como Linux controla recursos: Linux usa control groups para agrupar procesos y aplicar límites y prioridades. En cgroups v1 los parámetros eran cpu.cfs_quota_us y cpu.cfs_period_us para cuota de CPU y cpu.shares para prioridad relativa. En cgroups v2 se usan cpu.max con formato cuota periodo y cpu.weight para prioridad relativa. memory.max y memory.current controlan el uso de memoria y su umbral para OOM.

CPU throttling y cpu.max: cpu.max define cuantos microsegundos de CPU puede usar un cgroup en cada ventana de periodo (por ejemplo periodo 100000 microsegundos = 100 ms). Si un cgroup tiene quota inferior al periodo y agota su cuota, sus procesos son suspendidos hasta el siguiente periodo aunque el resto del sistema tenga CPU libre, de ahi que imponer limits de CPU pueda causar throttling inesperado.

cpu.weight y cpu.shares: cuando no hay límites estrictos el planificador CFS reparte CPU entre cgroups usando cpu.weight (cgroups v2) o cpu.shares (v1). Kubernetes convierte resources.requests.cpu en CPU shares siguiendo la convención 1 CPU Kubernetes = 1024 CPU shares. En sistemas con cgroups v2 esa cantidad se transforma internamente en cpu.weight para mantener la proporción entre grupos.

Qué hace el kubelet y el runtime: cuando un Pod se crea el kubelet toma spec.containers.resources y lo pasa al runtime (containerd o CRI-O) mediante CRI. El runtime genera la especificación del contenedor que crea los archivos o entradas de cgroup correspondientes: cpu.max y memory.max según limits, y cpu.shares / cpu.weight según requests.

Impacto en Scheduler y QoS: resources.requests.memory se usa para filtrar nodos con suficiente memoria disponible. La relación entre requests y limits determina la clase QoS del Pod: Guaranteed cuando requests == limits, Burstable cuando requests existen y limits pueden ser mayores, BestEffort cuando no hay requests ni limits. Estas clases influyen en decisiones de eviction y en el agrupamiento de cgroups dentro de /sys/fs/cgroup/kubepods.slice.

Buenas prácticas: definir requests razonables para CPU y memoria para que el Scheduler distribuya la carga correctamente; evitar imponer limits de CPU salvo cuando se persigue evitar que pods monopolizen CPU, porque el throttling puede degradar el rendimiento aun con CPU libre; siempre definir limits de memoria para evitar fugas que terminen con OOM en todo el nodo.

Comandos y archivos del sistema: en hosts Linux puedes inspeccionar cgroups en /sys/fs/cgroup. archivos clave en cgroups v2: cpu.max para cuota y periodo, cpu.weight para prioridad relativa, memory.max para límite de memoria y memory.current para consumo actual. En entornos con containerd puedes usar ctr -n k8s.io containers info para ver los campos linux.resources que incluyen shares, quota y period que luego se reflejan en el cgroup del contenedor.

Resumen técnico breve: limits configuran cpu.max y memory.max en el cgroup y definen el techo de consumo; requests influyen en cpu.weight (o cpu.shares) y en la selección del nodo por el Scheduler; cpu.max provoca throttling si se agota la cuota en la ventana de periodo; memory.max protege contra uso excesivo pero puede provocar OOM Killer si no hay memoria disponible en el nodo.

Servicios y experiencia de Q2BSTUDIO: en Q2BSTUDIO somos expertos en desarrollo de software a medida y aplicaciones a medida, arquitectura cloud y soluciones con inteligencia artificial para empresas. Podemos ayudarte a diseñar deployments de Kubernetes optimizados que integren buenas prácticas de requests y limits, monitorizacion y políticas de cgroups para maximizar rendimiento y estabilidad. Con nuestros servicios de software a medida y aplicaciones a medida desarrollamos pipelines de despliegue, contenedorizacion y automatizacion adecuados a tus necesidades.

Además ofrecemos consultoria en inteligencia artificial y agentes IA para resolver casos de uso con modelos y automatizacion, integrando herramientas de IA para empresas y soluciones de inteligencia de negocio con Power BI. Si buscas modernizar tu plataforma con capacidades de IA y analytics, consulta nuestros servicios de inteligencia artificial.

Complementariamente damos soporte en ciberseguridad, pentesting y seguridad en la nube, y desplegamos infraestructuras seguras en servicios cloud aws y azure aplicando políticas que protegen la integridad de contenedores y datos. Entre nuestras ofertas están auditorias de seguridad, configuracion de RBAC, hardening de nodos y pipelines seguros para CI CD.

Palabras clave integradas para mejorar posicionamiento: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.

Si quieres una auditoria de tu cluster Kubernetes, optimizacion de recursos, o desarrollar una plataforma a medida que combine IA y seguridad, contacta con Q2BSTUDIO para evaluar tu caso y ofrecer una solucion profesional y escalable.