Entrevista general: ¿Cómo gobernaría el redimensionamiento a nivel de Pod en Kubernetes?

Consigna y contexto

El equipo de plataforma está habilitando el redimensionamiento de CPU y memoria a nivel de Pod en Kubernetes. Los equipos de producto desean un ajuste automático, finanzas se preocupa por el costo y SRE teme que los cambios de memoria puedan reiniciar contenedores. Cree una política interfuncional de admisión, auditoría, respuesta a incidentes y reversión.

Qué evalúa el entrevistador

• Si la capacidad técnica se traduce en límites claros de propiedad, permisos y presupuesto.
• Si los niveles de riesgo determinan qué cargas de trabajo pueden redimensionarse automáticamente.
• Si las condiciones de estado, la política de reinicio y los SLO se convierten en evidencia para la aprobación.
• Si las auditorías y los simulacros demuestran que la política funciona durante un incidente.

Preguntas para clarificar

1. ¿Qué namespaces, entornos y cargas de trabajo pueden redimensionarse?
2. ¿Quién aprueba los límites, es dueño del costo y puede congelar cambios de forma urgente?
3. ¿Cómo detecta resizePolicy de contenedores, conexiones con estado y el riesgo de reinicio por memoria?
4. ¿La organización ya cuenta con cuotas, ventanas de cambio, auditoría y comando de incidentes?

Respuesta de 30 segundos

Clasificaría por entorno, criticidad de negocio y riesgo de reinicio: desarrollo puede ajustarse automáticamente, mientras que los servicios críticos de producción requieren aprobación. La política fija límites de CPU y memoria, incremento gradual (step), tiempo de enfriamiento (cooldown), cuota de namespace y salvaguardas de SLO, además de requerir el subrecurso /resize con propietario, motivo y observedGeneration. La admisión rechaza solicitudes no explicadas o fuera de los límites; los eventos distinguen entre Pending, InProgress, Infeasible y Deferred. Las auditorías conectan el costo con los reinicios, y los simulacros periódicos ejercitan el congelamiento, la reversión y el traspaso de propiedad.

Análisis detallado paso a paso

Definir niveles de riesgo

Clasifique por entorno, SLO, estado de los datos, capacidad de interrupción de conexiones y resizePolicy del contenedor. Las cargas de trabajo críticas con estado, de pagos y del plano de control tienen de forma predeterminada cambios de memoria aprobados; las cargas de trabajo sin estado de bajo riesgo pueden ajustarse dentro de los límites.

Establecer reglas de admisión

Exija listas de permitidos por namespace, límites de recursos, step, cooldown, capacidad de nodos, cuotas, ventanas de cambio y etiquetas. Cada solicitud especifica la fuente de métricas, el destino y el costo previsto.

Vincular la política al estado de Kubernetes

Exija que el controlador lea los recursos deseados/reales, observedGeneration y las condiciones de redimensionamiento. Solo un InProgress completado con valores reales coincidentes se considera un éxito; Pending, Infeasible y Deferred permanecen visibles con sus motivos.

Manejar reinicios y reversiones

Los cambios de memoria pueden reiniciar contenedores, por lo que los servicios declaran drenado de conexiones, recuperación de estado y cantidad máxima de reinicios. Superar un límite congela la automatización y restaura el último presupuesto estable; la fase Running del Pod no es prueba de continuidad del negocio.

Hacer que el costo y la auditoría sean de primer nivel

Registre la CPU y memoria antes y después, la duración, la estimación de costos, el propietario, el aprobador y el resultado. Finanzas visualiza la variación presupuestaria por namespace, equipo y carga de trabajo; SRE correlaciona eventos de SLO, OOM y reinicios.

Realizar simulacros de incidentes y evolucionar la gobernanza

Practique la escasez de capacidad de nodos, caídas del controlador, presupuestos erróneos y reversiones amplias. Actualice la política, los runbooks y los contactos posteriormente; cada excepción tiene una fecha de vencimiento para que una lista de permitidos temporal no se vuelva permanente.

Respuesta modelo

Trataría el redimensionamiento de Pods como un cambio gobernado, no como un interruptor abierto. Clasificaría por entorno, SLO, estado y resizePolicy; los servicios críticos con estado requieren aprobación. La admisión fija namespace, límites, step, cooldown, cuota, capacidad y ventanas de cambio, y exige /resize con propietario, motivo y observedGeneration. El controlador informa Pending, Infeasible y Deferred y confirma el éxito únicamente a partir del estado real. Las compuertas de reinicio por memoria exigen drenado y recuperación; los incumplimientos congelan y revierten. Las auditorías conectan costo, SLO, OOM y restartCount, y los simulacros ensayan congelamiento, reversión y traspaso de propiedad.

Errores comunes

• Establecer límites de recursos sin un aprobador, autoridad de congelamiento o propietario.
• Permitir el redimensionamiento automático de memoria en todos los namespaces de producción.
• Ignorar las condiciones de /resize y la política de reinicio de contenedores.
• Considerar la fase Running de un Pod como prueba de un servicio de negocio ininterrumpido.
• Omitir auditorías de costos, vencimiento de excepciones y simulacros de reversión.
• Buscar propietarios y runbooks solo después de que comienza un incidente.

Preguntas de seguimiento

¿Qué servicios deberían tener configurado de forma predeterminada ningún redimensionamiento automático de memoria?

Los servicios críticos que no pueden drenarse rápidamente, tienen una recuperación de estado costosa o arriesgan la consistencia al reiniciarse deberían requerir aprobación y un simulacro completado.

¿Cómo evita que los equipos eludan la política editando Pods?

Use admisión, RBAC, administración de campos y auditoría para rechazar escrituras no autorizadas; los permisos de emergencia son por tiempo limitado, rastreables y vencen automáticamente.

¿Quién decide cuándo el costo entra en conflicto con el SLO?

La política establece la prioridad y los umbrales de presupuesto por adelantado; un responsable designado de producto y SRE deciden por encima del umbral en lugar de dejar que el controlador elija silenciosamente.

¿Cómo sabe si la política funciona?

Compare las solicitudes fuera de límites rechazadas, las regresiones de SLO, OOM, reinicios, la variación del presupuesto, el tiempo de reversión y la finalización de simulacros, y luego revise con cada equipo.