> ## 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.

# Integrate sandboxes with the SUNK Pod Scheduler

> Route sandbox pods through the SUNK Pod Scheduler so Slurm places them alongside your Slurm jobs.

CPU 전용 샌드박스 파드를 SUNK Pod Scheduler를 통해 라우팅하여 Slurm이 클러스터에서 실행 중인 Slurm 작업과 함께 배치를 관리하도록 하세요. 샌드박스는 일반 Slurm 작업이 되어 클러스터 내 사용 가능한 리소스가 있는 모든 노드에서 실행될 수 있으며, 동일한 노드에서 이미 실행 중인 다른 Slurm 작업이나 샌드박스와 CPU 리소스를 공유할 수도 있습니다.

러너의 정책은 해당 러너에 배치된 모든 샌드박스에 SUNK 스케줄러를 설정합니다. 클라이언트는 CoreWeave Kubernetes Service (CKS) 배치를 통해 러너를 선택합니다. 이 가이드는 정책을 구성하는 클러스터 오퍼레이터와 샌드박스를 실행하는 워크로드 작성자를 위한 것입니다.

<Info>
  **CPU 전용 지원**

  GPU 샌드박스는 비공개 프리뷰 단계이며 SUNK Pod Scheduler 인테그레이션에서 아직 지원되지 않습니다. 지원되는 배치 옵션과 액세스 요청 방법은 [GPU 샌드박스](/ko/products/sandboxes/gpu-sandboxes)를 참조하세요.

  CPU 전용 샌드박스는 유휴 CPU 노드에 배치되거나 다른 샌드박스 또는 Slurm 작업과 CPU 노드를 공유할 수 있으며, 다른 워크로드가 실행 중인 GPU 노드에서도 CPU 리소스를 공유할 수 있습니다. 자세한 내용은 [알려진 제한 사항](/products/sunk/run_workloads/schedule-kubernetes-pods#known-limitations)을 참조하세요.
</Info>

<h2 id="prerequisites">
  사전 요구 사항
</h2>

* [SUNK](/products/sunk)가 배포되어 있고 [SUNK Pod Scheduler](/products/sunk/run_workloads/schedule-kubernetes-pods)가 활성화된 CKS 클러스터
* [동일한 클러스터에 배포된 CoreWeave 샌드박스 러너](/ko/products/sandboxes/operations/managed-runners)
* 설치 및 인증이 완료된 [CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) (`cwic`) v1.44.0 이상. 자세한 설정 방법은 [러너 배포 및 관리](/ko/products/sandboxes/operations/managed-runners)를 참조하세요.
* 러너의 정책을 조회하고 업데이트할 수 있는 `sandbox_admin` 역할과 Slurm 배포를 업데이트할 수 있는 권한
* v1 샌드박스 API를 사용하기 위해 설치 및 인증이 완료된 `cwsandbox >= 1.0.0`
* 클러스터 검사에 사용할 `kubectl` 및 `yq`. HTTP 예시에서는 `curl`, `jq`와 함께 `$TOKEN`에 저장된 CoreWeave API 토큰도 사용합니다.

이 페이지의 모든 `[RUNNER-ID]`를 SUNK 클러스터에 있는 러너의 ID로 바꾸세요.

<h2 id="step-1-verify-the-sunk-pod-scheduler">
  1단계: SUNK Pod Scheduler 확인
</h2>

SUNK 배포가 CoreWeave 샌드박스와 함께 작동하도록 설정되어 있는지 확인하세요.

1. 스케줄러가 실행 중인지 확인하세요:

   ```bash theme={"system"}
   kubectl get pods -n tenant-slurm -l app.kubernetes.io/name=sunk-scheduler
   ```

   반환되는 파드가 없으면 Slurm Helm values에서 `scheduler.enabled: true`를 설정하여 스케줄러를 활성화하세요. 자세한 내용은 [스케줄러 활성화](/products/sunk/run_workloads/schedule-kubernetes-pods#enable-the-scheduler)를 참조하세요.

2. 스케줄러 이름을 조회하세요. 이 이름은 2단계에서 러너 정책에 설정합니다. SUNK 8.0 이상에서는 스케줄러가 ConfigMap에서 이름을 읽습니다:

   ```bash theme={"system"}
   kubectl get configmap -n tenant-slurm -l app.kubernetes.io/component=scheduler \
     -o jsonpath='{.items[0].data.scheduler\.conf}' | yq '.scheduler.name'
   ```

   ```text theme={"system"}
   slurm-scheduler
   ```

   SUNK 7.x에서는 스케줄러 파드의 `--scheduler-name` 인수로 이름을 지정합니다. 내부 동작은 [스케줄러 설정 조회](/products/sunk/run_workloads/schedule-kubernetes-pods#look-up-the-scheduler-configuration)를 참조하세요.

3. `KillWait` 값을 조회하세요. 이 값은 파드 종료를 확인하는 데 사용합니다:

   ```bash theme={"system"}
   kubectl get pods -n tenant-slurm -l app.kubernetes.io/name=sunk-scheduler -o yaml \
     | yq '.items[0].spec.containers[] | select(.name == "scheduler").args'
   ```

   출력에서 `--slurm-kill-wait`를 찾으세요:

   ```text theme={"system"}
   - --slurm-kill-wait=30s
   ```

4. 샌드박스 파드의 Slurm 종료 시간 범위를 설정하세요. SUNK에서는 `terminationGracePeriodSeconds`가 `--slurm-kill-wait`에서 5초를 뺀 값보다 반드시 작아야 합니다.

   정책은 `base.spec.terminationGracePeriodSeconds`를 허용하지 않습니다. Kubernetes의 기본 유예 기간인 30초를 사용하는 파드의 경우 `KillWait`를 35초보다 크게 설정하세요. 예를 들어, 다음 내용을 Slurm Helm values에 병합하고 일반적인 SUNK 배포 절차를 통해 업데이트를 적용하세요:

   ```yaml theme={"system"}
   slurmConfig:
     KillWait: 60
   ```

   이렇게 하면 클러스터 전체 작업의 Slurm 종료 시간 범위가 변경됩니다. 앞의 명령을 사용하여 스케줄러가 이제 `--slurm-kill-wait=60s`를 보고하는지 확인하세요. [Slurm 설정 매개변수](/products/sunk/reference/slurm-parameters#slurmConfig) 및 [종료 유예 기간 설정](/products/sunk/run_workloads/schedule-kubernetes-pods#set-the-termination-grace-period)을 참조하세요.

   <Warning>
     스냅샷을 지원하는 저장소를 사용하는 샌드박스는 파드 유예 기간이 300초일 수 있습니다. 60초의 `KillWait`로는 이러한 파드를 처리할 수 없습니다. 생성된 파드의 `terminationGracePeriodSeconds`를 확인하고 `KillWait`를 해당 값에 5초를 더한 값보다 크게 설정하세요. 300초인 경우 330과 같은 값을 사용하세요. 스케줄러의 종료 대기 시간 설정을 Slurm과 일치시키세요.
   </Warning>

5. 스케줄러 범위에 샌드박스 namespace가 포함되는지 확인하세요. namespace 선택은 러너가 관리합니다. 이는 정책 필드가 아닙니다. 새 사용자를 위해 생성된 namespace를 포함하여 모든 샌드박스 namespace를 감시하려면 `scheduler.scope.type: cluster`를 설정하세요. `scheduler.scope.type: namespace`를 사용하는 경우 각 샌드박스 namespace를 `scheduler.scope.namespaces`에 포함하고 새 namespace가 생성될 때마다 목록을 업데이트하세요. 스케줄러가 해당 namespace에서 필요한 RBAC 권한도 부여받도록 Helm을 통해 범위 변경을 적용하세요. [스케줄러 활성화](/products/sunk/run_workloads/schedule-kubernetes-pods#enable-the-scheduler)를 참조하세요.

6. 샌드박스와 공유하려는 NodeSet에서 `slurmd` 리소스 요청량을 낮추세요. 이는 샌드박스 설정이 아니라 Slurm Helm values에서 수행하는 Slurm 측 변경입니다. 기본 NodeSet 리소스 요청량은 Kubernetes에서 노드의 할당 가능한 용량 대부분을 사용하므로 샌드박스 파드를 위한 여유 공간이 남지 않습니다. 이 변경을 하지 않으면 샌드박스 파드가 `OutOfMemory` 또는 `OutOfcpu` 오류로 거부됩니다. 설정에 대한 자세한 내용은 [SUNK Pod Scheduler로 리소스 관리](/products/sunk/run_workloads/manage-scheduler-resources)를 참조하세요.

<h2 id="step-2-configure-the-runner-policy">
  2단계: 러너 정책 설정
</h2>

모든 러너에는 하나의 정책이 있습니다. 해당 정책에서 `base.spec.schedulerName`을 설정하여 샌드박스 파드를 SUNK를 통해 라우팅하세요. 별도의 정책 리소스를 생성하거나 바인딩하지 않습니다.

<Warning>
  정책 업데이트는 전체 정책 문서를 대체합니다. 현재 정책을 조회하고 기존 `base` 연결 항목과 `constraints`를 유지한 다음 SUNK에 필요한 설정만 변경하세요. 이 변경 사항은 러너의 새 샌드박스에 적용됩니다. 실행 중인 샌드박스는 이동하지 않습니다.
</Warning>

러너의 기존 정책에 다음 조각을 병합하세요. `slurm-scheduler`를 1단계의 스케줄러 이름으로 교체하세요:

```yaml theme={"system"}
base:
  spec:
    schedulerName: "slurm-scheduler"
```

<Tabs>
  <Tab title="CLI">
    현재 정책을 조회한 다음 `$EDITOR`에서 엽니다:

    ```bash theme={"system"}
    cwic sandbox runner policy get [RUNNER-ID]
    cwic sandbox runner policy edit [RUNNER-ID]
    ```

    문서의 나머지 부분은 그대로 유지하면서 `base.spec` 아래에 `schedulerName`을 추가합니다. 편집기에서 저장하고 닫으면 변경 사항이 적용됩니다.

    전체 정책을 파일로 관리하는 경우 해당 파일을 검증한 후 적용합니다:

    ```bash theme={"system"}
    cwic sandbox runner policy validate -f slurm-policy.yaml
    cwic sandbox runner policy edit [RUNNER-ID] -f slurm-policy.yaml
    ```
  </Tab>

  <Tab title="curl">
    Connect HTTP API를 사용하여 정책 리비전(`etag`)을 포함한 러너 정보를 조회합니다:

    ```bash theme={"system"}
    curl --fail-with-body --silent --show-error -X POST \
      'https://api.coreweave.com/coreweave.sandbox.v1.RunnerManagementService/GetManagedRunner' \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -H "Connect-Protocol-Version: 1" \
      --data '{"runnerId": "[RUNNER-ID]"}' \
      -o runner.json
    ```

    러너에 정책이 없는 경우 계속하기 전에 [샌드박스 정책 설정](/ko/products/sandboxes/profiles/configure)을 참조하여 정책을 설정합니다.

    다른 모든 정책 필드는 유지하면서 스케줄러 이름을 추가합니다. 조회한 `etag`를 업데이트 요청에 포함합니다:

    ```bash theme={"system"}
    jq -e '
      if .policy == null or .etag == null then
        error("Read a configured runner policy and its etag before updating")
      else . end |
      .policy.base.spec.schedulerName = "slurm-scheduler" |
      {
        runnerId: .identity.runnerId,
        managedRunner: {identity: .identity, policy: .policy, etag: .etag},
        updateMask: "policy"
      }' runner.json > runner-policy-update.json
    ```

    `runner-policy-update.json` 파일을 검토한 다음 적용합니다:

    ```bash theme={"system"}
    curl --fail-with-body -X POST \
      'https://api.coreweave.com/coreweave.sandbox.v1.RunnerManagementService/UpdateManagedRunner' \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -H "Connect-Protocol-Version: 1" \
      --data-binary @runner-policy-update.json
    ```

    `etag`가 없는 요청은 거부됩니다. 요청을 제출하기 전에 다른 Admin이 정책을 업데이트한 경우 `etag`가 최신이 아니므로 업데이트가 `FAILED_PRECONDITION`으로 실패하며 아무것도 변경되지 않습니다. 이 경우 러너를 다시 조회하고, 반환된 정책에 변경 사항을 다시 적용한 후 새 `etag`로 다시 제출합니다.
  </Tab>
</Tabs>

<Warning>
  Slurm 배치와 충돌하는 `base.spec.nodeSelector` 및 샌드박스 인스턴스 유형 제한은 사용하지 마십시오. 노드는 Slurm이 선택하므로, 충돌하는 Kubernetes 선택기가 있으면 `NodeAffinity` 실패가 발생할 수 있습니다. 특정 노드를 대상으로 지정하려면 4단계의 어노테이션을 통해 Slurm 파티션이나 제약 조건을 사용하십시오.
</Warning>

네트워크 액세스는 `constraints.network` 필드와 샌드박스에 선언된 이그레스에 의해 제어됩니다. SUNK 스케줄링을 추가할 때는 러너의 기존 네트워크 제약 조건을 그대로 유지합니다. 자세한 내용은 [샌드박스 정책 설정](/ko/products/sandboxes/profiles/configure#constrain-network-access)을 참조하십시오.

정책 변경 사항이 샌드박스 생성에 반영되기까지 시간이 걸릴 수 있습니다. 새 스케줄러나 고정된 어노테이션을 사용하기 전에 샌드박스를 생성하고 [Pods remain pending](#pods-remain-pending)에 설명된 대로 해당 파드 필드를 확인하십시오. 정책을 조회하면 새 값이 표시되더라도 새 샌드박스에는 아직 적용되지 않았을 수 있습니다.

전체 스키마는 [정책 레퍼런스](/ko/products/sandboxes/reference/profile)를 참조하십시오. 러너 설정은 [러너 배포 및 관리](/ko/products/sandboxes/operations/managed-runners)를 참조하십시오.

<h2 id="step-3-create-sandboxes">
  3단계: 샌드박스 만들기
</h2>

`placement_mode="cks"`를 설정하고, `runner_ids`로 정책을 설정한 러너를 선택하세요. 스케줄러는 러너 정책이 자동으로 지정합니다.

```python theme={"system"}
from cwsandbox import Sandbox

with Sandbox.run(placement_mode="cks", runner_ids=["[RUNNER-ID]"]) as sb:
    print(f"Sandbox ID: {sb.sandbox_id}")
    result = sb.exec(["hostname"]).result()
    print(result.stdout)
```

샌드박스가 Slurm 작업으로 실행 중인지 확인하려면, 앞선 예시에서 출력된 샌드박스 ID를 사용하여 Slurm에서 해당 플레이스홀더 작업을 검색하세요:

```bash theme={"system"}
sacct --format=JobID,JobName%60,State,NodeList -X | grep [SANDBOX-ID]
```

Slurm이 노드를 선택합니다. Slurm의 스케줄러를 안내하기 위해 [Slurm 어노테이션](#step-4-control-placement-with-slurm-annotations)을 추가하지 않는 한, 샌드박스가 어느 노드에 배치될지 제어할 수 없습니다.

세션의 모든 샌드박스에 대해 SUNK로 설정된 동일한 러너를 사용하려면 `SandboxDefaults`에서 배치 필드를 설정하세요:

```python theme={"system"}
from cwsandbox import Sandbox, SandboxDefaults

defaults = SandboxDefaults(
    placement_mode="cks",
    runner_ids=("[RUNNER-ID]",),
)

with Sandbox.session(defaults) as session:
    sb1 = session.sandbox()
    sb2 = session.sandbox()

    r1 = sb1.exec(["hostname"]).result()
    r2 = sb2.exec(["hostname"]).result()
    print(f"sb1: {r1.stdout.strip()}, sb2: {r2.stdout.strip()}")
```

<h3 id="resource-requests-and-slurm-accounting">
  리소스 요청과 Slurm 어카운팅
</h3>

SUNK는 파드의 리소스 **요청**(limits가 아님)을 조회하고 이를 Slurm 작업 매개변수로 변환합니다:

| 파드 field | Slurm 매개변수 |
| - | - |
| `requests.cpu` | `CPUsPerTask` |
| `requests.memory` | `MinMemoryNode` |

Slurm은 이러한 값을 스케줄링 결정과 `sacct` 어카운팅에 사용합니다. SUNK는 특정 Quality of Service 클래스를 요구하지 않습니다. Guaranteed(리소스 요청이 limits와 같음)와 Burstable(리소스 요청이 limits보다 낮음) 모두 작동합니다.

`ResourceOptions`로 리소스 요청을 limits보다 낮게 설정하면, 용량이 여유 있을 때 파드가 limits까지 burst할 수 있지만, Slurm은 리소스 요청만 봅니다. 예를 들어, 다음과 같이 설정된 샌드박스:

```python theme={"system"}
requests={"cpu": "500m", "memory": "512Mi"},
limits={"cpu": "2",     "memory": "2Gi"},
```

`sacct`에는 500m CPU, 512Mi 메모리 작업으로 표시됩니다. 샌드박스는 노드에 여유가 있을 때 최대 2 CPU와 2Gi까지 사용할 수 있습니다. 전체 `ResourceOptions` 레퍼런스는 [리소스](/ko/products/sandboxes/client/guides/sandbox-configuration#resources)를 참조하세요.

샌드박스 워크로드에 필요한 만큼 요청을 설정하되, 1단계에서 낮춘 `slurmd` 요청을 수용할 수 있도록 대상 노드에 충분한 여유를 남겨 두세요. 기본 규칙은 [리소스 요청 설정](/products/sunk/run_workloads/schedule-kubernetes-pods#set-resource-requests) 및 [SUNK Pod Scheduler로 리소스 관리](/products/sunk/run_workloads/manage-scheduler-resources)를 참조하세요.

<h2 id="step-4-control-placement-with-slurm-annotations">
  단계 4: Slurm 어노테이션으로 샌드박스 배치 제어
</h2>

샌드박스 배치를 제어하려면, 샌드박스를 시작할 때 SUNK 어노테이션을 설정하세요. 다음 예시는 샌드박스를 `hpc-prod` 파티션에 고정합니다:

```python theme={"system"}
from cwsandbox import Sandbox

sb = Sandbox.run(
    placement_mode="cks",
    runner_ids=["[RUNNER-ID]"],
    annotations={
        "sunk.coreweave.com/partition": "hpc-prod",
    },
)
```

<h3 id="common-annotations">
  공통 어노테이션
</h3>

모든 어노테이션은 `sunk.coreweave.com/` 접두사를 공유합니다. 샌드박스 배치를 제어하는 데 일반적으로 사용되는 어노테이션은 다음과 같습니다.

| 어노테이션 키 | 설명 |
| - | - |
| `partition` | Slurm 파티션 이름 |
| `constraint` | Slurm 기능 제약 조건 |
| `account` | Slurm 어카운팅 이름 |
| `qos` | Slurm QoS 수준 |
| `user-id` | 어카운팅에 사용할 Slurm 사용자 ID. 숫자로 된 Linux UID여야 합니다(예: `"1000"`) |
| `exclusive` | 노드 독점 사용 여부(`none`, `user` 또는 `ok`) |

`user-id` 어노테이션에 숫자 UID 대신 사용자 이름을 전달하면 블로킹 오류가 발생하여 Slurm이 샌드박스를 스케줄링할 수 없습니다. Slurm 로그인 노드에서 숫자 UID를 확인하려면 `[USERNAME]`을 조회할 Linux 사용자 이름으로 바꾸세요.

```bash theme={"system"}
id -u           # 자신의 UID
id -u [USERNAME]  # 다른 사람의 UID
whoami          # 필요한 경우 먼저 사용자 이름을 확인하세요
```

전체 목록은 [어노테이션 레퍼런스](/products/sunk/run_workloads/schedule-kubernetes-pods#annotations-reference)를 참조하세요.

<h3 id="enforce-annotations-in-the-policy">
  정책에서 어노테이션 강제 적용하기
</h3>

러너의 모든 샌드박스에 Slurm 작업 매개변수를 설정하려면 해당 어노테이션을 `base.metadata.annotations`에 추가하세요. 예를 들어, `sandboxes` 파티션을 사용하려면 다음 구성 조각을 기존 정책에 병합하세요.

```yaml theme={"system"}
base:
  metadata:
    annotations:
      sunk.coreweave.com/partition: "sandboxes"
  spec:
    schedulerName: "slurm-scheduler"
```

정책 어노테이션은 동일한 키에 대해 클라이언트가 제공한 값보다 우선합니다. 클라이언트가 값을 선택할 수 있도록 하려면 `base.metadata.annotations`에서 해당 키를 생략하고 `constraints.metadata.denied_annotation_prefixes`에서 이를 허용하는지 확인하세요. 예를 들어, 클라이언트가 트레이닝 작업의 사용자와 일치시켜야 하는 경우 `sunk.coreweave.com/user-id`를 고정하지 마세요.

<h3 id="match-the-slurm-user-from-a-training-job">
  트레이닝 작업에서 Slurm 사용자 일치
</h3>

트레이닝 작업은 종종 `--exclusive=user`를 사용하여 단일 사용자에게 전체 노드를 점유합니다. 이는 다른 사용자의 작업이 해당 노드의 리소스를 경쟁하지 못하게 하면서도 동일한 사용자가 추가 작업(예: GPU 트레이닝과 함께 여유 CPU를 사용하는 샌드박스)을 실행할 수 있도록 합니다.

기본적으로 SUNK 플레이스홀더 작업은 root(UID 0)로 실행됩니다. root는 트레이닝 작업을 제출한 사용자와 다른 사용자이므로, Slurm은 샌드박스 플레이스홀더를 전용 노드에 배치하지 않습니다.

트레이닝 코드가 실행 중인 Slurm 작업 내에서 `cwsandbox` Python client를 사용하여 샌드박스를 생성할 때, 환경에서 작업의 Slurm 사용자 ID를 조회하여 어노테이션으로 전달할 수 있습니다. 이를 통해 샌드박스 플레이스홀더 작업이 트레이닝 작업과 동일한 Slurm 사용자로 제출되어, Slurm이 동일한 전용 노드에 배치할 수 있게 됩니다:

```python theme={"system"}
import os
from cwsandbox import Sandbox, SandboxDefaults

slurm_uid = os.environ["SLURM_JOB_UID"]

defaults = SandboxDefaults(
    placement_mode="cks",
    runner_ids=("[RUNNER-ID]",),
    annotations={
        "sunk.coreweave.com/user-id": slurm_uid,
    },
)

with Sandbox.session(defaults) as session:
    sb = session.sandbox()
    result = sb.exec(["hostname"]).result()
    print(result.stdout)
```

`user-id` 어노테이션은 사용자 이름이 아닌 숫자 Linux UID여야 합니다. 설정되면 SUNK는 `group-id`도 동일한 값으로 기본 설정합니다. 그룹 ID가 다르면 `sunk.coreweave.com/group-id`를 별도로 설정하세요.

<h2 id="troubleshooting">
  문제 해결
</h2>

SUNK Pod Scheduler를 통해 샌드박스를 실행할 때 흔히 발생하는 문제는 다음 섹션을 참고하여 진단하세요.

<h3 id="pods-remain-pending">
  Pods remain pending
</h3>

샌드박스 파드를 검사하여 러너가 스케줄러 이름을 적용했는지 확인하고 종료 유예 기간을 확인하세요:

```bash theme={"system"}
kubectl get pods -A -l 'sandbox.coreweave.com/sandbox-id=[SANDBOX-ID]' \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,SCHEDULER:.spec.schedulerName,GRACE:.spec.terminationGracePeriodSeconds,PARTITION:.metadata.annotations.sunk\.coreweave\.com/partition'
```

샌드박스가 활성 상태일 때 이 명령을 실행하세요. `SCHEDULER`가 SUNK 스케줄러와 일치하는지, 범위에 `NAMESPACE`가 포함되는지, `GRACE`가 스케줄러의 종료 대기 시간에서 5초를 뺀 값보다 엄격하게 작은지 확인하세요. 기본 30초 종료 대기 시간에서는 30초 유예 기간이 실패합니다. 정책이 파티션을 고정하는 경우, `PARTITION`이 일치하는지 확인하세요.

스케줄러 이름이나 고정된 어노테이션이 누락되었거나 올바르지 않으면, 러너 정책을 조회하여 클라이언트가 의도한 러너를 선택했는지 확인하세요. 새로 생성된 파드가 이전 값을 계속 사용하는 경우, 정책 전파를 위해 더 기다린 후 다른 샌드박스로 재시도하세요.

<h3 id="placeholder-jobs-temporarily-in-completing-state">
  플레이스홀더 작업이 일시적으로 completing 상태에 있음
</h3>

샌드박스가 중지되면, 해당 Slurm 플레이스홀더 작업은 정리 스크립트가 실행되고 노드가 풀에 반환되는 동안 `CG` (completing) 상태에 30\~60초 동안 머무릅니다. 이는 정상적인 Slurm 동작이며 동일한 노드에서 실행 중인 다른 작업에 영향을 주지 않습니다. 전체 상태 레퍼런스는 [Slurm 작업 상태](/products/sunk/manage_sunk/slurm-job-states)를 참조하세요.

<h3 id="sandboxes-not-landing-where-expected">
  샌드박스가 예상한 위치에 배치되지 않음
</h3>

Slurm은 정책에서 설정하거나 클라이언트가 전달하는 어노테이션을 기반으로 샌드박스 배치 위치를 확인합니다. 샌드박스가 예상한 노드에 배치되지 않는 경우 Slurm 작업 매개변수를 확인하세요.

SUNK는 각 샌드박스 파드에 대해 `<namespace>/<pod-name>`이라는 이름의 플레이스홀더 Slurm 작업을 생성합니다. 파드 이름에는 샌드박스 ID가 포함되며, 이 ID는 클라이언트의 `sb.sandbox_id`로 확인할 수 있습니다. 샌드박스 ID를 검색하여 플레이스홀더 작업을 찾고 매개변수를 확인하세요:

```bash theme={"system"}
sacct --format=JobID,JobName%60,Partition,Account,AllocCPUS,ReqMem,State,NodeList,Start,End -X \
  | grep [SANDBOX-ID]
```

`[SANDBOX-ID]`을 Python client의 `sb.sandbox_id` 값으로 교체하세요.

<h2 id="see-also">
  참고
</h2>

* [CoreWeave 샌드박스 소개](/ko/products/sandboxes)
* [러너 배포 및 관리](/ko/products/sandboxes/operations/managed-runners)
* [샌드박스 정책 설정](/ko/products/sandboxes/profiles/configure)
* [SUNK Pod Scheduler로 Kubernetes 파드 예약](/products/sunk/run_workloads/schedule-kubernetes-pods)
* [샌드박스를 사용한 RL 트레이닝](/ko/products/sandboxes/client/guides/rl-training)
* [샌드박스 설정](/ko/products/sandboxes/client/guides/sandbox-configuration)