Planteamiento y contexto
Eres responsable de un servicio con estado de cinco réplicas que debe mantener el quórum durante el mantenimiento de nodos y la reducción de escala (scale-down) del clúster. Diseña un PDB, elige entre minAvailable y maxUnavailable, y explica por qué aún pueden ocurrir interrupciones después de configurarlo. Asume un StatefulSet y una herramienta de mantenimiento que utiliza la Eviction API.
Qué evalúa el entrevistador
- Si defines la restricción de disponibilidad y quórum antes de escribir YAML.
- Si distingues la interrupción voluntaria de fallas de nodos, presión de recursos y otras interrupciones involuntarias.
- Si comprendes que un PDB limita los desalojos, no el número absoluto de Pods en buen estado (healthy) en todo momento.
- Si detectas excepciones de actualizaciones progresivas (rolling updates), selectores, redondeo de porcentajes y bloqueos de drenado (drain) relacionados con la capacidad.
Preguntas para aclarar antes de responder
- ¿Cuál es el quórum? Un servicio de consenso de cinco réplicas puede requerir tres réplicas saludables; un servicio sin estado (stateless) puede tener como objetivo un porcentaje de capacidad.
- ¿Quién realiza el desalojo? Los PDB son respetados por la Eviction API; la eliminación directa de un Deployment o Pod puede omitirlos.
- ¿El mantenimiento incluye un despliegue de la aplicación? Los PDB no limitan las actualizaciones progresivas de un Deployment o StatefulSet; la estrategia de la carga de trabajo es la que lo hace.
- ¿Hay capacidad para Pods de reemplazo? Un desalojo permitido no significa que un reemplazo pueda programarse (schedule) de inmediato; la escasez de capacidad puede bloquear el drenado.
Estructura de respuesta de 30 segundos
«Primero confirmo el requisito de réplicas saludables y la ruta de desalojo. Para cinco réplicas y un quórum de tres, usaría minAvailable: 3, o un maxUnavailable: 2 equivalente cuando cambia la escala de réplicas, con un selector que coincida con el StatefulSet. Un PDB limita el desalojo voluntario; no puede evitar la falla de un nodo ni reemplazar una estrategia de despliegue. Antes del despliegue ejecutaría un kubectl drain controlado, inspeccionaría disruptionsAllowed y verificaría que los Pods de reemplazo tengan capacidad programable».
Respuesta detallada paso a paso
1. Traduce la disponibilidad en un presupuesto
Un presupuesto de PDB es el número de réplicas que una interrupción voluntaria puede eliminar a la vez. Si cinco réplicas deben conservar tres Pods saludables, el presupuesto es como máximo dos. minAvailable: 3 establece la cantidad restante saludable; maxUnavailable: 2 establece la cantidad no disponible permitida. Los campos son mutuamente excluyentes.
2. Elige la expresión que coincida con el escalado
minAvailable es directo para un quórum fijo. Si las réplicas se autoescalan, la documentación de Kubernetes recomienda considerar maxUnavailable, que se evalúa frente a las réplicas deseadas. Los porcentajes se redondean hacia arriba: con siete réplicas deseadas y maxUnavailable: 30%, tres Pods pueden no estar disponibles, no dos. La planificación de capacidad debe incluir ese redondeo.
3. Vincula la carga de trabajo correcta
El selector de etiquetas del PDB debe coincidir con el selector del StatefulSet. De lo contrario, puede que no proteja a ningún Pod objetivo o combine accidentalmente múltiples aplicaciones. Mantén las etiquetas estables; no las cambies durante una versión para evadir el presupuesto.
4. Establece el límite del PDB
Un PDB limita las interrupciones voluntarias como kubectl drain y el mantenimiento automatizado. La falla de hardware, la pérdida de nodos y el desalojo por presión de recursos son involuntarios; el PDB no puede evitarlos y aun así se contabilizan contra el presupuesto. La eliminación directa de un Pod o Deployment también puede omitirlo.
5. Explica un drenado estancado
Cuando el presupuesto se agota, la Eviction API rechaza nuevos desalojos y el drenado reintenta. Incluso un desalojo permitido puede dejar su reemplazo en estado Pending cuando ningún nodo tiene capacidad, por lo que el drenado permanece bloqueado. Incluye los requests de los Pods, la dispersión por zonas (zone spreading), el tiempo de inicio y el margen de maniobra (headroom) del nodo; un PDB no es un sistema de capacidad.
6. Separa los despliegues de la política de salud
Un PDB no limita la actualización progresiva de un Deployment o StatefulSet; los campos de estrategia de actualización como maxUnavailable, maxSurge y readiness controlan el reemplazo durante un lanzamiento. Kubernetes también proporciona una política de desalojo de Pods no saludables, que debe elegirse según si los Pods con fallas deben limpiarse primero. Prueba el despliegue, el mantenimiento y la recuperación ante incidentes por separado.
Ejemplo de respuesta de alta calidad
Confirmaría que el servicio de cinco réplicas necesita tres réplicas saludables para el quórum y que la herramienta de mantenimiento llama a la Eviction API. El PDB básico es minAvailable: 3 con el selector exacto del StatefulSet. Si las réplicas se autoescalan, evaluaría maxUnavailable: 2 o un porcentaje con su comportamiento de redondeo. El PDB limita únicamente el desalojo voluntario; no evita fallas de nodos, presión de recursos, eliminación directa o una política de actualización progresiva.
Durante el despliegue inspeccionaría disruptionsAllowed, ejecutaría un drenado controlado y observaría el tiempo de terminación, la programación de reemplazos y el estado del quórum. Un drenado en pausa cuando el presupuesto se agota es algo esperado. Si los reemplazos están en Pending, añadiría capacidad o ajustaría los requests en lugar de ampliar el presupuesto. Finalmente probaría las rutas de actualización, pérdida de nodos y reversión (rollback) de mantenimiento por separado.
Errores comunes
- Error → Asumir que un PDB previene cualquier interrupción. Por qué falla: las interrupciones involuntarias están fuera de su control. Corrección: declara el límite para fallas de nodos, presión y desalojo por mantenimiento.
- Error → Escribir únicamente
maxUnavailable: 50%. Por qué falla: el comportamiento de redondeo hacia arriba puede permitir una pérdida de réplicas mayor de lo que sugiere la intuición. Corrección: calcúlalo a partir de las réplicas deseadas. - Error → Tratar un PDB como una política de despliegue. Por qué falla: las actualizaciones de Deployment y StatefulSet no están limitadas por el PDB. Corrección: configura la estrategia de actualización de la carga de trabajo por separado.
- Error → Culpar al PDB por un drenado atascado. Por qué falla: un presupuesto agotado y la falta de capacidad en los nodos tienen causas diferentes. Corrección: inspecciona
disruptionsAllowed, los Pods en Pending, los requests y la capacidad en conjunto.
Preguntas de seguimiento y respuestas
Solo tres de cinco réplicas están saludables. ¿Se puede desalojar otro Pod?
Con minAvailable: 3, la Eviction API debería rechazar el desalojo voluntario. Restaura una réplica saludable o acepta una pausa en el mantenimiento; eliminar el PDB para que el drenado finalice quitaría la protección del quórum.
El Cluster Autoscaler está atascado. ¿Deberías flexibilizar el PDB?
Primero verifica que la reducción de escala sea voluntaria, que el presupuesto esté agotado y que los Pods de reemplazo puedan programarse. Flexibilizar el presupuesto de un servicio con quórum puede romper la consistencia. Añade capacidad, cambia el lote de drenado o utiliza un porcentaje de capacidad para una carga de trabajo sin estado en lugar de debilitar el presupuesto de todas las aplicaciones.
¿Por qué la eliminación directa de Pods puede omitir el PDB?
El PDB rige las solicitudes de desalojo voluntario a través de la Eviction API, no cada operación de eliminación. Restringe los permisos de eliminación directa y haz que la automatización del mantenimiento utilice la API, manteniendo al mismo tiempo un mecanismo explícito de omisión para administradores en caso de emergencias.
¿Cuál es el riesgo de maxUnavailable: 0?
Requiere cero Pods no disponibles voluntariamente, por lo que el drenado de un nodo nunca podrá completarse mientras la carga de trabajo seleccionada permanezca allí. Utilízalo solo cuando el negocio no pueda tolerar interrupciones voluntarias y exista un procedimiento de mantenimiento coordinado.