Consigna y alcance
Un componente de programación externo recomienda un nodo para un Pod en estado Pending para reducir el filtrado repetido después de la apropiación (preemption). Con base en nominatedNodeName de Kubernetes, diseña el protocolo de cooperación y explica por qué no puede reemplazar a nodeName, cómo se manejan las sobrescrituras del scheduler y los cambios de recursos, y cómo realizas el rollback.
Kubernetes v1.35 marca nominatedNodeName como beta. Es un campo de status que los componentes externos pueden usar para nominar un nodo para un Pod pendiente. La nominación es de mejor esfuerzo (best effort), el scheduler puede sobrescribirla y el nodo nominado aún puede fallar las verificaciones de programación. La entrevista evalúa si mantienes una pista de intención separada de la vinculación final.
Qué evalúa el entrevistador
Cubre los permisos de escritura de status y la propiedad (ownership), la sincronización de la nominación y el filtrado, la terminación ordenada (graceful termination) de las víctimas de apropiación, la diferencia semántica entre nodeName y nominatedNodeName, las decisiones externas idempotentes y con expiración, las métricas y el despliegue y rollback del feature gate.
Una respuesta en 30 segundos
“Trato a nominatedNodeName como una sugerencia revocable, no como una promesa. Un componente externo actualiza el status solo con permiso explícito y registra una versión y un motivo; el scheduler valida el nodo nominado en cada ciclo y recurre a todos los candidatos cuando este falla. Un Pod de mayor prioridad puede tomar el nodo, y el scheduler puede reescribir o limpiar el campo. Utilizo el nodeName final y el evento de vinculación como el resultado, mido la tasa de aciertos, la tasa de fallback, la latencia de programación y el tiempo de terminación de las víctimas, y deshabilito el feature gate o el escritor externo si esas señales presentan una regresión.”
Solución paso a paso
Paso 1: Separar la semántica de los campos
nodeName es una asignación estricta en el spec del Pod. Elude el scheduler, y un nodo inexistente o de tamaño insuficiente puede hacer que el Pod falle directamente. nominatedNodeName está en el status y expresa un candidato para un Pod pendiente; tanto un nominador externo como la apropiación del scheduler pueden escribirlo, por lo que es un estado blando (soft state).
Paso 2: Definir permisos externos
Otorga al componente externo un RBAC mínimo para actualizar únicamente el status del Pod objetivo y registra el motivo de la nominación, la versión del algoritmo y la marca de tiempo en una anotación o evento. No debe escribir spec.nodeName ni asumir que una actualización de status hace que el kubelet vincule el Pod de inmediato.
apiVersion: v1
kind: Pod
metadata:
name: batch-worker
status:
nominatedNodeName: worker-07Paso 3: Respetar la propiedad del scheduler
El scheduler puede escribir el campo después de la apropiación o al ingresar a WaitOnPermit o PreBind. El componente externo debe aceptar las sobrescrituras y evitar una guerra de escrituras. Compara resourceVersion antes de cada actualización; ante un conflicto, vuelve a leer y a calcular.
Paso 4: Diseñar el filtrado y el fallback
El scheduler primero verifica si el nodo nominado aún pasa los filtros de recursos, afinidad, taints y topología. Si no los pasa, continúa el flujo normal de candidatos. El componente externo debe realizar una verificación previa rápida antes de nominar, pero su resultado nunca es la decisión final del scheduler.
Paso 5: Manejar la ventana de apropiación
La apropiación otorga a las víctimas un período de terminación ordenada, por lo que el nodo nominado puede seguir siendo inviable mientras estas salen. Un scheduler puede limpiar el campo o ceder el nodo a un Pod de mayor prioridad. El tráfico de negocio debe esperar un evento de vinculación en lugar de tratar el status de nominación como un estado de disponibilidad.
Paso 6: Hacer que las decisiones sean idempotentes y con expiración
Adjunta un ID de decisión trazable y un TTL corto a cada nominación. Los cambios en los recursos del nodo, una actualización del spec del Pod, un cambio de prioridad o el reordenamiento de la cola vuelven obsoleta una nominación anterior. La conciliación repetida debe escribir el mismo valor solo mientras la decisión siga siendo válida.
Paso 7: Definir la observabilidad
Mide el éxito de las escrituras de nominación, los conflictos de status, las fallas de filtrado en nodos nominados, la latencia de programación de fallback, el tiempo de Pending a vinculación, el tiempo de terminación de víctimas y los recuentos de limpieza de campos. Desglósalos por clúster, prioridad, scheduler y versión del algoritmo externo para localizar regresiones.
Paso 8: Despliegue y rollback
Habilita la ruta primero en unos pocos namespaces y PriorityClasses de bajo riesgo, comparando la latencia de programación y los resultados de apropiación. Si el tiempo de filtrado, las vinculaciones incorrectas o la inestabilidad del status aumentan, detén las escrituras externas de status y deshabilita el feature gate del scheduler. Mantén disponible la programación ordinaria; no fuerces un fallback escribiendo nodeName.
Compensaciones y límites
nominatedNodeName o nodeName
nominatedNodeName mantiene el filtrado, la apropiación y la vinculación bajo el control del scheduler, lo que lo hace adecuado para una recomendación externa. nodeName elude el scheduler y se reserva para casos avanzados donde el emisor acepta la responsabilidad de los recursos y las fallas; no es un mecanismo de aceleración general.
Primero la pista o escanear cada nodo
Probar la pista primero puede reducir el filtrado repetido en un clúster grande después de la apropiación, pero el nodo puede haber cambiado. Un escaneo completo de fallback es la base de corrección y no se puede eliminar en favor de una optimización de rendimiento.
Visibilidad o control
Status hace visible la intención de programación sin otorgar el control final. Las alertas, los controladores y la automatización de negocio deben observar la vinculación, FailedScheduling y los eventos en lugar de guiarse únicamente por nominatedNodeName.
Simulacros de fallas y evolución
El nodo nominado pierde capacidad
Inicia un Pod de mayor prioridad después de la nominación y verifica que el scheduler sobrescriba o limpie el campo y que el Pod original recurra al fallback en lugar de permanecer permanentemente en Pending.
Un conflicto en la actualización de status
Actualiza el status del mismo Pod de forma concurrente y verifica que el componente externo vuelva a leer tras un conflicto de resourceVersion en lugar de sobrescribir el scheduler con un objeto obsoleto.
La terminación de la víctima es lenta
Otorga a una víctima de apropiación un período de gracia de terminación prolongado. Confirma que el nodo nominado no se reporte como disponible demasiado pronto y monitorea la cola de la latencia de Pending a vinculación.
Errores comunes y preguntas de seguimiento
Error 1: Tratar nominatedNodeName como un resultado de vinculación
Seguimiento: ¿Está garantizado que el Pod se ejecutará allí una vez que existe el campo? No. El scheduler filtra nuevamente; el nodeName final y el evento de vinculación son el resultado.
Error 2: Reemplazar la nominación con nodeName
Seguimiento: ¿Por qué no escribir nodeName directamente? Elude las protecciones de recursos, taints, afinidad y apropiación, y puede fallar en un nodo inadecuado.
Error 3: Sobrescribir repetidamente el status
Seguimiento: ¿Qué ocurre si el scheduler cambia el campo? Acepta las carreras de propiedad, usa resourceVersion, TTLs de decisión y conciliación idempotente en lugar de competir contra el scheduler.
Preguntas de seguimiento más profundas y respuestas modelo
¿Por qué el nodo nominado podría no ser el definitivo?
Durante la terminación de la víctima, otro nodo puede liberar capacidad o un Pod de mayor prioridad puede tomar el nodo nominado. El scheduler continúa intentando y puede limpiar o sobrescribir la nominación.
¿Cómo demuestras que la optimización funciona?
Compara el tiempo de filtrado, la latencia de Pending a vinculación, la tasa de aciertos de nominación, la tasa de fallback y el tiempo de terminación de víctimas antes y después del despliegue. El recuento de escrituras por sí solo no demuestra una programación más rápida.
¿Cuál es el límite de seguridad mínimo para el componente externo?
Actualiza el status solo en Pods autorizados, nunca escribas nodeName ni el spec de prioridad y recursos, y confirma el resultado a través de un evento de vinculación. Cada decisión debe tener expiración, ser auditable y admitir rollback.