Entrevista de Backend: ¿qué puede proteger un PodDisruptionBudget y qué no puede proteger?

Planteamiento y contexto

Administras un servicio gestionado por un Deployment con un recuento deseado de cinco réplicas. Durante una actualización del clúster, se debe drenar un nodo y el equipo teme perder varias réplicas al mismo tiempo. El entrevistador te pide diseñar o revisar un PodDisruptionBudget y explicar sus efectos en rolling releases, fallos de nodos y la eliminación directa de Pods.

Esto evalúa los límites de disponibilidad en Kubernetes y el razonamiento operativo. Un PDB limita cuántas réplicas seleccionadas pueden no estar disponibles simultáneamente debido a disrupciones voluntarias. No es un controlador de réplicas ni una garantía contra cualquier fallo. Una buena respuesta conecta las réplicas deseadas, los selectores, el punto de entrada de la expulsión (eviction) y la capacidad restante.

Lo que evalúa el entrevistador

• Si distingues entre disrupciones voluntarias e involuntarias.
• Si explicas la semántica mutuamente excluyente de minAvailable y maxUnavailable.
• Si sabes que un PDB depende del recuento de réplicas deseadas del controlador y de un selector de Pods preciso.
• Si puedes explicar los reintentos de drain, las rutas de eliminación no cubiertas y los límites de los rolling updates.
• Si incorporas réplicas, topología, probes y capacidad al plan de disponibilidad.

Preguntas para aclarar primero

• ¿El servicio está gestionado por un Deployment, StatefulSet u otro controlador compatible?
• ¿El selector coincide únicamente con esta carga de trabajo? Un selector amplio puede mezclar Pods no relacionados en un solo presupuesto.
• ¿Se están protegiendo contra drains de nodos y reducciones de escala (scale-down), o contra una pérdida de energía? Un PDB no puede prevenir esto último.
• ¿Las réplicas están distribuidas entre zonas con suficiente capacidad y readiness correcta? Un PDB limita la expulsión; no crea capacidad.
• ¿Cuánto tiempo puede esperar el mantenimiento? Un presupuesto demasiado estricto puede prolongar la ventana, mientras que uno demasiado flexible reduce la capacidad.

Estructura para una respuesta de 30 segundos

“Un PDB restringe las solicitudes de disrupción voluntaria realizadas a través de la Eviction API. Con cinco réplicas, minAvailable: 4 o maxUnavailable: 1 pueden expresar que como máximo se debe perder una a la vez, pero los campos son mutuamente excluyentes. El presupuesto depende de las réplicas deseadas de la carga de trabajo y de un selector exacto; los fallos de nodo, la eliminación directa del Deployment y los rolling updates de la aplicación no son detenidos por completo por él. Si se rechaza el drain, inspeccionaría el presupuesto, las réplicas saludables, la capacidad y la ruta de expulsión, mientras utilizo réplicas, topología y probes para el resto del diseño de disponibilidad.”

Respuesta detallada

Clasificar la disrupción

El node drain, el mantenimiento de nodos y ciertas acciones de reducción de escala del clúster suelen solicitar el movimiento de Pods a través de la Eviction API. Son disrupciones voluntarias, por lo que el PDB puede rechazar temporalmente una expulsión. La pérdida de energía, los fallos del kernel o el aislamiento de red son disrupciones involuntarias; un PDB no puede prevenirlas, y los Pods no disponibles resultantes aún afectan el estado del presupuesto.

Explicar los campos mutuamente excluyentes

minAvailable indica cuántos Pods coincidentes deben permanecer disponibles después de la expulsión. maxUnavailable indica cuántos Pods coincidentes pueden no estar disponibles después de la expulsión. No se pueden configurar ambos. Para cinco réplicas deseadas, minAvailable: 4 y maxUnavailable: 1 expresan una intención similar a ese tamaño, pero los porcentajes cambian con la escala y el redondeo, así que indica el recuento deseado y la semántica de la versión.

Mostrar la dependencia de las réplicas deseadas y el selector

El plano de control encuentra la carga de trabajo que administra los Pods mediante sus owner references y deriva el recuento previsto a partir de .spec.replicas. El selector debe coincidir con las etiquetas del Deployment o StatefulSet y mantenerse específico. Un selector que coincida con múltiples aplicaciones crea un presupuesto compartido; sin un recurso propietario compatible, Kubernetes no puede derivar el total de forma confiable.

Usar una configuración para mostrar el límite

Este ejemplo permite que como máximo un Pod seleccionado no esté disponible por expulsión voluntaria cuando la carga de trabajo pretende tener cinco réplicas:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-api
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: checkout-api

No garantiza cuatro Pods saludables en todo momento. Una réplica ya podría no estar saludable, o un nodo podría fallar repentinamente. Antes del despliegue, verifica el selector, readiness, las réplicas deseadas y la capacidad multizona.

Explicar el rechazo y reintento de drain

Cuando actualmente no se permite ninguna expulsión, las réplicas saludables ya están por debajo de minAvailable, o el controlador de presupuesto no puede calcular el estado, la Eviction API puede rechazar la solicitud. kubectl drain reintenta periódicamente las solicitudes fallidas hasta que los Pods terminen o se alcance un tiempo de espera (timeout). La solución de problemas comienza con el estado del PDB, los Pods seleccionados, el recuento de Pods saludables, los fallos de readiness y la confirmación de que la acción de mantenimiento realmente use la Eviction API.

Separar los rolling updates de la eliminación directa

Las actualizaciones progresivas (rolling updates) de Deployment y StatefulSet se rigen por su propia estrategia de actualización; un PDB no es un sustituto completo para esas reglas. Un PDB tampoco puede restringir cada eliminación directa de un Pod o Deployment. Los sistemas de release deben combinar maxUnavailable, maxSurge, readiness y comportamiento de rollback en lugar de delegar toda la seguridad del release al PDB.

Añadir fiabilidad fuera del PDB

Un PDB cubre una clase de disrupción. Resistir el fallo de un nodo o zona también requiere suficientes réplicas, distribución topológica (topology spread), margen de capacidad (headroom), readiness y liveness correctos, terminación elegante (graceful termination) y drenado de conexiones. Para servicios con estado basados en quórum, deriva el presupuesto de las necesidades de quórum; para servicios sin estado, valida la disponibilidad con tráfico real, tiempo de recuperación y pruebas de capacidad.

Respuesta modelo de alta calidad

“El Deployment requiere cinco réplicas, por lo que primero verificaría que el selector del PDB coincida únicamente con checkout-api y que readiness y la capacidad entre zonas sean sólidas. Si la expulsión voluntaria debe dejar cuatro réplicas disponibles, puedo usar minAvailable: 4 o maxUnavailable: 1; son mutuamente excluyentes, y elegiría un valor absoluto o un porcentaje según el comportamiento de escalado.

El PDB protege los node drains, el mantenimiento y ciertas acciones de reducción de escala que usan la Eviction API. No puede detener la pérdida de energía, fallos del kernel o la eliminación directa de Pods, y los rolling updates son controlados principalmente por la estrategia del Deployment. Si se rechaza el drain, inspeccionaría las réplicas saludables, el estado del presupuesto, el selector, los fallos de readiness, la capacidad y la ruta de expulsión; kubectl drain puede reintentar hasta el timeout.

Validaría el PDB junto con réplicas, distribución topológica, readiness, graceful termination y rollback de releases. Un presupuesto demasiado estricto puede bloquear el mantenimiento, mientras que uno demasiado permisivo puede violar la capacidad mínima, por lo que el umbral debe derivarse del tráfico y simulacros de fallos en lugar de un porcentaje universal.”

Errores comunes

• Afirmar que un PDB evita fallos de nodo: se confunde la disrupción voluntaria con la involuntaria → limita la afirmación a la ruta de la Eviction API.
• Configurar tanto minAvailable como maxUnavailable: los campos son mutuamente excluyentes → elige una sola expresión de presupuesto.
• Contar únicamente los Pods actuales: el presupuesto utiliza las réplicas deseadas → inspecciona las owner references y .spec.replicas.
• Seleccionar un namespace entero: aplicaciones no relacionadas comparten un único presupuesto → utiliza un selector de carga de trabajo específico.
• Decir que un PDB protege rolling updates y eliminaciones directas: los controladores y las rutas de eliminación tienen semánticas separadas → inspecciona cada política y ruta de permisos.
• Eliminar el PDB cuando el drain se bloquea: el riesgo de capacidad puede aumentar → inspecciona primero las réplicas saludables, probes, el estado del presupuesto y la capacidad.
• Configurar un PDB sin topología o capacidad: los Pods supervivientes pueden compartir un solo dominio de fallo → combina zonas, margen de capacidad y simulacros.
• Tratar un porcentaje como un recuento fijo de réplicas: el escalado cambia el significado → define la escala deseada, el redondeo y el comportamiento del autoescalado.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Qué significa minAvailable: 80% para cinco réplicas?

Requiere el recuento disponible producido por las reglas de porcentaje y redondeo de Kubernetes. No asumas que siempre son exactamente cuatro; verifica la semántica de la API actual y observa el comportamiento tras el escalado.

Pregunta de seguimiento 2: ¿Por qué un drain aún puede hacer que el servicio no esté disponible?

Un PDB limita las expulsiones voluntarias aceptadas; no puede reparar Pods que ya no son saludables, crear capacidad, revertir la concentración en una sola zona o hacer que la aplicación tolere el movimiento de conexiones. Readiness, topología, capacidad y graceful termination deben validarse en conjunto.

Pregunta de seguimiento 3: ¿Un PDB bloquea kubectl delete pod?

No asumas que lo hace. La documentación de Kubernetes señala que eliminar directamente Pods o Deployments puede eludir la protección del PDB, por lo que los permisos, la auditoría y los procesos de release deben restringir esa ruta.

Pregunta de seguimiento 4: El PDB muestra cero disrupciones permitidas. ¿Deberías flexibilizarlo primero?

Primero inspecciona el selector, las réplicas deseadas, las réplicas saludables, los fallos de readiness y el estado del controlador. Flexibilizar a ciegas el presupuesto puede ocultar un problema de salud. Si el mantenimiento realmente requiere un cambio temporal, evalúa la capacidad y el rollback, registra la ventana y restaura la política.

Pregunta de seguimiento 5: ¿En qué se diferencian los servicios con estado y sin estado?

Un servicio con estado debe preservar el quórum o las réplicas mínimas del protocolo de consistencia y validar el rebalanceo y la recuperación. Un servicio sin estado suele centrarse en la capacidad restante, la latencia y el drenado de conexiones. Ninguna afirmación de disponibilidad se sostiene únicamente por el recuento de réplicas.

Pregunta de seguimiento 6: ¿Cómo verificas que el PDB es efectivo?

En una ventana controlada, ejecuta la Eviction API y un node drain, luego observa el rechazo, los reintentos, el tiempo de gracia de terminación, el tráfico, los errores y el tiempo de recuperación. Prueba también fallos de nodo y rutas de eliminación directa para que el equipo no confunda el alcance del PDB con una garantía contra todo tipo de fallos.