Memicu snapshot Pod

Untuk mengurangi latensi startup untuk workload Google Kubernetes Engine (GKE), Anda dapat mengambil snapshot Pod yang sedang berjalan dan memulihkan Pod baru darinya. Dokumen ini menunjukkan cara membuat kebijakan snapshot Pod dan memicu snapshot, baik dari workload Anda maupun secara manual. Untuk mengetahui informasi selengkapnya tentang cara kerja snapshot Pod, lihat Tentang snapshot Pod GKE.

Admin dan operator platform serta Developer aplikasi dapat menggunakan dokumen ini untuk mengonfigurasi kebijakan snapshot dan memicu snapshot. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang dirujuk dalam konten Cloud de Confiance by S3NS, lihat Peran dan tugas pengguna GKE umum.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Untuk 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 menjalankan perintah dalam dokumen ini.
  • Selesaikan prasyarat dan aktifkan snapshot Pod di cluster Anda. Untuk mengetahui informasi selengkapnya tentang cara menyiapkan cluster dan penyimpanan, lihat Bersiap untuk snapshot Pod.

Membuat kebijakan snapshot

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

  1. Simpan manifes berikut sebagai example-pod-snapshot-policy.yaml. Contoh ini membuat kebijakan yang berlaku untuk Pod dengan label app: my-app. Kebijakan ini menggunakan resource kustom example-pod-snapshot-storage-config PodSnapshotStorageConfig, yang Anda buat di Mempersiapkan snapshot Pod, untuk menentukan lokasi penyimpanan snapshot:

    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:

    • NAMESPACE: namespace untuk Pod Anda. Gunakan namespace yang sama dengan yang Anda beri akses Cloud Storage di Mempersiapkan snapshot Pod.
    • TRIGGER_TYPE: jenis pemicu. Nilai yang didukung adalah workload untuk pemicu berbasis workload atau manual untuk snapshot on-demand.

    Dalam contoh ini, setelan postCheckpoint: resume membuat Pod tetap berjalan setelah GKE mengambil snapshot.

    Untuk mengetahui daftar lengkap kolom yang dapat Anda konfigurasi, lihat spesifikasi PodSnapshotPolicy.

  2. Terapkan manifes:

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

Mengonfigurasi setelan kebijakan snapshot Pod tambahan

Resource kustom PodSnapshotPolicy Anda juga mendukung setelan opsional selain pemilih, konfigurasi penyimpanan, dan pemicu yang diperlukan. Setelan tambahan ini mengontrol apa yang diambil oleh setiap snapshot, berapa lama GKE menyimpan snapshot, dan cara GKE mengelompokkan snapshot untuk pemulihan:

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

  • Pembersihan otomatis: untuk otomatis membersihkan resource kustom PodSnapshot lama, konfigurasikan kebijakan retensi menggunakan kolom spec.retentionConfig. Anda dapat menentukan durasi menggunakan kolom lastAccessTimeout—misalnya, 7d. Setelah durasi ini berlalu, GKE akan menghapus snapshot.

  • Pengelompokan snapshot: untuk mengisolasi snapshot yang diambil di lingkungan yang serupa, tetapi dalam konteks yang berbeda, tentukan label pengelompokan di kolom spec.snapshotGroupingRules. Misalnya, dalam skenario multi-tenant dengan Pod dasar yang sama untuk semua pengguna, Anda dapat mengisolasi snapshot berdasarkan pengguna atau grup. Selama pemulihan, GKE hanya memilih snapshot dari grup label yang sama. Untuk mengetahui informasi selengkapnya tentang pengaruh pengelompokan ini terhadap pencocokan kompatibilitas selama pemulihan, lihat Pencocokan aturan pengelompokan.

Anda dapat mengonfigurasi setelan cakupan, retensi, dan pengelompokan snapshot secara terpisah. Contoh berikut menunjukkan ketiga setelan dalam resource kustom PodSnapshotPolicy:

# Multiple lines are omitted here
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Untuk mengetahui daftar lengkap kolom yang dapat Anda konfigurasi, lihat spesifikasi PodSnapshotPolicy.

Mengoptimalkan ukuran snapshot

Snapshot yang lebih besar memerlukan waktu lebih lama untuk disimpan dan dipulihkan. Sebelum Anda memicu snapshot, kurangi ukurannya dengan menghapus file sementara atau status aplikasi yang tidak diperlukan aplikasi setelah GKE memulihkan Pod dari snapshot.

Dengan cakupan snapshot whole-pod default, GKE Sandbox mengambil seluruh status semua container, termasuk hal berikut:

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

Mengoptimalkan ukuran snapshot sangat penting untuk workload seperti model bahasa besar (LLM). Server LLM sering kali mendownload bobot model ke penyimpanan lokal (rootfs atau tmpfs) sebelum memuatnya ke GPU. Saat Anda mengambil snapshot, GKE Sandbox akan menyimpan status GPU dan file bobot model. Dalam skenario ini, jika model berukuran 100 GB, snapshot yang dihasilkan berukuran sekitar 200 GB (100 GB file model, ditambah 100 GB yang mewakili status GPU). Setelah aplikasi memuat bobot model ke GPU, aplikasi sering kali tidak memerlukan file di sistem file untuk dijalankan. 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

Pilih salah satu metode berikut untuk memicu snapshot:

  • Pemicu workload: gunakan metode ini jika Anda dapat mengubah aplikasi untuk memberi sinyal bahwa aplikasi siap untuk snapshot—misalnya, setelah inisialisasi selesai. Metode ini paling cocok untuk meningkatkan latensi startup workload yang diskalakan secara horizontal. Pemicu workload hanya berjalan sekali dalam siklus workload.

  • Pemicu manual: gunakan metode ini jika Anda tidak dapat mengubah aplikasi untuk memberi sinyal kesiapan, atau jika Anda menginginkan snapshot on-demand dari Pod tertentu. Anda dapat membuat pemicu manual sebanyak yang Anda perlukan.

Memicu snapshot dari workload

Untuk memicu snapshot dari dalam kode aplikasi, konfigurasikan aplikasi Anda untuk mengirim sinyal saat siap untuk snapshot. Untuk memberi sinyal kesiapan, tulis nilai 1 ke file /proc/gvisor/checkpoint—misalnya, dengan menjalankan perintah echo 1 > /proc/gvisor/checkpoint. Operasi tulis memulai proses snapshot secara asinkron dan langsung menampilkan hasil. Membaca dari deskriptor file yang sama akan memblokir proses pembacaan hingga operasi snapshot atau pemulihan selesai dan workload siap dilanjutkan.

Sebelum memicu snapshot dari workload, pastikan kebijakan snapshot memilih Pod. Nilai kolom triggerConfig.type dalam kebijakan tersebut harus ditetapkan ke workload.

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

  1. Simpan manifes berikut sebagai my-app.yaml. Dalam contoh ini, label app: my-app cocok dengan pemilih dalam contoh kebijakan snapshot, dan setelan runtimeClassName: gvisor menjalankan Pod di GKE Sandbox:

    apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: SERVICEACCOUNT_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 readiness at the 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.
    • SERVICEACCOUNT_NAME: nama objek ServiceAccount yang Anda beri akses Cloud Storage di Mempersiapkan snapshot Pod.

  2. Deploy aplikasi:

    kubectl apply -f my-app.yaml

    Setelah aplikasi dimulai dan memberi sinyal bahwa aplikasi sudah siap, GKE Sandbox akan mengambil snapshot. Untuk mengonfirmasi bahwa snapshot berhasil, lihat Memverifikasi snapshot.

Memicu snapshot secara manual

Sebelum memicu snapshot secara manual, pastikan Pod target berjalan dan kebijakan snapshot memilih Pod. Nilai kolom triggerConfig.type dalam kebijakan tersebut harus ditetapkan ke manual.

Untuk memicu snapshot on-demand secara manual untuk Pod tertentu, buat resource kustom PodSnapshotManualTrigger dengan mengikuti langkah-langkah berikut:

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

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

    Ganti NAMESPACE dengan namespace untuk Pod Anda.

  2. Terapkan manifes:

    kubectl apply -f example-manual-trigger.yaml

  3. Untuk mengonfirmasi bahwa snapshot berhasil dipicu, periksa bagian status pada resource kustom PodSnapshotManualTrigger:

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

    Ganti NAMESPACE dengan namespace untuk Pod Anda.

    Jika pemicu berhasil, kolom status.conditions akan menunjukkan bahwa checkpoint telah selesai dan kolom status.snapshotCreated akan menampilkan nama resource kustom PodSnapshot yang dibuat.

Memverifikasi snapshot

Untuk mengonfirmasi bahwa GKE mengambil snapshot, periksa 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:

  • NAMESPACE: namespace untuk Pod Anda.
  • POD_NAME: nama Pod Anda.

Outputnya mirip dengan hal berikut ini:

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

Kolom MESSAGE menampilkan Successfully checkpointed the pod to PodSnapshot, yang mengonfirmasi bahwa GKE menyimpan status Pod ke resource kustom PodSnapshot. Untuk melihat dan mengelola resource kustom PodSnapshot, lihat Mengelola snapshot.

Langkah berikutnya