觸發 Pod 快照

瞭解如何建立快照政策，以及在 Google Kubernetes Engine (GKE) 上觸發執行中工作負載的 Pod 快照。

事前準備

開始之前，請務必先完成下列工作：

  • 啟用 Google Kubernetes Engine API。
    • 啟用 Google Kubernetes Engine API
  • 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。
  • 請確認您已完成必要條件，並在叢集上啟用 Pod 快照。詳情請參閱「準備 Pod 快照」。

建立快照政策

如要為 Pod 啟用快照，請建立 PodSnapshotPolicy 資源，並使用與 Pod 標籤相符的選取器。

  1. 下列範例會建立適用於具有 app: my-app 標籤的 Pod 的政策，並使用 example-pod-snapshot-storage-config 儲存空間設定。將下列資訊清單儲存為 example-pod-snapshot-policy.yaml：

    apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotPolicy
metadata:
  name: example-pod-snapshot-policy
  namespace: NAMESPACE
spec:
  storageConfigName: example-pod-snapshot-storage-config
  selector:
    matchLabels:
      app: my-app
  triggerConfig:
    type: TRIGGER_TYPE
    postCheckpoint: resume

    更改下列內容：

    • TRIGGER_TYPE：觸發條件類型。支援的值為 workload (工作負載觸發條件) 或 manual (隨選快照)。
    • NAMESPACE：Pod 的命名空間。

    如需可設定的所有欄位完整清單，請參閱 PodSnapshotPolicy CustomResourceDefinition (CRD) 說明文件。

  2. 套用資訊清單：

    kubectl apply -f example-pod-snapshot-policy.yaml

設定其他 Pod 快照政策

您可以在 PodSnapshotPolicy 中設定其他政策，例如：

  • 快照範圍：如要指定要在快照中擷取的 Pod 狀態部分，請設定 spec.snapshotScope 欄位。支援的值為 whole-pod (預設)，可檢查點整個 Pod，包括應用程式狀態、記憶體和檔案系統，或 rootfs-only，僅檢查點容器根檔案系統。rootfs-only 範圍需要 GKE 1.35.3-gke.1031000 以上版本。

  • 自動清理：如要自動清理舊的 Pod 快照資源，請使用 spec.retentionConfig 欄位設定保留政策。您可以使用 lastAccessTimeout 欄位指定時間長度 (例如 7d)，時間一到就會刪除快照。

  • 整理快照：您可以將快照依邏輯分組，區分在類似環境但不同情境下拍攝的快照。舉例來說，在多租戶情境中，如果所有使用者的基本 Pod 都相同，您可以依使用者或群組隔離快照。如要隔離快照，請使用 snapshotGroupingRules 欄位，在政策中指定分組標籤。還原 Pod 時，系統只會比對相同標籤群組中的快照。如要進一步瞭解分組對還原期間的相容性比對有何影響，請參閱「分組規則比對」。

以下範例說明如何在 PodSnapshotPolicy 中設定保留和分組設定。您可以分別設定以下項目：

# ... other fields omitted
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

如需可設定的所有欄位完整清單，請參閱 PodSnapshotPolicy 參考文件。

最佳化快照大小

觸發 Pod 快照時，gVisor 會擷取所有容器的完整狀態，包括：

  • 應用程式狀態，例如記憶體和暫存器
  • 根檔案系統和 tmpfs 的變更 (包括 emptyDir 磁碟區)
  • 核心狀態，例如開啟的檔案描述元、執行緒和通訊端

快照大小取決於下列因素。快照越大，儲存和還原所需的時間就越長。為提升效能，觸發快照前，您應清理從快照還原 Pod 後不需要的任何應用程式狀態或檔案。

對於大型語言模型 (LLM) 等工作負載，最佳化快照大小尤其重要。LLM 伺服器通常會先將模型權重下載到本機儲存空間 (rootfs 或 tmpfs)，再載入 GPU。建立快照時，系統會儲存 GPU 狀態和模型權重檔案。在這種情況下，如果模型為 100 GB，產生的快照大約為 200 GB (100 GB 的模型檔案，加上代表 GPU 狀態的 100 GB)。將模型權重載入 GPU 後，應用程式通常不需要檔案系統中的檔案即可執行。在觸發快照前刪除這些模型檔案，可將快照大小縮減一半，並以明顯較低的延遲時間還原應用程式。

觸發快照

應用程式準備就緒時，您可以從工作負載內觸發快照，也可以手動觸發特定 Pod 的隨選快照。

從工作負載觸發快照

如要從應用程式程式碼中觸發快照，請將應用程式設定為在準備好建立快照時傳送信號。如要發出就緒信號，請將 1 寫入 /proc/gvisor/checkpoint 檔案，例如 echo 1 > /proc/gvisor/checkpoint。寫入作業會非同步啟動快照程序，並立即傳回。從相同檔案描述元讀取資料時，讀取程序會遭到封鎖，直到快照和還原作業完成，且工作負載準備好繼續執行為止。

實際用量會因應用程式而異，但下列範例顯示 Python 應用程式的快照觸發程序。如要從這個範例工作負載觸發快照，請完成下列步驟：

  1. 將下列資訊清單儲存為 my-app.yaml：

    apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: KSA_NAME
  runtimeClassName: gvisor
  containers:
  - name: my-container
    image: python:3.10-slim
    command: ["python3", "-c"]
    args:
      - |
        import time
        def trigger_snapshot():
          try:
            with open("/proc/gvisor/checkpoint", "r+") as f:
              f.write("1")
              res = f.read().rstrip()
              print(f"GKE Pod Snapshot: {res}")
          except FileNotFoundError:
            print("GKE Pod Snapshot file does not exist -- Pod Snapshots is disabled")
            return
        i = 0
        while True:
          print(f"Count: {i}", flush=True)
          if (i == 20): #simulate the application being ready to snapshot at 20th count
            trigger_snapshot()
          i += 1
          time.sleep(1)
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "250m"
        memory: "256Mi"

    更改下列內容：

    • NAMESPACE：Pod 的命名空間。
    • KSA_NAME：KSA 名稱。

  2. 部署應用程式：

    kubectl apply -f my-app.yaml

手動觸發快照

如要手動觸發特定 Pod 的隨選快照，請建立 PodSnapshotManualTrigger 資源。

  1. 以下範例會觸發名為 my-pod 的 Pod 快照。將下列資訊清單儲存為 example-manual-trigger.yaml：

    apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod

    將 NAMESPACE 替換為 Pod 的命名空間。

  2. 套用資訊清單：

    kubectl apply -f example-manual-trigger.yaml

如要確認快照是否已成功觸發，請檢查 PodSnapshotManualTrigger 資源的 status 欄位：

kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io example-manual-trigger -n NAMESPACE -o yaml

status 欄位會指出快照觸發作業是否成功。

驗證快照

如要確認是否已拍攝快照，請查看事件記錄中的 GKEPodSnapshotting 事件：

kubectl get events -o \
custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
--namespace NAMESPACE \
--field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting

更改下列內容：

  • POD_NAME：Pod 的名稱，例如 my-app 或 my-pod。
  • NAMESPACE：Pod 的命名空間。

輸出結果會與下列內容相似：

NAME                                    CREATIONTIME           REASON               MESSAGE
default/5b449f9c7c-bd7pc                2025-11-05T16:25:11Z   GKEPodSnapshotting   Successfully checkpointed the pod to PodSnapshot

後續步驟

瞭解如何從 Pod 快照還原工作負載。