サンドボックスのリソース
- マネージドランナー: お客様の CKS クラスターのいずれかで動作する、CoreWeave が運用するコンポーネントです。ランナーは、そのクラスター上でサンドボックスの配置、監視、破棄を行います。1 つのクラスターでホストできるマネージドランナーは最大 1 つで、CoreWeave は選択された
RELEASE_CHANNEL_STABLEまたはRELEASE_CHANNEL_RAPIDチャンネルに従ってランナーを常に最新の状態に保ちます。 - ポリシー: クラスター上のサンドボックスが要求できる内容と、デフォルトで割り当てられる内容を定めます。ポリシーは独立したリソースではなく、専用のエンドポイントも持ちません。ポリシーはランナーのフィールドの 1 つであるため、各クラスターに適用されるポリシーは常に 1 つだけです。ポリシーの作成方法については、サンドボックスポリシーを設定するを参照してください。
- サンドボックス: お客様のクラスター上で実行される、分離されたワークロードです。サンドボックスは、必要なイメージ、コンピュート、ネットワークアクセス、有効期間をすべて自ら宣言します。サンドボックスは Python クライアントを使用してオンデマンドで作成します。
api.cwsandbox.com で提供される CoreWeave のサービスで、クライアントからのすべての呼び出しを認証し、サンドボックスをホストできるランナーを選択して、クライアントと各サンドボックスを所有するランナーとの間でトラフィックを中継します。サンドボックスの実行開始後は、ゲートウェイを経由せずに直接 mTLS 接続を使用してデータ操作を行うこともできます。詳しくは、サンドボックスへの直接接続を参照してください。
主な制約
- 1 つのクラスターでホストできるマネージドランナーは最大 1 つで、各ランナーには必ず 1 つのポリシーが設定されます。つまり、1 つのクラスターは 1 つのポリシーによって管理されます。異なるポスチャーでサンドボックスを実行するには、別のクラスターにランナーをデプロイし、そのランナーに専用のポリシーを設定してください。
- ポリシーは必須です。空のポリシーも有効で、制限のない完全に許可されたポスチャーを宣言します。これにより、クラスターのポスチャーが意図せず継承されることはなく、常に明示的に定義されます。
- ポリシーでは、サンドボックスのライフタイムのデフォルト値を指定できます。最大値の 30 日はプラットフォームによって強制されます。
- ポリシーの変更は、変更後に作成されたサンドボックスにのみ適用されます。実行中のサンドボックスには、起動時に解決されたポリシーが引き続き適用されます。
- クラスター内でユーザー単位やチーム単位のスコープを設定することはできません。ポリシーは、作成者にかかわらず、そのクラスターに配置されたすべてのサンドボックスに適用されます。
リソース間の関係
ランナーは両者をつなぐ役割を担います。ランナーは自身のクラスターを管理するポリシーを保持し、すべてのサンドボックスをそのクラスター上に配置します。サンドボックスは必要なリソースを宣言し、ポリシーはそのリクエストを許可するかどうかを判断します。 ランナーは、サンドボックスの spec をポリシーのデフォルトにマージしたうえで、その結果を制約に照らして検証します。違反がある場合は、黙って範囲を狭めることはせずに拒否し、拒否した内容をエラーに明示します。詳しくは ポリシーの概要 を参照してください。マルチクラスターのスコープ
各クラスターには、それぞれ独自のランナーとポリシーがあります。ユーザーがこのトポロジを意識する必要はありません。必要な設定のサンドボックスを SDK にリクエストするだけで、ゲートウェイがそのリクエストを受け入れるポリシーを持つクラスターへルーティングします。 CKS での配置では、ゲートウェイが組織内のクラスター全体からコンピュートを選択します。ランナー ID による制限がない場合は、空き容量があり、かつランナーのポリシーがサンドボックスのリクエストを許可するクラスターが選択されます。 ポスチャーはクラスターごとに定義されるため、許容範囲の広い環境と制限の厳しい環境の両方を必要とするチームは、1 つのクラスターで 2 つの設定を使用するのではなく、2 つのクラスターを運用します。サンドボックスの起動の仕組み
リソースは 2 つのサービス面を経由します。api.coreweave.com の コントロールプレーンでは、ランナーと各ランナーに適用するポリシーを定義します。api.cwsandbox.com の データプレーンでは、サンドボックスを起動して操作します。この分離は、障害やアクセス制御を検討する際に重要です。コントロールプレーンの障害はランナーやポリシーの編集を妨げますが、すでに実行中のサンドボックスには影響しません。一方、データプレーンの障害は処理中のサンドボックスのトラフィックに影響しますが、コントロールプレーンに保存されている設定には影響しません。
コントロールプレーン: 初回設定
管理者は CoreWeave Intelligent CLI または REST API を使用して、CKS クラスターにランナーをデプロイし、そのランナーに適用するポリシーを設定します。その後、コントロールプレーンがクラスター内にランナーをデプロイし、ランナーはハートビートを通じて状態を報告します。 このステップはクラスターごとに一度実行し、その後はポリシーを変更するたびに再度実行します。対応するワークフローについては、サンドボックスポリシーを設定するとランナーのデプロイと管理を参照してください。データプレーン: サンドボックスの起動
クライアントがサンドボックスを起動すると、ゲートウェイは条件を満たすランナーを選び、そのランナーに配置リクエストを送信します。ランナーは自身のポリシーに照らしてサンドボックスの spec を解決し、その結果をもとにサンドボックスを作成します。ランナーはサンドボックスの起動完了を待たず、作成した時点で配置を受け入れます。そのため、クライアントはサンドボックスの起動中にサンドボックス ID を受け取ることになります。 開始リクエストに対して成功の応答が返っても、それはランナーがサンドボックスを受け付けたことを示すだけで、サンドボックスがすでにコマンドを実行できる状態になったことを意味するわけではありません。サンドボックスを使用する前に、RUNNING になるまで待機するか、ポーリングしてください。起動に失敗した場合、サンドボックスは FAILED に移行します。また、メインコマンドがステータス 0 ですぐに終了した場合は、RUNNING になる前に COMPLETED に達することもあります。どちらの終端状態にも対応できるようにしてください。Python SDK の wait() はポーリングを自動で行います。また、exec() などの操作は、実行前に RUNNING になるまで待機します。詳細は サンドボックスのライフサイクル を参照してください。
ユーザーが実際に意識するのは、リクエストが拒否された場合です。エラーには満たされなかった制約が示されるため、クラスターで許可されていない内容を要求したユーザーは、事前にポスチャーを確認しておかなくても、何を変更すればよいか、あるいは管理者に何を依頼すればよいかを把握できます。
データプレーン: サンドボックス操作の実行
サンドボックスが配置されると、それ以降のクライアントからの 呼び出し (exec、ファイル操作、停止) は、ゲートウェイを経由してサンドボックスを管理するランナーに送られ、そこからサンドボックス自体に送られます。
Exec、ログ、ファイル操作もゲートウェイを完全に迂回できます。Python SDK はクライアントからサンドボックスへの直接 mTLS 接続を優先し、直接アクセスできない場合は、上記のゲートウェイ経由の経路にフォールバックします。ライフサイクルと管理の 呼び出し は常にゲートウェイを使用します。サンドボックスへの直接接続を参照してください。
コントロールプレーンのリソース
コントロールプレーンは、管理用のリソースとしてランナーを公開します。ポリシーには専用のエンドポイントがなく、そのポリシーを保持するランナーを通じてアクセスします。
コントロールプレーン API の概要では、これらのエンドポイントの認証、フィールドマスク、ハートビート、およびリクエストと応答の形式について説明しています。
関連情報
- 独自のコンピュートを使用する: ランナーを有効にして、サンドボックスを起動します。
- ポリシーの概要: サンドボックスがポリシーに基づいて解決される仕組みを説明します。
- サンドボックスポリシーを設定する: すべての制約グループを具体例とともに説明します。
- ランナーのデプロイと管理: マネージドランナーのライフサイクルを説明します。
- コントロールプレーン API の概要: 認証、フィールドマスク、および各エンドポイントのリクエストと応答の構造を説明します。
- Protobuf: 各サービスを提供するホストと、公開されている Protobuf モジュールからクライアントを生成する方法を説明します。