このドキュメントは、Standard クラスタ専用です。
このドキュメントでは、GKE Pod スナップショットを使用して、実行中の Agent Sandbox 環境の状態を保存する方法について説明します。
Agent Sandbox は、大規模言語モデル（LLM）によって生成されたコードなど、信頼性の低いコードを実行するための安全で分離された環境を提供します。このタイプのコードをクラスタで直接実行すると、信頼できないコードが他のアプリや基盤となるクラスタノード自体にアクセスしたり、干渉する可能性があるため、セキュリティ上のリスクが生じます。
GKE Pod スナップショットを使用すると、サンドボックス環境の状態を保存して復元できます。この機能は、次の理由で便利です。
- 高速起動: 事前ウォーミングされたスナップショットから復元することで、サンドボックスの起動時間を短縮します。
- 長時間実行エージェント: 実行に時間がかかるサンドボックスを一時停止し、後で再開するか、進行状況を失うことなく別のノードに移動します。
- ステートフル ワークロード: サンドボックス環境の状態を保存して復元することで、会話履歴や中間計算など、エージェントのコンテキストを保持します。
- 再現性: 特定の状態をキャプチャし、それをベースとして使用して、同じ初期化状態で複数の新しいサンドボックスを開始します。
スナップショットは次の 2 つの方法でトリガーできます。
- 手動トリガー:
PodSnapshotManualTriggerリソースを作成して、スナップショットをトリガーします。 - ワークロード トリガー: サンドボックス アプリケーション自体が、保存の準備ができたときにシグナルを送信します。
このドキュメントでは、スナップショットを手動でトリガーする方法について説明します。
注: GKE Pod スナップショットはプレビュー機能です。
始める前に
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Enable the Google Kubernetes Engine, Cloud Storage, Identity and Access Management (IAM) APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles. -
In the Google Cloud console, activate Cloud Shell.
要件
GKE Pod スナップショットを使用するには、GKE バージョン 1.34.1-gke.3084001 以降を実行する Standard モードのクラスタが必要です。GKE バージョン 1.35 以降を使用することをおすすめします。GKE バージョン 1.34 には、Cloud Storage 権限のバグに関連する入出力エラーでチェックポイントが失敗する可能性があるという既知の問題があります。
Pod スナップショットは、E2 マシンタイプをサポートしていません。そのため、このチュートリアルでは N2 マシンで構成されるノードプールを作成します。
ノードプールのノードに GPU ベースのマシンタイプを使用する場合は、制限事項と要件をご覧ください。
環境変数を定義する
このドキュメントで実行するコマンドを簡略化するために、Cloud Shell で環境変数を設定できます。これらの変数には、 Google Cloud プロジェクトの ID、スナップショットを保存する Cloud Storage バケットの名前、GKE クラスタのロケーションなどの値が格納されます。
これらの変数を定義すると、値を毎回再入力または置き換えるのではなく、変数名（
$CLUSTER_NAMEなど）を参照して、複数のコマンドで再利用できます。このアプローチにより、プロセスがわかりやすくなり、エラーのリスクが軽減されます。Cloud Shell で次の環境変数を定義するには、次のコマンドを実行します。
export PROJECT_ID=$(gcloud config get project) export CLUSTER_NAME="agent-sandbox-cluster" export GKE_LOCATION="us-central1" export GKE_VERSION="1.35.0-gke.1795000" export AGENT_SANDBOX_VERSION="v0.1.0" export NODE_POOL_NAME="agent-sandbox-node-pool" export MACHINE_TYPE="n2-standard-2" export SNAPSHOTS_BUCKET_NAME="agent-sandbox-snapshots-${PROJECT_ID}" export SNAPSHOT_NAMESPACE="pod-snapshots-ns" export SNAPSHOT_KSA_NAME="pod-snapshot-sa" export SNAPSHOT_FOLDER="my-snapshots" export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")これらの環境変数の説明は次のとおりです。
PROJECT_ID: 現在の Google Cloud プロジェクトの ID。この変数を定義すると、GKE クラスタなどのすべてのリソースが正しいプロジェクトに作成されます。CLUSTER_NAME: GKE クラスタの名前（例:agent-sandbox-cluster）。GKE_LOCATION: GKE クラスタが作成される Google Cloud リージョン（例:us-central1）。GKE_VERSION: Pod スナップショットとの互換性に必要な GKE クラスタとノードのバージョン。GKE Pod スナップショットには、GKE バージョン 1.34.1-gke.3084001 以降が必要です。AGENT_SANDBOX_VERSION: クラスタにデプロイする Agent Sandbox コントローラのバージョン。NODE_POOL_NAME: サンドボックス化されたワークロードを実行するノードプールの名前（例:agent-sandbox-node-pool）。MACHINE_TYPE: ノードプール内のノードのマシンタイプ（n2-standard-2など）。Pod スナップショットは、E2 マシンタイプをサポートしていません。ノードプールのノードに GPU ベースのマシンタイプを使用する場合は、制限事項と要件をご覧ください。さまざまなマシンシリーズとさまざまなオプションの選択の詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。SNAPSHOTS_BUCKET_NAME: スナップショットを保存するために作成する Cloud Storage バケットの名前。SNAPSHOT_NAMESPACE: スナップショット ワークロードとサービス アカウントが配置される Kubernetes Namespace。SNAPSHOT_KSA_NAME: ワークロードが認証に使用する Kubernetes サービス アカウントの名前。SNAPSHOT_FOLDER: スナップショットが整理される Cloud Storage バケット内のディレクトリ。PROJECT_NUMBER: IAM 権限バインディングに使用されるプロジェクトの一意の数値識別子。
構成手順の概要
Agent Sandbox 環境の Pod スナップショットを有効にするには、いくつかの構成手順を行う必要があります。これらの手順を理解するには、まずいくつかの重要なコンセプトとスナップショット プロセスを理解しておくと役立ちます。
主なコンセプト
- 環境: サンドボックス化されたアプリケーションは、GKE クラスタノードの Kubernetes Pod 内で実行されます。
- ID: Pod は Kubernetes サービス アカウントに関連付けられ、作成した特別な Namespace で実行されます。Kubernetes サービス アカウントと Namespace は、Pod に Google Cloud リソースへの安全なアクセス権を付与するために使用される一意の ID を形成します。
- 権限: スナップショットを Cloud Storage に保存できるようにするには、Pod の ID に、Cloud Storage バケットへの書き込みを許可する特定の IAM 権限を付与する必要があります。
スナップショット プロセス
- トリガー: スナップショットが手動（外部）またはサンドボックス化されたワークロード自体によって開始されます。このドキュメントでは、
PodSnapshotManualTriggerリソースを作成して開始する手動トリガーについて説明します。 - キャプチャ: GKE は、Pod のメモリの状態やファイル システムなど、Pod の実行状態をキャプチャします。
- アップロード: Pod の Kubernetes サービス アカウントに付与された権限を使用して、GKE はキャプチャされた状態をスナップショット ファイルとして指定された Cloud Storage バケットにアップロードします。
GKE が Kubernetes サービス アカウントと IAM ロールを使用して Google Cloud リソースにアクセスする方法については、GKE ワークロードから Google Cloud API に対する認証を行うをご覧ください。
Agent Sandbox 環境の Pod スナップショットを有効にするには、次の構成を行います。まず、Workload Identity Federation for GKE と Pod スナップショット機能が有効になっている GKE クラスタを作成して、クラスタ環境を準備します。次に、Cloud Storage と IAM ポリシーを構成して、スナップショットが安全に保存され、サンドボックスに必要な権限が付与されるようにします。最後に、サンドボックスのストレージ ロケーションとポリシーを指定するスナップショット リソースを作成します。
次の表に、実行する必要がある構成手順の概要を示します。各手順については、以降のセクションで説明します。
クラスタの設定
サンドボックス化されたアプリは GKE クラスタノードの Pod 内で実行されるため、クラスタ環境を設定する必要があります。このセクションでは、GKE クラスタを作成し、Agent Sandbox コントローラをデプロイする方法について説明します。
GKE クラスタを作成する
GKE Standard クラスタを作成します。このクラスタは、Agent Sandbox 環境のスナップショットを作成する Kubernetes 環境を提供します。次のコマンドは、クラスタを作成し、Workload Identity Federation for GKE と Pod スナップショット機能を有効にします。
Google Cloud CLI を使用して Standard クラスタを作成するには、次のコマンドを実行します。
gcloud beta container clusters create ${CLUSTER_NAME} \ --location=${GKE_LOCATION} \ --cluster-version=${GKE_VERSION} \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --workload-metadata=GKE_METADATA \ --num-nodes=1 \ --enable-pod-snapshotsこのコマンドは、クラスタの作成に加えて、クラスタで Workload Identity Federation for GKE と Pod スナップショット機能を有効にします。
kubectlCLI がクラスタに接続できるように、クラスタの認証情報を取得します。このコマンドは、デフォルトで~/.kube/configディレクトリに保存されている Kubernetes 構成ファイルを更新します。この構成ファイルには、kubectlが GKE クラスタとやり取りするために必要な認証情報が含まれています。gcloud container clusters get-credentials ${CLUSTER_NAME} \ --location=${GKE_LOCATION}gVisor を有効にしてノードプールを作成します。
gcloud container node-pools create ${NODE_POOL_NAME} \ --cluster=${CLUSTER_NAME} \ --location=${GKE_LOCATION} \ --machine-type=${MACHINE_TYPE} \ --node-version=${GKE_VERSION} \ --image-type=cos_containerd \ --num-nodes=1 \ --sandbox type=gvisorこのコマンドでは、次のキーフラグを使用します。
--image-type=cos_containerd: ノードで containerd を含む Container-Optimized OS を使用することを指定します。--sandbox type=gvisor: ノードで gVisor サンドボックス技術を有効にします。これは Agent Sandbox に必要です。
Agent Sandbox コントローラをクラスタにデプロイする
公式リリース マニフェストをクラスタに適用することで、Agent Sandbox コントローラとその必須コンポーネントをデプロイできます。これらのマニフェストは、クラスタに Agent Sandbox コントローラをデプロイして実行するために必要なすべてのコンポーネントをダウンロードするように Kubernetes に指示する構成ファイルです。
Agent Sandbox を GKE クラスタにデプロイするには、次のコマンドを実行します。
# Apply the main manifest for the controller and its Custom Resource Definitions (CRDs) kubectl apply \ -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}/manifest.yaml \ -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}/extensions.yamlコントローラを確認する
マニフェストを適用したら、
agent-sandbox-systemNamespace で Agent Sandbox コントローラ Pod が正しく実行されていることを確認します。マニフェストは、前の手順で適用したときにagent-sandbox-systemNamespace を自動的に作成しました。kubectl get pods -n agent-sandbox-systemPod の STATUS 列に「Running」、READY 列に「1/1」が表示されるまで待ちます。Pod が正常に実行されている場合、出力は次のようになります。
NAME READY STATUS RESTARTS AGE agent-sandbox-controller-0 1/1 Running 0 44dAgent Sandbox コントローラが実行されると、クラスタに作成した
Sandboxリソースのサンドボックス環境を自動的に作成して管理できます。ストレージと権限を構成する
このセクションでは、Pod スナップショットに必要なストレージと権限を構成する方法について説明します。スナップショット データを保存する Cloud Storage バケットとマネージド フォルダを作成します。次に、サンドボックスとスナップショット コントローラに、そのストレージへのアクセスに必要な権限を付与します。
Cloud Storage バケットを作成する
スナップショットを保存するバケットを作成します。スナップショット プロセスを高速かつ費用対効果の高いものにするには、次の設定でバケットを作成することをおすすめします。
- 階層型名前空間を有効にする: 階層型名前空間機能により、バケットがフラットな名前空間ではなくファイル システム階層に整理されます。この構成により、読み取りと書き込みのスループットが向上し、スナップショットの保存と復元が高速化されます。
- 削除（復元可能）を無効にする: 削除（復元可能）機能は、削除されたファイルを一定期間保持することでデータを保護します。ただし、スナップショット プロセスでは、アップロード中に多くの一時ファイルが作成および削除されます。これらの一時ファイルの保存に対する不要な課金が発生しないように、削除（復元可能）を無効にすることをおすすめします。
これらの設定でバケットを作成するには、次のコマンドを実行します。
gcloud storage buckets create "gs://${SNAPSHOTS_BUCKET_NAME}" \ --uniform-bucket-level-access \ --enable-hierarchical-namespace \ --soft-delete-duration=0d \ --location="${GKE_LOCATION}"マネージド フォルダを作成する
管理フォルダを作成して、バケット内のスナップショットを整理します。マネージド フォルダを使用すると、バケット全体ではなく、特定のフォルダに IAM 権限を適用できます。このフォルダレベルのアクセスにより、サンドボックスのアクセスは独自のスナップショットのみに制限され、これらのスナップショットはバケット内の他のデータから分離されます。
マネージド フォルダを作成するには、次のコマンドを実行します。
gcloud storage managed-folders create "gs://${SNAPSHOTS_BUCKET_NAME}/${SNAPSHOT_FOLDER}/"サービス アカウントと IAM ロールを構成する
GKE がスナップショットを安全に保存できるようにするには、サンドボックス化されたワークロードを実行している Pod で使用される Kubernetes サービス アカウントに、バケットへの書き込み権限が必要です。この権限を付与するには、Pod で使用される Kubernetes サービス アカウントに Google CloudIAM ロールをバインドします。このセクションでは、カスタム IAM ロールを作成し、Kubernetes サービス アカウントを作成して、必要な権限を構成する方法について説明します。
スナップショット データの書き込みに必要な権限を含む
podSnapshotGcsReadWriterという名前のカスタム IAM ロールを作成します。gcloud iam roles create podSnapshotGcsReadWriter \ --project="${PROJECT_ID}" \ --permissions="storage.objects.get,storage.objects.create,storage.objects.delete,storage.folders.create"ロールが正常に作成されると、次のような出力が表示されます。
Created role [podSnapshotGcsReadWriter]. etag: BwZJUfjNbew= includedPermissions: - storage.folders.create - storage.objects.create - storage.objects.delete - storage.objects.get name: projects/${PROJECT_ID}/roles/podSnapshotGcsReadWriter stage: ALPHA title: podSnapshotGcsReadWriterサンドボックスとそのサービス アカウントが存在する Namespace を作成します。
kubectl create namespace "${SNAPSHOT_NAMESPACE}"作成した Namespace に Kubernetes サービス アカウントを作成します。Kubernetes サービス アカウントと Namespace は、サンドボックスにリソースへの安全なアクセス権を付与するために使用される一意の ID を形成します。 Google Cloud
kubectl create serviceaccount "${SNAPSHOT_KSA_NAME}" \ --namespace "${SNAPSHOT_NAMESPACE}"Namespace 内のすべてのサービス アカウントに
roles/storage.bucketViewerロールを付与します。このロールを使用すると、アカウントはバケットのメタデータを表示できますが、データ自体を読み書きすることはできません。gcloud storage buckets add-iam-policy-binding "gs://${SNAPSHOTS_BUCKET_NAME}" \ --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/namespace/${SNAPSHOT_NAMESPACE}" \ --role="roles/storage.bucketViewer"カスタム
podSnapshotGcsReadWriterロールをサンドボックスの Kubernetes サービス アカウントに付与します。このバインディングにより、この特定のアカウントのみがマネージド フォルダにデータを書き込むことができます。gcloud storage buckets add-iam-policy-binding "gs://${SNAPSHOTS_BUCKET_NAME}" \ --member="principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${SNAPSHOT_NAMESPACE}/sa/${SNAPSHOT_KSA_NAME}" \ --role="projects/${PROJECT_ID}/roles/podSnapshotGcsReadWriter"Kubernetes サービス アカウントに
roles/storage.objectUserロールを付与します。このロールは、Pod スナップショット エージェントがマネージド フォルダでオペレーションを実行するために必要です。gcloud storage buckets add-iam-policy-binding "gs://${SNAPSHOTS_BUCKET_NAME}" \ --member="principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${SNAPSHOT_NAMESPACE}/sa/${SNAPSHOT_KSA_NAME}" \ --role="roles/storage.objectUser"
スナップショット コントローラに権限を付与する
GKE システムのスナップショット コントローラに
objectUserロールを付与します。この権限により、コントローラはスナップショットのライフサイクルを管理できます。たとえば、PodSnapshotリソースを削除すると、スナップショット オブジェクトが削除されます。gcloud storage buckets add-iam-policy-binding "gs://${SNAPSHOTS_BUCKET_NAME}" \ --member="serviceAccount:service-${PROJECT_NUMBER}@container-engine-robot.iam.gserviceaccount.com" \ --role="roles/storage.objectUser"スナップショット リソースを構成する
このセクションでは、Agent Sandbox ワークロードのスナップショット リソースを構成する方法について説明します。
スナップショットのストレージとルールを定義する
GKE がスナップショットを保存する場所と、スナップショット プロセスを制御するルールを指定するには、次の 2 つのカスタム リソースを作成します。
PodSnapshotStorageConfig: このリソースは、GKE がスナップショット ファイルを保存する Cloud Storage バケットとフォルダの場所を指定します。PodSnapshotPolicy: このリソースは、Kubernetes ラベルに基づいて、スナップショットの対象となる Pod を定義します。また、スナップショットが手動か、サンドボックス ワークロードによって開始されたかなど、トリガー ルールも指定します。
両方のリソースを 1 つのステップで適用するには、Cloud Shell で次のコマンドを実行します。この方法を使用すると、環境変数が正しく挿入されます。
kubectl apply -f - <<EOF apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotStorageConfig metadata: name: cpu-pssc-gcs spec: snapshotStorageConfig: gcs: bucket: "${SNAPSHOTS_BUCKET_NAME}" path: "${SNAPSHOT_FOLDER}" EOF sleep 5 kubectl apply -f - <<EOF apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotPolicy metadata: name: cpu-psp namespace: ${SNAPSHOT_NAMESPACE} spec: storageConfigName: cpu-pssc-gcs selector: matchLabels: app: agent-sandbox-workload triggerConfig: type: manual postCheckpoint: resume EOF構成を確認する
スナップショット ストレージの構成とポリシーを適用したら、リソースが使用可能であることを確認します。このセクションでは、これらのカスタム リソースのステータスを確認する方法について説明します。
PodSnapshotStorageConfigリソースのステータスを確認します。kubectl get podsnapshotstorageconfigs.podsnapshot.gke.io cpu-pssc-gcs \ --namespace "${SNAPSHOT_NAMESPACE}" -o yaml出力には、
type: Readyとstatus: "True"を含む条件が含まれているはずです。status: conditions: - lastTransitionTime: "2025-10-31T18:18:02Z" message: Valid PodSnapshotStorageConfig reason: StorageConfigValid status: "True" type: ReadyPodSnapshotPolicyリソースのステータスを確認します。kubectl get podsnapshotpolicies.podsnapshot.gke.io cpu-psp \ --namespace "${SNAPSHOT_NAMESPACE}" -o yaml出力には、
type: Readyとstatus: "True"を含む条件が含まれているはずです。また、参照されたPodSnapshotStorageConfigが見つかったことも示す必要があります。status: conditions: - lastTransitionTime: "2025-10-31T18:19:47Z" message: The referenced PodSnapshotStorageConfig "cpu-pssc-gcs" was found reason: StorageConfigValid status: "True" type: Ready
サンドボックス テンプレートを作成する
ストレージ ポリシーと権限が設定されたので、
SandboxTemplateリソースとSandboxClaimリソースを作成します。スナップショット プロセスが機能するには、このドキュメントで前に作成した Kubernetes サービス アカウントでサンドボックスを実行する必要があります。サンドボックスには、PodSnapshotPolicyで指定したラベルも必要です。この例では、インクリメント カウンタをログに出力する Python アプリを使用します。このカウンタを使用すると、状態が正常に保存され、後で復元されたことを確認できます。
SandboxTemplateリソースとSandboxClaimリソースを作成するには、次のマニフェストを適用します。kubectl apply -f - <<EOF --- apiVersion: extensions.agents.x-k8s.io/v1alpha1 kind: SandboxTemplate metadata: name: python-runtime-template namespace: ${SNAPSHOT_NAMESPACE} spec: podTemplate: metadata: labels: app: agent-sandbox-workload spec: serviceAccountName: ${SNAPSHOT_KSA_NAME} runtimeClassName: gvisor containers: - name: my-container image: python:3.10-slim command: ["python3", "-c"] args: - | import time i = 0 while True: print(f"Count: {i}", flush=True) i += 1 time.sleep(1) --- apiVersion: extensions.agents.x-k8s.io/v1alpha1 kind: SandboxClaim metadata: name: python-sandbox-example namespace: ${SNAPSHOT_NAMESPACE} labels: app: agent-sandbox-workload spec: sandboxTemplateRef: name: python-runtime-template EOFこれで、サンドボックスが正しい ID で実行され、スナップショットを作成できるようになりました。
スナップショットの作成
このセクションでは、実行中のサンドボックスのスナップショットを手動でトリガーする方法について説明します。サンドボックス Pod をターゲットとするトリガー リソースを作成し、スナップショット プロセスが正常に完了したことを確認します。
初期カウンタのログを確認する: スナップショットをトリガーする前に、実行中のサンドボックスのログを表示して、現在のカウンタ値を確認します。ログを表示すると、復元後に比較するベースラインが確立されます。
kubectl logs python-sandbox-example --namespace "${SNAPSHOT_NAMESPACE}" --tail=5出力には、カウンタの最後の数行が表示されます。次に例を示します。
Count: 15 Count: 16 Count: 17出力された最後の数個の「Count」の値をメモします。
PodSnapshotManualTrigger リソースを作成します。スナップショットを開始します。
kubectl apply -f - <<EOF apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotManualTrigger metadata: name: cpu-snapshot-trigger namespace: ${SNAPSHOT_NAMESPACE} spec: targetPod: python-sandbox-example EOF手動トリガーが成功したことを確認します。
kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io \ --namespace "${SNAPSHOT_NAMESPACE}"出力には、ステータス
Completeが表示されます。これは、GKE がターゲット Pod のスナップショットを正常にトリガーしたことを示します。NAME TARGET POD STATUS AGE cpu-snapshot-trigger python-sandbox-example Complete XXsトリガーを記述して、キャプチャされた状態の詳細を表示します。
kubectl describe podsnapshotmanualtriggers.podsnapshot.gke.io cpu-snapshot-trigger \ --namespace "${SNAPSHOT_NAMESPACE}"出力には、バケットに保存されているスナップショット ファイルの固有の名前を含む
Snapshot Createdセクションが含まれます。Status: Conditions: Last Transition Time: 2026-01-30T19:11:04Z Message: checkpoint completed successfully Reason: Complete Status: True Type: Triggered Observed Generation: 1 Snapshot Created: Name: <UNIQUE_SNAPSHOT_NAME>
スナップショットから復元する
スナップショットをキャプチャしたら、サンドボックス環境を復元して、保存された状態から実行を再開できます。サンドボックスを復元するには、元の
SandboxTemplateを参照する新しいSandboxClaimを作成します。Pod スナップショット コントローラは、一致する最新のスナップショットを自動的に識別して復元します。サンドボックスを復元するための新しい
SandboxClaimを作成します。kubectl apply -f - <<EOF apiVersion: extensions.agents.x-k8s.io/v1alpha1 kind: SandboxClaim metadata: name: python-sandbox-from-snapshot namespace: ${SNAPSHOT_NAMESPACE} labels: app: agent-sandbox-workload spec: sandboxTemplateRef: name: python-runtime-template EOFログを表示して、復元が行われたことを確認します。カウンタはスナップショットが取得された時点から継続されます。
kubectl logs python-sandbox-from-snapshot --namespace "${SNAPSHOT_NAMESPACE}"出力には、次のようにカウンタが再開されたことが表示されます。
Count: 18 Count: 19 Count: 20 Count: 21
クリーンアップ
このドキュメントで使用したリソースについて、 Google Cloud アカウントに課金されないようにするには、次の手順で作成したリソースを削除します。
サンドボックス クレームを削除して、実行中の Pod を停止し、エージェント サンドボックス コントローラがコンテナを正常に終了できるようにします。
kubectl delete sandboxclaims --all --namespace "${SNAPSHOT_NAMESPACE}"サンドボックスの作成とスナップショットの開始に使用されたサンドボックス テンプレートと手動トリガーを削除します。
# Delete the blueprints kubectl delete sandboxtemplates --all --namespace "${SNAPSHOT_NAMESPACE}" # Delete the snapshot initiation objects kubectl delete podsnapshotmanualtriggers --all --namespace "${SNAPSHOT_NAMESPACE}"Namespace 内でスナップショットの対象となる Pod を定義するスナップショット ポリシーを削除します。
kubectl delete podsnapshotpolicy cpu-psp --namespace "${SNAPSHOT_NAMESPACE}"スナップショット ストレージ構成（スナップショット ストレージ バックエンドのグローバル定義）を削除します。このリソースはクラスタ スコープであるため、Namespace フラグは使用しないでください。
kubectl delete podsnapshotstorageconfig cpu-pssc-gcsKubernetes Namespace を削除して、Kubernetes サービス アカウントと残りの Namespace メタデータを自動的に削除します。
kubectl delete namespace "${SNAPSHOT_NAMESPACE}"GKE クラスタを削除して、基盤となるインフラストラクチャとチュートリアルに関連付けられているすべてのノードを削除します。
gcloud container clusters delete "${CLUSTER_NAME}" --location="${GKE_LOCATION}" --quietストレージを完全にリセットする場合は、再帰的削除コマンドを使用して Cloud Storage バケットを削除します（省略可）。正しく構成されたバケットを今後のテストで再利用する場合は、この手順をスキップできます。
gcloud storage rm --recursive "gs://${SNAPSHOTS_BUCKET_NAME:?Error: SNAPSHOTS_BUCKET_NAME is not set. Please re-define the environment variables you defined earlier.}"プロジェクトを完全にクリーンな状態に戻す場合は、カスタム IAM ロールを削除します（省略可）。IAM ロールはクラスタが削除された後も保持されるため、個別に削除する必要があります。
gcloud iam roles delete podSnapshotGcsReadWriter --project="${PROJECT_ID}"
次のステップ
- GKE Pod スナップショットの詳細を確認する。
- Agent Sandbox オープンソース プロジェクトの詳細については、GitHub をご覧ください。
- Agent Sandbox で AI コードの実行を分離する方法を学習する。