Entrevista de diseño de sistemas: ¿Cómo desplegarías Kubernetes Node Declared Features de forma segura?

Planteamiento y contexto

Tu clúster está adoptando Kubernetes Node Declared Features: los kubelets reportan capacidades administradas del nodo en el estado del Node, el scheduler filtra los Pods en consecuencia y un controlador de admisión valida las actualizaciones de los Pods. Diseña el despliegue, la observabilidad, el manejo de fallos y la reversión para un clúster con versiones mixtas. Asume que solo se utilizan características de nodo controladas; los equipos de aplicaciones no pueden escribir nombres de capacidad arbitrarios.

Qué evalúa el entrevistador

• Si las declaraciones de capacidad se tratan como hechos del estado del nodo en lugar de etiquetas controladas por el usuario.
• Si el orden de dependencias entre kubelet, kube-apiserver, kube-scheduler y el control de admisión es explícito.
• Si se cubren los nodos antiguos, el estado desactualizado, las actualizaciones de Pods y la reversión de feature-gates.
• Si la seguridad se demuestra con la completitud de las declaraciones y el rechazo de programación, no solo con el inicio de los procesos.

Preguntas para clarificar

• ¿Qué versión del kubelet produce la capacidad y pueden los nodos antiguos seguir atendiendo Pods ordinarios?
• ¿El objetivo es proteger únicamente la ubicación inicial o también las actualizaciones una vez que el Pod está vinculado?
• ¿Existen schedulers personalizados, múltiples servidores de API o un plano de control multirregión?
• Ante un reporte falso, ¿deben detenerse los nuevos Pods mientras los Pods existentes continúan ejecutándose?

Respuesta en 30 segundos

Trataría esto como una cadena de hechos entre componentes: los kubelets publican status.declaredFeatures, el plugin del scheduler infiere los requisitos del Pod en PreFilter y filtra los nodos, y la validación de admisión protege las actualizaciones posteriores. Lo habilitaría primero en un grupo de nodos reversible y en una pequeña porción de cargas de trabajo, verificaría que la configuración del feature-gate coincida en el servidor de API, el scheduler y los kubelets, y luego expandiría. Monitorearía la completitud del reporte, los motivos de rechazo de programación, los rechazos de actualización y el desfase de versiones. Cualquier inconsistencia detiene las cargas de trabajo que requieren la nueva capacidad y preserva la ruta de programación ordinaria para los demás Pods.

Solución paso a paso

1. Definir la fuente de la verdad. Al iniciar, el kubelet detecta las características administradas y las escribe en Node.status.declaredFeatures; las etiquetas de aplicación no son equivalentes. Los nombres de las capacidades deben provenir de feature-gates administrados o de un contrato de componentes explícito.
2. Hacer explícitas las dependencias. Kubernetes requiere el gate NodeDeclaredFeatures en kube-apiserver, kube-scheduler y kubelet. Verifica las versiones y la configuración del plano de control antes de actualizar los kubelets; habilitar solo un lado crea un campo que nadie consume o un scheduler que espera reportes que los nodos no pueden generar.
3. Diseñar la ruta de programación. El plugin del scheduler infiere las características requeridas a partir del PodSpec en PreFilter y las compara con la declaración del nodo en Filter. Un nodo sin la declaración requerida no es programable para ese Pod. Un scheduler personalizado que utilice este campo debe preservar la misma semántica predeterminada y de fallos.
4. Proteger la ruta de actualización. El controlador de admisión NodeDeclaredFeatureValidator verifica las actualizaciones de los Pods contra el nodo vinculado, evitando que una actualización posterior eluda la restricción de capacidad. Muestra un rechazo claro en lugar de degradar silenciosamente.
5. Manejar el desfase de versiones. Un kubelet antiguo puede omitir el campo o desconocer una nueva capacidad. Trata una característica no declarada como no soportada, dejando los Pods dependientes en estado pendiente mientras los Pods ordinarios usan nodos compatibles. No edites manualmente el estado del Node para eludir el desfase.
6. Desplegar por etapas. Habilita el gate en un grupo de nodos reversible, coloca una carga de trabajo de prueba que requiera la capacidad y expande gradualmente. Detén el despliegue si la tasa de reportes faltantes, los rechazos de programación, los rechazos de actualización de Pods o la latencia del scheduler superan su línea base.
7. Observar y auditar. Recolecta la versión de declaración del nodo, un resumen (digest) de los conjuntos de capacidades, los motivos de filtrado del scheduler, los motivos de rechazo de admisión y las huellas de configuración de los gates, desglosados por grupo y versión de Kubernetes. Evita escribir objetos Node completos en logs de alta cardinalidad.
8. Revertir deliberadamente. Detén la creación de Pods que dependan de la característica, restaura la programación ordinaria y cierra el gate en el orden adecuado de componentes después de gestionar el trabajo dependiente pendiente. Si el negocio ya depende de la capacidad, migra las cargas de trabajo o retén nodos compatibles antes de hacer desaparecer las declaraciones.

Respuesta modelo

Primero identificaría la fuente de la verdad y el límite de protección. Los kubelets publican status.declaredFeatures administrados, el plugin NodeDeclaredFeatures del scheduler filtra la ubicación y NodeDeclaredFeatureValidator protege las actualizaciones tras la vinculación. Dado que Kubernetes requiere el gate en kube-apiserver, scheduler y kubelet, alinearía versiones y configuraciones antes de habilitarlo en un grupo reversible. Un Pod de prueba verifica el reporte de capacidades y la ubicación; la tasa de reportes faltantes, los rechazos de filtro, los rechazos de actualización y la latencia de programación se convierten en criterios de control de expansión. Un nodo antiguo que no declare la característica no tiene soporte, mientras que los Pods ordinarios mantienen la ruta anterior. Para la reversión, detendría las nuevas cargas de trabajo dependientes, migraría las existentes, cerraría el gate y confirmaría que los conteos de pendientes y la programación ordinaria se recuperen.

Errores comunes

• Tratar declaredFeatures como una etiqueta ordinaria → los usuarios pueden falsificar capacidades y anular la seguridad de la programación → aceptar solo el conjunto administrado por el kubelet.
• Habilitar el gate solo en el scheduler → los nodos no publican el campo → verificar conjuntamente la configuración del servidor de API, el scheduler y el kubelet.
• Tratar "no declarado" como soportado → los nodos con versiones mixtas pueden recibir Pods incompatibles → no declarado significa no soportado.
• Probar únicamente la ubicación inicial → una actualización de Pod puede eludir la restricción → habilitar y observar también la validación de admisión.
• Activarlo a nivel de todo el clúster → los fallos no podrán atribuirse a un grupo, versión o carga de trabajo específicos → usar pruebas, etapas y condiciones de parada.
• Deshabilitar el gate inmediatamente → los Pods dependientes pueden volverse irrecuperables → detener la creación y migrar primero las cargas de trabajo dependientes.

Preguntas de seguimiento y respuestas

Un nodo reportó una capacidad pero su estado está desactualizado. ¿Qué debería hacer el scheduler?

Hacer de la antigüedad del reporte una señal operativa. Un Pod que requiera la característica debe esperar o moverse a un nodo actualizado en lugar de depender de una declaración antigua. Tras el límite de vigencia (freshness deadline), aislar el grupo y requerir confirmación del operador.

¿Qué puede salir mal con un scheduler personalizado que ignore el plugin oficial?

Podría admitir un Pod que el scheduler por defecto rechazaría. La ruta personalizada debe implementar una semántica equivalente para PreFilter, Filter, valores predeterminados y versiones; ejecuta pruebas de conformidad antes de permitir que las cargas de trabajo lo seleccionen.

¿Cómo evitas una ventana de inconsistencia en la configuración mientras tres componentes cambian el gate?

Incluye una huella digital de configuración en la verificación de despliegue, mantén activas las cargas de trabajo ordinarias y realiza el despliegue a través del plano de control, el scheduler y los grupos de nodos en un orden controlado. Cualquier discrepancia detiene la expansión; el simple inicio de los procesos no equivale al éxito.

El negocio depende de la característica, pero la reversión encuentra que los nodos antiguos no la soportan. ¿Qué hacer en ese caso?

Conserva un grupo de nodos que declaren la capacidad, migra o reduce las cargas de trabajo dependientes y solo entonces cierra el gate. Si la migración es imposible, pausa la reversión y añade capacidad compatible en lugar de eliminar repentinamente la restricción de programación.