샌드박스 리소스
- 관리형 러너: CKS 클러스터 중 하나에서 실행되며 CoreWeave가 운영하는 컴포넌트입니다. 러너는 해당 클러스터에서 샌드박스를 배치하고 감독하며 종료합니다. 각 클러스터에는 관리형 러너를 최대 하나만 호스팅할 수 있으며, CoreWeave는 사용자가 선택한
RELEASE_CHANNEL_STABLE또는RELEASE_CHANNEL_RAPID채널에 따라 러너를 최신 상태로 유지합니다. - 정책: 클러스터의 샌드박스가 요청할 수 있는 항목과 기본적으로 할당받는 항목을 정의합니다. 정책은 독립적인 리소스가 아니며 자체 엔드포인트도 없습니다. 정책은 러너의 필드이므로 각 클러스터에는 정확히 하나의 정책이 적용됩니다. 정책을 작성하려면 샌드박스 정책 설정을 참조하세요.
- 샌드박스: 클러스터에서 실행되는 격리된 워크로드입니다. 샌드박스는 필요한 이미지, 컴퓨팅, 네트워크 액세스, 수명을 직접 선언하므로 그 자체로 완전하게 정의됩니다. 샌드박스는 Python client를 통해 필요할 때 생성됩니다.
api.cwsandbox.com에서 제공되는 CoreWeave 서비스로, 모든 클라이언트 Call을 인증하고, 샌드박스를 호스팅할 수 있는 러너를 선택하며, 클라이언트와 각 샌드박스를 소유한 러너 간의 트래픽을 전달합니다. 샌드박스가 실행된 후에는 게이트웨이를 거치지 않는 직접 mTLS 연결을 통해서도 데이터 오퍼레이션을 주고받을 수 있습니다. 자세한 내용은 샌드박스 직접 연결을 참조하세요.
주요 제약 사항
- 클러스터는 최대 하나의 관리형 러너를 호스팅하며, 각 러너에는 정확히 하나의 정책이 있습니다. 따라서 하나의 정책이 하나의 클러스터를 관리합니다. 다른 보안 태세로 샌드박스를 실행하려면 다른 클러스터에 러너를 배포하고 별도의 정책을 부여하세요.
- 정책은 필수입니다. 빈 정책도 유효하며 모든 것을 허용하는 보안 태세를 선언합니다. 따라서 클러스터의 보안 태세는 의도치 않게 상속되는 대신 항상 명시됩니다.
- 정책에서 기본 샌드박스 수명을 지정할 수 있으며, 플랫폼은 최대 30일 제한을 강제 적용합니다.
- 정책을 수정하면 수정 이후에 생성된 샌드박스에 적용됩니다. 실행 중인 샌드박스는 시작 시 적용된 정책을 유지합니다.
- 클러스터 내에서는 사용자별 또는 팀별로 적용 범위를 지정할 수 없습니다. 정책은 생성한 사람과 관계없이 해당 클러스터에 배치된 모든 샌드박스에 적용됩니다.
리소스 관계
러너는 이들을 서로 연결하는 역할을 합니다. 러너는 자신의 클러스터를 관리하는 정책을 가지고 있으며, 모든 샌드박스를 해당 클러스터에 배치합니다. 샌드박스가 필요한 리소스를 명시하면, 정책이 해당 요청의 허용 여부를 결정합니다. 러너는 정책의 기본값 위에 샌드박스 사양을 병합한 다음, 그 결과가 제약 조건을 충족하는지 검증합니다. 제약 조건을 위반하는 값은 임의로 축소되지 않고 거부되며, 오류 메시지에 거부된 항목이 표시됩니다. 정책 개요를 참조하세요.멀티 클러스터 범위
각 클러스터에는 자체 러너와 정책이 있습니다. 사용자는 이러한 토폴로지를 알 필요가 없습니다. 필요한 설정을 갖춘 샌드박스를 SDK에 요청하면, 게이트웨이가 해당 요청을 허용하는 정책이 있는 클러스터로 요청을 라우팅합니다. CKS 배치의 경우, 게이트웨이는 조직 내 여러 클러스터 중에서 컴퓨팅을 선택합니다. 러너 ID 제한이 없으면 가용 용량이 있고 러너 정책상 해당 샌드박스 요청이 허용되는 클러스터를 선택합니다. 보안 태세는 클러스터별로 정해지므로, 허용 범위가 넓은 환경과 제한된 환경이 모두 필요한 팀은 하나의 클러스터에 두 가지 설정을 적용하는 대신 두 개의 클러스터를 운영합니다.샌드박스가 시작되는 방식
리소스는 두 서비스 영역을 거칩니다.api.coreweave.com의 컨트롤 플레인에서는 러너와 각 러너에 적용되는 정책을 정의합니다. api.cwsandbox.com의 데이터 플레인에서는 샌드박스를 시작하고 운영합니다. 장애와 액세스 제어를 고려할 때 이 구분은 중요합니다. 컨트롤 플레인 장애는 러너와 정책의 수정을 차단하지만 이미 실행 중인 샌드박스에는 영향을 주지 않습니다. 반면 데이터 플레인 장애는 처리 중인 샌드박스 트래픽에 영향을 주지만 컨트롤 플레인에 저장된 설정에는 영향을 주지 않습니다.
컨트롤 플레인: 일회성 설정
Admin은 CoreWeave Intelligent CLI 또는 REST API를 사용해 CKS 클러스터에 러너를 배포하고, 러너에 적용할 정책을 설정합니다. 그러면 컨트롤 플레인이 러너를 클러스터에 배포하며, 러너는 하트비트를 통해 상태를 보고합니다. 이 단계는 클러스터마다 한 번 수행되며, 이후 정책을 변경할 때마다 다시 수행됩니다. 해당 워크플로는 샌드박스 정책 설정 및 러너 배포 및 관리를 참조하세요.데이터 영역: 샌드박스 시작
클라이언트가 샌드박스를 시작하면 게이트웨이는 조건에 맞는 러너를 선택해 배치 요청을 보냅니다. 러너는 자체 정책을 기준으로 샌드박스 사양을 확정하고, 그 결과에 따라 샌드박스를 생성합니다. 러너는 샌드박스가 시작될 때까지 기다리지 않고 생성하는 즉시 배치를 허용합니다. 따라서 클라이언트는 샌드박스가 아직 시작되는 동안 샌드박스 ID를 받게 됩니다. 시작 요청에 성공 응답이 반환되었다면 러너가 샌드박스를 수락했다는 뜻일 뿐, 샌드박스가 명령어를 실행할 준비가 되었다는 의미는 아닙니다. 샌드박스를 사용하기 전에RUNNING 상태가 될 때까지 대기하거나 폴링하세요. 시작에 실패하면 샌드박스는 FAILED 상태로 전환됩니다. 또한 메인 명령이 상태 코드 0으로 빠르게 종료되면 RUNNING을 거치지 않고 COMPLETED 상태에 도달할 수도 있습니다. 두 가지 종료 상태를 모두 처리하세요. Python SDK의 wait()는 폴링을 자동으로 수행하며, exec()와 같은 오퍼레이션은 실행 전에 RUNNING 상태가 될 때까지 대기합니다. 자세한 내용은 샌드박스 라이프사이클을 참조하세요.
사용자가 실제로 체감하는 것은 거부 경로입니다. 오류 메시지에 실패한 제약 조건이 명시되므로, 클러스터에서 허용하지 않는 항목을 요청한 사용자는 보안 태세를 미리 파악하지 않아도 무엇을 변경해야 하는지, 또는 Admin에게 무엇을 요청해야 하는지 알 수 있습니다.
데이터 영역: 샌드박스 오퍼레이션 실행
샌드박스가 배치되면 이후 클라이언트 Call(exec, 파일 오퍼레이션, 중지)은 게이트웨이를 통해 해당 샌드박스를 소유한 러너로 전달되고, 거기서 샌드박스 자체로 전달됩니다.
실행, 로깅 및 파일 오퍼레이션도 게이트웨이를 완전히 우회할 수 있습니다. Python SDK는 클라이언트에서 샌드박스로의 직접 mTLS 연결을 우선 사용하며, 직접 액세스가 불가능한 경우 위에 표시된 게이트웨이 경로로 대체합니다. 라이프사이클 및 관리 Call은 항상 게이트웨이를 사용합니다. 샌드박스 직접 연결을 참조하세요.
컨트롤 플레인 리소스
컨트롤 플레인은 러너를 관리 리소스로 노출합니다. 정책은 이를 수행하는 러너를 통해 접근하며, 자체 엔드포인트가 아닙니다.
컨트롤 플레인 API 개요에서는 이러한 엔드포인트에 대한 인증, 필드 마스크, 하트비트 및 request와 response 형태를 다룹니다.
참고 자료
- 자체 컴퓨팅 사용하기: 러너를 활성화하고 샌드박스를 실행하세요.
- 정책 개요: 샌드박스에 정책이 적용되는 방식입니다.
- 샌드박스 정책 설정: 모든 제약 조건 그룹과 구체적인 예시입니다.
- 러너 배포 및 관리: 관리형 러너의 라이프사이클입니다.
- 컨트롤 플레인 API 개요: 인증, 필드 마스크, 모든 엔드포인트의 요청 및 응답 구조입니다.
- Protobuf: 각 서비스를 제공하는 호스트와 게시된 Protobuf 모듈로 클라이언트를 생성하는 방법입니다.