Intégrer les bacs à sable au SUNK Pod Scheduler

​

Prérequis

• Un cluster CKS sur lequel SUNK est déployé et le SUNK Pod Scheduler activé.
• Un exécuteur de sandbox CoreWeave déployé sur le même cluster.
• La CoreWeave Intelligent CLI (cwic) v1.44.0 ou version ultérieure, installée et authentifiée. Pour plus de détails sur la configuration, voir Déployer et gérer un runner.
• Le rôle sandbox_admin, pour consulter et mettre à jour la politique de l’exécuteur, ainsi que l’autorisation de mettre à jour le déploiement Slurm.
• cwsandbox >= 1.0.0, installé et authentifié, pour l’API de sandbox v1.
• kubectl et yq pour l’inspection du cluster. Les exemples HTTP utilisent également curl, jq et un jeton API CoreWeave stocké dans $TOKEN.

​

Étape 1 : Vérifier le SUNK Pod Scheduler

1. Vérifiez que l’ordonnanceur est en cours d’exécution :
   kubectl get pods -n tenant-slurm -l app.kubernetes.io/name=sunk-scheduler
   
   Si aucun pod n’est renvoyé, activez l’ordonnanceur dans vos valeurs Helm Slurm en définissant scheduler.enabled: true. Pour plus de détails, voir Activer l’ordonnanceur.
2. Récupérez le nom de l’ordonnanceur. Vous le définirez dans la politique de l’exécuteur à l’étape 2. À partir de SUNK 8.0, l’ordonnanceur lit son nom dans une ConfigMap :
   kubectl get configmap -n tenant-slurm -l app.kubernetes.io/component=scheduler \
     -o jsonpath='{.items[0].data.scheduler\.conf}' | yq '.scheduler.name'
   
   slurm-scheduler
   
   Sur SUNK 7.x, le nom est plutôt fourni par l’argument --scheduler-name du Pod de l’ordonnanceur. Pour comprendre le fonctionnement sous-jacent, voir Rechercher la configuration de l’ordonnanceur.
3. Récupérez la valeur de KillWait. Elle vous servira à vérifier l’arrêt des Pods :
   kubectl get pods -n tenant-slurm -l app.kubernetes.io/name=sunk-scheduler -o yaml \
     | yq '.items[0].spec.containers[] | select(.name == "scheduler").args'
   
   Repérez --slurm-kill-wait dans la sortie :
   - --slurm-kill-wait=30s
   
4. Configurez la fenêtre d’arrêt de Slurm pour les Pods des bacs à sable. SUNK exige que terminationGracePeriodSeconds soit strictement inférieur à --slurm-kill-wait moins 5 secondes. La politique n’accepte pas base.spec.terminationGracePeriodSeconds. Pour un Pod utilisant le délai de grâce par défaut de Kubernetes (30 secondes), définissez KillWait sur une valeur supérieure à 35 secondes. Par exemple, intégrez ce bloc à vos valeurs Helm Slurm et appliquez la mise à jour via votre processus de déploiement SUNK habituel :
   slurmConfig:
     KillWait: 60
   
   Cette modification s’applique à la fenêtre d’arrêt de Slurm pour toutes les tâches du cluster. À l’aide de la commande précédente, vérifiez que l’ordonnanceur indique désormais --slurm-kill-wait=60s. Voir Paramètres de configuration de Slurm et Définir le délai de grâce d’arrêt.
   Les bacs à sable dotés d’un stockage compatible avec les instantanés peuvent avoir un délai de grâce de Pod de 300 secondes. Une valeur KillWait de 60 secondes ne suffit pas pour ces Pods. Examinez la valeur terminationGracePeriodSeconds du Pod généré et définissez KillWait sur une valeur supérieure à celle-ci plus 5 secondes. Pour 300 secondes, utilisez par exemple 330. Veillez à ce que le paramètre kill-wait de l’ordonnanceur reste aligné sur celui de Slurm.
5. Vérifiez que la portée de l’ordonnanceur couvre les namespace des bacs à sable. La sélection des namespace est gérée par l’exécuteur ; il ne s’agit pas d’un champ de la politique. Définissez scheduler.scope.type: cluster pour surveiller tous les namespace des bacs à sable, y compris ceux créés pour de nouveaux utilisateurs. Si vous utilisez scheduler.scope.type: namespace, incluez chaque namespace de bac à sable dans scheduler.scope.namespaces et mettez la liste à jour à mesure que de nouveaux namespace sont créés. Appliquez les modifications de portée via Helm afin que l’ordonnanceur reçoive également les autorisations RBAC requises dans ces namespace. Voir Activer l’ordonnanceur.
6. Réduisez les demandes de ressources de slurmd sur les NodeSets que vous souhaitez partager avec les bacs à sable. Cette modification s’effectue côté Slurm, dans vos valeurs Helm Slurm, et non dans une configuration de bac à sable. Par défaut, les demandes de ressources des NodeSets consomment la majeure partie de la capacité allouable du nœud dans Kubernetes, ce qui ne laisse aucune place aux pods des bacs à sable. Sans cette modification, les pods des bacs à sable sont rejetés avec des erreurs OutOfMemory ou OutOfcpu. Pour plus de détails sur la configuration, voir Gérer les ressources avec le SUNK Pod Scheduler.

​

Étape 2 : configurer la politique de l’exécuteur

base:
  spec:
    schedulerName: "slurm-scheduler"

cwic sandbox runner policy get [RUNNER-ID]
cwic sandbox runner policy edit [RUNNER-ID]

cwic sandbox runner policy validate -f slurm-policy.yaml
cwic sandbox runner policy edit [RUNNER-ID] -f slurm-policy.yaml

curl --fail-with-body --silent --show-error -X POST \
  'https://api.coreweave.com/coreweave.sandbox.v1.RunnerManagementService/GetManagedRunner' \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Connect-Protocol-Version: 1" \
  --data '{"runnerId": "[RUNNER-ID]"}' \
  -o runner.json

jq -e '
  if .policy == null or .etag == null then
    error("Read a configured runner policy and its etag before updating")
  else . end |
  .policy.base.spec.schedulerName = "slurm-scheduler" |
  {
    runnerId: .identity.runnerId,
    managedRunner: {identity: .identity, policy: .policy, etag: .etag},
    updateMask: "policy"
  }' runner.json > runner-policy-update.json

curl --fail-with-body -X POST \
  'https://api.coreweave.com/coreweave.sandbox.v1.RunnerManagementService/UpdateManagedRunner' \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Connect-Protocol-Version: 1" \
  --data-binary @runner-policy-update.json

​

Étape 3 : créer des bacs à sable

from cwsandbox import Sandbox

with Sandbox.run(placement_mode="cks", runner_ids=["[RUNNER-ID]"]) as sb:
    print(f"Sandbox ID: {sb.sandbox_id}")
    result = sb.exec(["hostname"]).result()
    print(result.stdout)

sacct --format=JobID,JobName%60,State,NodeList -X | grep [SANDBOX-ID]

from cwsandbox import Sandbox, SandboxDefaults

defaults = SandboxDefaults(
    placement_mode="cks",
    runner_ids=("[RUNNER-ID]",),
)

with Sandbox.session(defaults) as session:
    sb1 = session.sandbox()
    sb2 = session.sandbox()

    r1 = sb1.exec(["hostname"]).result()
    r2 = sb2.exec(["hostname"]).result()
    print(f"sb1: {r1.stdout.strip()}, sb2: {r2.stdout.strip()}")

​

Demandes de ressources et comptabilité Slurm

requests={"cpu": "500m", "memory": "512Mi"},
limits={"cpu": "2",     "memory": "2Gi"},

​

Étape 4 : contrôler le placement avec des annotations Slurm

from cwsandbox import Sandbox

sb = Sandbox.run(
    placement_mode="cks",
    runner_ids=["[RUNNER-ID]"],
    annotations={
        "sunk.coreweave.com/partition": "hpc-prod",
    },
)

​

Annotations courantes

id -u           # votre UID
id -u [USERNAME]  # l'UID d'un autre utilisateur
whoami          # vérifiez d'abord votre nom d'utilisateur, si nécessaire

​

Appliquer les annotations dans la politique

base:
  metadata:
    annotations:
      sunk.coreweave.com/partition: "sandboxes"
  spec:
    schedulerName: "slurm-scheduler"

​

Faire correspondre l’utilisateur Slurm d’une tâche d’entraînement

import os
from cwsandbox import Sandbox, SandboxDefaults

slurm_uid = os.environ["SLURM_JOB_UID"]

defaults = SandboxDefaults(
    placement_mode="cks",
    runner_ids=("[RUNNER-ID]",),
    annotations={
        "sunk.coreweave.com/user-id": slurm_uid,
    },
)

with Sandbox.session(defaults) as session:
    sb = session.sandbox()
    result = sb.exec(["hostname"]).result()
    print(result.stdout)

​

Dépannage

​

Les pods restent en attente

kubectl get pods -A -l 'sandbox.coreweave.com/sandbox-id=[SANDBOX-ID]' \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,SCHEDULER:.spec.schedulerName,GRACE:.spec.terminationGracePeriodSeconds,PARTITION:.metadata.annotations.sunk\.coreweave\.com/partition'

​

Tâches de substitution temporairement à l’état « completing »

​

Les bacs à sable ne sont pas placés à l’endroit prévu

sacct --format=JobID,JobName%60,Partition,Account,AllocCPUS,ReqMem,State,NodeList,Start,End -X \
  | grep [SANDBOX-ID]

​

Voir aussi

• À propos des bacs à sable CoreWeave
• Déployer et gérer un runner
• Configurer une politique de sandbox
• Planifier des pods Kubernetes avec le SUNK Pod Scheduler
• Entraînement RL avec des bacs à sable
• Configuration du bac à sable