Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Memicu snapshot Pod

Autopilot Standard

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.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel compute/region properti . Jika Anda terutama menggunakan cluster zona, tetapkan compute/zone sebagai gantinya. Dengan menetapkan lokasi default, Anda dapat menghindari error di gcloud CLI seperti berikut: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster berbeda dengan default yang Anda tetapkan.

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.

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).

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:

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.

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.

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.

Catatan: Kebijakan snapshot yang memilih Pod ini harus memiliki jenis pemicu yang ditetapkan ke manual.

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