Editing Openai/692aba85-5b10-8006-817a-d5a83b020f8e (section)

===== 2.3 Prime Sandboxes：コード実行基盤 =====

====== 2.3.1 素朴な Kubernetes 実装の限界 ======

「kubectl exec でエフェメラル Pod に入ってコードを走らせる」という素朴な設計だと、
* API Server & etcd が制御プレーンのボトルネックになり、
* 数千並列のとき 1コマンドのレイテンシが2.5秒まで悪化した、という測定結果が示されています。INTELLECT_3_Technical_Report

====== 2.3.2 Prime Sandboxes のアーキテクチャ ======

これを解決するために、
* Rust 製 Gateway - 軽量HTTP APIで実行リクエストを受付 - Kubernetes APIではなく Headless Service を通じてPod IPを直接解決 - kube-proxy を迂回し、Pod へ直接接続
* 高スループット CoreDNS - Headless Service 由来の大量のAレコード更新に耐えるよう、CoreDNS構成をカスタム
* Sidecar パターンのサンドボックスPod - 特権 sidecar が nsenter でターゲットコンテナの namespace 内へ侵入してコマンド実行 - これにより ローカルプロセス並の速度とフルコンテナ隔離を両立

というかなり攻めた設計になっています。INTELLECT_3_Technical_Report

====== 2.3.3 非同期ライフサイクル管理 ======

Pod の Ready 検知も、
* Kubernetes API や Kopf controller でのイベント監視に頼ると、 - 大量Pod同時起動でバックログが溜まり、 - 実際には起動済みなのに「Ready通知が来ない」時間が長くなる

ため、
* Kopf はエラーハンドリング等のメンテ専用に縮小し、
* Pod 側の sidecar からトレーニングバックエンドへ Webhook を直接送ることで 起動完了を即時通知する方式に変更。
* この結果、クラスタ負荷に関わらず 起動から Ready まで常に < 10 秒に抑えられたと報告。INTELLECT_3_Technical_Report

====== 2.3.4 イメージ配布と高密度化 ======

イメージ配布は2段構え：
# 専用レジストリ＋Lazy Pulling - 動的環境向け - エントリポイントに必要なレイヤだけ先読みし、残りはバックグラウンドでストリーミング
# Warm Pool - 標準的なランタイムイメージ用に、常に起動済みPodをプール - 取得即実行可能

さらに、1ノードに256サンドボックスを詰め込むことを目標とした bin-packing スケジューラと、
* RLは「短時間CPUスパイク＋長時間待ち」のワークロードなので、
* CPUを Burstable QoS で大幅オーバーサブスクライブ

という設計でリソース効率を高めています。INTELLECT_3_Technical_Report

====== 2.3.5 セキュリティ ======
* ランタイムには gVisor (runsc) を採用して、ユーザ空間カーネルでホストを隔離
* ネットワークポリシーで外部通信を制限
* 必要に応じて GPU をマウントしたサンドボックスも支援