Blog · 09

Un controlador de Kubernetes que drena, repara o pone en cuarentena nodos GPUTeaching a Kubernetes controller to drain, repair or quarantine GPU nodes

Primer laboratorio de GPU: los XID, el ECC y la temperatura llevan cada nodo por una máquina de estados.First GPU lab: XID errors, ECC and temperature drive each node through a state machine.

Por qué este laboratorio

Viene de la operación de hardware: validar y certificar servidores, y automatizar la detección y la reparación de fallos de hardware. Es el primero de una serie de laboratorios que lleva eso a las flotas de GPU. Funciona con GPU simuladas, así que cualquiera puede reproducirlo en un portátil.

Qué he hecho

Un controlador de Kubernetes en Go (solo librería estándar, sin client-go) que lee métricas DCGM (errores XID, ECC de doble bit, row remapping, temperatura) y lleva cada nodo por Healthy → Draining → Repairing → Validating → Healthy, o a Cordoned por temperatura, o a Quarantined.

  • El estado vive en anotaciones del nodo, con un presupuesto de nodos en remediación (max-unavailable).
  • Las evicciones respetan los PodDisruptionBudget y la validación es un Job fijado al nodo con todas sus GPU.
  • Regla de reincidencia, modo dry-run, eventos y métricas de Prometheus.
  • La política de XID se basa en la documentación de NVIDIA (docs/xid-policy.md).

Cómo se prueba

Un simulador gpu-sim hace de dcgm-exporter. La CI pasa tests unitarios, shellcheck y una prueba de punta a punta en kind con 8 escenarios (28 comprobaciones), en verde a la primera. Hay además un modo gpuremediate check que usa nvidia-smi en una GPU real.

Siguientes pasos

  • En un clúster con GPU, desplegar dcgm-exporter en lugar del simulador.
  • Empezar en modo dry-run y fijar el presupuesto de nodos en reparación (max-unavailable).
  • gpuremediate check funciona en cualquier máquina con nvidia-smi, también en un puesto Windows.

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

Why this lab

Comes from hardware operations: validating and certifying servers, and automating the detection and remediation of hardware failures. This is the first of a series of labs that applies that to GPU fleets. It runs on simulated GPUs, so anyone can reproduce it on a laptop.

What I built

A Kubernetes controller in Go (standard library only, no client-go) that reads DCGM metrics (XID errors, double-bit ECC, row remapping, temperature) and moves each node through Healthy → Draining → Repairing → Validating → Healthy, or to Cordoned for thermal issues, or Quarantined.

  • State is kept in node annotations, with a budget of nodes in remediation (max-unavailable).
  • Evictions respect PodDisruptionBudgets, and validation runs as a Job pinned to the node with all its GPUs.
  • A repeat-offender rule, dry-run mode, events and Prometheus metrics.
  • The XID policy is based on NVIDIA's documentation (docs/xid-policy.md).

How it is tested

A gpu-sim simulator stands in for dcgm-exporter. CI runs unit tests, shellcheck and an end-to-end test on kind with 8 scenarios (28 checks), green on the first run. There is also a gpuremediate check mode that uses nvidia-smi on a real GPU.

Next steps

  • On a cluster with GPUs, deploy dcgm-exporter instead of the simulator.
  • Start in dry-run mode and set the budget of nodes in remediation (max-unavailable).
  • gpuremediate check runs on any machine with nvidia-smi, including a Windows workstation.

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 →