Deploy and manage a runner

관리형 러너는 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: 이 페이지의 예시에서 토큰을 사용할 수 있도록 셸에서 토큰을 export하세요. [API-ACCESS-TOKEN]을 CoreWeave API 액세스 토큰으로 바꾸세요.

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

Terraform: Terraform과 CoreWeave Terraform 공급자를 설치하고, sandbox_admin 권한이 있는 토큰을 사용하세요. 배포 예시에서는 0.x 시리즈 중 0.26.0 이상 버전의 공급자를 사용합니다. 앞의 셸 명령어에서 export한 토큰으로 공급자의 인증 변수를 설정하세요.

export COREWEAVE_API_TOKEN="$TOKEN"

클러스터에 이미 러너가 있다면 적용하기 전에 러너를 Terraform 상태로 임포트하세요. 공급자 설정과 전체 Terraform 라이프사이클에 대한 자세한 내용은 Terraform으로 러너 관리를 참조하세요.

러너 명령어

cwic sandbox runner 그룹은 러너를 관리합니다. 다음 table은 각 라이프사이클 작업과 이를 수행하는 명령어를 연결합니다. 이후 섹션에서는 실제 사용 맥락에서 이러한 명령어를 설명합니다.

목표	명령어
러너 배포(마법사)	`cwic sandbox runner create [RUNNER-ID]`
파일에서 러너 배포	`cwic sandbox runner create [RUNNER-ID] -f runner.yaml`
러너 목록 조회	`cwic sandbox runner get` (별칭 `ls`)
러너 하나 확인	`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 클러스터는 최대 하나의 관리형 러너를 호스팅합니다. 배포하려면 다음을 제공하세요:

러너 ID: 클라이언트가 할당한 사람이 읽을 수 있는 ID로, 조직 내에서 고유합니다.
영역: 클러스터가 속한 지리적 영역.
Cluster ID (또는 cluster name): 러너가 실행되는 CKS 클러스터. Cloud Console의 Clusters 페이지에서 둘 다 찾을 수 있습니다.
정책: 클러스터의 샌드박스에 대해 러너가 강제 적용하는 규칙. 샌드박스를 실행하려면 정책이 있어야 합니다. 정책을 생략하면 러너가 연결될 때 CoreWeave가 기본 정책을 제공합니다. 정책에서 기본 샌드박스 수명을 지정할 수 있으며, 최대 수명인 30일은 플랫폼이 강제 적용합니다. 샌드박스 정책 설정 참조.

CLI
curl
Terraform

마법사가 클러스터, 릴리스 채널 및 유지 관리 창을 대화식으로 수집한 다음 제출하기 전에 미리 채워진 사양으로 편집기를 엽니다:

cwic sandbox runner create prod-us-east-1

파일 모드는 YAML 또는 JSON을 허용하므로 반복 가능한 설정에 선호되는 경로이며, 대신 러너 사양을 생성하는 Claude Code 또는 Codex와 같은 에이전트에 적합합니다. CLI는 -f -로 표준 입력에서도 읽습니다. 러너를 배포할 CKS 클러스터 이름으로 [CLUSTER-NAME]을 교체하세요:

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

사양을 제출하세요:

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

러너를 배포할 CKS 클러스터 ID로 [CLUSTER-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`	영역을 지정하세요. Cloud Console의 Clusters 페이지에서 또는 `cwic cluster get`을 실행하여 CKS 클러스터가 있는 영역(따라서 러너 할당량이 있는 영역)을 찾으세요.
`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`	클러스터는 관리형 러너를 최대 하나만 호스팅할 수 있습니다. 기존 러너를 업데이트하거나 먼저 삭제하세요.

러너 상태 확인

생성 후 러너의 상태를 확인하여 성공적으로 배포되었는지 확인하고, 그렇지 않은 경우 문제를 진단하세요.

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과 같으면 러너가 준비 완료된 것입니다. 롤아웃이 아직 진행 중이면 다시 새로 고치세요.

응답에는 추적할 상태 필드가 두 개 포함됩니다:

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는 수행해야 할 조치입니다. diagnosticDetail에는 지원 요청을 제출할 때 첨부하면 유용한 내부 로그도 포함되어 있습니다.

러너 업데이트

Terraform으로 관리하는 러너의 경우 해당 리소스 설정을 편집하고 terraform plan을 검토한 다음 플랜을 적용하세요. 원하는 정책과 재정의 값은 빠짐없이 모두 설정에 포함해 두세요. 그렇지 않으면 이후에 적용할 때 CLI 또는 API로 변경한 내용이 되돌려질 수 있습니다. 불일치 및 교체 동작에 대한 자세한 내용은 Terraform 설정 업데이트를 참조하세요. 러너 편집 명령어는 대화형 마법사와 파일 기반 패치를 모두 지원합니다. 내부적으로 업데이트는 필드 마스크를 사용하여 변경한 필드만 적용합니다. installStatus, connectionStatus, 타임스탬프, 최종 배포 사양을 포함한 나머지 모든 항목은 읽기 전용입니다. 수정 가능한 필드 경로는 업데이트 시 필드 마스크를 참조하세요. v1 REST API에서 PATCH 본문은 요청 래퍼 없이 관리형 러너 자체이며, 필드 마스크는 updateMask 쿼리 매개변수로 전달됩니다. 마스크를 생략하거나 비워 두면 수정 가능한 리소스 전체를 대체합니다. 다음 두 경로는 기존 v1beta2 API에서만 허용되며 v1 관리형 러너 쓰기 작업에서는 거부됩니다. profile_bindings (대신 policy를 설정하세요) 및 spec.allow_privileged_profile_annotations.

일반적인 러너 업데이트

다음 예시는 러너에 가장 자주 적용하는 변경 사항을 보여줍니다. 릴리스 채널 전환, 러너에 적용된 정책 교체, 클러스터 내 러너 파드 배치 위치 조정, 기존 프로필 템플릿에 특권 보안 설정 허용이 포함됩니다.

예시: 릴리스 채널 전환

CLI
curl

표준 입력에서 한 줄 패치를 적용하세요:

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 필드는 샌드박스 파드가 아니라 러너 자체의 파드를 조정합니다. 러너 파드를 올바른 노드에 배치하는 데 특정 toleration, 노드 셀렉터 또는 런타임 클래스가 필요한 경우에 사용하세요. 흔히 사용하는 방식은 러너 파드를 SUNK Pod Scheduler로 라우팅하여 SUNK 클러스터에서 Slurm 작업과 함께 실행하는 것입니다. 러너 오버라이드에 스케줄러 이름과 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를 사용하여 러너 자체 파드의 Kubernetes 노드 선호도, 파드 선호도 또는 파드 안티어피니티를 설정하세요. 값은 Kubernetes Affinity 객체이며, 내부 키는 Kubernetes 카멜 케이스 형식을 따릅니다. 러너 선호도는 샌드박스 파드 배치를 설정하거나 노드 예산을 변경하지 않습니다. 다음 예시는 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는 선호(preferred) 선호도를 다른 스케줄링 점수와 함께 고려합니다. 따라서 이 설정이 온디맨드 노드 우선 배치를 보장하지는 않으며, 선호하는 용량이 나중에 확보되더라도 이미 실행 중인 파드를 옮기지 않습니다. 기존 node_selector 제한은 계속 적용됩니다. NoSchedule 또는 NoExecute 테인트가 있는 노드에 배치하려면 일치하는 톨러레이션이 필요합니다. 스팟 노드로의 대체를 허용하려면 스팟 노드를 제외하는 노드 셀렉터를 사용하지 마세요. 배치를 엄격하게 제한하려면 requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms를 사용하세요. 필수(required) 노드 선호도와 node_selector는 둘 다 충족되어야 합니다. 각 term은 논리 OR로, term 내의 표현식은 논리 AND로 결합됩니다. 필수 노드 선호도는 러너 사전 점검 대상에 포함됩니다. 선호 선호도와 파드 선호도 또는 안티어피니티는 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 API로 전송됩니다. 기본값은 false이며, 이 플래그가 설정되지 않은 러너에서는 특권 보안 설정을 포함한 템플릿이 거부됩니다. 이름과 달리 이 플래그는 두 가지 유형의 콘텐츠를 제어합니다.

특권 파드 어노테이션으로, 런타임 및 스케줄러 접두사를 의미합니다.
serviceAccountName, 호스트 namespace, hostPath 볼륨, 특권 컨테이너 또는 권한 상승이 가능한 컨테이너와 같은 특권 구조화된 파드 사양 필드.

러너가 거부하는 템플릿은 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

템플릿을 거부한 러너에 플래그를 설정하세요. 이 플래그는 하나의 러너에만 적용되므로, 특권 보안 설정이 필요한 각 러너에 대해 이 작업을 반복하세요.

CLI
curl

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

Allow a privileged profile posture on one runner

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 역할이 있는 사용자는 누구나 이 플래그를 설정할 수 있습니다. 이 플래그를 설정하면 샌드박스가 클러스터 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분 동안 대기합니다.

러너를 삭제하면 클러스터에서 러너 배포가 제거됩니다. 해당 러너에서 실행 중인 모든 샌드박스가 중지됩니다. 정책은 러너의 일부이므로 함께 삭제됩니다. 클러스터를 다시 배포할 계획이라면 정책 문서를 버전 관리 시스템에 보관하세요.

삭제는 영구적입니다. 트래픽을 일시 중지하기만 하려면 이 러너를 삭제하기 전에 샌드박스를 다른 러너로 이동하세요.

참고 항목

노드 할당 예산 설정: Node Pool 또는 노드 그룹별로 샌드박스의 CPU 및 메모리 요청량을 제한합니다.
샌드박스 아키텍처: 리소스 모델, 컨트롤 플레인과 데이터 플레인 비교, 다중 클러스터 토폴로지를 설명합니다.
정책 개요: 샌드박스에 정책이 적용되는 방식을 설명합니다.
샌드박스 정책 설정: 모든 제약 조건 그룹을 구체적인 예시와 함께 설명합니다.
컨트롤 플레인 API 개요: 인증, 필드 마스크, 모든 엔드포인트의 요청 및 응답 구조를 설명합니다.
정책 레퍼런스: 정책에서 설정할 수 있는 모든 필드를 설명합니다.

샌드박스

샌드박스 사용하기

샌드박스 관리

레퍼런스

Deploy and manage a runner

시작하기 전에

러너 명령어

러너 배포

일반적인 검증 오류

러너 상태 확인

러너 업데이트

일반적인 러너 업데이트

예시: 릴리스 채널 전환

예시: 정책 교체

예시: 배포 오버라이드로 노드 배치 고정하기

예시: 러너 선호도 설정

예시: 특권 프로필 보안 설정 허용

필요 시 러너 업데이트 트리거

러너 목록 조회

러너 삭제

참고 항목

​시작하기 전에

​러너 명령어

​러너 배포

​일반적인 검증 오류

​러너 상태 확인

​러너 업데이트

​일반적인 러너 업데이트

​예시: 릴리스 채널 전환

​예시: 정책 교체

​예시: 배포 오버라이드로 노드 배치 고정하기

​예시: 러너 선호도 설정

​예시: 특권 프로필 보안 설정 허용

​필요 시 러너 업데이트 트리거

​러너 목록 조회

​러너 삭제

​참고 항목

시작하기 전에

러너 명령어

러너 배포

일반적인 검증 오류

러너 상태 확인

러너 업데이트

일반적인 러너 업데이트

예시: 릴리스 채널 전환

예시: 정책 교체

예시: 배포 오버라이드로 노드 배치 고정하기

예시: 러너 선호도 설정

예시: 특권 프로필 보안 설정 허용

필요 시 러너 업데이트 트리거

러너 목록 조회

러너 삭제

참고 항목