Entrevista de diseño de sistemas: ¿Cómo debería Kubernetes actualizar dinámicamente la capacidad de volumen del nodo CSI?

Consigna y contexto

La capacidad de adjuntar volúmenes de un controlador CSI cambia según las cuotas de la nube y el estado de salud. Diseñe el reporte de capacidad, la consistencia del programador, la protección contra fallas y las actualizaciones para Mutable CSINode Allocatable de Kubernetes. Explique los límites de responsabilidad entre el controlador CSI, el objeto nodo, el programador y las fallas de adjuntos (attach).

Qué evalúa el entrevistador

• Comprender que CSINode.spec.drivers[].allocatable.count es una pista de programación, no un bloqueo en tiempo real.
• Explicar cómo un controlador CSI actualiza la capacidad periódicamente o después de un error.
• Manejar valores obsoletos, actualizaciones concurrentes, cachés del programador y fallas de adjunto.
• Diseñar alertas, retroceso (backoff), actualizaciones de compatibilidad y recuperación de capacidad.

Preguntas de clarificación para hacer

1. ¿La capacidad cambia debido a una cuota de la nube, el estado del controlador o los recursos locales del nodo?
2. ¿Qué demora de actualización y qué margen de error son aceptables, y es aceptable un comportamiento conservador de estado Pending?
3. ¿Las versiones del clúster y del controlador CSI admiten valores allocatable mutables?
4. Tras una falla de adjunto, ¿el sistema debe reintentar, mover Pods o congelar el nodo primero?

Estructura de respuesta en 30 segundos

Comience con el objeto: el controlador CSI escribe la capacidad de volumen utilizable en CSINode, y el programador filtra con base en ella; debido a que el valor puede tener desfase (lag), el proceso de adjunto sigue realizando la verificación final. El controlador actualiza según un período o ante un error claro de capacidad, mientras que los controladores y el programador convergen mediante watches. Aplique límites de tasa a las actualizaciones, proteja el orden y reduzca la capacidad de forma conservadora ante la incertidumbre para evitar que un valor alto incorrecto se propague por el clúster.

Análisis detallado paso a paso

1. Cadena de responsabilidad y modelo de datos

Cada par de nodo y controlador tiene CSINode.spec.drivers[].allocatable.count. El controlador CSI conoce el límite de adjuntos del backend de almacenamiento y reporta la capacidad utilizable; el programador lo trata como información previa al filtrado. Este campo no es un bloqueo distribuido y no puede evitar condiciones de carrera entre decisiones de programación. El controlador de almacenamiento y el controlador de Kubernetes deben validar la capacidad nuevamente cuando un volumen se crea o se adjunta efectivamente.

2. Disparadores de actualización y consistencia

El controlador puede actualizarse según el período configurado mediante CSIDriver, o inmediatamente después de un error claro de agotamiento de capacidad. Utilice precondiciones de versión de recurso (resource-version) para que un controlador más antiguo no pueda sobrescribir un valor más nuevo. Añada un intervalo mínimo y variación aleatoria (jitter) para evitar transformar el ruido de las API de la nube en una amplificación de escrituras en el plano de control. El programador actualiza su caché mediante un watch y debe tomar decisiones conservadoras durante una ventana breve de inconsistencia.

3. Protección contra fallas y recuperación

Cuando el controlador no puede obtener la cuota o el estado de salud, no debe reportar capacidad infinita. Puede retener el último valor bueno conocido con una fecha de caducidad o reducir la capacidad a cero para que los nuevos Pods permanezcan en Pending. Clasifique las fallas de adjunto en errores de capacidad, permisos, topología o red transitoria; solo los errores de capacidad deben actualizar el valor allocatable. Aumente la capacidad gradualmente después de la recuperación mientras monitorea el éxito de los adjuntos.

4. Actualizar, observar y validar

Kubernetes v1.36 hace que Mutable CSINode Allocatable sea estable. Antes de actualizar, valide la matriz de versiones del API Server, programador, kubelet y controlador CSI; luego habilite las actualizaciones periódicas en un grupo canario pequeño de nodos. Monitoree la demora de actualización de objetos, la frecuencia de cambio de capacidad, los motivos de Pending, las clases de fallas de adjunto, las QPS de escritura en el plano de control y el uso real del nodo. Si las señales se degradan, pause las actualizaciones, restaure configuraciones compatibles y conserve la última capacidad de confianza.

Respuesta modelo

Trataría el valor allocatable mutable como una pista de programación, no como un bloqueo en tiempo real. El controlador CSI reporta la capacidad de adjunto del par nodo-controlador en CSINode.spec.drivers[].allocatable.count, actualizándose periódicamente o tras un error claro de agotamiento de capacidad. El programador observa el objeto mediante un watch, pero el controlador aún realiza la comprobación final al adjuntar.

Las actualizaciones necesitan límites de tasa, condiciones de versión de recurso y jitter. Si la cuota no es confiable, reduzca la capacidad de forma conservadora en lugar de escribir un valor arbitrariamente alto. Clasifique las fallas de adjunto por capacidad, permisos, topología y red; solo las fallas de capacidad disparan una actualización. Una vez que v1.36 estabilice la funcionalidad, despliegue en nodos canario y observe el desfase de actualización, los motivos de Pending, las fallas de adjunto, las QPS de escritura y el uso real. Pause las actualizaciones y restaure el último valor de confianza cuando las señales se degraden.

Errores comunes

• Tratar el valor allocatable como un bloqueo en tiempo real sin contención.
• Reducir la capacidad a cero ante cualquier falla de adjunto y provocar Pods en Pending colaterales.
• Permitir que un controlador escriba CSINode con alta frecuencia y amplifique la carga del plano de control.
• Reportar alta capacidad cuando la consulta de cuota falla.
• Actualizar únicamente las versiones de la API ignorando la compatibilidad del controlador CSI, el programador y kubelet.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué puede fallar el adjunto después de que el programador vio capacidad suficiente?

El campo tiene un retraso de propagación y consumidores concurrentes pueden consumir la misma cuota. Los filtros de programación disminuyen la probabilidad de falla; el controlador CSI debe validar nuevamente al adjuntar y devolver un error clasificado.

Pregunta de seguimiento 2: ¿Con qué frecuencia se debe refrescar la capacidad?

Depende de la frecuencia de cambio de cuota, el presupuesto de escritura en el plano de control y la tolerancia del negocio para Pods en estado Pending. Comience de forma conservadora, ajuste a partir del desfase de actualización, la tasa de fallas y las QPS de escritura, y use una actualización disparada por retroceso (backoff) tras los errores.

Pregunta de seguimiento 3: ¿Cómo se evita que un controlador antiguo sobrescriba una nueva capacidad?

Utilice actualizaciones condicionales basadas en la versión del recurso y un control de versiones de controlador, limitando las escrituras de controladores antiguos durante las actualizaciones. Monitoree la identidad del escritor, marcas de tiempo y regresiones; pause la expansión automática cuando se detecte una reversión.