Iñigo GonzálezIT Operations · Infra

Blog · 16

Promocionar versiones del GPU Operator de staging a prod con FluxPromoting GPU Operator releases from staging to prod with Flux

Un fichero define versiones y clústeres; Git y Flux hacen el resto, con una puerta antes de producción.One file defines releases and clusters; Git and Flux do the rest, with a gate before production.

Laboratorio GPUGPU lab · 9 oct 20269 Oct 2026 · 2 min2 min read

Por qué este laboratorio

Se apoya en Git, pipelines de CI/CD y gestión de releases, y une varios laboratorios anteriores: cómo actualizar el software de GPU en una flota de clústeres desde Git, con una puerta antes de producción.

Qué he hecho

  • fleet.toml define versiones (GPU Operator, Network Operator y driver, más una versión que falla a propósito) y clústeres con pools de GPU.
  • Las olas van staging → prod H100 → prod A100, con una pausa tras el canary.
  • python -m fleet render escribe la carpeta de cada clúster y Flux la aplica en tres pasos: operators → config → lifecycle. El paso lifecycle es el controlador del laboratorio 11, con su plan generado desde el mismo fichero.
  • fleet start / promote / approve editan una línea cada uno, fleet gate revisa los clústeres vivos antes de promocionar y aprobar producción es un commit.

Cómo se prueba

CI: 21 tests unitarios; un paso de validación que renderiza los charts de Helm reales de NGC en cada versión y los comprueba contra los esquemas de CRD de esa versión exacta (detecta un nodeSelecter mal escrito); y una prueba de punta a punta de 20 minutos con Gitea y dos clústeres kind, 29 comprobaciones, incluida la deriva corregida por Flux y una versión mala parada en staging.

Qué aprendí

Una iteración de CI: el plan de rollout se aplicaba antes que los objetos NVIDIADriver, así que lifecycle ahora depende de config. También encontré una diferencia en el CRD NVIDIADriver entre dos versiones del GPU Operator.

Siguientes pasos

  • Describir tus clústeres y releases en fleet.toml.
  • Instalar Flux en cada clúster (o usar Argo CD, la misma estructura sirve).
  • Mantener la puerta antes de producción como comprobación obligatoria en tu repositorio.

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

Why this lab

Builds on Git, CI/CD pipelines and release management, and ties several earlier labs together: how to upgrade the GPU software stack across a fleet of clusters from Git, with a gate before production.

What I built

  • fleet.toml defines releases (GPU Operator, Network Operator and driver versions, plus one release that fails on purpose) and clusters with GPU pools.
  • Waves go staging → prod H100 → prod A100, with a pause after the canary.
  • python -m fleet render writes each cluster's folder, and Flux applies it in three steps: operators → config → lifecycle. The lifecycle step is lab 11's controller, with its rollout plan generated from the same file.
  • fleet start / promote / approve each edit one line, fleet gate checks the live clusters before promoting, and approving prod is a commit.

How it is tested

CI: 21 unit tests; a validate step that renders the real NGC Helm charts at every version and checks them against the CRD schemas of that exact version (it catches a misspelt nodeSelecter); and a 20-minute end-to-end run with Gitea and two kind clusters, 29 checks, including drift corrected by Flux and a bad release stopped in staging.

What I learned

One CI iteration: the rollout plan was applied before the NVIDIADriver objects, so lifecycle now depends on config. I also found a difference in the NVIDIADriver CRD between two GPU Operator versions.

Next steps

  • Describe your clusters and releases in fleet.toml.
  • Bootstrap Flux on each cluster (or use Argo CD, the same structure works).
  • Keep the gate before production as a required check in your repository.

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 →