> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Intégrer les bacs à sable au SUNK Pod Scheduler

> Acheminez les pods de sandbox via le SUNK Pod Scheduler afin que Slurm les place aux côtés de vos tâches Slurm.

Acheminez les pods de sandbox exclusivement CPU via le SUNK Pod Scheduler afin que Slurm gère leur placement aux côtés des tâches Slurm exécutées dans votre cluster. Les bacs à sable deviennent des tâches Slurm ordinaires et peuvent s’exécuter sur n’importe quel nœud du cluster disposant de ressources libres, y compris en partageant des ressources CPU avec d’autres tâches Slurm ou bacs à sable déjà en cours d’exécution sur ce même nœud.

La politique d’un exécuteur définit l’ordonnanceur SUNK pour chaque sandbox placée sur cet exécuteur. Les clients sélectionnent l’exécuteur au moyen du placement CoreWeave Kubernetes Service (CKS). Ce guide s’adresse aux opérateurs de cluster chargés de configurer la politique ainsi qu’aux auteurs de charges de travail qui lancent des bacs à sable.

<Info>
  **Prise en charge limitée au CPU**

  Les bacs à sable GPU sont en préversion privée et ne sont pas encore pris en charge par l’intégration au SUNK Pod Scheduler. Consultez [Bacs à sable GPU](/fr/products/sandboxes/gpu-sandboxes) pour connaître les options de placement prises en charge et savoir comment demander l’accès.

  Les bacs à sable exclusivement CPU peuvent être placés sur des nœuds CPU inactifs, partager des nœuds CPU avec d’autres bacs à sable ou tâches Slurm, et partager des ressources CPU sur des nœuds GPU où s’exécutent d’autres charges de travail. Consultez [Limitations connues](/products/sunk/run_workloads/schedule-kubernetes-pods#known-limitations) pour plus de détails.
</Info>

<h2 id="prerequisites">
  Prérequis
</h2>

* Un cluster CKS sur lequel [SUNK](/products/sunk) est déployé et le [SUNK Pod Scheduler](/products/sunk/run_workloads/schedule-kubernetes-pods) activé.
* Un [exécuteur de sandbox CoreWeave déployé sur le même cluster](/fr/products/sandboxes/operations/managed-runners).
* La [CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) (`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](/fr/products/sandboxes/operations/managed-runners).
* 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`.

Sur l’ensemble de cette page, remplacez `[RUNNER-ID]` par l’ID de l’exécuteur de votre cluster SUNK.

<h2 id="step-1-verify-the-sunk-pod-scheduler">
  Étape 1 : Vérifier le SUNK Pod Scheduler
</h2>

Vérifiez que votre déploiement SUNK est configuré pour fonctionner avec les bacs à sable CoreWeave.

1. Vérifiez que l’ordonnanceur est en cours d’exécution :

   ```bash theme={"system"}
   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](/products/sunk/run_workloads/schedule-kubernetes-pods#enable-the-scheduler).

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 :

   ```bash theme={"system"}
   kubectl get configmap -n tenant-slurm -l app.kubernetes.io/component=scheduler \
     -o jsonpath='{.items[0].data.scheduler\.conf}' | yq '.scheduler.name'
   ```

   ```text theme={"system"}
   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](/products/sunk/run_workloads/schedule-kubernetes-pods#look-up-the-scheduler-configuration).

3. Récupérez la valeur de `KillWait`. Elle vous servira à vérifier l’arrêt des Pods :

   ```bash theme={"system"}
   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 :

   ```text theme={"system"}
   - --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 :

   ```yaml theme={"system"}
   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](/products/sunk/reference/slurm-parameters#slurmConfig) et [Définir le délai de grâce d’arrêt](/products/sunk/run_workloads/schedule-kubernetes-pods#set-the-termination-grace-period).

   <Warning>
     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.
   </Warning>

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](/products/sunk/run_workloads/schedule-kubernetes-pods#enable-the-scheduler).

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](/products/sunk/run_workloads/manage-scheduler-resources).

<h2 id="step-2-configure-the-runner-policy">
  Étape 2 : configurer la politique de l’exécuteur
</h2>

Chaque exécuteur possède une seule politique. Définissez `base.spec.schedulerName` dans cette politique pour acheminer ses Pods de sandbox via SUNK. Vous n'avez pas à créer ni à lier de ressource de politique distincte.

<Warning>
  Toute mise à jour de la politique remplace l'intégralité du document de politique. Lisez la politique actuelle, conservez ses éléments `base` joints et ses `constraints` existants, et ne modifiez que les paramètres nécessaires pour SUNK. Cette modification s'applique aux nouveaux bacs à sable de l'exécuteur. Elle ne déplace pas les bacs à sable en cours d'exécution.
</Warning>

Fusionnez le fragment suivant dans la politique existante de l'exécuteur. Remplacez `slurm-scheduler` par le nom de l'ordonnanceur obtenu à l'étape 1 :

```yaml theme={"system"}
base:
  spec:
    schedulerName: "slurm-scheduler"
```

<Tabs>
  <Tab title="CLI">
    Lisez la politique actuelle, puis ouvrez-la dans `$EDITOR` :

    ```bash theme={"system"}
    cwic sandbox runner policy get [RUNNER-ID]
    cwic sandbox runner policy edit [RUNNER-ID]
    ```

    Ajoutez `schedulerName` sous `base.spec` sans modifier le reste du document. Enregistrez et fermez l’éditeur pour appliquer la politique.

    Si vous gérez la politique complète dans un fichier, validez puis appliquez ce fichier :

    ```bash theme={"system"}
    cwic sandbox runner policy validate -f slurm-policy.yaml
    cwic sandbox runner policy edit [RUNNER-ID] -f slurm-policy.yaml
    ```
  </Tab>

  <Tab title="curl">
    Utilisez l’API HTTP Connect pour lire l’exécuteur, y compris la révision de sa politique (`etag`) :

    ```bash theme={"system"}
    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
    ```

    Si l’exécuteur n’a pas de politique, configurez-en une en suivant [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure) avant de continuer.

    Ajoutez le nom de l’ordonnanceur en conservant tous les autres champs de la politique. Incluez dans la requête de mise à jour l’`etag` obtenu lors de la lecture :

    ```bash theme={"system"}
    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
    ```

    Vérifiez le fichier `runner-policy-update.json`, puis appliquez-le :

    ```bash theme={"system"}
    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
    ```

    Toute requête sans `etag` est rejetée. Si un autre administrateur met à jour la politique avant que vous ne soumettiez la vôtre, l’`etag` obsolète fait échouer la mise à jour avec `FAILED_PRECONDITION` et aucune modification n’est appliquée. Relisez l’exécuteur, réappliquez vos modifications à la politique renvoyée, puis soumettez-la à nouveau avec le nouvel `etag`.
  </Tab>
</Tabs>

<Warning>
  Évitez `base.spec.nodeSelector` et les restrictions de type d’instance de sandbox qui entrent en conflit avec le placement Slurm. C’est Slurm qui choisit le nœud : un sélecteur Kubernetes contradictoire peut provoquer des échecs `NodeAffinity`. Pour cibler des nœuds, utilisez des partitions ou des contraintes Slurm au moyen des annotations de l’étape 4.
</Warning>

L’accès réseau est régi par le champ `constraints.network` et par le trafic sortant déclaré par la sandbox. Conservez les contraintes réseau existantes de l’exécuteur lorsque vous ajoutez l’ordonnancement SUNK. Voir [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure#constrain-network-access).

Les modifications de politique peuvent mettre un certain temps à s’appliquer à la création des sandboxes. Avant de vous fier à un nouvel ordonnanceur ou à une annotation épinglée, créez une sandbox et vérifiez les champs de son Pod comme décrit dans [Les pods restent en attente](#pods-remain-pending). La lecture de la politique peut afficher la nouvelle valeur avant que les nouvelles sandboxes ne l’utilisent.

Pour le schéma complet, voir [Référence de la politique](/fr/products/sandboxes/reference/profile). Pour la configuration de l’exécuteur, voir [Déployer et gérer un runner](/fr/products/sandboxes/operations/managed-runners).

<h2 id="step-3-create-sandboxes">
  Étape 3 : créer des bacs à sable
</h2>

Définissez `placement_mode="cks"` et `runner_ids` pour sélectionner l’exécuteur dont vous avez configuré la politique. La politique de l’exécuteur fournit automatiquement l’ordonnanceur.

```python theme={"system"}
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)
```

Pour vérifier que la sandbox s’exécute en tant que tâche Slurm, recherchez sa tâche de substitution dans Slurm à l’aide de l’ID de la sandbox affiché dans l’exemple précédent :

```bash theme={"system"}
sacct --format=JobID,JobName%60,State,NodeList -X | grep [SANDBOX-ID]
```

Slurm choisit le nœud. Vous ne contrôlez pas le nœud sur lequel la sandbox est placée, sauf si vous ajoutez des [annotations Slurm](#step-4-control-placement-with-slurm-annotations) pour orienter l'ordonnanceur de Slurm.

Pour utiliser le même exécuteur configuré pour SUNK pour toutes les sandboxes d'une session, définissez les champs de placement dans `SandboxDefaults` :

```python theme={"system"}
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()}")
```

<h3 id="resource-requests-and-slurm-accounting">
  Demandes de ressources et comptabilité Slurm
</h3>

SUNK lit les **demandes de ressources** (et non les limites) du pod et les convertit en paramètres de tâche Slurm :

| Champ du pod | Paramètre Slurm |
| - | - |
| `requests.cpu` | `CPUsPerTask` |
| `requests.memory` | `MinMemoryNode` |

Slurm utilise ces valeurs pour les décisions d’ordonnancement et pour la comptabilité `sacct`. SUNK n’exige aucune classe de Qualité de service particulière : les classes Guaranteed (demandes égales aux limites) et Burstable (demandes inférieures aux limites) fonctionnent toutes les deux.

Si vous définissez avec `ResourceOptions` des demandes inférieures aux limites, le pod peut monter jusqu’à ses limites lorsque de la capacité se libère, mais Slurm ne voit que les demandes. Par exemple, une sandbox configurée avec :

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

apparaît dans `sacct` comme une tâche de 500m de CPU et 512Mi de mémoire, même si le sandbox peut utiliser jusqu'à 2 CPU et 2Gi lorsque le nœud a de la capacité libre. Pour la référence complète de `ResourceOptions`, voir [Ressources](/fr/products/sandboxes/client/guides/sandbox-configuration#resources).

Dimensionnez les demandes de ressources en fonction des besoins des charges de travail de vos sandbox, tout en laissant suffisamment de place sur les nœuds cibles pour les demandes de ressources de `slurmd` que vous avez réduites à l'étape 1. Pour connaître les règles sous-jacentes, voir [Définir les demandes de ressources](/products/sunk/run_workloads/schedule-kubernetes-pods#set-resource-requests) et [Gérer les ressources avec le SUNK Pod Scheduler](/products/sunk/run_workloads/manage-scheduler-resources).

<h2 id="step-4-control-placement-with-slurm-annotations">
  Étape 4 : contrôler le placement avec des annotations Slurm
</h2>

Pour contrôler le placement de la sandbox, définissez des annotations SUNK sur la sandbox lors de son lancement. L’exemple suivant force l’exécution de la sandbox sur la partition `hpc-prod` :

```python theme={"system"}
from cwsandbox import Sandbox

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

<h3 id="common-annotations">
  Annotations courantes
</h3>

Toutes les annotations partagent le préfixe `sunk.coreweave.com/`. Les annotations couramment utilisées pour contrôler le placement des sandboxes sont les suivantes :

| Clé d’annotation | Description |
| - | - |
| `partition` | Nom de la partition Slurm |
| `constraint` | Contrainte de fonctionnalité Slurm |
| `account` | Nom du compte de comptabilisation Slurm |
| `qos` | Niveau de QoS Slurm |
| `user-id` | ID utilisateur Slurm pour la comptabilisation. Doit être un UID Linux numérique (par exemple `"1000"`) |
| `exclusive` | Exclusivité du nœud (`none`, `user` ou `ok`) |

Si vous transmettez un nom d’utilisateur au lieu d’un UID numérique à l’annotation `user-id`, une erreur bloquante empêche Slurm d’ordonnancer la sandbox. Pour trouver l’UID numérique depuis un nœud de connexion Slurm, remplacez `[USERNAME]` par le nom d’utilisateur Linux à rechercher :

```bash theme={"system"}
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
```

Pour la liste complète, consultez [Référence des annotations](/products/sunk/run_workloads/schedule-kubernetes-pods#annotations-reference).

<h3 id="enforce-annotations-in-the-policy">
  Appliquer les annotations dans la politique
</h3>

Pour définir un paramètre de tâche Slurm pour chaque sandbox de l’exécuteur, ajoutez l’annotation correspondante à `base.metadata.annotations`. Par exemple, pour utiliser la partition `sandboxes`, fusionnez ce fragment dans la politique existante :

```yaml theme={"system"}
base:
  metadata:
    annotations:
      sunk.coreweave.com/partition: "sandboxes"
  spec:
    schedulerName: "slurm-scheduler"
```

Les annotations de la politique prévalent sur les valeurs fournies par le client pour une même clé. Pour permettre aux clients de choisir une valeur, retirez cette clé de `base.metadata.annotations` et vérifiez que `constraints.metadata.denied_annotation_prefixes` l’autorise. Par exemple, ne fixez pas `sunk.coreweave.com/user-id` lorsque les clients doivent faire correspondre la valeur à l’utilisateur d’une tâche d’entraînement.

<h3 id="match-the-slurm-user-from-a-training-job">
  Faire correspondre l’utilisateur Slurm d’une tâche d’entraînement
</h3>

Les tâches d’entraînement s’exécutent souvent avec `--exclusive=user` afin de réserver des nœuds entiers à un seul utilisateur. Les tâches des autres utilisateurs ne peuvent ainsi pas entrer en concurrence pour les ressources de ces nœuds, tandis que le même utilisateur peut toujours y exécuter d’autres tâches, par exemple des bacs à sable qui exploitent le CPU inutilisé en parallèle de l’entraînement sur GPU.

Par défaut, les tâches de substitution SUNK s’exécutent en tant que root (UID 0). Comme root n’est pas l’utilisateur qui a soumis la tâche d’entraînement, Slurm ne place pas la tâche de substitution de la sandbox sur le nœud exclusif.

Lorsque le code d’entraînement utilise le client Python `cwsandbox` pour créer des bacs à sable depuis une tâche Slurm en cours d’exécution, il peut lire l’ID utilisateur Slurm de la tâche dans l’environnement et le transmettre sous forme d’annotation. Les tâches de substitution de la sandbox sont alors soumises sous le même utilisateur Slurm que la tâche d’entraînement, ce qui permet à Slurm de les placer sur les mêmes nœuds exclusifs :

```python theme={"system"}
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)
```

L’annotation `user-id` doit être un UID Linux numérique, et non un nom d’utilisateur. Lorsqu’elle est définie, SUNK attribue également par défaut cette même valeur à `group-id`. Si l’ID de groupe est différent, définissez `sunk.coreweave.com/group-id` séparément.

<h2 id="troubleshooting">
  Dépannage
</h2>

Les sections suivantes vous aident à diagnostiquer les problèmes courants lors de l’exécution de bacs à sable via le SUNK Pod Scheduler.

<h3 id="pods-remain-pending">
  Les pods restent en attente
</h3>

Inspectez le Pod de la sandbox pour vérifier que l’exécuteur a bien appliqué le nom de l’ordonnanceur, et pour contrôler son délai de grâce avant arrêt :

```bash theme={"system"}
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'
```

Exécutez cette commande pendant que la sandbox est active. Vérifiez que `SCHEDULER` correspond à l’ordonnanceur SUNK, que sa portée inclut `NAMESPACE` et que `GRACE` est strictement inférieur au délai d’attente avant arrêt forcé (kill wait) de l’ordonnanceur, moins 5 secondes. Un délai de grâce de 30 secondes échoue avec le délai d’attente avant arrêt forcé par défaut, qui est de 30 secondes. Si la politique impose une partition, vérifiez que `PARTITION` y correspond.

Si le nom de l’ordonnanceur ou les annotations imposées sont manquants ou incorrects, relisez la politique de l’exécuteur et vérifiez que le client a sélectionné l’exécuteur prévu. Si les Pods nouvellement créés utilisent encore les anciennes valeurs, laissez à la politique le temps de se propager, puis faites une nouvelle tentative avec une autre sandbox.

<h3 id="placeholder-jobs-temporarily-in-completing-state">
  Tâches de substitution temporairement à l’état « completing »
</h3>

Lorsqu’une sandbox s’arrête, sa tâche de substitution Slurm reste 30 à 60 secondes à l’état `CG` (completing), le temps que les scripts de nettoyage s’exécutent et que le nœud soit restitué au pool. Il s’agit du comportement normal de Slurm, qui n’affecte pas les autres tâches exécutées sur le même nœud. Consultez [Slurm job states](/products/sunk/manage_sunk/slurm-job-states) pour la référence complète des états.

<h3 id="sandboxes-not-landing-where-expected">
  Les bacs à sable ne sont pas placés à l'endroit prévu
</h3>

Slurm détermine le placement des sandbox en fonction des annotations définies par la politique ou transmises par le client. Si les bacs à sable ne sont pas placés sur les nœuds prévus, vérifiez les paramètres de la tâche Slurm.

Pour chaque pod de sandbox, SUNK crée une tâche Slurm de substitution nommée `<namespace>/<pod-name>`. Le nom du pod contient l'ID de la sandbox, disponible côté client via `sb.sandbox_id`. Pour trouver la tâche de substitution et inspecter ses paramètres, lancez une recherche sur l'ID de la sandbox :

```bash theme={"system"}
sacct --format=JobID,JobName%60,Partition,Account,AllocCPUS,ReqMem,State,NodeList,Start,End -X \
  | grep [SANDBOX-ID]
```

Remplacez `[SANDBOX-ID]` par la valeur de `sb.sandbox_id` fournie par le client Python.

<h2 id="see-also">
  Voir aussi
</h2>

* [À propos des bacs à sable CoreWeave](/fr/products/sandboxes)
* [Déployer et gérer un runner](/fr/products/sandboxes/operations/managed-runners)
* [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure)
* [Planifier des pods Kubernetes avec le SUNK Pod Scheduler](/products/sunk/run_workloads/schedule-kubernetes-pods)
* [Entraînement RL avec des bacs à sable](/fr/products/sandboxes/client/guides/rl-training)
* [Configuration du bac à sable](/fr/products/sandboxes/client/guides/sandbox-configuration)