Desplegar un driver de GPU por la flota: canary, aprobación y rollback

Por qué este laboratorio

Se apoya en la gestión de releases: planificación, pruebas, vuelta atrás y validación después de cada despliegue, aplicadas a actualizar el driver de GPU en toda una flota. En producción lo hace el controlador de actualización del propio GPU Operator; el laboratorio enseña lo que tiene que hacer bien.

Qué he hecho

Un controlador en Go (solo librería estándar) que despliega una versión de driver por la flota:

• Canary, aprobación humana por nombre de rollout, lotes, ventana de mantenimiento, pausa y aborto, y presupuesto de fallos.
• maxUnavailable cuenta también los nodos que están fuera por otros motivos, como la cuarentena y la remediación del laboratorio 09.
• Cada nodo pasa por Draining → Installing → Validating → Soaking → Done. Un XID de hardware o un error ECC durante el soak cuenta como fallo.
• Si falla, vuelve a la versión anterior y, si eso también falla, pone el nodo en cuarentena con la etiqueta del laboratorio 09.

Cómo se prueba

El plan vive en un ConfigMap validado donde los campos desconocidos son error. La CI pasa 12 tests unitarios del controlador, shellcheck y una prueba de punta a punta en kind con 4 workers: 26 comprobaciones, en verde a la primera, con ventana cerrada, un driver malo parado en el canary y un XID en el soak con rollback.

Siguientes pasos

• Usar el laboratorio para ensayar tu política de despliegue: canary, aprobación, lotes y vuelta atrás.
• Aplicar la misma política con el controlador de actualización del GPU Operator en tus clústeres.
• Reutilizar la etiqueta de cuarentena del laboratorio 09, para que un nodo que falla dos veces salga de servicio.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.