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.
Why this lab
Builds on release management: planning, testing, rollback and validation after each release, applied to rolling a GPU driver across a fleet. In production the GPU Operator's own upgrade controller does this job; the lab shows what it has to get right.
What I built
A Go controller (standard library only) that rolls a driver version across the fleet:
- Canary, human approval by rollout name, batches, a maintenance window, pause and abort, and a failure budget.
- maxUnavailable also counts nodes that are out for other reasons, such as the quarantine and remediation from lab 09.
- Each node goes Draining → Installing → Validating → Soaking → Done. A hardware XID or ECC error during the soak counts as a failure.
- On failure it rolls back to the previous version, and if that also fails, it quarantines the node with lab 09's label.
How it is tested
The plan lives in a validated ConfigMap where unknown fields are errors. CI runs 12 controller unit tests, shellcheck and an end-to-end test on kind with 4 workers: 26 checks, green on the first run, including a closed window, a bad driver stopped at the canary and an XID during the soak with rollback.
Next steps
- Use the lab to rehearse your rollout policy: canary, approval, batches and rollback.
- Apply the same policy with the GPU Operator's upgrade controller on your clusters.
- Reuse the quarantine label from lab 09, so a node that fails twice is taken out of service.
Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →