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

GKE Pod スナップショットについて

Autopilot Standard

Google Kubernetes Engine（GKE）Pod スナップショットは、実行中の Pod のスナップショットを復元することで、ワークロードの起動レイテンシを改善します。Pod スナップショットは、メモリやファイルシステムの変更など、Pod の状態全体を保存します。新しいレプリカを作成すると、スナップショットから復元されるため、ワークロードは新しい状態から開始するのではなく、再開できます。

このドキュメントでは、GKE Pod スナップショットの概要について説明します。この機能を有効にして使用するには、次のドキュメントをご覧ください。

Pod スナップショットを使用するタイミング

初期化に時間がかかるワークロード（大規模なモデルを CPU または GPU メモリに読み込む AI 推論ワークロードや、多くのライブラリと依存関係を読み込む大規模なアプリケーションなど）には、Pod スナップショットを使用します。起動時間がすでに短いワークロードでは、一般的に Pod スナップショットのメリットはありません。

Pod スナップショットの仕組み

GKE Pod スナップショットは、特定の時点での Pod のプロセス状態の正確なコピーを保存します。新しいレプリカが作成されると、Pod は新しい状態から初期化されるのではなく、スナップショットから復元され、スナップショットが取得された時点から実行が再開されます。

Pod スナップショットを使用するには、Kubernetes カスタムリソース定義（CRD）を作成して、スナップショットの動作を宣言的に構成します。各 GKE ノードで実行されているエージェントが、スナップショットのライフサイクルを管理します。定義したポリシーに基づいて、エージェントは新しいスナップショットを作成するタイミングと、既存のスナップショットを使用して新しい Pod を復元するタイミングを決定します。GKE コントロールプレーンで実行されているコントローラは、古いスナップショットをクリーンアップし、問題を解決します。Cloud Storage は Pod スナップショットを保存します。

スナップショットの内容

次の表に、Pod スナップショットに含まれるものと含まれないものを示します。

カテゴリ	スナップショットに含まれるもの	スナップショットに含まれないもの
アプリケーションの状態	アプリケーションの状態全体: 開いているファイル記述子、スレッド、CPU レジスタ、メモリ。
ファイルシステム	コンテナのルートファイルシステム（`rootfs`）、`EmptyDir` ボリューム、`tmpfs` マウント。	前の列に記載されていないもの。特に、永続ボリュームはチェックポイントされません。
ネットワーキング	ループバック接続、リスニングソケット、Unix ドメインソケット。	外部接続は復元されません（復元時に終了します）。`iptables` や `nftables` などのユーザーが追加したルールとルートは復元されません。

CustomResourceDefinitions

Pod スナップショットは、次の CRD を使用して宣言的に構成されます。

PodSnapshotStorageConfig: スナップショットの保存場所を指定します。Cloud Storage バケットのみがサポートされています。
PodSnapshotPolicy: Kubernetes ラベルセレクタに基づいて、スナップショットを作成する Pod を定義します。このリソースには、スナップショットのトリガー方法、スナップショットスコープ、保持ポリシーなど、機能の構成オプションの大部分が含まれています。
PodSnapshotManualTrigger: （省略可）ワークロードトリガーを使用しない場合は、特定の Pod のスナップショットを作成する手動トリガーを定義します。

スナップショットトリガー

Pod スナップショットは、次の方法でトリガーできます。

ワークロードトリガー: Pod 内のアプリケーションが、スナップショットの準備ができたことを GKE エージェントに通知します。このタイプのトリガーは、ワークロードの準備完了状態など、ワークロードサイクルで 1 回実行されます。この方法は、水平スケーリングワークロードの起動レイテンシを改善する場合に最適です。
手動トリガー: PodSnapshotManualTrigger カスタムリソースを作成して、特定の Pod のスナップショットをオンデマンドでトリガーできます。このタイプのトリガーは、必要な回数だけ実行できます。この方法は、準備完了を通知するようにアプリケーションを変更できない場合に最適です。

スナップショットの照合と互換性

スナップショットが復元されたワークロードと互換性があることを確認するため、GKE は元のチェックポイントされた Pod とターゲット Pod の間で互換性照合を行います。

互換性は、次のルールによって決まります。

選択順序: デフォルトでは、GKE は Pod の名前空間と構成に一致する最新の PodSnapshot リソースからワークロードを復元します。
一致条件: 互換性チェックは、PodSnapshotPolicy で構成されたスナップショットスコープ（whole-pod と rootfs-only）によって異なります。

`whole-pod` スコープの一致（デフォルト）

デフォルトの whole-pod スコープのポリシーの場合、GKE は次のことを確認します。

抽出された仕様のハッシュ: GKE は、Pod の仕様の重要なランタイムフィールドに基づいて一意のハッシュを生成します。復元を成功させるには、ターゲット Pod が抽出された仕様から同一のハッシュを生成する必要があります。このチェックにより、チェックポイントされた Pod と復元された Pod のランタイム構成が同一であることが保証されます。

Pod オブジェクトの次のフィールドは、抽出された仕様の一部であり、一意のハッシュに影響します。
- metadata:
  - annotations: gVisor ランタイムに関連するアノテーション（dev.gvisor.* プレフィックスで始まるアノテーションなど）。
  - labels: batch.kubernetes.io/job-completion-index
- spec:
  - volumes: name、volumeSource、hostPath、persistentVolumeClaim、configMap
  - containers:
    - name
    - image
    - command
    - args
    - workingDir
    - ports: name、containerPort、protocol
    - volumeMounts: name、readOnly、recursiveReadOnly、mountPath、subPath、mountPropagation、subPathExpr
    - volumeDevices: name
    - lifecycle: postStart、preStop
    - terminationMessagePath
    - terminationMessagePolicy
    - securityContext（およびすべてのサブフィールド）
    - stdin
    - stdinOnce
    - tty
  - initContainers: containers と同じサブフィールド。
  - dnsPolicy
  - automountServiceAccountToken
  - hostNetwork
  - hostPID
  - hostIPC
  - shareProcessNamespace
  - securityContext
  - dnsConfig
  - runtimeClassName
  - os
  - hostUsers
ハードウェアの互換性: ターゲット Pod は、元のチェックポイントされた Pod と同じマシンシリーズと CPU アーキテクチャを持つノードで実行する必要があります（N2 から N2、G2 から G2 など）。
バージョンの互換性: gVisor カーネルバージョンと GPU ドライバのバージョンは、元のスナップショットでキャプチャされたバージョンと一致している必要があります。

`rootfs-only` スコープの一致

rootfs-only スコープ（GKE バージョン 1.35.3-gke.1031000 以降で使用可能）でポリシーを構成する場合、一致要件は厳しくありません。

GKE は、抽出された Pod 仕様のハッシュを計算または比較しません。この一致条件が緩和されることで、基盤となるコンテナイメージとノードのバージョンに互換性がある場合、元のチェックポイントされた Pod とは異なるリソース、環境、その他の構成フィールドを持つターゲット Pod にスナップショットを復元できます。
プロセスメモリは復元されないため、あるマシンファミリーで取得したスナップショットを別のマシンファミリー（E2 マシンタイプを含む）に復元できます。

グループ化ルールの照合

ポリシーで snapshotGroupingRules フィールドを使用して、特定ラベルの値（テナントや環境など）でスナップショットをグループ化する場合、復元された Pod にはまったく同じラベルキーと値が必要です。Pod スナップショットコントローラは、一致するグループからスナップショットを選択します。グループ化ラベルの設定方法の詳細については、追加の Pod スナップショットポリシーを構成するをご覧ください。

readiness の復元とバックグラウンドの読み込み

Pod がスナップショットから復元されると、通常は数秒で gVisor カーネルが復元されます。起動レイテンシを最小限に抑えるため、カーネルが復元されるとすぐにアプリケーションが再開され、アプリケーションのメモリが完全に読み込まれるのを待ちません。アプリケーションのメモリは、バックグラウンドストリーミングメカニズムを使用して復元されます。

アプリケーションがまだ読み込まれていないメモリの一部にアクセスしようとすると、ページフォールトが発生します。gVisor はこのフォールトをインターセプトし、アプリケーションスレッドを一時停止して、必要なメモリページをストレージからすぐに取得します。このオンデマンドのフェッチは、バックグラウンドストリームよりも優先されます。

このバックグラウンド読み込みにより、アプリケーションがまだストリーミングされていないメモリを必要とする場合、復元後数秒間はメモリアクセスにわずかなレイテンシが生じる可能性があります。このレイテンシは、メモリ状態が完全に同期されると解消されます。

このバックグラウンド読み込みの動作は、GPU の状態にも適用されます。たとえば、大規模言語モデル（LLM）Pod は、GPU メモリがまだ入力中にもかかわらず、Running 状態になり、ネットワークチェックに応答することがあります。GPU の状態が完全に復元されるまで、モデルは推論に対して完全にレスポンシブになりません。この遅延のため、復元速度を測定する場合は、モデルサーバーが起動したタイミングを必ずキャプチャしてください。モデルサーバーの起動時刻は、最初のトークンまでの時間（TTFT）やPod の readiness プローブなどの指標を使用して確認できます。

GPU の状態

Pod スナップショットは、GPU の状態のキャプチャをサポートしています。GPU を使用する Pod のスナップショットをトリガーすると、NVIDIA cuda-checkpoint ツールは GPU 状態をプロセスのメモリに保存します。つまり、GPU に保存されているデータ（モデルの重みなど）はスナップショットに含まれます。その後、Pod は一時停止され、スナップショットが作成されます。復元の際には前述のプロセスが逆順で実行されます。

GPU の状態はプロセスのメモリに書き込まれるため、スナップショットと復元オペレーション中に Pod のメモリ使用量が増加します。Pod のメモリ上限を設定する場合は、この追加のメモリ要件を考慮する必要があります。

復元された Pod に関する考慮事項

Kubernetes API の観点から見ると、新しい Pod が作成されます。Pod の起動時に、Pod に対応するスナップショットがある場合、Pod は元のメモリとプロセス状態を含め、そのスナップショットから復元されます。ただし、新しい一意のインスタンスとして機能するには、Pod の状態のいくつかの側面を変更する必要があります。

復元後の次の状態の変化を検討してください。

ネットワークインターフェース: 復元された Pod に新しい IP アドレスが割り振られます。すべてのインターフェースとルートが再構成されます。スナップショットの時点で存在していたアクティブなネットワーク接続は、復元時に閉じられます。リスニングソケット、ループバック接続、Unix ドメインソケット接続は引き続き機能します。
ホスト名: 復元された Pod は新しい ID を想定し、新しいホスト名を受け取ります。
実時間: 実時間が現在の時刻にジャンプします。
アプリケーションの状態: アプリケーションの状態は、テスト ID や乱数シードなど、各 Pod で一意である必要があり、復元後に再初期化する必要があります。
Secret: スナップショットが取得される前に作成された暗号鍵と証明書は、再作成する必要があります。
環境変数: スナップショットと復元の間で環境変数を変更できます。ただし、環境変数はアプリケーションメモリに保存されるため、GKE Sandbox は環境変数を確実に検出して置換できません。ワークロードが復元後に新しい環境変数に依存している場合、Pod はそれらの変数を手動で更新する必要があります。新しい環境変数は /proc/gvisor/spec_environ ファイルで使用できます。ファイル形式は /proc/<pid>/environ と同じです。

マルチテナントと ID

Pod スナップショットでは、各 Pod の Kubernetes サービスアカウント（KSA）が Cloud Storage にアクセスするために、手動で IAM バインディングを行う必要があります。手動 IAM バインディングの伝播には時間がかかるため、Pod の作成直後にスナップショットを作成する必要がある場合は問題になる可能性があります。

遅延に対処し、マルチテナント管理を簡素化するために、IAM を KSA に手動でバインドする代わりに、GKE ノードサービスアカウントを使用して、オンデマンドで有効期間の短いトークンを作成することもできます。この方法で Pod スナップショットを構成するには、PodSnapshotStorageConfig オブジェクトの tokenSource フィールドに次のいずれかの値を指定します。

podKSA （デフォルト）: Pod の KSA を Cloud Storage バケットに手動で IAM バインドします。
federatedP4SA: ノードサービスアカウントによって生成されたパス固有のトークンを使用します。

制限事項と要件

GKE Pod スナップショットには次の制限があります。

Pod スナップショットは GKE Sandbox が提供する gVisor コンテナランタイムに依存するため、Pod は GKE Sandbox で実行する必要があります。
Pod スナップショットは、デフォルトの whole-pod スナップショットスコープを使用する場合、E2 マシンタイプをサポートしていません。ファイルシステムスナップショット（rootfs-only）は、E2 マシンタイプをサポートしています。
Pod スナップショットの GPU サポートには、次の要件と制限があります。
- シングル GPU Pod は、シングル GPU ノードとマルチ GPU ノードの両方でサポートされています。
- マルチ GPU Pod は、L4 GPU（g2-standard-* マシンタイプ）でのみサポートされています。
- マルチインスタンス GPU（MIG）との GPU 共有はサポートされていません。
- GKE バージョン 1.35.0-gke.1738000 以前では、マルチ GPU ノードで実行されている Pod は、そのノードで使用可能なすべての GPU を使用する必要があります。バージョン 1.35.0-gke.1738000 以降では、Pod はノード上の GPU のサブセットを使用できます。
- Pod スナップショットは、次のマシンタイプをサポートしています。
  - g2-standard-4（1 x L4）
  - g2-standard-8（1 x L4）
  - g2-standard-12（1 x L4）
  - g2-standard-16（1 x L4）
  - g2-standard-32（1 x L4）
  - g2-standard-48（4 x L4）
  - g2-standard-96（8 x L4）
  - a2-highgpu-1g（1 x A100-40GB）
  - a2-ultragpu-1g（1 x A100-80GB）
  - a3-highgpu-1g（1 x H100-80GB）
Cloud Storage FUSE CSI ドライバのサイドカーコンテナは、Pod スナップショットではサポートされていません。
Pod スナップショットは、TPU マシンタイプをサポートしていません。

次のステップ

Pod スナップショットの準備方法を学習する。

GKE Pod スナップショットについて コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。