Consigna y contexto
Un servicio sin estado (stateless) se ejecuta en múltiples zonas y escala de 2 a 30 réplicas. Durante fallas de nodos, escalado y lanzamientos progresivos (rolling releases), el equipo desea evitar concentrar réplicas en un único dominio de falla sin hacer que un nuevo lanzamiento sea imposible de programar. Diseña topologySpreadConstraints y explica cuándo usar DoNotSchedule, ScheduleAnyway o anti-affinity.
Qué evalúa el entrevistador
- Si traduces la disponibilidad en objetivos explícitos de dominio de falla a nivel de nodo, zona y región.
- Si explicas correctamente
maxSkew,minDomains,topologyKeyywhenUnsatisfiable. - Si detectas casos límite relacionados con selectores, etiquetas de topología faltantes y un número reducido de réplicas.
- Si la ubicación, los PDB, las actualizaciones progresivas, el autoescalado y la observabilidad funcionan como un diseño integral.
Preguntas para clarificar
- ¿Las zonas son independientes en energía, red y capacidad, y una falla regional está dentro del alcance?
- ¿Cuántas réplicas deben permanecer tras perder un dominio de falla?
- ¿Un Pod no programable debería esperar, reducir la disponibilidad o tolerar un desbalance (skew) temporal?
- ¿Las etiquetas de cargas de trabajo, las etiquetas de topología de nodos y las restricciones predeterminadas son administradas por la plataforma?
- ¿Las versiones anteriores y nuevas utilizan el mismo
labelSelectordurante una actualización progresiva?
Respuesta en 30 segundos
Definiría primero los dominios de falla y la capacidad mínima, y luego establecería objetivos de ubicación separados para nodos y zonas. Los servicios críticos utilizan DoNotSchedule acotado; las cargas de trabajo ordinarias o elásticas utilizan ScheduleAnyway como objetivo flexible (soft). maxSkew limita la diferencia para un selector a través de los dominios elegibles, mientras que minDomains evita cálculos engañosos cuando faltan dominios. Antes del despliegue probaría etiquetas, escalado, actualizaciones progresivas y la falla de un único dominio; en producción monitorearía réplicas por dominio, tiempo en Pending, capacidad disponible y el presupuesto de disrupción del PDB.
Respuesta a fondo
Paso 1: Definir dominios y capacidad
Mapea nodos, zonas y regiones a valores distintos de topologyKey. Si el servicio debe sobrevivir a la pérdida de una zona, mantén suficientes réplicas en al menos dos zonas; con solo dos réplicas, no puedes garantizar una distribución uniforme en tres zonas y dos réplicas saludables tras perder una. Establece el invariante de capacidad antes de elegir el nivel de rigurosidad.
Paso 2: Elegir maxSkew y minDomains
maxSkew es la diferencia permitida entre un dominio de destino y el mínimo global; con DoNotSchedule, superarla deja al Pod en estado Pending. minDomains expresa cuántos dominios elegibles se requieren y evita que un conjunto de dominios reducido se trate como una distribución válida. Prueba servicios con pocas réplicas para que la restricción no bloquee los lanzamientos.
Paso 3: Separar restricciones duras y flexibles
Los servicios de plano de control o de pagos pueden usar DoNotSchedule a nivel de zona y convertir los fallos de ubicación en alertas de capacidad. El trabajo por lotes o postergable puede usar ScheduleAnyway, pidiéndole al planificador que reduzca el desbalance mientras permite desajustes temporales. La anti-afinidad dura se ajusta a una regla simple de “no coubicar”; la topología multinivel y el desbalance medible suelen ser más claros con topology spread constraints.
Paso 4: Hacer que los selectores y las etiquetas sean confiables
El labelSelector de la restricción debe coincidir con la plantilla real del Pod, o los nuevos Pods podrían contabilizarse contra el conjunto incorrecto. Los nodos necesitan etiquetas estables de zona, región y nombre de host; un nodo sin la clave de topología no participa correctamente en el cálculo de ese dominio. Las comprobaciones de admisión deben validar selectores, etiquetas y valores predeterminados antes de que los equipos copien un manifiesto defectuoso.
Paso 5: Coordinar lanzamientos, PDBs y escalado
Una actualización progresiva debe considerar las réplicas antiguas, las nuevas réplicas y maxUnavailable en conjunto. Un PDB limita la disrupción voluntaria; no reemplaza la ubicación entre dominios. El autoescalador debe comprender los Pods en estado Pending y la capacidad por dominio; de lo contrario, las restricciones estrictas pueden esperar indefinidamente sin agregar nodos utilizables.
Paso 6: Definir acciones de falla y degradación
Ejercita la pérdida de un nodo, la pérdida de una zona y la falta de etiquetas en nodos, y luego observa si los nuevos Pods son rechazados, desbalanceados o quedan en Pending. Los servicios críticos pueden pausar lanzamientos de baja prioridad, agregar capacidad a dominios saludables o entrar en modo de solo lectura. No elimines una restricción dura en producción sin registrar el riesgo para la disponibilidad. Versiona y revierte las acciones de degradación.
Paso 7: Verificar con métricas de distribución
Registra réplicas, desbalance (skew), duración en Pending, motivos de programación, capacidad disponible, disrupción de PDB y errores de solicitudes por carga de trabajo, versión y dominio de topología. Las pruebas de carga deben cubrir de 2 a 30 réplicas, capacidad de dominio desigual, actualizaciones progresivas y autoescalado. El objetivo es demostrar que la capacidad restante cumple con el SLO tras la pérdida de un dominio, no simplemente que las réplicas quedaron en diferentes nodos.
Respuesta modelo
Modelaría nodos, zonas y regiones como tres capas de dominios de falla y establecería primero el mínimo de réplicas requeridas tras perder una zona. Los Pods del servicio utilizan un selector que coincide con la plantilla; las restricciones se aplican por separado al nombre de host y a la zona. Los servicios críticos usan un maxSkew de zona pequeño con DoNotSchedule, mientras que el trabajo por lotes usa ScheduleAnyway. Si los dominios elegibles caen por debajo de minDomains, genera una alerta de capacidad en lugar de aceptar silenciosamente una distribución engañosa. Valida el PDB, maxUnavailable y los selectores antiguos/nuevos durante las actualizaciones progresivas, y haz que el autoescalador observe los motivos de Pending y la capacidad por dominio. Realiza el despliegue en modo de observación y luego habilita las restricciones duras gradualmente utilizando réplicas por dominio, tiempo en Pending, simulacros de dominio de falla y SLOs de negocio como criterios de reversión.
Errores comunes
- Decir “desplegar entre zonas” sin nombrar el
topologyKeyo el objetivo de capacidad. - Tratar a
maxSkewcomo un límite absoluto de réplicas por dominio. - Ignorar un desajuste en el selector y, por ende, contabilizar el conjunto de Pods incorrecto.
- Tratar a un PDB como una restricción del planificador o como protección ante cualquier falla de nodo.
- Prometer una distribución uniforme en tres zonas y sin degradación tras la pérdida de una zona con solo dos réplicas.
- Eliminar
DoNotSchedulepara destrabar el estado Pending sin registrar el impacto sobre la disponibilidad.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿ScheduleAnyway sigue ayudando a la disponibilidad?
Sí. Hace que un menor desbalance sea una preferencia de programación mientras permite que una carga de trabajo se ejecute cuando la capacidad está restringida. Se adapta a tareas postergables o cargas de trabajo con otra redundancia; los servicios críticos pueden escalar con antelación y utilizar una restricción estricta.
Pregunta de seguimiento 2: ¿Por qué no usar únicamente pod anti-affinity?
La anti-afinidad establece que no se debe coubicar con ciertos Pods seleccionados. Expresa niveles múltiples de topología, desbalance numérico y requisitos mínimos de dominio de forma menos directa. Las topology spread constraints describen el desbalance entre dominios, mientras que la anti-afinidad sigue siendo útil para una regla de exclusión simple.
Pregunta de seguimiento 3: ¿Qué sucede cuando minDomains es incorrecto?
Con muy pocos dominios elegibles, el mínimo global utilizado para el desbalance puede hacer que una restricción parezca cumplida o mantener Pods en Pending. Incluye la disponibilidad de dominios en las comprobaciones de admisión y alertas de capacidad, y verifica el comportamiento del campo para la versión del clúster.
Pregunta de seguimiento 4: ¿Por qué un lanzamiento progresivo puede romper la distribución?
Las versiones antiguas y nuevas pueden usar diferentes selectores, o maxUnavailable y maxSurge pueden agregar réplicas temporalmente en un dominio. Simula estados intermedios e inspecciona el desbalance por versión y dominio antes del lanzamiento.
Pregunta de seguimiento 5: ¿Qué pasa si un nodo carece de una etiqueta de zona?
No participará correctamente en el cálculo de la topología solicitada. Repara o aísla el nodo; no cuentes un nodo sin etiquetar como un dominio de falla independiente.
Pregunta de seguimiento 6: ¿Cómo se demuestra que el SLO sobrevive a una falla de zona?
Ejecuta un simulacro de aislamiento y verifica la capacidad programable, las réplicas saludables, los errores de solicitudes y el tiempo de recuperación en los dominios restantes. Registra el estado del PDB, los motivos de Pending y el tiempo de escalado vertical para validar todo el flujo desde la programación hasta las métricas de negocio.