Configurer les budgets d’allocation des Nœuds

Les budgets d’allocation des Nœuds déterminent la part du CPU et de la mémoire allouables de chaque Nœud que les bacs à sable peuvent demander. Ce guide explique aux administrateurs de cluster comment configurer et activer des budgets pour l’ensemble des Nœuds, pour certains Node Pools ou pour des groupes de Nœuds. Prenons l’exemple d’un Nœud qui dispose de 32 CPU et de 128 GiB de mémoire allouables. Avec un budget de 50 %, les demandes cumulées des bacs à sable peuvent atteindre 16 CPU et 64 GiB. Les pourcentages s’appliquent aux demandes de ressources, et non à l’utilisation mesurée. La réduction d’un budget n’entraîne pas l’éviction des bacs à sable existants.

Avant de commencer

Avant de configurer les budgets, remplissez les prérequis suivants :

Vérifiez auprès de CoreWeave que la prise en charge des budgets d’allocation de Nœud et les autorisations requises sont activées pour votre cluster.
Appliquez toute mise à jour requise du runner géré et attendez que le runner soit prêt et connecté.
Utilisez CoreWeave Intelligent CLI v1.44.0 ou une version ultérieure, authentifié auprès de la bonne organisation avec des autorisations d’administrateur Sandbox.
Installez jq.
Disposez d’un accès Kubernetes permettant d’inspecter les libellés des Nœuds et les budgets publiés. Pour réduire un budget, vous devez également disposer de l’autorisation de marquer les Nœuds concernés comme non planifiables (cordon), puis de les rétablir (uncordon).
Utilisez l’ordonnanceur Kubernetes par défaut, ou vérifiez que votre ordonnanceur applique les ressources étendues de budget.
Si les bacs à sable sélectionnent une RuntimeClass, vérifiez auprès de l’administrateur de votre cluster qu’elle déclare une map overhead.podFixed non vide. Un runtime sans surcharge doit déclarer explicitement des valeurs nulles. Ce paramètre n’est pas nécessaire pour les bacs à sable sans RuntimeClass.

CoreWeave Intelligent CLI v1.44.0 prend en charge le flux de travail reposant uniquement sur l’environnement décrit dans ce guide. Une mise à jour du runner n’active les budgets qu’une fois la configuration appliquée. Tous les runners logiques qui partagent le même cluster Kubernetes physique doivent utiliser la même configuration et le même mode de budget. Des clusters distincts peuvent utiliser des configurations différentes.

Identifier l’exécuteur et les libellés de Nœud

Identifiez l’exécuteur à mettre à jour ainsi que les libellés de Nœud à utiliser dans vos sélecteurs de budget. Listez les exécuteurs disponibles :

cwic sandbox runner get

Facultatif : filtrez par cluster. Remplacez [CLUSTER-ID] par l’ID de votre cluster CoreWeave Kubernetes Service (CKS) :

cwic sandbox runner get --cluster "[CLUSTER-ID]"

Choisissez l’exécuteur et le contexte Kubernetes. Remplacez [RUNNER-ID] par l’identifiant de l’exécuteur et [KUBE-CONTEXT] par son contexte Kubernetes :

export RUNNER_ID="[RUNNER-ID]"
export KUBE_CONTEXT="[KUBE-CONTEXT]"

Inspectez les libellés du Node Pool et du nom d’hôte :

kubectl --context "$KUBE_CONTEXT" get nodes \
  -L compute.coreweave.com/node-pool,kubernetes.io/hostname

Les Nœuds CKS peuvent exposer les libellés suivants :

Libellé	Utilité
`compute.coreweave.com/node-pool`	Sélectionner des Nœuds selon le nom du Node Pool
`compute.coreweave.com/node-pool-uid`	Sélectionner un Node Pool précis par son identité
`kubernetes.io/hostname`	Sélectionner des Nœuds individuels
Un libellé personnalisé	Sélectionner un groupe quelconque de Nœuds

Utilisez les clés et les valeurs de libellés présentes dans votre cluster. Un sélecteur de budget sélectionne des Nœuds Kubernetes. Il ne sélectionne pas les groupes d’exécuteurs d’API et ne remplace ni les contraintes de placement des sandboxes, ni les taints, ni les tolérances, ni les RuntimeClasses.

Créer une configuration de budget

Enregistrez l’un des exemples suivants dans le fichier node-budget.json. Commencez par "mode": "prepare". La préparation publie les ressources de budget. L’application est activée lors d’une étape ultérieure.

95 % du CPU et de la mémoire sur chaque nœud

Un sélecteur vide correspond à tous les nœuds.

{
  "version": 1,
  "mode": "prepare",
  "managedNodes": {
    "selector": {},
    "defaultBudget": {
      "cpuPercent": 95,
      "memoryPercent": 95
    }
  }
}

Les deux pourcentages sont requis et doivent être des entiers compris entre 0 et 100. Une valeur de 0 correspond à une capacité de sandbox nulle.

50 % uniquement sur certains Node Pools

Cette configuration sélectionne les Nœuds de l’un ou l’autre de deux Node Pools. Remplacez [BATCH-POOL] et [INTERACTIVE-POOL] par les valeurs de label de ces Node Pools :

{
  "version": 1,
  "mode": "prepare",
  "managedNodes": {
    "selector": {
      "matchExpressions": [
        {
          "key": "compute.coreweave.com/node-pool",
          "operator": "In",
          "values": [
            "[BATCH-POOL]",
            "[INTERACTIVE-POOL]"
          ]
        }
      ]
    },
    "defaultBudget": {
      "cpuPercent": 50,
      "memoryPercent": 50
    }
  }
}

Les Nœuds situés en dehors de managedNodes.selector reçoivent un budget de sandbox nul. Une fois l’application activée, les bacs à sable qui nécessitent des jetons de budget ne peuvent plus utiliser ces Nœuds. Prévisualisez la sélection :

kubectl --context "$KUBE_CONTEXT" get nodes \
  -l 'compute.coreweave.com/node-pool in ([BATCH-POOL],[INTERACTIVE-POOL])'

Pour préserver la capacité des sandboxes sur les autres Nœuds, utilisez les remplacements par Node Pool et par groupe.

Budgets différents pour les Node Pools et les groupes personnalisés

Cette configuration définit les budgets suivants :

95 % du CPU et de la mémoire par défaut.
50 % du CPU et de la mémoire pour les Nœuds du Node Pool [CPU-POOL].
25 % du CPU et 40 % de la mémoire pour les Nœuds portant le label [BUDGET-GROUP-LABEL]=[TRAINING-GROUP].

Remplacez [CPU-POOL] par la valeur du label du Node Pool. Remplacez [BUDGET-GROUP-LABEL] par une clé de label personnalisée et [TRAINING-GROUP] par sa valeur.

{
  "version": 1,
  "mode": "prepare",
  "managedNodes": {
    "selector": {},
    "defaultBudget": {
      "cpuPercent": 95,
      "memoryPercent": 95
    },
    "overrides": [
      {
        "name": "shared-cpu",
        "selector": {
          "matchLabels": {
            "compute.coreweave.com/node-pool": "[CPU-POOL]"
          }
        },
        "budget": {
          "cpuPercent": 50,
          "memoryPercent": 50
        }
      },
      {
        "name": "training",
        "selector": {
          "matchLabels": {
            "[BUDGET-GROUP-LABEL]": "[TRAINING-GROUP]"
          }
        },
        "budget": {
          "cpuPercent": 25,
          "memoryPercent": 40
        }
      }
    ]
  }
}

Les sélecteurs se comportent comme suit :

Un remplacement correspondant remplace les pourcentages par défaut.
Si plusieurs remplacements correspondent, le pourcentage minimum de chaque dimension l’emporte.
L’ordre des règles n’établit aucune priorité.
Tout chevauchement est signalé par selector_conflict. Privilégiez des groupes disjoints si le chevauchement n’est pas voulu.
Les entrées de matchLabels et les expressions distinctes doivent toutes correspondre.
Les valeurs d’une même expression In sont des alternatives.

Dans cet exemple, un nœud correspondant aux deux remplacements se voit attribuer 25 % de CPU et 40 % de mémoire. Pour les groupes personnalisés, configurez si possible les libellés dans la configuration de votre Node Pool, afin que les nœuds de remplacement en héritent.

50 % sur des nœuds spécifiques

Remplacez [HOSTNAME-A] et [HOSTNAME-B] par les valeurs de l’étiquette kubernetes.io/hostname relevées sur les nœuds que vous souhaitez sélectionner :

{
  "version": 1,
  "mode": "prepare",
  "managedNodes": {
    "selector": {
      "matchExpressions": [
        {
          "key": "kubernetes.io/hostname",
          "operator": "In",
          "values": [
            "[HOSTNAME-A]",
            "[HOSTNAME-B]"
          ]
        }
      ]
    },
    "defaultBudget": {
      "cpuPercent": 50,
      "memoryPercent": 50
    }
  }
}

Les valeurs du label de nom d’hôte peuvent différer des noms des objets Nœud. Les autres Nœuds ne reçoivent aucun budget de sandbox. Privilégiez les sélecteurs de Node Pool ou de groupe personnalisé si les Nœuds de remplacement doivent hériter automatiquement de la configuration.

Appliquer la configuration

Stockez la configuration sous forme de string JavaScript Object Notation (JSON) dans le champ suivant :

spec.overrides.env.SANDBOX_NODE_BUDGET_CONFIG

Sélectionnez le fichier de configuration à appliquer :

export BUDGET_FILE=node-budget.json

Les commandes suivantes lisent l’exécuteur actuel et conservent ses champs de remplacement de déploiement et ses variables d’environnement existants. Vous n’avez besoin ni de la configuration d’origine de l’exécuteur ni du fichier de politique. Pour appliquer une autre configuration, modifiez BUDGET_FILE, puis réutilisez ce bloc :

umask 077

# cwic renvoie un tableau, même lorsque vous récupérez un seul exécuteur.
cwic sandbox runner get "$RUNNER_ID" -o json > current-runner.json

jq --slurpfile budget "$BUDGET_FILE" '
  if length != 1 then
    error("expected one runner")
  else
    .[0]
  end |
  {
    spec: {
      overrides: (
        (.spec.overrides // {}) |
        .env = (
          (.env // {}) + {
            SANDBOX_NODE_BUDGET_CONFIG: ($budget[0] | tojson)
          }
        )
      )
    }
  }
' current-runner.json > node-budget-patch.json

cwic sandbox runner edit "$RUNNER_ID" -f node-budget-patch.json
cwic sandbox runner describe "$RUNNER_ID"

Répétez cette procédure pour chaque exécuteur logique du même cluster physique. Lisez chaque exécuteur avant de construire son patch. spec.overrides est remplacé en tant qu’objet entier : vous devez donc conserver les champs situés au même niveau. Pour CoreWeave Intelligent CLI v1.44.0, utilisez ce patch limité à l’environnement. L’ancien schéma de politique de cette version ne permet pas d’exporter intégralement les champs de nom d’hôte HTTPS renommés depuis les serveurs plus récents. Si vous réappliquez un document d’exécuteur complet, vous risquez donc de remplacer sa politique par des données incomplètes. Le patch précédent n’inclut ni ne modifie la politique. Gardez les exports d’exécuteur privés et supprimez ensuite les fichiers temporaires :

rm current-runner.json node-budget-patch.json

Vérifier la préparation

La préparation publie les ressources étendues suivantes dans le statut du nœud :

sandbox.coreweave.com/cpu-millicores
sandbox.coreweave.com/memory-bytes

Vérifiez leurs valeurs de capacité et de ressources allouables :

kubectl --context "$KUBE_CONTEXT" get nodes -o json | jq '
  .items[] | {
    node: .metadata.name,
    cordoned: (.spec.unschedulable // false),
    physical: {
      cpu: .status.allocatable.cpu,
      memory: .status.allocatable.memory
    },
    budgetCapacity: {
      cpuMillicores:
        .status.capacity["sandbox.coreweave.com/cpu-millicores"],
      memoryBytes:
        .status.capacity["sandbox.coreweave.com/memory-bytes"]
    },
    budgetAllocatable: {
      cpuMillicores:
        .status.allocatable["sandbox.coreweave.com/cpu-millicores"],
      memoryBytes:
        .status.allocatable["sandbox.coreweave.com/memory-bytes"]
    }
  }'

Attendez que les valeurs capacity et allocatable concordent pour les deux ressources du budget sur chaque Nœud. La comptabilisation du budget tient compte des éléments suivants :

Les bacs à sable existants déjà liés et dépourvus de jetons de budget sont déduits du budget publié jusqu’à ce qu’ils se terminent.
D’autres charges de travail consomment des ressources physiques ; la capacité disponible pour les bacs à sable peut donc être inférieure au budget configuré.
La consommation imputée aux bacs à sable inclut les conteneurs auxiliaires, les pics des conteneurs d’initialisation et la surcharge liée à la RuntimeClass.
Les pourcentages de CPU et de mémoire ne servent pas à répartir la capacité GPU.

Lorsque des métriques sont disponibles, vérifiez les métriques suivantes :

sandbox_runner_node_budget_ready
sandbox_runner_node_budget_writer
sandbox_runner_node_budget_nodes{state="converged"}
sandbox_runner_node_budget_policy

La métrique sandbox_runner_node_budget_policy expose les libellés mode et policy_hash. Vérifiez que chaque exécuteur du cluster signale mode="prepare" et une valeur policy_hash identique. Si vous n’avez pas accès à ces métriques, demandez à CoreWeave de vérifier l’état de préparation avant d’activer l’application des budgets.

Activer l’application

Une fois que la préparation est en bon état de santé, modifiez uniquement le mode :

jq '.mode = "enforce"' node-budget.json > node-budget-enforce.json
export BUDGET_FILE=node-budget-enforce.json

Répétez les commandes de lecture, de compilation du patch et d’application décrites dans Appliquer la configuration pour chaque exécuteur du cluster. Utilisez cwic sandbox runner describe "$RUNNER_ID" pour vérifier le déploiement de l’exécuteur, puis demandez à CoreWeave de confirmer que la transition d’admission du cluster est terminée. Cette transition détermine à quel moment le cluster commence à appliquer les budgets. Elle comprend le retrait des anciennes partitions, ainsi que la liaison ou l’arrêt des charges de travail en attente antérieures à l’application des budgets. Pour vérifier l’application des budgets, procédez comme suit :

Créez une petite sandbox sur chaque exécuteur.
Vérifiez que les demandes de ressources de son Pod incluent les deux ressources de budget.
Si vous effectuez un test de saturation contrôlé, vérifiez que les nouvelles allocations sont bloquées dès que le budget CPU ou le budget mémoire est épuisé.
Supprimez les bacs à sable de test.

Le motif d’épuisement de capacité suivant est attendu :

CWSANDBOX_RUNNER_CAPACITY_EXHAUSTED

Configurer les runners gérés par Terraform

Si le runner est géré par Terraform, fusionnez le paramètre spec.overrides.env suivant dans sa ressource coreweave_sandbox_managed_runner existante :

spec = {
  overrides = {
    env = {
      # Conservez les autres variables d’environnement configurées.
      SANDBOX_NODE_BUDGET_CONFIG = file("${path.module}/node-budget.json")
    }

    # Conservez les autres champs overrides configurés.
  }

  # Conservez les autres champs spec configurés.
}

Une fois que la préparation est dans un état sain, remplacez prepare par enforce dans le fichier JSON, puis appliquez la modification Terraform correspondante. Si l’exécuteur est géré par Terraform, effectuez vos modifications dans Terraform afin que les terraform apply ultérieurs conservent la configuration prévue.

Réduire les budgets ou modifier l’appartenance des Nœuds

Les Nœuds ne sont ni isolés (cordon) ni drainés automatiquement. Avant de réduire les pourcentages ou de modifier les sélecteurs ou les libellés d’une manière qui réduit la capacité, effectuez les étapes suivantes :

Isolez (cordon) les Nœuds concernés.
Appliquez la configuration mise à jour à chaque exécuteur de ce cluster.
Attendez la convergence du budget.
Levez l’isolement (uncordon) des seuls Nœuds que vous avez isolés pour cette modification.

L’isolement (cordon) empêche tout nouvel ordonnancement, mais laisse les Pods existants s’exécuter. Les allocations existantes peuvent dépasser le nouveau plafond jusqu’à ce qu’elles se terminent. Une réduction du budget n’entraîne pas leur éviction. Une réduction effectuée sans isolement préalable est journalisée avec le message suivant :

decrease_without_cordon

Pour désactiver complètement les budgets, planifiez la procédure de retrait avec CoreWeave. Supprimer la variable d’environnement ou désactiver directement le gate de fonctionnalité n’exécute pas la séquence de restauration nécessaire.

Voir aussi

Pour plus d’informations, voir les pages suivantes :

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Configurer les budgets d’allocation des Nœuds

Avant de commencer

Identifier l’exécuteur et les libellés de Nœud

Créer une configuration de budget

95 % du CPU et de la mémoire sur chaque nœud

50 % uniquement sur certains Node Pools

Budgets différents pour les Node Pools et les groupes personnalisés

50 % sur des nœuds spécifiques

Appliquer la configuration

Vérifier la préparation

Activer l’application

Configurer les runners gérés par Terraform

Réduire les budgets ou modifier l’appartenance des Nœuds

Voir aussi

​Avant de commencer

​Identifier l’exécuteur et les libellés de Nœud

​Créer une configuration de budget

​95 % du CPU et de la mémoire sur chaque nœud

​50 % uniquement sur certains Node Pools

​Budgets différents pour les Node Pools et les groupes personnalisés

​50 % sur des nœuds spécifiques

​Appliquer la configuration

​Vérifier la préparation

​Activer l’application

​Configurer les runners gérés par Terraform

​Réduire les budgets ou modifier l’appartenance des Nœuds

​Voir aussi

Avant de commencer

Identifier l’exécuteur et les libellés de Nœud

Créer une configuration de budget

95 % du CPU et de la mémoire sur chaque nœud

50 % uniquement sur certains Node Pools

Budgets différents pour les Node Pools et les groupes personnalisés

50 % sur des nœuds spécifiques

Appliquer la configuration

Vérifier la préparation

Activer l’application

Configurer les runners gérés par Terraform

Réduire les budgets ou modifier l’appartenance des Nœuds

Voir aussi