Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

GKE で Agent Sandbox を有効にする

Autopilot 標準

このドキュメントでは、クラスタで Google Kubernetes Engine（GKE）の Agent Sandbox を有効にする方法について説明します。また、信頼できないコードを安全に実行するために、クラスタにサンドボックス環境を作成する方法についても説明します。

GKE の Agent Sandbox が信頼できない AI 生成コードを分離する方法の概要については、 GKE の Agent Sandbox についてをご覧ください。

費用

GKE の Agent Sandbox は追加料金なしで提供されます。 GKE の料金は、作成したリソースに適用されます。

不要な料金が発生しないように、このドキュメントの完了後に GKE を無効にするか、プロジェクトを削除してください。

始める前に

コンソールの Google Cloud プロジェクトセレクタページで、 Google Cloud プロジェクトを選択または作成します。
プロジェクトを選択または作成するために必要なロール
- プロジェクトを選択する: プロジェクトの選択には特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトを選択できます。
- プロジェクトを作成する: プロジェクトを作成するには、プロジェクト作成者ロール（roles/resourcemanager.projectCreator）が必要です。これには resourcemanager.projects.create 権限が含まれています。詳しくは、ロールを付与する方法をご覧ください。
注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
プロジェクトに対して課金が有効になっていることを確認します Google Cloud 。
Artifact Registry API と Google Kubernetes Engine API を有効にします（有効になっていない場合）。
API を有効にするために必要なロール
API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を通じてこの権限が付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を通じてこの権限を取得できます。ロールを付与する方法をご覧ください。
API を有効にする

コンソール Google Cloud で Cloud Shell をアクティブにします。

Cloud Shell をアクティブにする
クラスタが GKE バージョン 1.36.3-gke.1767000 以降（v1beta1 API をサポート）を実行していることを確認します。

環境変数を定義する

このドキュメントで実行するコマンドを簡略化するために、Cloud Shell で環境変数を設定できます。Cloud Shell で、次のコマンドを実行して環境変数を定義します。

export PROJECT_ID=$(gcloud config get project)
export CLUSTER_NAME="agent-sandbox-cluster"
export LOCATION="us-central1"
export CLUSTER_VERSION="1.36.3-gke.1767000"
export NODE_POOL_NAME="agent-sandbox-pool"
export MACHINE_TYPE="e2-standard-2"

これらの環境変数の説明は次のとおりです。

PROJECT_ID: 現在の Google Cloud プロジェクトの ID。この変数を定義すると、GKE クラスタなどのすべてのリソースが正しいプロジェクトに作成されます。
CLUSTER_NAME: GKE クラスタの名前（例: agent-sandbox-cluster）。
LOCATION: GKE クラスタが作成される Google Cloud リージョンまたはゾーン。Autopilot クラスタを作成する場合はリージョン（us-central1 など）、Standard クラスタを作成する場合はゾーン（us-central1-a など）に設定します。
CLUSTER_VERSION: クラスタが実行する GKE のバージョン（1.36.3-gke.1767000 以降）。
NODE_POOL_NAME: サンドボックス化されたワークロードを実行するノードプールの名前（例: agent-sandbox-pool）。この変数は、GKE Standard クラスタを作成する場合にのみ必要です。
MACHINE_TYPE: ノードプール内のノードのマシンタイプ（e2-standard-2 など）。さまざまなマシンシリーズとさまざまなオプションの選択の詳細については、マシンファミリーのリソースと比較ガイドをご覧ください。この変数は、GKE Standard クラスタを作成する場合にのみ必要です。

GKE で Agent Sandbox を有効にする

GKE の Agent Sandbox は、新しいクラスタを作成するとき、または既存のクラスタを更新するときに有効にできます。

新しいクラスタを作成するときに GKE の Agent Sandbox を有効にする

フルマネージドの Kubernetes エクスペリエンスを実現するには、Autopilot クラスタを使用することをおすすめします。ワークロードに最適な GKE のオペレーションモードを選択するには、 GKE の運用モードを選択するをご覧ください。

Autopilot

GKE の Agent Sandbox を有効にして新しい GKE Autopilot クラスタを作成するには、--enable-agent-sandbox フラグを含めます。

gcloud beta container clusters create-auto ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-agent-sandbox

Autopilot クラスタの場合は、LOCATION 環境変数がリージョン（us-central1 など）に設定されていることを確認します。

標準

GKE の Agent Sandbox を有効にして新しい GKE Standard クラスタを作成するには、クラスタを作成し、gVisor を有効にしたノードプールを追加してから、GKE の Agent Sandbox を有効にする必要があります。費用を抑えるため、プールごとに 1 つのノードを持つゾーンクラスタを作成することをおすすめします。

クラスタを作成します。
```
gcloud beta container clusters create ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --num-nodes=1 \
    --cluster-version=${CLUSTER_VERSION}
```
この Standard クラスタでは、LOCATION 環境変数がゾーン（us-central1-a など）に設定されていることを確認します。

gVisor を有効にして、独立したノードプールを作成します。

gcloud container node-pools create ${NODE_POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --machine-type=${MACHINE_TYPE} \
    --location=${LOCATION} \
    --num-nodes=1 \
    --image-type=cos_containerd \
    --sandbox=type=gvisor

LOCATION は、クラスタの作成時に使用したゾーンと同じである必要があります。

クラスタを更新して、GKE の Agent Sandbox を有効にします。

gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-agent-sandbox

既存のクラスタを更新するときに GKE の Agent Sandbox を有効にする

既存のクラスタで GKE の Agent Sandbox を有効にするには、クラスタがバージョン 1.36.3-gke.1767000 以降（v1beta1 API をサポート）を実行している必要があります。

LOCATION 環境変数が、既存のクラスタがあるリージョンまたはゾーンに設定されていることを確認します。

GKE Standard クラスタを使用している場合、GKE の Agent Sandbox は gVisor に依存します。Standard クラスタに gVisor が有効なノードプールがない場合は、最初にノードプールを作成する必要があります。
```
gcloud container node-pools create ${NODE_POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --machine-type=${MACHINE_TYPE} \
    --location=${LOCATION} \
    --image-type=cos_containerd \
    --sandbox=type=gvisor
```

クラスタを更新して、GKE の Agent Sandbox を有効にします。

gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-agent-sandbox

構成を確認する

GKE の Agent Sandbox が有効になっているかどうかは、クラスタの説明を調べることで確認できます。

gcloud beta container clusters describe ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --format="value(addonsConfig.agentSandboxConfig.enabled)"

Autopilot クラスタを作成した場合、ロケーションはリージョン（us-central1 など）です。Standard クラスタを作成した場合、ロケーションはゾーン（us-central1-a など）です。

機能が正常に有効になると、コマンドは True を返します。

GKE の Agent Sandbox のデプロイ要件

Sandbox や SandboxTemplate などのワークロードを正常にデプロイするには、 YAML マニフェストに特定のセキュリティ設定と構成設定を含める必要があります。 GKE は、検証アドミッションポリシー（VAP）を使用してこれらの要件を適用します。これらの要件が満たされていない場合、アドミッションコントローラはデプロイを拒否します。

必要な構成

デプロイマニフェストには次の設定を含める必要があります。

runtimeClassName: gvisor: Pod が gVisor サンドボックスで実行されるようにします。
automountServiceAccountToken: false: Pod がデフォルトのサービスアカウントトークンを自動的にマウントしないようにします。
securityContext.runAsNonRoot: true: コンテナが root ユーザーとして実行されないようにします。
securityContext.capabilities.drop: ["ALL"]: すべての Linux 機能をコンテナから削除します。
resources.limits: サービス拒否（DoS）のシナリオを防ぐため、CPU とメモリの上限を指定する必要があります。
nodeSelector: sandbox.gke.io/runtime: gvisor をターゲットにする必要があります。
tolerations: sandbox.gke.io/runtime=gvisor:NoSchedule taint の toleration を含める必要があります。

禁止されている構成

デプロイマニフェストに次のいずれも含めない でください。

hostNetwork: true、hostPID: true、hostIPC: true。
コンテナのセキュリティコンテキストの privileged: true。
HostPath ボリューム。
追加された機能（capabilities.add）。
hostPort 設定。
カスタム sysctl。
サービスアカウントトークンまたは証明書のプロジェクションボリューム。

サンドボックス環境をデプロイする

サンドボックス環境をデプロイするには、SandboxTemplate を定義し、SandboxWarmPool を使用して事前にウォームアップされたインスタンスを準備しておくことをおすすめします。その後、SandboxClaim を使用して、このウォームノードプールからインスタンスをリクエストできます。または、Sandbox を直接作成することもできますが、この方法ではウォームプールはサポートされません。

SandboxTemplate、SandboxWarmPool、SandboxClaim、Sandbox は Kubernetes のカスタムリソースです。

推奨: SandboxTemplate と SandboxWarmPool を作成する

SandboxTemplate は、再利用可能なブループリントとして機能します。SandboxWarmPool は、指定された数の事前にウォームアップされた Pod が常に実行され、要求される準備ができていることを保証します。このカスタムリソースを使用すると、起動レイテンシを最小限に抑えることができます。

SandboxTemplate と SandboxWarmPool を作成してサンドボックス環境をデプロイする手順は次のとおりです。

Cloud Shell で、次の内容を含むファイルを sandbox-template.yaml という名前で作成します。

apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxTemplate
metadata:
  name: python-runtime-template
  namespace: default
spec:
  podTemplate:
    metadata:
      labels:
        sandbox-type: python-runtime
    spec:
      runtimeClassName: gvisor # Required
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
      nodeSelector:
        sandbox.gke.io/runtime: gvisor # Required
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: runtime
        image: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
        ports:
        - containerPort: 8888
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi" # Required
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
      restartPolicy: OnFailure

SandboxTemplate マニフェストを適用します。
```
kubectl apply -f sandbox-template.yaml
```

次の内容で sandbox-warmpool.yaml という名前のファイルを作成します。

apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: python-runtime-warmpool
  namespace: default
  labels:
    app: python-runtime-warmpool
spec:
  replicas: 2
  sandboxTemplateRef:
    # This must match the name of the SandboxTemplate.
    name: python-runtime-template

SandboxWarmPool マニフェストを適用します。
```
kubectl apply -f sandbox-warmpool.yaml
```

SandboxClaim を作成する

SandboxClaim は、ウォームプールからサンドボックスをリクエストします。ウォームプールを作成したため、作成された Sandbox は新しい Pod を起動するのではなく、プールから実行中の Pod を採用します。

SandboxClaim を作成してウォームプールからサンドボックスをリクエストする手順は次のとおりです。

次の内容で sandbox-claim.yaml という名前のファイルを作成します。

apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: sandbox-claim
  namespace: default
spec:
  warmPoolRef:
    # This must match the name of the SandboxWarmPool.
    name: python-runtime-warmpool

SandboxClaim マニフェストを適用します。
```
kubectl apply -f sandbox-claim.yaml
```
サンドボックス、クレーム、ウォームプールが準備できていることを確認します。
```
kubectl get sandboxwarmpool,sandboxclaim,sandbox,pod
```

代替方法: Sandbox を直接作成する

ウォームプールによる高速起動が必要ない場合は、テンプレートを使用せずに Sandbox を直接デプロイできます。

Sandbox を直接作成してサンドボックス環境をデプロイする手順は次のとおりです。

次の内容で sandbox.yaml という名前のファイルを作成します。

apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: sandbox-example-2
spec:
  replicas: 1
  podTemplate:
    metadata:
      labels:
        sandbox: sandbox-example
    spec:
      runtimeClassName: gvisor
      restartPolicy: OnFailure
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
        runAsUser: 1000 # Required if image defaults to root (e.g. busybox)
      nodeSelector:
        sandbox.gke.io/runtime: gvisor
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: my-container
        image: busybox
        command: ["/bin/sh", "-c"]
        args: ["sleep 3600000; echo 'Container finished successfully'; exit 0"]
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
          allowPrivilegeEscalation: false
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi" # Required

Sandbox マニフェストを適用します。
```
kubectl apply -f sandbox.yaml
```
サンドボックスが実行されていることを確認します。
```
kubectl get sandbox
```

GKE の Agent Sandbox を `v1alpha1` から `v1beta1` に移行する

v1alpha1 カスタムリソースを使用して、以前のバージョンの GKE の Agent Sandbox でクラスタをデプロイした場合は、ワークロードのダウンタイムをほぼゼロにして GKE バージョン 1.36.3-gke.1767000 以降にアップグレードできます。

注: この移行手順は、GKE のマネージド Agent Sandbox 機能（--enable-agent-sandbox）を使用するクラスタに適用されます。オープンソースマニフェストを使用して Agent Sandbox をデプロイした場合は、アップストリームの移行ガイドをご覧ください。

`v1alpha1` と `v1beta1` の主な API の違い

コンセプト	`v1alpha1` の動作	`v1beta1` の動作	移行の影響
SandboxClaim のターゲット	ウォームプール（コールドスタート）なしで `SandboxTemplate` を直接参照できます。	`SandboxWarmPool`（`spec.warmPoolRef.name`）への参照が必要です。	コールドスタートのクレームは、シャドウウォームプール（`replicas: 0`）にマッピングする必要があります。
サンドボックスのオペレーティングモード	レプリカまたは状態フィールドから推測されます。	`spec.operatingMode` フィールドの明示的な値（`Running`、`Suspended` など）。	変換 Webhook は、このフィールドを自動的にマッピングして設定します。
CustomResourceDefinition ストレージバージョン	etcd に保存された `v1alpha1`（`storage: true`）。	etcd に保存された `v1beta1`（`storage: true`）。	Webhook は動的に変換します。アップグレード後の手順で etcd オブジェクトを再永続化します。
変換 Webhook	なし	`/convert`（ポート 9447）で有効。	`v1alpha1` と `v1beta1` の間の双方向変換。

移行ツールを使用して移行する

シャドウウォームプールを自動的に作成して永続ストレージを再永続化するには、Agent Sandbox リポジトリの正規の移行スクリプトを使用します。

スクリプトをダウンロードして準備します。

curl -LO https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/v0.5.6/helm/files/migrate.sh
chmod +x migrate.sh

移行ランブック

ワークロードのダウンタイムをほぼゼロにして既存のクラスタを移行するには、次の 3 つのフェーズを順番に完了します。

フェーズ 1: アップグレード前のブートストラップフェーズ

重要: ブートストラップフェーズは、クラスタが実行している間に実行する必要があります。v1alpha1アップグレード後にブートストラップフェーズを実行することはできません。v1beta1 API スキーマでは、以前の spec.sandboxTemplateRef がクレームに公開されなくなるためです。

既存のリソースをバックアップする: GKE の宣言型 Agent Sandbox リソース（sandboxtemplates、sandboxwarmpools、sandboxclaims）の YAML バックアップを保存します。
```
kubectl get sandboxtemplates,sandboxwarmpools,sandboxclaims \
    --all-namespaces -o yaml > agent-sandbox-v1alpha1-backup.yaml
```
注: このコマンドは、Sandbox またはSandboxClaim SandboxWarmPool によって管理されるオブジェクトを除外します。これは、クレームとウォームプールが復元されると、コントローラが動的に再作成するためです。クレームやウォームプールなしでスタンドアロンの Sandbox リソースを直接作成した場合は、復元時に失われないように、バックアップに sandboxes を含めます（または個別にバックアップします）。
テンプレートのセキュリティコンプライアンスを確認します。既存の SandboxTemplate リソースが GKE の Agent Sandbox のデプロイ要件を満たしていることを確認します。フェーズ 3 のストレージ移行中に、アドミッションコントローラは、これらのセキュリティポリシーに準拠していないテンプレートの更新を拒否します。
作成するシャドウプールをプレビューします。
```
./migrate.sh --phase=bootstrap --dry-run
```
ブートストラップフェーズを実行します。
```
./migrate.sh --phase=bootstrap
```
作成したシャドウプールを確認します。
```
kubectl get sandboxwarmpools --all-namespaces \
    -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,SHADOW:.metadata.annotations.agents\.x-k8s\.io/migration-shadow"
```
注: シャドウプールはレプリカなしで作成されるため、追加のコンピューティング費用が発生したり、ノードのフットプリントが増加したりすることはありません。

フェーズ 2: GKE コントロールプレーンをアップグレードする

GKE コントロールプレーンをバージョン 1.36.3-gke.1767000 以降にアップグレードします。

gcloud container clusters upgrade ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --master \
    --cluster-version=1.36.3-gke.1767000

コントロールプレーンのロールアウト中は、次の点に注意してください。

Pod の再起動やダウンタイムは発生しません。
新しいコントローラと /convert Webhook エンドポイントがコントロールプレーンにデプロイされます。

警告: フェーズ 3 は、ダウンタイムなしの移行の戻り点です。 ./migrate.sh --phase=migrate を実行すると、etcd 内のすべてのオブジェクトが v1beta1 スキーマに書き換えられます。このステップの後、古いコントロールプレーンバージョンでは v1beta1 オブジェクトを逆シリアル化できません。続行する前に、フェーズ 1 と 2 が正常に完了していることを確認してください。

フェーズ 3: アップグレード後のストレージ移行

コントロールプレーンのアップグレードが完了したら、認証情報を更新し、ストレージ移行フェーズを実行して保存されている etcd オブジェクトを書き換えます。

./migrate.sh --phase=migrate

移行後の確認チェックリスト

チェック項目	コマンド	期待される結果
CustomResourceDefinition ストレージバージョン	`kubectl get crd sandboxes.agents.x-k8s.io sandboxclaims.extensions.agents.x-k8s.io sandboxtemplates.extensions.agents.x-k8s.io sandboxwarmpools.extensions.agents.x-k8s.io -o jsonpath='{range .items[*]}{.metadata.name}{": storedVersions="}{.status.storedVersions}{"\n"}{end}'`	4 つの CustomResourceDefinition すべてに次の内容が表示されます: `storedVersions=["v1beta1"]`
Pod の継続性	`kubectl get pods -n default -o wide`	`Status: 1/1 Running` `Restarts: 0` （アクティブな実行中のサンドボックスがあるクラスタに適用）
クレームバインディング	`kubectl get sandboxclaims -n default -o yaml`	`spec.warmPoolRef.name: shadow-pool-...` `status.conditions: Ready=True` （アドミッション要件に準拠したテンプレートが必要）
v1alpha1 の互換性	`kubectl get sandboxes.v1alpha1.agents.x-k8s.io`	非推奨の警告が表示され、リソースが返される
v1beta1 ネイティブ CRUD	`kubectl apply -f sandbox-claim.yaml`	警告なしで適用される

移行フェーズが完了した後も、CustomResourceDefinition の .status.storedVersions に ["v1alpha1", "v1beta1"] が表示される場合は、Kubernetes の想定される動作です。移行スクリプトは、etcd 内の既存のレコードをすべて v1beta1 に書き換えますが、Kubernetes は非推奨のバージョンを status.storedVersions リストから自動的に削除しません。

すべてのリソースが移行されたことを確認したら、必要に応じて、保存されているバージョンから v1alpha1 を削除できます。

for crd in \
    sandboxes.agents.x-k8s.io \
    sandboxclaims.extensions.agents.x-k8s.io \
    sandboxtemplates.extensions.agents.x-k8s.io \
    sandboxwarmpools.extensions.agents.x-k8s.io; do
  kubectl patch crd "${crd}" --subresource=status --type=merge \
    -p '{"status":{"storedVersions":["v1beta1"]}}'
done

移行に関する問題のトラブルシューティング

コントロールプレーンのアップグレード後またはストレージ移行の実行後に問題が発生した場合は、コントロールプレーンのダウングレードを試みるのではなく、問題を解決してください。

クレームが WarmPoolNotFound で停止している:
- ./migrate.sh --phase=bootstrap を実行せずにコールドスタートの v1alpha1 クレームをアップグレードした場合は、不足しているシャドウウォームプールを手動で作成します。
```
apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: shadow-pool-TEMPLATE_NAME
  namespace: NAMESPACE
  annotations:
    agents.x-k8s.io/migration-shadow: "true"
spec:
  replicas: 0
  sandboxTemplateRef:
    name: TEMPLATE_NAME
```
- クレームが、存在しない特定のウォームプールを指定している場合は、その名前で不足している SandboxWarmPool リソースを作成するか、クレームの spec.warmPoolRef.name を更新して既存のウォームプールを参照します。
クレーム条件 Ready=False: kubectl describe sandboxclaim を実行して、クレームのイベントを調べます。参照先の SandboxTemplate が GKE の Agent Sandbox のデプロイ要件をすべて満たしていることを確認し、必要に応じてテンプレートを再適用します。
変換エラーまたはコントローラエラー: kubectl get leases -n gke-managed-agentsandbox を実行して、コントロールプレーンのリーダー選出リースがアクティブであることを確認します。問題が解決しない場合は、 Cloud カスタマーケアにお問い合わせください。

GKE の Agent Sandbox を無効にする

GKE の Agent Sandbox を無効にするには、--no-enable-agent-sandbox フラグを指定して gcloud beta container clusters update コマンドを使用します。

gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --no-enable-agent-sandbox

リソースのクリーンアップ

アカウント Google Cloud に課金されないようにするには、作成した GKE クラスタを削除します。

gcloud container clusters delete $CLUSTER_NAME \
    --location=${LOCATION} \
    --quiet

次のステップ

Pod スナップショットを使用して GKE の Agent Sandbox 環境を保存して復元する方法を学習する。
GKE の Agent Sandbox で使用される基盤となるテクノロジーについて学習する。
GKE セキュリティの詳細を確認する。
GitHub で Agent Sandbox オープンソースプロジェクトを調べる。
GKE の Agent Sandbox でオープンソースの Kata Containers を使用する方法を学習する。 Kata Containers は Google Cloud プロダクトではありません。このソフトウェアをインストールして使用する場合は、管理とトラブルシューティングを行う必要があります。 Google のサポートと SLA は Kata Containers には適用されません。

GKE で Agent Sandbox を有効にする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

費用

始める前に

環境変数を定義する

GKE で Agent Sandbox を有効にする

新しいクラスタを作成するときに GKE の Agent Sandbox を有効にする

Autopilot

標準

既存のクラスタを更新するときに GKE の Agent Sandbox を有効にする

構成を確認する

GKE の Agent Sandbox のデプロイ要件

必要な構成

禁止されている構成

サンドボックス環境をデプロイする

推奨: SandboxTemplate と SandboxWarmPool を作成する

SandboxClaim を作成する

代替方法: Sandbox を直接作成する

GKE の Agent Sandbox を v1alpha1 から v1beta1 に移行する

v1alpha1 と v1beta1 の主な API の違い

移行ツールを使用して移行する

移行ランブック

フェーズ 1: アップグレード前のブートストラップ フェーズ

フェーズ 2: GKE コントロール プレーンをアップグレードする

フェーズ 3: アップグレード後のストレージ移行

移行後の確認チェックリスト

移行に関する問題のトラブルシューティング

GKE の Agent Sandbox を無効にする

リソースのクリーンアップ

次のステップ

GKE で Agent Sandbox を有効にする

GKE の Agent Sandbox を `v1alpha1` から `v1beta1` に移行する

`v1alpha1` と `v1beta1` の主な API の違い

フェーズ 1: アップグレード前のブートストラップフェーズ

フェーズ 2: GKE コントロールプレーンをアップグレードする