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

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

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

PVC を使用したチェックポイント後のミューテーションのリスク

Pod が Persistent Volume Claim（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 と同様にチェックポイントは作成されません。ベースイメージをチェックして、重要なデータが暗黙的なボリュームに保存されていないことを確認します。