ランナーのデプロイと管理

マネージドランナーは、CKS クラスター内でサンドボックスを実行する、CoreWeave が管理するコンポーネントです。このページでは、ランナーのデプロイ、健全性の確認、ニーズの変化に応じた設定の調整、不要になった場合の削除まで、ライフサイクル全体を説明します。サンドボックスのアーキテクチャにおけるランナーの位置付けと、ゲートウェイがランナーへのリクエストを仲介する仕組みについては、サンドボックスのアーキテクチャを参照してください。ランナーの有効化から最初のサンドボックスの実行までの手順ガイドについては、独自のコンピュートを使用するを参照してください。ランナーをコードとしてのインフラストラクチャで管理するには、Terraform でランナーを管理するを参照してください。

事前準備

このページの CLI、curl、Terraform の例は、いずれも CoreWeave API アクセストークンで認証します。Cloud Console の Tokens ページでトークンを生成し、Token Secret の値をコピーしてください。トークンの詳細については、API アクセストークンの管理を参照してください。 CLI: CoreWeave Intelligent CLI (cwic) をインストールし、cwic auth login を実行して、プロンプトが表示されたらトークンを貼り付けます。トークンはローカルの cwic 設定に保存され、以降のコマンドでは自動的に読み込まれます。環境変数を設定する必要はありません。

cwic auth login

curl: このページの例からトークンを参照できるよう、シェルでトークンをエクスポートします。[API-ACCESS-TOKEN] は、ご自身の CoreWeave API アクセストークンに置き換えてください。

export TOKEN="[API-ACCESS-TOKEN]"

Terraform: Terraform と CoreWeave Terraform プロバイダーをインストールし、sandbox_admin 権限を持つトークンを使用します。このデプロイメントの例では、0.x 系のプロバイダー 0.26.0 以降を使用します。前述のシェルコマンドでエクスポートしたトークンを使用して、プロバイダーの認証変数を次のように設定します。

export COREWEAVE_API_TOKEN="$TOKEN"

クラスターにすでにランナーが存在する場合は、適用する前にランナーを Terraform の state にインポートしてください。プロバイダーのセットアップと Terraform の完全なライフサイクルについては、Terraform でランナーを管理するを参照してください。

ランナーコマンド

cwic sandbox runner グループはランナーを管理します。以下の表は、各ライフサイクルタスクとそれを実行するコマンドの対応を示しています。以降のセクションでは、これらのコマンドについてコンテキストに沿って順を追って説明します。

目的	コマンド
ランナーをデプロイする (ウィザード)	`cwic sandbox runner create [RUNNER-ID]`
ファイルからランナーをデプロイする	`cwic sandbox runner create [RUNNER-ID] -f runner.yaml`
ランナーを一覧表示する	`cwic sandbox runner get` (エイリアス `ls`)
1つのランナーを検査する	`cwic sandbox runner get [RUNNER-ID]`
詳細ビュー	`cwic sandbox runner describe [RUNNER-ID]`
ランナーを編集する	`cwic sandbox runner edit [RUNNER-ID]`
利用可能なアップデートを適用する	`cwic sandbox runner upgrade [RUNNER-ID]`
ランナーを削除する	`cwic sandbox runner delete [RUNNER-ID]`
ランナーのポリシーを読み取る	`cwic sandbox runner policy get [RUNNER-ID]`
ランナーのポリシーを編集する	`cwic sandbox runner policy edit [RUNNER-ID]`

すべての入力は YAML または JSON を受け入れます。

ランナーをデプロイする

組織内の各 CKS クラスターでホストできるマネージドランナーは最大 1 つです。デプロイするには、以下を指定します。

ランナー ID: クライアント側で割り当てる、人が読める形式の ID。組織内で一意である必要があります。
ゾーン: クラスターが属する地理的ゾーン。
クラスター ID (またはクラスター名): ランナーを実行する CKS クラスター。どちらも Cloud Console の Clusters ページで確認できます。
ポリシー: ランナーがそのクラスター上のサンドボックスに適用するルール。サンドボックスを実行するにはポリシーが必要です。省略した場合は、ランナーの接続時に CoreWeave がデフォルトのポリシーを適用します。ポリシーではサンドボックスのデフォルトのライフタイムを指定できます。ただし、上限である 30 日はプラットフォーム側で強制されます。サンドボックスポリシーを設定するを参照してください。

CLI
curl
Terraform

ウィザードでは、クラスター、リリースチャンネル、メンテナンス期間をインタラクティブに入力します。その後、送信前に値が入力済みの spec がエディターで開きます。

cwic sandbox runner create prod-us-east-1

ファイルモードは YAML または JSON を受け入れます。そのため、再現可能なセットアップにはこの方法が推奨されます。また、Claude Code や Codex など、ユーザーに代わってランナーの spec を生成するエージェントとの併用にも適しています。CLI は -f - を指定すると stdin からも読み込めます。[CLUSTER-NAME] は、ランナーをデプロイする CKS クラスターの名前に置き換えてください。

runner.yaml

identity:
  zone: us-east-1
  cluster_name: [CLUSTER-NAME]
spec:
  release_channel: RELEASE_CHANNEL_STABLE
  maintenance_policy:
    windows:
      - cron: "0 9 * * SAT"
        duration_seconds: 14400
policy:
  display_name: default
  constraints:
    resources:
      default_cpu: "1"
      default_memory: "2Gi"
      max_cpu: "4"
      max_memory: "8Gi"
      require_limits: true
    lifecycle:
      default_lifetime_seconds: 3600

spec を送信します。

cwic sandbox runner create prod-us-east-1 -f runner.yaml

[CLUSTER-ID] は、ランナーをデプロイする CKS クラスターの ID に置き換えてください。

Deploy a managed runner

curl -X POST https://api.coreweave.com/v1/sandbox/managedRunners \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "Production runner (US East)",
    "identity": {
      "runnerId": "prod-us-east-1",
      "zone": "us-east-1",
      "clusterId": "[CLUSTER-ID]"
    },
    "spec": {
      "releaseChannel": "RELEASE_CHANNEL_STABLE",
      "maintenancePolicy": {
        "windows": [
          { "cron": "0 9 * * SAT", "durationSeconds": 14400 }
        ]
      }
    },
    "policy": {
      "displayName": "default",
      "constraints": {
        "resources": {
          "defaultCpu": "1",
          "defaultMemory": "2Gi",
          "maxCpu": "4",
          "maxMemory": "8Gi",
          "requireLimits": true
        },
        "lifecycle": { "defaultLifetimeSeconds": 3600 }
      }
    }
  }'

次の設定を main.tf ファイルに保存します。[CLUSTER-ID] は CKS クラスターの UUID に、[ZONE] はそのクラスターの Availability Zone に置き換えてください。このリソースでは、policy オブジェクトを明示的に指定する必要があります。

main.tf

terraform {
  required_providers {
    coreweave = {
      source  = "coreweave/coreweave"
      version = "~> 0.26"
    }
  }
}

provider "coreweave" {}

resource "coreweave_sandbox_managed_runner" "runner" {
  runner_id  = "prod-us-east-1"
  cluster_id = "[CLUSTER-ID]"
  zone       = lower("[ZONE]")

  spec = {
    release_channel = "RELEASE_CHANNEL_STABLE"
    maintenance_policy = {
      windows = [{ cron = "0 9 * * SAT", duration_seconds = 14400 }]
    }
  }

  policy = {
    display_name = "default"
    constraints = {
      resources = {
        default_cpu    = "1"
        default_memory = "2Gi"
        max_cpu        = "4"
        max_memory     = "8Gi"
        require_limits = true
      }
      lifecycle = { default_lifetime_seconds = 3600 }
    }
  }
}

output "runner_status" {
  value = {
    install_status    = coreweave_sandbox_managed_runner.runner.install_status
    connection_status = coreweave_sandbox_managed_runner.runner.connection_status
    active_revision   = coreweave_sandbox_managed_runner.runner.active_revision
    target_revision   = coreweave_sandbox_managed_runner.runner.target_revision
  }
}

設定を確認して適用します。

terraform init
terraform validate
terraform plan -out=runner.tfplan
terraform apply runner.tfplan

apply が成功した場合、API が設定を受け付けたことを意味します。インストールはその後も非同期で続行されます。ロールアウトが完了したかどうかは、ランナーのステータスを確認するにある Terraform の例を使用して確認してください。Terraform の状態は、アクセス制御が設定されたバックエンドに保存してください。

以下の動作に注意してください。

maintenance_policy.windows はオプションです。設定すると、自動更新は指定した cron ウィンドウの間にのみ適用されます。
runner_group_id はオプションです。同じゾーンに複数のランナーがある場合、スケジューリングのアフィニティ指定に使用します。

よくある検証エラー

エラー	対処
`runner.identity.zone is required`	ゾーンを指定してください。CKS クラスターがある (つまりランナーのクォータがある) ゾーンは、Cloud Console の Clusters ページ、または `cwic cluster get` の実行で確認できます。
`runner.identity.cluster_id or cluster_name is required`	いずれかを指定してください。どちらも Cloud Console の Clusters ページ、または `cwic cluster get` の実行で確認できます。
`policy exceeds 256 KiB limit`	ポリシードキュメントを削減してください。エンコード後のドキュメントの上限は 256 KiB です。
`a managed runner already exists for this cluster`	1 つのクラスターでホストできるマネージドランナーは最大 1 つです。先に既存のランナーを更新するか、削除してください。

ランナーのステータスを確認する

作成後、ランナーのステータスを確認して、正常にロールアウトされたかどうかを確認します。ロールアウトに失敗した場合は、ステータスをもとに問題を診断します。

CLI
curl
Terraform

cwic sandbox runner describe prod-us-east-1

表形式で概要をすばやく確認するには、エイリアス get を使用します。

cwic sandbox runner get prod-us-east-1

どちらのコマンドでも、作成時に指定したランナー ID (prod-us-east-1) またはサーバーが割り当てた UUID を指定できます。

ランナーを取得する

curl -H "Authorization: Bearer $TOKEN" \
  https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1

作成時に指定したランナー ID と、サーバーが割り当てた UUID のどちらでも渡すことができます。

デプロイメントの設定を含むディレクトリで、実際のステータスを更新し、runner_status 出力を読み取ります。

terraform plan -refresh-only -out=runner-status.tfplan
terraform apply runner-status.tfplan
terraform output runner_status

install_status が RUNNER_INSTALL_STATUS_READY、connection_status が RUNNER_CONNECTION_STATUS_CONNECTED で、かつ active_revision が target_revision と一致していれば、ランナーは準備完了です。ロールアウトがまだ進行中の場合は、再度更新してください。

応答には、トラッキングすべき 2 つのステータスフィールドが含まれます。

installStatus: クラスターへのランナーのデプロイメントの進行状況 (PENDING、PROVISIONING、READY、または FAILED) 。
connectionStatus: 現在の接続状態 (CONNECTED または DISCONNECTED) 。この値はランナーのハートビートによって更新されるため、最大 30 秒の遅延が生じることがあります。

installStatus == FAILED の場合、応答には構造化された installError が含まれます。

{
  "installError": {
    "reason": "...",
    "message": "...",
    "remediationHints": ["Add toleration for taint 'workload=gpu:NoSchedule'"],
    "occurredAt": "2026-04-24T12:03:11Z"
  }
}

remediationHints は、実行すべき action を示します。diagnosticDetail には、サポートチケットを作成する際に添付すると役立つ内部ログも含まれています。

ランナーを更新する

Terraform で管理しているランナーの場合は、リソース設定を編集し、terraform plan の内容を確認してからプランを適用します。目的のポリシーとオーバーライドは、すべて設定内に完全な形で記述しておいてください。CLI または API で行った変更は、その後の適用によって元に戻される可能性があります。ドリフトとリソースの置き換えの動作については、Terraform 設定を更新するを参照してください。ランナーの編集コマンドは、対話型ウィザードとファイルによるパッチの両方をサポートします。内部的には、更新にフィールドマスクを使用し、変更したフィールドのみが適用されます。それ以外はすべて読み取り専用で、installStatus、connectionStatus、タイムスタンプ、解決済みのデプロイメント仕様も含まれます。変更可能なフィールドのパスについては、更新時のフィールドマスクを参照してください。 v1 REST API では、PATCH の本文はマネージドランナー自体であり、リクエストのラッパーはありません。フィールドマスクは updateMask クエリパラメーターとして渡されます。マスクが省略されている場合、または空の場合は、変更可能なリソース全体が置き換えられます。次の 2 つのパスは、従来の v1beta2 サーフェスでのみ受け付けられ、v1 のマネージドランナーへの書き込みでは拒否されます。profile_bindings (代わりに policy を設定してください) と spec.allow_privileged_profile_annotations です。

ランナーの一般的な更新

以下の例では、ランナーに対して最も頻繁に行われる編集を紹介します。リリースチャネルの切り替え、ランナーが保持するポリシーの置き換え、クラスター内でランナー Pod を配置する場所の調整、そしてレガシーのプロファイルテンプレートに特権構成を許可する方法です。

例: リリースチャンネルを切り替える

CLI
curl

stdin から 1 行のパッチを適用します:

echo 'spec: {release_channel: RELEASE_CHANNEL_RAPID}' \
  | cwic sandbox runner edit prod-us-east-1 -f -

または、パッチをファイルに書き込んで送信します:

patch.yaml

spec:
  release_channel: RELEASE_CHANNEL_RAPID

cwic sandbox runner edit prod-us-east-1 -f patch.yaml

ランナーを RAPID チャンネルに移動する

curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=spec.releaseChannel" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "identity": { "runnerId": "prod-us-east-1" },
    "spec": { "releaseChannel": "RELEASE_CHANNEL_RAPID" }
  }'

例: ポリシーを置き換える

ポリシーはドキュメント全体として置き換えられます。現在のポリシーを読み取り、必要な箇所を変更して送り返してください。policy 内にはフィールド単位のマスクがないため、本文の一部だけを送信すると、省略したグループは消去されます。 CLI および REST の手順については、ポリシーを更新するを参照してください。ポリシーとその etag は同じ読み取りで取得し、編集したドキュメントをその etag とともに送信してください。これにより、同時に行われた変更を検出できます。

例: デプロイメントのオーバーライドによるノード配置の固定

spec.overrides フィールドは、サンドボックスの Pod ではなく、ランナー自体の Pod を調整します。ランナーの Pod を適切なノードに配置するために、特定のトレランス、ノードセレクター、またはランタイムクラスが必要な場合に使用します。よくあるケースは、SUNK クラスター内で Slurm ジョブと並行して実行できるように、ランナーの Pod を SUNK Pod Scheduler 経由で配置することです。ランナーのオーバーライドにスケジューラー名と SUNK アノテーションを設定します。使用可能なアノテーションと必要な設定については、SUNK Pod Scheduler インテグレーションを参照してください。

CLI
curl

overrides.yaml

spec:
  overrides:
    node_selector:
      node-pool: system
    tolerations:
      - key: dedicated
        operator: Equal
        value: system
        effect: NoSchedule

cwic sandbox runner edit prod-us-east-1 -f overrides.yaml

ランナーを特定の Node Pool に固定

curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=spec.overrides" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "identity": { "runnerId": "prod-us-east-1" },
    "spec": {
      "overrides": {
        "nodeSelector": { "node-pool": "system" },
        "tolerations":  [ { "key": "dedicated", "operator": "Equal", "value": "system", "effect": "NoSchedule" } ]
      }
    }
  }'

例: ランナーのアフィニティを設定する

spec.overrides.affinity を使用して、ランナー自身の Pod に対する Kubernetes のノードアフィニティ、Pod アフィニティ、または Pod アンチアフィニティを設定します。値は Kubernetes の Affinity オブジェクトで、その内部のキーには Kubernetes のキャメルケースを使用します。ランナーのアフィニティは、サンドボックス Pod の配置を設定するものではなく、ノードの予算も変更しません。次の例では、example.com/capacity-class: on-demand というラベルが付いたノードを優先しつつ、条件を満たすその他のノードも引き続き使用できるようにします。この例示用のラベルは、ご使用のクラスターで使用しているラベルに置き換えてください。

CLI
REST
Terraform

ランナーのアフィニティをサポートするバージョンの CoreWeave Intelligent CLI を使用してください。コマンドで affinity フィールドが不明であると報告される場合は、CLI をアップグレードするか、REST の例を使用してください。

アフィニティのパッチを保存します。

affinity.yaml

spec:
  overrides:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
                - key: example.com/capacity-class
                  operator: In
                  values: [on-demand]

ランナーに適用します。

cwic sandbox runner edit prod-us-east-1 -f affinity.yaml

アフィニティのみのパッチは spec.overrides.affinity だけを対象とするため、他のオーバーライドは保持されます。同じパッチに他のオーバーライドフィールドが含まれる場合、CLI は spec.overrides オブジェクト全体を置き換えます。保持したい兄弟のオーバーライドはすべて含めてください。

このリクエストは、他のオーバーライドを保持したままアフィニティを置き換えます。

Set runner affinity

curl --fail-with-body -X PATCH \
  'https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=spec.overrides.affinity' \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "overrides": {
        "affinity": {
          "nodeAffinity": {
            "preferredDuringSchedulingIgnoredDuringExecution": [
              {
                "weight": 100,
                "preference": {
                  "matchExpressions": [
                    {
                      "key": "example.com/capacity-class",
                      "operator": "In",
                      "values": ["on-demand"]
                    }
                  ]
                }
              }
            ]
          }
        }
      }
    }
  }'

アフィニティを使用するには、spec.overrides.affinity に対応したプロバイダーのリリースが必要です。プロバイダー 0.26.0 は対応していません。対応リリースが利用可能になるまでは REST の例を使用し、以降の apply で変更が上書きされないよう Terraform 側と調整してください。対応プロバイダーをインストールしたら、ランナーリソースの spec.overrides 内に次の属性を追加します。Terraform はオーバーライドオブジェクト全体を置き換えるため、必要な他のオーバーライドも残しておいてください。

Affinity attribute inside spec.overrides

affinity = jsonencode({
  nodeAffinity = {
    preferredDuringSchedulingIgnoredDuringExecution = [{
      weight = 100
      preference = {
        matchExpressions = [{
          key      = "example.com/capacity-class"
          operator = "In"
          values   = ["on-demand"]
        }]
      }
    }]
  }
})

更新内容を確認して適用します。

terraform plan -out=runner.tfplan
terraform apply runner.tfplan

継承されたアフィニティを含むすべてのルールをクリアするには、affinity = jsonencode({}) を設定します。プラットフォームのデフォルトにリストアするには、この属性を削除します。いずれの場合も、必要な他のオーバーライドは保持してください。完全な設定については、Terraform でランナーを管理するを参照してください。

Kubernetes は、優先アフィニティを他のスケジューリングスコアと組み合わせて評価します。この優先設定は、on-demand を優先した配置を保証するものではありません。また、優先するキャパシティが利用可能になっても、すでに実行中の Pod が移動されることはありません。既存の node_selector による制限は引き続き適用されます。NoSchedule または NoExecute の taint を持つノードには、一致するトレランスが必要です。spot へのフォールバックを許可する場合は、spot ノードを除外するノードセレクターを使用しないでください。配置を厳密に制限するには、requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms を使用します。必須のノードアフィニティと node_selector の両方に一致する必要があります。各 term は論理 OR で、term 内の式は論理 AND で結合されます。必須のノードアフィニティは、ランナーのプリフライトチェックの対象となります。優先アフィニティと Pod アフィニティまたはアンチアフィニティは、スケジューリング時に Kubernetes によって評価されます。更新後は、cwic sandbox runner describe prod-us-east-1 を使用してロールアウトの進行状況を確認します。API 応答で、activeRevision が targetRevision と一致していること、installStatus が RUNNER_INSTALL_STATUS_READY であること、connectionStatus が RUNNER_CONNECTION_STATUS_CONNECTED であることを確認します。解決後の設定は、出力専用の deploymentSpec.affinity フィールドに表示されます。アフィニティはルール単位でマージされるのではなく、全体が置き換えられます。継承されたルールも含めてすべてのアフィニティルールを削除するには、空のオブジェクトを明示的に適用します。

printf '%s\n' 'spec: {overrides: {affinity: {}}}' \
  | cwic sandbox runner edit prod-us-east-1 -f -

オーバーライドを削除してプラットフォームのデフォルトをリストアするには、アフィニティのみを対象とする CLI パッチで affinity: null を使用します。REST の場合は、updateMask=spec.overrides.affinity はそのままにして {"spec":{"overrides":{}}} を送信します。アフィニティをクリアしても、ノードセレクターとトレランスは変更されません。従来の v1beta2 のフィールドは managed_spec.overrides.affinity です。新しいインテグレーションでは、ここに示す v1 のフィールド spec.overrides.affinity を使用してください。

例: 特権プロファイルの構成を許可する

allow_privileged_profile_annotations は、ランナーにバインドされたレガシーのプロファイルテンプレートが特権的な構成を保持できるかどうかを制御します。ポリシーではなくプロファイルバインディングを引き続き使用しているランナーに適用されるため、リクエストは v1beta2 サーフェスに送信されます。既定値は false で、このフラグが設定されていないランナーでは、特権的な構成を含むテンプレートは拒否されます。名前から受ける印象とは異なり、このフラグは次の 2 種類の内容を制御します。

特権 Pod アノテーション、つまりランタイムおよびスケジューラーのプレフィックス。
serviceAccountName、ホスト名前空間、hostPath ボリューム、特権コンテナや権限昇格コンテナなど、特権的な構造化 Pod スペックフィールド。

ランナーが拒否したテンプレートは permission_denied を返し、問題となったフィールド名を示します。たとえば、securityContext.appArmorProfile と securityContext.seccompProfile を設定するテンプレートは、次のように失敗します。

Example output

Error: updating runner: permission_denied: profile_bindings[7]: template
"[TEMPLATE-ID]" contains privileged pod-spec fields
[securityContext.appArmorProfile securityContext.seccompProfile];
runner does not have allow_privileged_profile_annotations=true

テンプレートを拒否したランナーにフラグを設定します。このフラグは 1 つのランナーにのみ適用されるため、特権構成が必要なランナーごとにこの操作を繰り返してください。

CLI
curl

echo 'managed_spec: {allow_privileged_profile_annotations: true}' \
  | cwic sandbox runner edit prod-us-east-1 -f -

1 つのランナーで特権プロファイル構成を許可する

curl -X PATCH https://api.coreweave.com/v1beta2/sandbox/managed-runners/prod-us-east-1 \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "runner": {
      "id": "prod-us-east-1",
      "managedSpec": { "allowPrivilegedProfileAnnotations": true }
    },
    "updateMask": "managedSpec.allowPrivilegedProfileAnnotations"
  }'

更新が成功したら、拒否されたプロファイルテンプレートを再度適用します。

このフラグを設定すると、ホストリソースへのアクセスを含め、ランナー上のサンドボックスが実行できる操作の範囲が広がります。特権構成が必要なランナーにのみ設定してください。Sandbox Admin ロールを持つユーザーであれば、誰でもこのフラグを設定できます。設定すると、クラスター管理者に匹敵するノードアクセス権がサンドボックスに付与される可能性があります。

ランナーの更新をオンデマンドで実行する

ランナーの updateAvailable が true の場合、次のメンテナンス期間を待たずに、すぐに更新を適用できます。

CLI
curl

cwic sandbox runner upgrade prod-us-east-1

利用可能な更新をすぐに適用する

curl -X POST https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1:applyAvailableUpdate \
  -H "Authorization: Bearer $TOKEN"

コントロールプレーンは、ランナーのリリースチャンネルで最新のバージョンを特定し、target_revision を更新します。クラスター内のコントローラーがその更新をロールアウトします。

ランナーの一覧表示

組織内のすべてのランナーを確認する場合や、特定のゾーン、クラスター、接続状態に絞り込んで表示する場合は、次の一覧コマンドを使用します。

CLI
curl

cwic sandbox runner get

ゾーン、クラスター、接続状態でフィルタリングします。

cwic sandbox runner get --zone us-east-1
cwic sandbox runner get --connection-status CONNECTED

マネージドランナーの一覧表示

curl -H "Authorization: Bearer $TOKEN" \
  'https://api.coreweave.com/v1/sandbox/managedRunners?pageSize=50&zone=us-east-1'

サポートされているクエリパラメーターは、zone、clusterId、connectionStatus、runnerId、managementMode、pageSize (デフォルト 50、最大 100) 、pageToken です。ページネーションはカーソルベースです。

ランナーを削除する

クラスター上のサンドボックスのキャパシティが不要になった場合、または同じクラスターに新しいランナーを再デプロイする前に、ランナーを削除します。

CLI
curl
Terraform

cwic sandbox runner delete prod-us-east-1

CLI で確認を求められます。スクリプトで使用する場合は、--yes を指定して確認を省略します。

cwic sandbox runner delete prod-us-east-1 --yes

Decommission a runner

curl -X DELETE https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \
  -H "Authorization: Bearer $TOKEN"

Terraform の設定から、ランナーリソースとその runner_status 出力を削除し、そのリソースへのその他の参照もすべて削除します。適用前に削除計画を確認してください。

terraform plan -out=runner.tfplan
terraform apply runner.tfplan

リソースを削除すると、マネージドランナーが廃止されます。プロバイダーは削除が完了するまで最大 30 分間待機します。

ランナーを削除すると、クラスター内のランナーのデプロイメントが撤去されます。そのランナーで実行中のサンドボックスはすべて停止します。ポリシーはランナーの一部なので、ランナーとともに削除されます。クラスターを再デプロイする予定がある場合は、ポリシードキュメントをバージョン管理下に保存してください。

削除は元に戻せません。トラフィックを一時停止したいだけの場合は、このランナーを削除する前にサンドボックスを別のランナーに移動してください。

サンドボックス

サンドボックスを使用する

サンドボックスの管理

リファレンス

ランナーのデプロイと管理

事前準備

ランナーコマンド

ランナーをデプロイする

よくある検証エラー

ランナーのステータスを確認する

ランナーを更新する

ランナーの一般的な更新

例: リリースチャンネルを切り替える

例: ポリシーを置き換える

例: デプロイメントのオーバーライドによるノード配置の固定

例: ランナーのアフィニティを設定する

例: 特権プロファイルの構成を許可する

ランナーの更新をオンデマンドで実行する

ランナーの一覧表示

ランナーを削除する

関連情報

​事前準備

​ランナーコマンド

​ランナーをデプロイする

​よくある検証エラー

​ランナーのステータスを確認する

​ランナーを更新する

​ランナーの一般的な更新

​例: リリースチャンネルを切り替える

​例: ポリシーを置き換える

​例: デプロイメントのオーバーライドによるノード配置の固定

​例: ランナーのアフィニティを設定する

​例: 特権プロファイルの構成を許可する

​ランナーの更新をオンデマンドで実行する

​ランナーの一覧表示

​ランナーを削除する

​関連情報

事前準備

ランナーコマンド

ランナーをデプロイする

よくある検証エラー

ランナーのステータスを確認する

ランナーを更新する

ランナーの一般的な更新

例: リリースチャンネルを切り替える

例: ポリシーを置き換える

例: デプロイメントのオーバーライドによるノード配置の固定

例: ランナーのアフィニティを設定する

例: 特権プロファイルの構成を許可する

ランナーの更新をオンデマンドで実行する

ランナーの一覧表示

ランナーを削除する

関連情報