Entrevista de diseño de sistemas: ¿cómo diseñaría un orquestador de mantenimiento que respete PDB y topology spread?

Enunciado y alcance

Un clúster necesita una actualización continua de nodos mientras las cargas de trabajo utilizan PodDisruptionBudget y restricciones de topology spread. Diseñe el orquestador de mantenimiento, cubriendo los nodos candidatos, la concurrencia de desalojo, los reemplazos no programables, la reserva de capacidad, la recuperación y la observabilidad.

Kubernetes define un PDB para limitar los Pods afectados por interrupciones voluntarias; las herramientas de mantenimiento deben usar la Eviction API para que el presupuesto participe en la admisión. Las restricciones de topology spread controlan el sesgo (skew) a través de dominios de falla como zonas y nodos. Un diseño sólido coloca ambas restricciones en un solo bucle de control en lugar de verificar el recuento de Pods una sola vez y eliminar un lote.

Qué evalúa el entrevistador

• Distinguir la interrupción voluntaria de la falla involuntaria y su límite de garantía.
• Utilizar la Eviction API en lugar de eliminar Pods directamente.
• Evaluar maxSkew, whenUnsatisfiable y los selectores de etiquetas de topology spread.
• Diseñar la concurrencia y las reservas de capacidad por nodo y dominio de falla.
• Gestionar el bloqueo por PDB, Pods no listos, reintentos, tiempos de espera y reversión (rollback).
• Explicar las decisiones a través de eventos, métricas y registros de auditoría.

Preguntas aclaratorias para hacer

1. ¿Se trata de una actualización de SO, reemplazo de instancias o una reparación de emergencia? Una falla de emergencia puede eludir la protección de PDB.
2. ¿Cuáles son los recuentos de réplicas, las configuraciones de PDB, los dominios de topología y la capacidad de reserva?
3. ¿La prioridad es la duración total, el riesgo mínimo para el usuario o una redundancia estricta en cada zona?
4. ¿Existe un Cluster Autoscaler, un grupo de nodos temporal o un límite de capacidad entre zonas?
5. ¿Cuánto tiempo puede esperar el controlador ante un PDB antes de pausar, degradar o solicitar aprobación?

Respuesta en 30 segundos

Construiría un controlador declarativo que lea nodos, Pods, PDBs, restricciones de topología y capacidad programable. Simularía el impacto de un desalojo en las réplicas saludables y en el sesgo de topología, para luego ejecutar lotes pequeños a través de la Eviction API. Los tokens de nodo y de dominio de falla definen la concurrencia; el controlador espera a que un Pod de reemplazo pase a estar Ready antes de continuar. Los conflictos de PDB o las restricciones de topología insatisfechas pausan el lote con un motivo en lugar de forzar la eliminación. Cada operación es idempotente y observable, con tiempo de espera, reversión y una ruta de riesgo separada para fallas involuntarias.

Análisis detallado paso a paso

1. Definir el estado y las entradas de restricciones

La tarea contiene nodos objetivo, lotes de actualización, concurrencia máxima, plazos y política de reversión. Almacene en caché las etiquetas de nodo, los propietarios de Pods, el estado de preparación (readiness), el disruptionsAllowed del PDB, las restricciones de topología y la capacidad disponible, pero vuelva a leer el estado crítico antes de cada decisión en lugar de confiar en una instantánea antigua.

2. Elegir nodos candidatos y lotes seguros

Filtre los nodos acordonados (cordoned), los nodos que albergan Pods críticos del sistema y los nodos sin capacidad de reemplazo. Agrupe los candidatos por zona, rack y carga de trabajo. Un lote debe mantenerse dentro del margen de PDB de cada carga de trabajo y simular el sesgo de topología después del reemplazo. Prefiera nodos con capacidad de reserva que no conviertan un dominio de falla en un punto único de falla.

3. Usar la Eviction API

Para el mantenimiento voluntario, llame a la Eviction API y deje que Kubernetes evalúe el PDB. Registre el PDB específico, la carga de trabajo y el tiempo de reintento en caso de conflicto o rechazo. La eliminación directa elude el presupuesto y debe reservarse para una ruta de emergencia destructiva explícitamente aprobada.

read constraints -> choose one node -> create eviction request
                -> PDB allows? no: back off and re-evaluate
                -> yes: wait for Ready replacement and topology recovery
                -> success: mark node complete; failure: pause and recover

4. Reaccionar a la retroalimentación de topología y capacidad

El desalojo no implica la finalización. Un reemplazo puede permanecer en estado Pending debido a DoNotSchedule, la falta de una clave de topología, afinidad o capacidad insuficiente. Observe los eventos del programador (scheduler); expanda un grupo temporal o cambie el orden de los lotes cuando sea apropiado, pero no relaje silenciosamente las restricciones de la carga de trabajo. ScheduleAnyway aún requiere registrar el sesgo real y el costo.

5. Diseñar concurrencia, concesiones (leases) e idempotencia

Utilice una concesión de tarea para un nodo y la generación del controlador de modo que múltiples trabajadores de mantenimiento no puedan desalojar el mismo objetivo. Comience con un límite pequeño por zona o un bucket de tokens por carga de trabajo. Adquiera el siguiente token solo después de que el reemplazo esté Ready, el presupuesto del PDB se recupere y el sesgo de topología esté dentro del límite previsto. Trate un desalojo repetido como ya gestionado y recupérese a partir del estado de la API tras el reinicio del controlador.

6. Fallas, tiempos de espera y reversión

Si un Pod permanece en Pending, un PDB se mantiene en cero, el vaciado (draining) agota el tiempo de espera o un nuevo nodo no es saludable, pause los lotes posteriores y elimine los acordonamientos innecesarios. Cuando un nodo actualizado no pueda revertirse a una imagen antigua, conserve un grupo antiguo o cambie a una imagen validada. La reversión restaura la redundancia del servicio; no fuerza a que el porcentaje de mantenimiento llegue al 100%.

7. Observabilidad y simulacros

Registre los nodos seleccionados, las cargas de trabajo afectadas, el margen de PDB antes y después, los recuentos de topología, las respuestas de desalojo, los motivos de Pending y la duración. Mida los desalojos exitosos, el tiempo de bloqueo por PDB, el sesgo máximo, la latencia de Ready, el tráfico entre zonas y los reintentos. Realice simulacros de escasez de capacidad en una sola zona, presupuesto de PDB en cero, fallas del programador, reinicios del controlador y pérdida repentina de nodos.

Respuesta de muestra de alta calidad

Modelaría el orquestador como un controlador declarativo que avanza por nodo y dominio de falla. Lee los propietarios de los Pods, el estado de preparación, los PDBs, el topology spread, las etiquetas de los nodos y la capacidad programable; simula el efecto de un desalojo en las réplicas saludables y en maxSkew, y luego envía un lote pequeño a la Eviction API. Cada zona tiene un token de concurrencia, y el siguiente nodo espera a que haya un reemplazo en estado Ready, un presupuesto de PDB recuperado y restricciones de topología satisfechas.

Los conflictos de PDB, los reemplazos en Pending, la escasez de capacidad o el tiempo de espera pausan el lote y registran un motivo. El controlador puede expandir un grupo temporal o reordenar los candidatos, pero nunca elimina Pods directamente ni relaja silenciosamente las restricciones. Las concesiones y las generaciones hacen que los reintentos sean idempotentes, y los reinicios se recuperan a partir del estado de la API. Las métricas cubren el bloqueo de presupuesto, el sesgo máximo, la latencia de Ready, los reintentos y el costo entre zonas antes de ampliar el lote.

Errores comunes

• Eliminar Pods para vaciar más rápido → elude el PDB → utilice la Eviction API para el mantenimiento voluntario.
• Observar solo disruptionsAllowed → los reemplazos pueden violar la topología o carecer de capacidad → simule primero el sesgo y la ubicación.
• Desalojar réplicas en varias zonas a la vez → pierde la redundancia del dominio de falla → use tokens de concurrencia por zona y por carga de trabajo.
• Editar el PDB cuando se bloquea → transfiere el riesgo a los usuarios → pause, añada capacidad o solicite aprobación.
• Esperar solo la eliminación → un servicio puede no tener un reemplazo en Ready → controle el estado con preparación, eventos del programador y plazos.
• Omitir concesiones del controlador → los trabajadores repiten operaciones → persista concesiones, generaciones y estado idempotente.

Preguntas de seguimiento y respuestas

¿Puede un PDB proteger contra la desaparición repentina de un nodo?

No completamente. Un PDB limita principalmente las interrupciones voluntarias; las fallas de hardware y el agotamiento de recursos pueden eliminar réplicas directamente. La redundancia sigue requiriendo múltiples dominios de falla, réplicas y capacidad de reserva.

¿Por qué no usar kubectl delete pod?

La eliminación directa elude la verificación de admisión del PDB. Un controlador de mantenimiento debe llamar a la Eviction API para que el servidor de la API devuelva una decisión de autorización o conflicto.

¿Qué sucede si el PDB permite el desalojo pero el reemplazo permanece en Pending?

Pause el lote, inspeccione los eventos del programador y los recuentos de topología, y añada capacidad o elija otro nodo. Continuar desalojando crearía una brecha de redundancia mayor.

¿Se puede interpretar ScheduleAnyway como ignorar el sesgo?

No. Le indica al programador que prefiera nodos que reduzcan el sesgo, pero el sesgo aún puede persistir. Registre la distribución real, el costo y el riesgo para la redundancia.

¿Cómo evita un reinicio del controlador los desalojos duplicados?

Utilice concesiones de tareas, bloqueos de nodos, generaciones del controlador y estado persistente. En la recuperación, confíe en el estado de los Pods, de Eviction y de los nodos obtenido de la API en lugar de reproducir una cola en memoria.

¿Cuándo es aceptable la eliminación forzada?

Solo para una emergencia explícitamente aprobada cuando la ruta voluntaria no puede manejar el riesgo, con autorización elevada y un registro de que el PDB y la redundancia pueden verse comprometidos.