> ## 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.
# Configurer les budgets d’allocation des Nœuds
> Limiter les demandes de CPU et de mémoire des bacs à sable sur l’ensemble des Nœuds, sur certains Node Pools ou sur des groupes de 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é](/fr/products/sandboxes/operations/managed-runners#trigger-an-on-demand-runner-update) et attendez que le runner soit prêt et connecté.
* Utilisez [CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) 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 :
```bash theme={"system"}
cwic sandbox runner get
```
Facultatif : filtrez par cluster. Remplacez `[CLUSTER-ID]` par l’ID de votre cluster CoreWeave Kubernetes Service (CKS) :
```bash theme={"system"}
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 :
```bash theme={"system"}
export RUNNER_ID="[RUNNER-ID]"
export KUBE_CONTEXT="[KUBE-CONTEXT]"
```
Inspectez les libellés du Node Pool et du nom d’hôte :
```bash theme={"system"}
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.
```json theme={"system"}
{
"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 :
```json theme={"system"}
{
"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 :
```bash theme={"system"}
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](#different-budgets-for-node-pools-and-custom-groups).
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.
```json theme={"system"}
{
"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 :
```json theme={"system"}
{
"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 :
```text theme={"system"}
spec.overrides.env.SANDBOX_NODE_BUDGET_CONFIG
```
Sélectionnez le fichier de configuration à appliquer :
```bash theme={"system"}
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 :
```bash theme={"system"}
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 :
```bash theme={"system"}
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 :
```text theme={"system"}
sandbox.coreweave.com/cpu-millicores
sandbox.coreweave.com/memory-bytes
```
Vérifiez leurs valeurs de capacité et de ressources allouables :
```bash theme={"system"}
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 :
```text theme={"system"}
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 :
```bash theme={"system"}
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](#apply-the-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 :
1. Créez une petite sandbox sur chaque exécuteur.
2. Vérifiez que les demandes de ressources de son Pod incluent les deux ressources de budget.
3. 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é.
4. Supprimez les bacs à sable de test.
Le motif d’épuisement de capacité suivant est attendu :
```text theme={"system"}
CWSANDBOX_RUNNER_CAPACITY_EXHAUSTED
```
Si le runner est géré par Terraform, fusionnez le paramètre `spec.overrides.env` suivant dans sa ressource `coreweave_sandbox_managed_runner` existante :
```hcl theme={"system"}
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 :
1. Isolez (cordon) les Nœuds concernés.
2. Appliquez la configuration mise à jour à chaque exécuteur de ce cluster.
3. Attendez la convergence du budget.
4. 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 :
```text theme={"system"}
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 :
* [Déployer et gérer un runner](/fr/products/sandboxes/operations/managed-runners).
* [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure).