Pod スナップショットのトラブルシューティング

このドキュメントでは、GKE Pod スナップショットとその関連リソースに関する一般的な問題を解決する方法について説明します。

この情報は、Pod スナップショットを使用してワークロードのチェックポイントと復元を行うアプリケーション デベロッパー、プラットフォーム管理者、運用担当者にとって重要です。のコンテンツで 使用されている Google Cloud 一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロール とタスクをご覧ください。

PVC を使用したチェックポイント後の変更のリスク

Pod が永続ボリュームの要求（PVC）を使用している場合、「チェックポイントと再開」ワークフローで重大なリスクが発生します。チェックポイントの直後に再開するようにワークロードを構成すると（postCheckpoint: resume フィールドを使用）、アプリケーションはアクティブな状態を維持し、チェックポイント後に PVC を変更できます。

  • 正常なシャットダウンの問題: チェックポイントと再開のサイクル後、 Pod を削除すると、Kubernetes はコンテナ内のメインプロセスに SIGTERM シグナルを送信して、正常なシャットダウン シーケンスを開始します。多くのアプリケーションは、正常なシャットダウン ロジックを実装しています。このロジックでは、クリーンアップ ルーチンをトリガーして、PVC 上の一時ファイルを削除または更新する場合があります。
  • 復元の失敗: Pod スナップショットの作成後に PVC でこれらの変更が行われると、復元手順ではチェックポイントの時点での PVC の状態が想定されるため、復元の失敗やデータの不整合が発生する可能性があります。
  • 推奨される軽減策: ワークロードに PVC の使用が必要な場合は、 チェックポイント後にワークロードを再開しないでください。PodSnapshotPolicy で構成 postCheckpoint: stop を使用します。この構成により、チェックポイント フェーズの完了後にプロセスが補助的な書き込みや状態変更を行うことがなくなります。

ConfigMap マウントとディレクトリ マスク

構成データをコンテナに統合する場合、マウント方法がスナップショットの整合性に影響する可能性があります。

標準のボリューム マウントを使用して ConfigMap がマウントされている場合、Kubernetes はターゲット ディレクトリ全体を外部マウントとして扱います。外部マウントはスナップショットの作成時にスキップされるため、ディレクトリ全体がスナップショットから除外されます。

次の例では、ディレクトリ全体が外部マウントであるため、/etc/my-app/ ディレクトリの変更はスナップショットにキャプチャされません。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

この問題を解決するには、subPath を使用します。subPath を使用すると、特定の構成ファイルのみが外部マウントとして扱われます。この構成は正確なファイルをターゲットとするため、親ディレクトリ内の残りのファイルと構造はコンテナのローカル ファイル システムの一部として保持され、チェックポイント処理中に適切にキャプチャされます。

次の例は、subPath を使用する volumeMounts 構成を示しています。

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

暗黙的な匿名ボリューム

一部のコンテナ イメージでは、Dockerfile の VOLUME 命令を使用して、メタデータ内にボリュームを定義します。Pod 仕様でボリュームを定義していない場合でも、Kubernetes はベースイメージでボリュームとして定義されたパスに対して匿名ボリュームを自動的に作成します。たとえば、alpine/git イメージ は /git を暗黙的なボリュームとして定義します。

これらの匿名ボリュームは外部マウントとして扱われ、PVC と同様にチェックポイントは作成されません。重要なデータが暗黙的なボリュームに保存されていないことを確認するには、ベースイメージを確認してください。