Memicu snapshot Pod

Pelajari cara membuat kebijakan snapshot dan memicu snapshot Pod dari workload yang berjalan di Google Kubernetes Engine (GKE).

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

• Aktifkan Google Kubernetes Engine API.
Aktifkan Google Kubernetes Engine API
• Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung perintah yang dijalankan dalam dokumen ini.

• Pastikan Anda telah menyelesaikan prasyarat dan mengaktifkan snapshot Pod di cluster. Untuk mengetahui informasi selengkapnya, lihat Mempersiapkan snapshot Pod.

Membuat kebijakan snapshot

Untuk mengaktifkan snapshot untuk Pod, buat resource PodSnapshotPolicy dengan pemilih yang cocok dengan label Pod.

1. Contoh berikut membuat kebijakan yang berlaku untuk Pod dengan label app: my-app dan menggunakan konfigurasi penyimpanan example-pod-snapshot-storage-config. Simpan manifes berikut sebagai 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
   

   Ganti kode berikut:

   • TRIGGER_TYPE: jenis pemicu. Nilai yang didukung adalah workload untuk pemicu berbasis workload atau manual untuk snapshot sesuai permintaan.
   • NAMESPACE: namespace untuk Pod Anda.

   Untuk mengetahui daftar lengkap semua kolom yang dapat Anda konfigurasi, lihat dokumentasi PodSnapshotPolicy CustomResourceDefinition (CRD).

2. Terapkan manifes:

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

Mengonfigurasi kebijakan snapshot Pod tambahan

Anda dapat mengonfigurasi kebijakan tambahan di PodSnapshotPolicy, seperti berikut:

• Cakupan snapshot: untuk menentukan bagian status Pod yang akan diambil dalam snapshot, konfigurasi kolom spec.snapshotScope. Nilai yang didukung adalah whole-pod (default) untuk membuat checkpoint seluruh Pod termasuk status aplikasi, memori, dan sistem file, atau rootfs-only untuk membuat checkpoint hanya sistem file root container. Cakupan rootfs-only memerlukan GKE versi 1.35.3-gke.1031000 atau yang lebih baru.

• Pembersihan otomatis: untuk membersihkan resource snapshot Pod lama secara otomatis, konfigurasi kebijakan retensi menggunakan kolom spec.retentionConfig. Anda dapat menentukan durasi menggunakan kolom lastAccessTimeout (misalnya, 7d), setelah itu, snapshot akan dihapus.

• Mengatur snapshot: Anda dapat mengelompokkan snapshot secara logis untuk membedakan antara snapshot yang diambil di lingkungan yang serupa, tetapi dalam konteks yang berbeda. Misalnya, dalam skenario multi-tenant di mana Pod dasar sama untuk semua pengguna, Anda dapat mengisolasi snapshot menurut pengguna atau grup. Untuk mengisolasi snapshot, tentukan label pengelompokan dalam kebijakan menggunakan kolom snapshotGroupingRules. Saat dipulihkan, Pod hanya cocok dengan snapshot dalam grup label yang sama. Untuk mengetahui informasi selengkapnya tentang pengaruh pengelompokan ini terhadap pencocokan kompatibilitas selama pemulihan, lihat Pencocokan aturan pengelompokan.

Contoh berikut menunjukkan cara mengonfigurasi setelan retensi dan pengelompokan di PodSnapshotPolicy. Setelan ini dapat ditetapkan secara terpisah:

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

Untuk mengetahui daftar lengkap semua kolom yang dapat Anda konfigurasi, lihat dokumentasi referensi PodSnapshotPolicy.

Mengoptimalkan ukuran snapshot

Saat snapshot Pod dipicu, gVisor akan mengambil seluruh status semua container, termasuk:

• Status aplikasi, seperti memori dan register
• Perubahan pada sistem file root dan tmpfs (termasuk volume emptyDir)
• Status kernel, seperti deskriptor file terbuka, thread, dan soket

Ukuran snapshot ditentukan oleh faktor-faktor ini. Snapshot yang lebih besar memerlukan waktu lebih lama untuk disimpan dan dipulihkan. Untuk mengoptimalkan performa, sebelum memicu snapshot, Anda harus membersihkan status aplikasi atau file yang tidak diperlukan setelah Pod dipulihkan dari snapshot.

Mengoptimalkan ukuran snapshot sangat penting untuk workload seperti model bahasa besar (LLM). Server LLM sering mendownload bobot model ke penyimpanan lokal (rootfs atau tmpfs) sebelum memuatnya ke GPU. Saat snapshot diambil, status GPU dan file bobot model akan disimpan. Dalam skenario ini, jika modelnya 100 GB, snapshot yang dihasilkan kira-kira 200 GB (100 GB file model, ditambah 100 GB yang mewakili status GPU). Setelah bobot model dimuat ke GPU, file pada sistem file sering kali tidak diperlukan agar aplikasi dapat berjalan. Dengan menghapus file model ini sebelum memicu snapshot, Anda dapat mengurangi ukuran snapshot hingga setengahnya dan memulihkan aplikasi dengan latensi yang jauh lebih rendah.

Memicu snapshot

Anda dapat memicu snapshot dari dalam workload saat aplikasi siap, atau Anda dapat memicu snapshot sesuai permintaan secara manual untuk Pod tertentu.

Memicu snapshot dari workload

Untuk memicu snapshot dari dalam kode aplikasi, konfigurasi aplikasi Anda untuk mengirim sinyal saat siap untuk snapshot. Untuk memberi sinyal kesiapan, tulis 1 ke file /proc/gvisor/checkpoint, misalnya echo 1 > /proc/gvisor/checkpoint. Operasi tulis memulai proses snapshot secara asinkron dan langsung ditampilkan. Membaca dari deskriptor file yang sama akan memblokir proses pembacaan hingga snapshot dan pemulihan selesai serta workload siap dilanjutkan.

Penggunaan yang tepat akan bervariasi bergantung pada aplikasi Anda, tetapi contoh berikut menunjukkan pemicu snapshot untuk aplikasi Python. Untuk memicu snapshot dari workload contoh ini, selesaikan langkah-langkah berikut:

1. Simpan manifes berikut sebagai 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"
   

   Ganti kode berikut:

   • NAMESPACE: namespace untuk Pod Anda.
   • KSA_NAME: nama KSA Anda.

2. Deploy aplikasi:

   kubectl apply -f my-app.yaml
   

Memicu snapshot secara manual

Untuk memicu snapshot sesuai permintaan secara manual untuk Pod tertentu, buat resource PodSnapshotManualTrigger.

1. Contoh berikut memicu snapshot untuk Pod bernama my-pod. Simpan manifes berikut sebagai example-manual-trigger.yaml:

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

   Ganti NAMESPACE dengan namespace Pod Anda.

2. Terapkan manifes:

   kubectl apply -f example-manual-trigger.yaml
   

Untuk mengonfirmasi apakah snapshot berhasil dipicu, periksa kolom status dari resource PodSnapshotManualTrigger:

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

Kolom status menunjukkan apakah pemicu snapshot berhasil atau gagal.

Memverifikasi snapshot

Anda dapat mengonfirmasi bahwa snapshot telah diambil dengan memeriksa histori peristiwa untuk peristiwa 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

Ganti kode berikut:

• POD_NAME: nama Pod Anda, misalnya my-app atau my-pod.
• NAMESPACE: namespace untuk Pod Anda.

Outputnya akan terlihat seperti berikut:

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

Langkah berikutnya

Pelajari cara memulihkan workload dari snapshot Pod.