cwic sandbox runner policy edit [RUNNER-ID] -f policy.json を使用して適用するか、ランナー更新の policy フィールドとして送信します。[RUNNER-ID] をポリシーを編集したいランナーの ID に置き換え、イメージレジストリのサンプルの [GITHUB-ORG] を GitHub Container Registry の組織名またはユーザー名に置き換えてください。
フィールドごとの詳細な手順については、サンドボックスポリシーを設定するを参照してください。
GPU データサイエンスクラスター
ユーザーごとの長期的な作業向けのクラスターです。十分なコンピュート、GPU Node に加え、データセットやパッケージをプルするためのインターネットアクセスを備えています。ただし、インスタンスメタデータエンドポイントへのアクセスは除外されています。policy.json
allowedRuntimeClasses はフェイルクローズで動作するため、両方のランタイムクラスを列挙しています。サンドボックスが固定できるのは明示的に指定したクラスのみで、クラスを固定しない場合にどのクラスが割り当てられるかは、2 つのデフォルトによって決まります。
許可リスト付き外向き通信を備えた共有エージェントクラスター
組織内のエージェントワークロード向けのマルチテナントクラスターです。エージェントは組織内の固定された上流のセットと相互に到達可能で、それ以外には到達できません。policy.json
エフェメラル CI クラスター
短命で、小規模かつ狭いものです。サンドボックスは test run の期間だけ存在します。policy.json
max_lifetime_seconds を設定してください。
デフォルトの外向き通信がない VM 分離実行
このポリシーは VM 分離を必須とし、デフォルトの外向き通信ルールを定義しません。UDP/TCP ポート 53 宛ての外向き DNS トラフィックはブロックしますが、allowedEgress が空であるため、サンドボックスはその他の外向き通信を宣言できます。
policy.json
allowedImages はレジストリ単位ではなく 1 つのイメージを固定するため、サンドボックスが信頼済みレジストリから任意のイメージを選択することはできません。
内部ワーカークラスター
組織内の他のサンドボックスからサービス経由でアクセスできる、長時間稼働するバックグラウンドワーカーです。サードパーティ API の呼び出し用に外部へのアクセスを備えています。policy.json
この例では外向き通信のみを設定します。可視性が
CUSTOM のポートへの受信アクセスを制限するには、allowedIngress を追加し、必要に応じて defaultIngress も追加します。詳しくは、ネットワークアクセスを制限するを参照してください。ベースレイヤーで管理者デフォルトを固定する
上記のどのポリシーにもbase フラグメントを含めることができます。これは管理者が設定するアタッチメントで、サンドボックスが何を要求するかにかかわらず、ランナー上のすべてのサンドボックスに適用されます。次に示す内部ワーカーポリシーのバリエーションでは、ノードの選択、プライベートレジストリ用のイメージプルシークレット、コスト配分ラベルをすべてのサンドボックスに固定しています。
policy.json
base フラグメントは、周辺の制約フィールドとは異なり、camelCase キーを使用した Kubernetes の Pod 仕様のサブセットであり、不明なキーは拒否されます。受け入れるのはスケジューリングとランタイムの接続のみです: nodeSelector、tolerations、imagePullSecrets、volumes、topologySpreadConstraints、hostAliases、DNS 設定、name、env、envFrom、volumeMounts、volumeDevices に限定された単一の containers エントリ、および Pod のラベルとアノテーションです。セキュリティ上重要なフィールドは拒否されます: securityContext、runtimeClassName、initContainers、affinity、ホスト namespace、hostPath ボリューム、デフォルト以外のサービスアカウント、およびランナーが所有する namespace です。有効期間、イメージ、外向き通信などの型指定された項目は constraints に属し、base には属しません。
CKS クラスターでは、template attachments がテンプレートごとにこのフラグメントを特化します: imagePullSecrets と tolerations は結合され、重複排除され、他のリストは追加され、マップキーはキーごとに上書きされ、同じ名前の競合は作成を拒否します。base の現在の適用ステータスについては、ベースレイヤー を参照してください。
クラスター間でポスチャーを変える
ポリシーはクラスターに属するため、異なるポスチャーは1つのクラスター上の異なるドキュメントではなく、異なるクラスターとなります。オープンなデータサイエンス環境とロックダウンされた実行環境の両方を必要とするチームは、2つのクラスターを実行し、それぞれに一致するポリシーを割り当てます。 リージョンごとに1つのディメンションを変えるには、リージョン固有の値を変更した同じポリシーを各クラスターに適用します。共有または継承されたポリシードキュメントはないため、信頼できるソースをバージョン管理に保持し、クラスターごとに適用します。関連項目
- サンドボックスポリシーを設定する: これらのサンプルで使用されるフィールドを持つ、すべての制約グループ。
- ポリシーの概要: サンドボックスがポリシーに対してどのように解決されるか。
- エージェント型 RL トレーニング: 報酬関数とマルチターンエージェントのロールアウト、動作する Python コード付き。
- ランナーのデプロイと管理: ランナー設定の残りの部分。