Promocionar versiones del GPU Operator de staging a prod con Flux

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.