Levantar un cluster de Kubernetes dedicado por equipo suele entregar más aislamiento del que una organización realmente necesita. Y aunque un solo cluster puede compartirse entre muchos equipos, los costos de coordinación crecen a medida que se suman. Los problemas típicos son conocidos: versiones de CRD en conflicto, reglas de control de acceso (RBAC) superpuestas y ninguna forma limpia de repartir la capacidad de GPU en presupuestos por equipo. Pasado cierto tamaño, los equipos empiezan a pedir su propio cluster solo para recuperar autonomía.
NVIDIA publicó un patrón que preserva esa autonomía sin partir el hardware. La solución consta de un único cluster de plano de control con un conjunto de GPU, uso compartido con cuotas por equipo, y un plano de control de Kubernetes aislado para cada uno, que incluye servidor de API, controlador, almacén de datos, sincronizador y planificador. Todo se logra con dos herramientas de código abierto: KAI Scheduler y vCluster.
¿Qué hace cada una de las dos piezas?
KAI Scheduler es un planificador de Kubernetes consciente de la topología, construido específicamente para optimizar la asignación de GPU en cargas de inteligencia artificial. Está diseñado para administrar clusters de gran escala, del orden de miles de nodos, con alto volumen de trabajos. Puede convivir con el planificador por defecto: cualquier pod con schedulerName: kai-scheduler lo maneja KAI, y el resto sigue el camino habitual de kube-scheduler.
vCluster aprovisiona clusters inquilinos completamente aislados sobre la infraestructura existente o directamente sobre metal desnudo. Cada cluster inquilino recibe su propio servidor de API, sus definiciones de recursos personalizados (CRD) y su control de acceso basado en roles, indistinguibles de un cluster dedicado, mientras comparte los nodos y el hardware subyacentes. El plano de control virtualizado es invisible para los inquilinos: no hay nodos de plano de control compartidos, no hay pods agente dentro del cluster y no existe camino lateral entre entornos.
Este tutorial usa el modelo de nodos compartidos de vCluster, adecuado para equipos internos de confianza. Para inquilinos no confiables, que requieren separación a nivel de nodo, red y almacenamiento, el mismo patrón se extiende a los nodos privados de vCluster.
¿Qué caso de uso resuelve?
El ejemplo plantea tres equipos con necesidades incompatibles entre sí:
- El equipo de procesamiento de lenguaje natural quiere instalar sus propios CRD.
- El equipo de visión necesita acceso de administrador del cluster para depurar la planificación.
- El equipo de sistemas de recomendación trabaja sobre una versión distinta de Kubeflow.
Nadie quiere compartir un contexto de kubectl y romper por accidente el entorno del vecino. Con vCluster, cada equipo obtiene su plano de control, su RBAC, sus espacios de nombres y sus CRD, con acceso de administrador incluido. Por debajo, todos los clusters inquilinos comparten los mismos nodos y las mismas GPU.
¿Con qué hardware se puede reproducir?
Para mantener el ejercicio reproducible con recursos limitados, la demostración corre sobre una instancia de NVIDIA Brev en Nebius con una sola GPU NVIDIA L40S repartida entre tres equipos:
- Una NVIDIA L40S con 48 GB de VRAM, 40 vCPU, 160 GiB de RAM y 256 GiB de disco.
- Ubuntu 24.04.4 LTS.
- MicroK8s v1.36.2, con el complemento de GPU que preinstala el NVIDIA GPU Operator.
- KAI Scheduler v0.16.4.
- vCluster CLI 0.35.1.
El procedimiento funciona igual en un cluster mayor, con cientos de nodos de GPU y decenas de equipos: se escalan el conjunto de nodos, la jerarquía de colas y la cantidad de clusters inquilinos. Desde el paso de instalación de KAI Scheduler en adelante, los comandos son idénticos en cualquier Kubernetes que tenga corriendo el NVIDIA GPU Operator con la Container Device Interface (CDI) habilitada. Los pasos previos de creación del cluster e instalación del operador sí cambian según se trate de GKE, EKS, AKS, Kubernetes puro o k3s.
Instalación de KAI Scheduler
Tras agregar el repositorio de Helm de NVIDIA y confirmar que el GPU Operator está operativo, la instalación del planificador es una sola línea:
helm upgrade -i kai-scheduler \
oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler \
-n kai-scheduler --create-namespace \
--version v0.16.4 \
--set "global.gpuSharing=true"El despliegue levanta siete pods en el espacio de nombres kai-scheduler, entre ellos el controlador de colas, el agrupador de pods y el enlazador.
¿Cómo se reparte la GPU entre equipos?
Acá está el corazón del patrón. KAI Scheduler usa un CRD de tipo Queue para modelar la jerarquía organización a equipo. Se crea una cola padre, ml-org, con un presupuesto total de una GPU, y tres colas hijas. Cada una tiene garantizado 0,33 de la GPU y puede crecer hasta la GPU completa cuando las demás están ociosas.
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: ml-org
spec:
resources:
gpu: { quota: 1, limit: -1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: team-nlp
spec:
parentQueue: ml-org
priority: 100
resources:
gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }Los tres parámetros que definen el comportamiento son directos: quota es el mínimo garantizado, limit es el máximo permitido y overQuotaWeight controla cómo se reparte el excedente. Las colas de los equipos de visión y de recomendación se declaran igual que la de lenguaje natural, cambiando solo el nombre.
| Cola | Cuota garantizada | Límite máximo | Prioridad |
|---|---|---|---|
| ml-org (padre) | 1 GPU | Sin límite | Sin definir |
| team-nlp | 0,33 GPU | 1 GPU | 100 |
| team-vision | 0,33 GPU | 1 GPU | 100 |
| team-recommender | 0,33 GPU | 1 GPU | 100 |
Ese diseño habilita los dos modelos de consumo que interesan en la práctica: uso compartido estable, donde cada equipo se mantiene dentro de su tercio, y uso en ráfaga, donde un equipo toma la GPU completa mientras los otros no la están usando. Nadie queda bloqueado por capacidad reservada y ociosa, que es el desperdicio clásico de las particiones rígidas de hardware.
¿Por qué importa este patrón?
La combinación resuelve un problema de costos que se vuelve concreto apenas la infraestructura de GPU deja de ser trivial. En Chile y la región, donde el acceso a GPU de centro de datos suele pasar por arriendo por hora o por instancias reservadas en la nube, partir físicamente el hardware para dar autonomía a tres equipos significa pagar tres veces por capacidad que la mayor parte del tiempo estará ociosa. El patrón de NVIDIA apunta exactamente ahí: máxima eficiencia de infraestructura sin sacrificar la separación lógica entre equipos.
El recorrido completo del tutorial, con todos los pasos de verificación, está disponible en el blog de desarrolladores de NVIDIA.
