GKE上のRay・gVisorサンドボックスとGKE Sandboxの違い、実行場所と準備する設定

GKEで生成コードをRay APIから隔離実行したいなら、まずRay 2.58.0のKubeRay導入例で、ワーカー内のrunscを準備する構成を確認します。PodそのものをgVisorで動かしたい場合は、GKE Sandboxの利用条件とPod設定が確認先です。同じgVisorを使っていても、準備する場所が異なります。 [3] [4]

Rayからコードを試すなら、ワーカーの準備から始める

原記事の論点GKE で Ray サンドボックスを試す → GKEでRayサンドボックスを試すユーザーガイド ／ Ray プリミティブとしてのサンドボックス → OCIイメージから環境を作りアクターハンドルを得る高水準API ／ gVisor を選ぶ理由 → 生成コードを信頼できないものとして扱いgVisorで追加の隔離を設ける／Linuxシステムコールのユーザー空間実装とホストカーネルとの分離境界／OCI互換と標準イメージ、Dockerデーモン/ホストソケットを公開しない構成

確認に使った資料Ray 2.58.0：Deploy Ray sandboxes with KubeRay — Step 1・Step 3・Optional Step 5 [3]

Rayのガイドは、Linuxとcontainerdを使う通常のGKEノードプールを例にしています。runscをRayワーカーコンテナ内からrootlessで動かすため、GKE Sandbox用ノードプールを前提にした手順ではありません。まずこの例に沿って試す構成なのかを決め、二つのガイドの設定を混ぜずに準備します。 [3]

Google Cloudは、gVisorがLinuxのシステムコールの多くをユーザー空間に実装し、処理とホストカーネルの間へ分離境界を加える点を紹介しています。OCI互換イメージを使え、DockerデーモンやホストのDockerソケットをサンドボックスへ公開する必要もありません。この構成を試す際に準備する実行プログラムは、ワーカー内のrunscです。 [1] [3]

KubeRayを導入した後、runscと必要なsecurityContextを備えたRayClusterを作成し、処理を実行するRayJobを用意します。例のジョブはsandbox.create()で環境を作り、コードを書き込み、実行して削除します。個々のサンドボックスを作るたびに別のPodを用意する例ではありません。 [3]

最初の動作確認では、ワーカー内のPATHからrunscを呼べることを確認し、公式例のジョブで終了コードと標準出力、削除後の完了ログを追います。作成や実行のどこで止まるかを切り分けてから、自分たちの処理に置き換えます。この一例の成功は、すべてのコードや構成の動作・安全性を保証するものではありません。 [3]

Podを隔離したいなら、GKE側の利用条件を確認する

原記事の論点GKE で Ray サンドボックスを試す → GKEでRayサンドボックスを試すユーザーガイド

確認に使った資料Google Cloud：GKE Sandboxを使用する — Use GKE Sandbox in Autopilot and Standard・Run an application in a sandbox [4]

GKE Sandboxを使う場合は、クラスタのモード・バージョンなどの利用条件を確認し、Podの仕様にruntimeClassName: gvisorを指定します。GKE StandardではGKE Sandboxを有効にしたノードプールも必要です。Ray APIで環境を作る操作とは、準備する対象を分けて考えます。 [3] [4]

GKE Sandboxで動いているかは、Kubernetes側からPodのruntimeClassNameがgvisorになっていることを確認します。公式資料は、Pod内部のプログラムが返す情報を根拠にしない確認方法を案内しています。期待した設定になっていなければ、Podのマニフェストと適用先を見直します。 [4]

採用する版と設定をそろえてから、自分たちの処理を試す

原記事の論点GKE で Ray サンドボックスを試す → GKEでRayサンドボックスを試すユーザーガイド ／ Ray プリミティブとしてのサンドボックス → CPU・メモリの予約とAPIでの資源指定

確認に使った資料Ray 2.58.0：Ray Sandboxes／Ray 2.58.0：Deploy Ray sandboxes with KubeRay／Google Cloud：GKE Sandboxを使用する — S2：Warning・Requirements／S8：Step 3のmasterサンプルURL／S9：Enable GKE Sandbox [2] [3] [4]

Ray SandboxesはAPIが変更・削除され得るalpha版です。2.58.0のガイドが参照するKubeRayサンプルYAMLもmasterの可変URLなので、使うRayの版、ワーカーイメージ、実際に適用するsecurityContextを一組として記録します。固定版のガイドを読んだだけで、適用するサンプルまで同じ版だとは判断できません。 [2] [3]

CPU・メモリも、Rayスケジューラによる予約と、実行時に上限を効かせる仕組みを分けて確認します。gVisorの資源制限はホスト側のcgroupsに依存します。上限が必要な処理では、採用するGKE構成でcgroupsが働く条件を確認し、予約値の指定だけで実効制限を確認したことにしないようにします。 [1] [5] [3]

Rayの例ではrunscをPod起動時にダウンロードしますが、本番向けにはワーカーイメージへ事前に組み込む方法も案内されています。起動時の取得に依存させたくない場合は、この方法を検討します。GKE Sandboxとの併用を考える場合も、名称が共通だから動くと判断せず、両方の利用条件を確認したうえで、その組み合わせの動作検証を別に行います。 [3] [4]