Skip to main content
ノード割り当て予算は、各ノードの割り当て可能なCPUとメモリのうち、サンドボックスがリクエストできる量を制御します。 このガイドでは、クラスター管理者がすべてのノード、選択したNode Pool、またはノードのグループに対して予算を設定して有効にする方法を説明します。 たとえば、ノードに32の割り当て可能なCPUと128 GiBの割り当て可能なメモリがある場合、50%の予算により、16 CPUと64 GiBの集約サンドボックスリクエストが可能になります。 パーセンテージは、測定された使用率ではなく、リソースリクエストに適用されます。予算が減少しても、既存のサンドボックスは退避されません。

開始前の準備

予算を設定する前に、以下の前提条件を満たしてください:
  • CoreWeave に、ノード割り当て予算サポートと必要な権限がクラスターで有効になっていることを確認します。
  • 必要なマネージドランナー更新を適用する し、ランナーが準備完了して接続されるまで待機します。
  • CoreWeave Intelligent CLI v1.44.0 以降を使用し、正しい組織に認証済みで、サンドボックス管理者権限を持っている必要があります。
  • jq をインストールします。
  • ノードラベルと公開された予算を検査するための Kubernetes アクセスが必要です。予算を減らす前に、影響を受けるノードを cordon/uncordon する権限も必要です。
  • デフォルトの Kubernetes スケジューラーを使用するか、スケジューラーが予算の拡張リソースを強制することを確認します。
  • サンドボックスが RuntimeClass を選択する場合、クラスター管理者に nonempty overhead.podFixed マップを宣言していることを確認します。オーバーヘッドのないランタイムは明示的なゼロ値を宣言する必要があります。RuntimeClass なしのサンドボックスはこの設定を必要としません。
CoreWeave Intelligent CLI v1.44.0 は、このガイドの環境のみのワークフローをサポートします。ランナー更新は、設定を適用するまで予算を有効にしません。 同じ物理 Kubernetes クラスターを共有するすべての論理ランナーは、同じ予算設定とモードを使用する必要があります。別々のクラスターは異なる設定を使用できます。

ランナーとノードのラベルを特定する

更新するランナーと、予算セレクターで使用するノードのラベルを特定します。 利用可能なランナーを一覧表示します。
オプション: クラスターでフィルタリングします。[CLUSTER-ID] を CoreWeave Kubernetes Service (CKS) のクラスター ID に置き換えてください。
ランナーと Kubernetes コンテキストを選択します。[RUNNER-ID] をランナー ID に、[KUBE-CONTEXT] をその Kubernetes コンテキストに置き換えてください。
Node Pool とホスト名のラベルを確認します:
CKS ノードでは、次のラベルを公開できます。 クラスターに存在するラベルのキーと値を使用してください。 予算セレクターが選択するのは Kubernetes ノードです。API ランナーグループを選択したり、サンドボックスの配置制約、taint、トレランス、RuntimeClass を上書きしたりすることはありません。

予算の設定を作成する

以下のいずれかの例を node-budget.json ファイルとして保存します。 まず "mode": "prepare" から始めます。準備段階では予算リソースがパブリッシュされます。適用は後のステップで有効にします。

すべてのノードで CPU とメモリを 95%

空のセレクターはすべてのノードに一致します。
両方の割合は必須で、0 から 100 までの整数である必要があります。値が 0 の場合、サンドボックスのキャパシティはゼロになります。

選択した Node Pools のみに 50%

これにより、2 つの Node Pools のいずれかのノードが選択されます。[BATCH-POOL] と [INTERACTIVE-POOL] をそれぞれの Node Pool ラベルの値に置き換えてください:
managedNodes.selector の外にあるノードは、サンドボックス予算をゼロで受け取ります。適用が有効になると、予算トークンを必要とするサンドボックスはそれらのノードを使用できません。 選択内容をプレビュー:
他のノード上のサンドボックスのキャパシティを維持するためには、Node Pool とグループのオーバーライド を使用します。

Node Pools と独自のグループの異なる予算

この設定では、次の予算が提供されます。
  • デフォルトで CPU とメモリの 95%。
  • [CPU-POOL] Node Pool 内のノードに対して CPU とメモリの 50%。
  • [BUDGET-GROUP-LABEL]=[TRAINING-GROUP] のラベルが付いたノードに対して CPU の 25% とメモリの 40%。
[CPU-POOL] を Node Pool のラベル値に置き換えてください。[BUDGET-GROUP-LABEL] を独自のラベルキーに、[TRAINING-GROUP] をその値に置き換えてください。
セレクター have the following 動作:
  • A matching オーバーライド replaces the default percentages.
  • If 複数のオーバーライド match, the 最小値 percentage in each dimension wins.
  • Rule 順序 doesn’t establish priority.
  • Overlap is reported as selector_conflict. Prefer disjoint groups when overlap is unintended.
  • エントリ in matchLabels and separate 式 must all match.
  • Values within one In expression are alternatives.
In this example, a ノード matching both オーバーライド receives 25% CPU and 40% メモリ. For custom groups, configure labels through your Node Pool 設定 where possible so replacement ノード inherit them.

特定のノードに 50%

選択したいノードの観測された kubernetes.io/hostname ラベル値に [HOSTNAME-A] と [HOSTNAME-B] を置き換えてください:
ホスト名ラベルの値は、ノードオブジェクトの名と異なる場合があります。 他のノードはサンドボックスの予算をゼロで受け取ります。Node Pool または custom-group セレクターは、置き換えノードが設定を自動的に継承する場合に推奨されます。

設定を適用する

設定を JavaScript Object Notation (JSON) の string として次のフィールドに保存します。
適用する設定ファイルを選択します:
以下のコマンドは、現在のランナーを読み取り、既存のデプロイメントのオーバーライドフィールドと環境変数を保持します。元のランナー設定ファイルやポリシーファイルは必要ありません。別の設定を適用するには、BUDGET_FILE を変更したうえで、このブロックを再利用してください:
同じ物理クラスター内のすべての論理ランナーに対して、このプロセスを繰り返します。パッチを作成する前に、各ランナーを読み取ってください。 spec.overrides はオブジェクト全体として置き換えられるため、その兄弟フィールドを保持する必要があります。 CoreWeave Intelligent CLI v1.44.0 では、この環境変数のみのパッチを使用してください。このリリースの古いポリシースキーマでは、新しいサーバーからリネームされた HTTPS ホスト名フィールドを完全にエクスポートできません。そのため、ランナーのドキュメント全体を再適用すると、ポリシーが不完全なデータで置き換えられる可能性があります。上記のパッチには、ポリシーは含まれず、更新もされません。 ランナーのエクスポートは非公開にし、作業後は一時ファイルを削除してください。

検証の準備

準備により、ノードのステータスにこれらの拡張リソースがパブリッシュされます:
それらのキャパシティと割り当て可能値を確認します:
キャパシティと割り当て可能値がすべてのノードの予算リソースの両方で一致するまで待機します。 予算アカウンティングには以下の詳細が含まれます:
  • 予算トークンのない既存のバインド済みサンドボックスは、終了するまでパブリッシュされた予算から差し引かれます。
  • その他のワークロードは物理リソースを消費するため、利用可能なサンドボックスキャパシティは設定された予算より低くなる場合があります。
  • サンドボックスの料金には、ヘルパーコンテナー、init-containerのピーク、RuntimeClassのオーバーヘッドが含まれます。
  • CPUとメモリの割合はGPUキャパシティを分割しません。
メトリクスが利用可能な場合は、以下のメトリクスを確認してください:
sandbox_runner_node_budget_policy メトリクスは mode と policy_hash ラベルを公開します。クラスター内のすべてのランナーが mode="prepare" および同じ policy_hash 値を report していることを確認してください。これらのメトリクスにアクセスできない場合は、適用を有効にする前に CoreWeave に準備完了を検証するよう依頼してください。

適用を有効にする

準備が正常な状態になったら、モードのみを変更します。
設定を適用するの読み取り、パッチの作成、適用の各コマンドを、クラスター内のすべてのランナーに対して繰り返し実行します。 cwic sandbox runner describe "$RUNNER_ID" を使用してランナーのロールアウトを確認し、クラスターの受け入れの遷移が完了したことを CoreWeave に確認してもらいます。この遷移によって、クラスターが予算の適用を開始するタイミングが調整されます。遷移には、古いシャードの廃止や、適用前から保留中だったワークロードのバインドまたは終了も含まれます。 適用を検証するには、次の手順を実行します。
  1. 各ランナー上に小規模なサンドボックスを作成します。
  2. その Pod が両方の予算リソースをリクエストしていることを確認します。
  3. 制御された飽和テストを実施する場合は、CPU またはメモリのいずれかの予算を使い切った時点で新しい割り当てが停止することを検証します。
  4. テスト用のサンドボックスを削除します。
次のキャパシティ枯渇の理由が表示されるのは想定どおりの動作です。

Terraform 管理のランナーを設定する

Terraform がランナーを管理している場合は、次の spec.overrides.env 設定を既存の coreweave_sandbox_managed_runner リソースにマージしてください:
準備が健全になったら、JSON ファイルを prepare から enforce に更新し、対応する Terraform の変更を適用します。 Terraform がランナーを管理している場合、変更を Terraform に保持して、後続の apply が意図した設定を維持するようにします。

予算を削減する、またはノードのメンバーシップを変更する

ノードが自動的に cordon またはドレインされることはありません。 キャパシティが減少するような形でパーセンテージを下げたり、セレクターやラベルを変更したりする場合は、事前に次の手順を実行してください。
  1. 影響を受けるノードを cordon します。
  2. 更新した設定を、そのクラスター内のすべてのランナーに適用します。
  3. 予算が収束するまで待ちます。
  4. この変更のために cordon したノードのみを uncordon します。
cordon を実行すると新たなスケジューリングは行われなくなりますが、既存の Pod は引き続き実行されます。既存の割り当ては、終了するまで新しい上限を超えた状態のままになることがあります。予算を削減しても、それらが退避されることはありません。 cordon せずに削減を行った場合は、次のメッセージがログに記録されます。
予算を完全に無効にするには、廃止手順について CoreWeave と調整してください。環境変数を削除したり、機能ゲートを直接無効にしたりしても、必要なロールバック手順は実行されません。

関連項目

詳細については、以下のページを参照してください。
最終更新日 2026年10月15日