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

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

このドキュメントでは、GKE Pod スナップショットの概要について説明します。この機能を有効にして使用する方法については、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 などのユーザーが追加したルールとルートは復元されません。

カスタム リソース定義

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

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

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

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

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

スナップショットの照合

Pod の照合では、Pod スナップショットが特定の Pod と互換性があるかどうかが判断されます。この照合は、Pod の重要なランタイム仕様（抽出された Pod 仕様とも呼ばれます）から一意のハッシュを作成することで実現されます。このハッシュは Pod スナップショット内に埋め込まれます。後でこの Pod スナップショットから Pod を復元するには、独自の抽出された Pod 仕様から同一のハッシュを生成する必要があります。このプロセスにより、チェックポイントされた Pod と復元された Pod のランタイム構成が同一であることが保証されます。

蒸留では、image などの重要なランタイム フィールドのみを保持し、nodeName や nodeSelector などの不要なフィールドを削除することで、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 の数とメモリ容量は変更できます。E2 マシンタイプは、基盤となる動的アーキテクチャのためサポートされていません。
  • バージョニング: gVisor カーネルのバージョンと GPU ドライバのバージョンが一致している必要があります。

GKE はスナップショットの互換性を管理します。GKE が互換性のあるスナップショットを見つけると、GKE はスナップショットから新しい 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 スナップショットでは、Cloud Storage にアクセスするために、各 Pod の Kubernetes ServiceAccount（KSA）に手動で 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 スナップショットは、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）
  • Pod スナップショットでの Cloud Storage FUSE CSI ドライバのサイドカー コンテナの使用はサポートされていません。
  • Pod スナップショットは、TPU マシンタイプをサポートしていません。

次のステップ