排解 Pod 快照問題

本文說明如何解決 GKE Pod 快照和相關資源的常見問題。

如果您是應用程式開發人員、平台管理員或運算子，且使用 Pod 快照檢查點和還原工作負載，請務必詳閱本文資訊。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 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 相同，不會檢查點。檢查基礎映像檔，確保重要資料不會儲存在隱含磁碟區中。