¿Cómo diseñarías las solicitudes de recursos a nivel de Pod en Kubernetes?

Problema y contexto

Los recursos a nivel de Pod en Kubernetes permiten que un Pod declare solicitudes (requests) y límites (limits) de CPU, memoria o hugepages además de los valores a nivel de contenedor. Los valores a nivel de Pod tienen precedencia cuando ambos están presentes e influyen en la programación (scheduling), la QoS y la puntuación de OOM. El feature gate PodLevelResources y la versión del clúster deben verificarse antes del despliegue.

Supongamos que el proxy y los workers comparten una carga de trabajo con ráfagas (bursty), pero el proxy tiene un SLO de latencia y los workers pueden utilizar la capacidad sobrante. El objetivo es expresar esa relación sin hacer que el scheduler o kubelet apliquen un presupuesto que el equipo no tenía previsto.

Qué evalúan los entrevistadores

Los entrevistadores buscan un modelo claro de propiedad de recursos, reglas de precedencia correctas y conciencia de que las solicitudes a nivel de Pod modifican la programación y la QoS. Las respuestas sólidas analizan garantías agregadas versus por contenedor, límites, escalado automático, observabilidad y pruebas de migración.

Una respuesta común copia la suma de las solicitudes de los contenedores en spec.resources. Una respuesta sólida explica si el presupuesto del Pod es un pool compartido, qué contenedor necesita un piso mínimo (floor) y cómo evitar que un worker consuma el margen de latencia del proxy.

Preguntas para aclarar primero

• ¿Es la solicitud a nivel de Pod un presupuesto compartido o un mínimo estricto para cada contenedor?
• ¿Qué versiones de Kubernetes, feature gates, administradores de recursos y sistemas operativos están dentro del alcance?
• ¿Necesita el proxy un piso mínimo garantizado de CPU o un límite de memoria independiente de los workers?
• ¿Cómo observan el nuevo alcance HPA, VPA y las políticas de desalojo (eviction)?
• ¿Qué sucede cuando se especifican solicitudes tanto a nivel de Pod como a nivel de contenedor durante la migración?

Si los contenedores tienen dominios de falla o escalado independientes, usar Pods separados puede ser más seguro. Si realmente comparten un ciclo de vida y un presupuesto de ráfagas, los recursos a nivel de Pod pueden expresar esa relación de forma más directa.

Una respuesta de 30 segundos

“Primero verificaría el soporte de versiones y feature gates, luego modelaría el Pod como un presupuesto compartido con un piso explícito para el proxy. Las solicitudes a nivel de Pod tienen precedencia, por lo que evitaría configuraciones mixtas accidentales, probaría el comportamiento de QoS y OOM, y verificaría las entradas del escalador automático. Haría un canary del manifiesto, compararía latencia, throttling, desalojo y costos con la política anterior, y mantendría un rollback a solicitudes a nivel de contenedor”.

Diseño paso a paso

1. Mapear los roles de recursos. Medir la sensibilidad a la latencia del proxy, la variabilidad de ráfagas de los workers, el uso en estado estacionario y el crecimiento de la memoria. Decidir si los contenedores comparten un presupuesto o necesitan garantías aisladas.
2. Verificar la compatibilidad. Confirmar la versión del servidor de Kubernetes, el gate PodLevelResources en el plano de control y los nodos, los tipos de recursos soportados y las limitaciones exclusivas de Linux donde corresponda.
3. Establecer el presupuesto del Pod. Elegir solicitudes para la programación y límites para el techo agregado. Asegurarse de que el presupuesto deje espacio para el piso de latencia del proxy y las ráfagas de los workers.
4. Evitar precedencias ambiguas. Durante la migración, documentar que los valores a nivel de Pod anulan los valores a nivel de contenedor. Eliminar valores obsoletos de contenedores o mantenerlos solo cuando la política requiera intencionalmente ambos alcances.
5. Verificar QoS y desalojo. Recalcular la clase de QoS y el comportamiento de OOM, luego probar la presión de los nodos, el throttling y la contención de los workers. Un agregado saludable aún puede ocultar la inanición (starvation) del proxy.
6. Desplegar y observar. Hacer un canary de una carga de trabajo y rastrear la latencia p95, el throttling de CPU, la presión de memoria, los OOM kills, los desalojos, los reinicios y el costo. Expandir solo cuando las salvaguardas se mantengan.

Las alternativas incluyen Deployments separados, solicitudes exclusivas para cada contenedor o un sidecar con límites explícitos. Los recursos a nivel de Pod son más útiles cuando el ciclo de vida y la capacidad de ráfaga se comparten intencionalmente.

Ejemplo de respuesta

“El proxy necesita un piso de latencia, mientras que los workers pueden tomar prestada CPU sobrante. Establecería una solicitud a nivel de Pod que refleje el agregado normal y un límite para el techo de ráfagas, validando luego que el proxy no sufra inanición bajo la carga de los workers. Durante la migración eliminaría las solicitudes de contenedores conflictivas o documentaría su propósito porque los valores a nivel de Pod prevalecen. Haría un canary en dos nodos, monitorearía la latencia p95, el throttling, OOM, el desalojo y el comportamiento del escalador automático, y revertiría a la política de contenedores anterior si el SLO del proxy se degrada”.

Errores comunes

• Error: Asumir que las solicitudes del Pod son automáticamente garantías por contenedor → Por qué falla: el presupuesto puede ser compartido → Solución: definir pisos y aislamiento explícitamente.
• Error: Dejar valores de contenedor conflictivos sin documentar → Por qué falla: la precedencia a nivel de Pod sorprende a los operadores → Solución: documentar y probar los recursos efectivos.
• Error: Verificar solo la utilización de CPU → Por qué falla: la presión de memoria y el comportamiento de OOM pueden cambiar → Solución: observar CPU, memoria, QoS, desalojo y latencia en conjunto.
• Error: Habilitar la característica solo en un componente del plano de control → Por qué falla: todos los nodos y componentes requeridos deben soportarla → Solución: verificar la capacidad en todo el clúster antes del despliegue.

Preguntas de seguimiento y respuestas

¿Qué pasa si el proxy sufre inanición aunque el Pod esté por debajo de su límite?

Trátalo como una falla por contención. Añade un piso para el proxy, separa las cargas de trabajo o utiliza aislamiento a nivel de contenedor; el margen agregado por sí solo no garantiza la latencia.

¿Cómo afectan las solicitudes a nivel de Pod a la QoS?

Tienen precedencia cuando ambos alcances están presentes e influyen en los cálculos de QoS y OOM del Pod. Recalcula la clase durante la migración y prueba la presión sobre los nodos.

¿Pueden los Pods de Windows usar recursos a nivel de Pod?

Verifica las limitaciones específicas de la versión. El comportamiento documentado de Kubernetes 1.35 no soporta recursos a nivel de Pod para Pods de Windows, por lo que se debe mantener una política a nivel de contenedor allí.

¿Cuándo dividirías el Pod en su lugar?

Divídelo cuando los contenedores escalen, fallen o tengan SLOs de forma independiente. Mantén un solo Pod cuando el ciclo de vida compartido y el presupuesto de ráfaga sean intencionales y observables.