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

Google Kubernetes Engine（GKE）Pod スナップショットは、実行中の Pod のスナップショットを復元することで、ワークロードの起動レイテンシを改善します。Pod スナップショットは、メモリやファイル システムの変更など、Pod の状態全体を保存します。新しいレプリカを作成すると、スナップショットから復元されるため、ワークロードは新しい状態から開始するのではなく、再開できます。この機能は、大規模な重みをメモリに読み込む AI 推論モデルや、広範な依存関係を読み込むアプリケーションなど、ワークロードの水平スケーリングに役立ちます。

このドキュメントでは、GKE Pod スナップショットの仕組みを理解し、ワークロードでメリットが得られるかどうかを評価します。

プラットフォーム管理者とオペレーター、アプリケーション デベロッパーは、このドキュメントを使用して、ワークロードの互換性を評価し、スナップショット ストレージ ポリシーを計画し、GKE がチェックポイントと復元を管理する方法を理解できます。Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

クラスタで Pod スナップショットを準備して使用するには、次のガイドをご覧ください。

  1. Pod スナップショットの準備をする
  2. Pod スナップショットをトリガーする
  3. Pod スナップショットからワークロードを復元する

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

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

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

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

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

スナップショットの内容

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

カテゴリ 含まれる 含まない
アプリケーションのステータス
  • プロセスメモリ
  • 実行スレッド
  • CPU レジスタ
  • 開いているファイル記述子
 なし（メモリ内のすべてのプロセス状態がキャプチャされます）
ファイル システム
  • コンテナのルート ファイル システム（rootfs）
  • emptyDir 巻
  • tmpfs 個のマウント
  • PersistentVolumeClaim オブジェクト
  • 含まれるものとして記載されていないその他のボリュームまたはストレージ タイプ
ネットワーキング
  • ループバック接続
  • リスニング ソケット
  • Unix ドメイン ソケット
  • アクティブな外部接続（復元時に閉じられます）
  • カスタムルート
  • ユーザー定義ルール（iptables、nftables）

カスタム リソース

Pod スナップショットを宣言的に構成するには、次のカスタム リソースを使用します。

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

リファレンス仕様については、PodSnapshot CustomResourceDefinition リファレンスをご覧ください。

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

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

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

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

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

GKE は、次のルールを使用して互換性を判断します。

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

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

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

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

    Pod オブジェクトの次のフィールドは、抽出された仕様の一部であり、一意のハッシュに影響します。

    • metadata:
      • annotations: GKE Sandbox に関連するアノテーション（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 など）。

  • バージョンの互換性: GKE Sandbox カーネル バージョンと GPU ドライバのバージョンが、元のスナップショットでキャプチャされたバージョンと一致している必要があります。

rootfs-only スコープのマッチング

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

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

グループ化ルールの照合

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

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

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

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

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

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

GPU の状態

Pod スナップショットは、GPU の状態のキャプチャをサポートしています。GPU を使用する Pod のスナップショットをトリガーすると、NVIDIA cuda-checkpoint ツールは GPU 状態をプロセスのメモリに保存します。この手順により、モデルの重みなど、GPU に保存されているデータがスナップショットに含まれるようになります。GKE は Pod を一時停止し、スナップショットを取得します。復元中、GKE はこのオペレーションを逆に行います。

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

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

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

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

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

マルチテナンシーと ID

Pod スナップショットでは、Cloud Storage を使用するために、各 Pod の Kubernetes ServiceAccount オブジェクトに Identity and Access Management（IAM）バインディングを手動で作成する必要があります。手動の IAM バインディングは伝播に時間がかかるため、Pod の作成直後にスナップショットを作成する必要がある場合は問題になる可能性があります。

遅延を解消し、マルチテナント管理を簡素化するには、IAM を ServiceAccount オブジェクトに手動でバインドする代わりに、GKE ノード サービス アカウントを使用してオンデマンドで短命トークンを作成します。この方法で Pod スナップショットを構成するには、PodSnapshotStorageConfig カスタム リソースの tokenSource フィールドに次のいずれかの値を指定します。

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

要件

GKE Pod スナップショットを使用するには、次の要件を満たしていることを確認してください。

  • Pod スナップショットは GKE Sandbox が提供する分離された環境に依存するため、Pod は GKE Sandbox で実行する必要があります。
  • Pod スナップショットで GPU を使用するには、次の要件を満たす必要があります。
    • 単一 GPU Pod は、単一 GPU ノードとマルチ GPU ノードの両方でサポートされています。
    • マルチ GPU Pod は、L4 GPU（g2-standard-* マシンタイプ）でのみサポートされています。
    • GKE バージョン 1.35.0-gke.1738000 以前では、マルチ GPU ノードで実行される Pod は、そのノードで使用可能なすべての GPU を使用する必要があります。バージョン 1.35.0-gke.1738000 以降では、Pod はノード上の GPU のサブセットを使用できます。
    • 次のいずれかのサポートされているマシンタイプを使用する必要があります。
      • 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）

制限事項

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

  • デフォルトの whole-pod スナップショット スコープを使用する場合、Pod スナップショットは E2 マシンタイプをサポートしません。ファイル システム スナップショット（rootfs-only）は、E2 マシンタイプをサポートしています。
  • マルチインスタンス GPU（MIG）を使用した GPU 共有はサポートされていません。
  • Cloud Storage FUSE CSI ドライバのサイドカー コンテナは、Pod スナップショットではサポートされていません。
  • Pod スナップショットは TPU をサポートしていません。

次のステップ