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 ベンダー、CPU 機能セット（CPUID フラグ）を持つノードで実行する必要があります。たとえば、両方のノードで同じ N2 または G2 シリーズと、同じ Intel または AMD プロセッサ機能を使用する必要があります。GKE Sandbox は、プロセスのメモリと CPU 状態を復元する前に CPU 機能を検証するため、whole-pod スコープのスナップショットは、異なる CPU 機能を持つノードに復元できません。

  • バージョンの互換性: 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 スナップショットでは、各 Pod の Kubernetes ServiceAccount オブジェクトに Identity and Access Management（IAM）バインディングを手動で設定して、Cloud Storage を使用する必要があります。手動の IAM バインディングは反映に時間がかかることがあります。Pod の作成直後にスナップショットを取得する必要がある場合は、これが問題になる可能性があります。

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

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

要件

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

  • Pod スナップショットは GKE Sandbox が提供する分離環境に依存するため、Pod は GKE Sandbox で実行する必要があります。
  • デフォルトの whole-pod スナップショット スコープの場合、Pod が復元されるノードには、スナップショットが作成されたノードと同じマシンシリーズ、CPU ベンダー、CPU 機能が必要です。CPU のみのワークロードでは、これらのハードウェア互換性要件を満たす、GKE Sandbox でサポートされている E2 以外のマシンシリーズを使用できます。詳細については、制限事項をご覧ください。
  • 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 のサブセットを使用できます。
    • GPU ワークロードの場合は、次のサポートされている 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 スナップショット スコープを使用する場合、スナップショットは、スナップショットが作成された VM とは異なる CPU 機能（CPUID フラグ）を持つ Compute Engine VM に復元できません。
    • whole-pod スコープの Pod スナップショットは、E2 マシンシリーズ、または Intel と AMD のプロセッサや CPU 世代を動的に混在させる他のマシンシリーズをサポートしていません。ファイル システム スナップショット（rootfs-only スコープ）は、E2 マシンシリーズをサポートしています。
    • 同じ E2 以外のマシンシリーズと CPU ベンダー内でも、Compute Engine は異なる CPU プラットフォームまたは VM ごとの CPU 機能セットを使用して VM をプロビジョニングする場合があります。CPU 機能が一致しないノードに Pod がスケジュールされている場合、whole-pod スコープのスナップショットの復元は失敗します。
  • マルチインスタンス GPU（MIG）を使用した GPU 共有はサポートされていません。
  • Cloud Storage FUSE CSI ドライバのサイドカー コンテナは、Pod スナップショットではサポートされていません。
  • Pod スナップショットは TPU をサポートしていません。

次のステップ