Tentang snapshot Pod GKE

Snapshot Pod Google Kubernetes Engine (GKE) membantu meningkatkan latensi startup workload dengan memulihkan snapshot Pod yang sedang berjalan. Snapshot Pod menyimpan seluruh status Pod, termasuk perubahan memori dan sistem file. Saat Anda membuat replika baru, replika tersebut akan dipulihkan dari snapshot, sehingga workload dapat dilanjutkan, bukan dimulai dari status baru. Kemampuan ini berguna untuk menskalakan workload secara horizontal, seperti model inferensi AI yang memuat bobot besar ke dalam memori atau aplikasi yang memuat dependensi ekstensif.

Gunakan dokumen ini untuk memahami cara kerja snapshot Pod GKE dan mengevaluasi apakah workload Anda dapat memperoleh manfaat darinya.

Admin dan operator platform serta Developer aplikasi dapat menggunakan dokumen ini untuk mengevaluasi kompatibilitas workload, merencanakan kebijakan penyimpanan snapshot, dan memahami cara GKE mengelola checkpoint dan pemulihan. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang dirujuk dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE umum.

Untuk mempersiapkan dan menggunakan snapshot Pod di cluster Anda, lihat panduan berikut:

  1. Bersiap untuk snapshot Pod
  2. Memicu snapshot Pod
  3. Memulihkan workload dari snapshot Pod

Kapan harus menggunakan snapshot Pod

Gunakan snapshot Pod untuk workload yang memiliki waktu inisialisasi yang lama. Contohnya mencakup workload inferensi AI yang memuat model besar ke dalam memori CPU atau GPU, atau aplikasi besar yang memuat banyak library dan dependensi. Workload yang sudah memiliki waktu startup cepat umumnya tidak akan mendapatkan manfaat dari snapshot Pod.

Cara kerja snapshot Pod

Snapshot Pod GKE menyimpan salinan persis status proses Pod pada waktu tertentu. Saat Anda membuat replika baru, GKE akan memulihkan Pod dari snapshot, bukan menginisialisasi Pod dari status baru. Pemulihan ini berarti Pod melanjutkan eksekusi dari titik pengambilan snapshot.

Untuk mengonfigurasi snapshot Pod secara deklaratif, Anda membuat resource kustom Kubernetes untuk menentukan perilaku snapshot. Agen yang berjalan di setiap node GKE mengelola siklus proses snapshot. Berdasarkan kebijakan yang Anda tentukan, agen akan menentukan kapan harus membuat snapshot baru dan kapan harus menggunakan snapshot yang ada untuk memulihkan Pod baru. Pengontrol yang berjalan di bidang kontrol GKE membersihkan snapshot yang sudah tidak berlaku dan menyelesaikan masalah. Cloud Storage menyimpan snapshot Pod Anda.

Konten snapshot

Tabel berikut mencantumkan hal-hal yang disertakan dan dikecualikan dalam snapshot Pod:

Kategori Disertakan Dikecualikan
Status aplikasi
  • Memori proses
  • Thread eksekusi
  • Register CPU
  • Deskriptor file terbuka
 Tidak ada (semua status proses dalam memori diambil)
Sistem file
  • Sistem file root container (rootfs)
  • emptyDir volume
  • tmpfs pemasangan
  • Objek PersistentVolumeClaim
  • Jenis volume atau penyimpanan lain yang tidak tercantum sebagai disertakan
Jaringan
  • Koneksi loopback
  • Soket pemroses
  • Soket domain Unix
  • Koneksi eksternal aktif (ditutup saat pemulihan)
  • Rute kustom
  • Aturan yang ditentukan pengguna (iptables, nftables)

Resource kustom

Untuk mengonfigurasi snapshot Pod secara deklaratif, gunakan resource kustom berikut:

  • PodSnapshotStorageConfig: menentukan lokasi penyimpanan untuk snapshot. Hanya mendukung bucket Cloud Storage.
  • PodSnapshotPolicy: menentukan Pod mana yang akan di-snapshot berdasarkan pemilih label Kubernetes. Resource kustom ini berisi sebagian besar opsi konfigurasi untuk fitur, termasuk cara snapshot dipicu, cakupan snapshot, dan kebijakan retensi.
  • PodSnapshotManualTrigger (opsional): jika Anda tidak menggunakan pemicu workload, tentukan pemicu manual untuk membuat snapshot untuk Pod tertentu.

Untuk spesifikasi referensi, lihat Referensi CustomResourceDefinition PodSnapshot.

Pemicu snapshot

Anda dapat memicu snapshot Pod dengan cara berikut:

  • Pemicu workload: aplikasi di dalam Pod memberi sinyal kepada agen GKE bahwa aplikasi tersebut siap untuk snapshot. Jenis pemicu ini dijalankan sekali dalam siklus workload, misalnya pada status workload siap. Pendekatan ini paling cocok untuk meningkatkan latensi startup workload yang diskalakan secara horizontal.
  • Pemicu manual: Anda dapat memicu snapshot sesuai permintaan untuk Pod tertentu dengan membuat resource kustom PodSnapshotManualTrigger. Jenis pemicu ini dapat dieksekusi sebanyak yang diperlukan. Pendekatan ini paling cocok untuk situasi saat Anda tidak dapat mengubah aplikasi untuk memberi sinyal kesiapan.

Pencocokan dan kompatibilitas snapshot

Untuk membantu memastikan bahwa snapshot kompatibel dengan workload yang dipulihkan, GKE melakukan pencocokan kompatibilitas antara Pod asli yang di-checkpoint dan Pod target.

GKE menggunakan aturan berikut untuk menentukan kompatibilitas:

  • Urutan pemilihan: secara default, GKE memulihkan workload dari resource kustom PodSnapshot terbaru yang cocok dengan namespace dan konfigurasi Pod.
  • Kriteria kecocokan: pemeriksaan kompatibilitas bergantung pada cakupan snapshot yang dikonfigurasi di resource kustom PodSnapshotPolicy (whole-pod atau rootfs-only).

whole-pod pencocokan cakupan (default)

Untuk kebijakan dengan cakupan whole-pod default, GKE akan memeriksa hal berikut:

  • Distilled spec hash: GKE menghasilkan hash unik berdasarkan kolom runtime penting dalam spesifikasi Pod. Agar pemulihan berhasil, Pod target harus menghasilkan hash yang identik dari spesifikasi yang disaring. Pemeriksaan ini memverifikasi bahwa Pod yang di-checkpoint dan dipulihkan memiliki konfigurasi runtime yang identik.

    Kolom berikut dari objek Pod adalah bagian dari spesifikasi yang diringkas dan memengaruhi hash unik:

    • metadata:
      • annotations: hanya anotasi yang relevan dengan GKE Sandbox (seperti anotasi yang dimulai dengan awalan dev.gvisor.*).
      • labels: batch.kubernetes.io/job-completion-index
    • spec:
      • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
      • containers:
        • name
        • image
        • command
        • args
        • workingDir
        • ports: name, containerPort, protocol
        • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
        • volumeDevices: name
        • lifecycle: postStart, preStop
        • terminationMessagePath
        • terminationMessagePolicy
        • securityContext (dan semua subkolom)
        • stdin
        • stdinOnce
        • tty
      • initContainers: subkolom yang sama dengan containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • Kompatibilitas hardware: Pod target harus berjalan di node dengan seri mesin, vendor CPU, dan set fitur CPU (flag CPUID) yang sama dengan Pod yang di-checkpoint. Misalnya, kedua node harus menggunakan seri N2 atau G2 yang sama dan fitur prosesor Intel atau AMD yang sama. GKE Sandbox memverifikasi fitur CPU sebelum memulihkan memori proses dan status CPU, sehingga snapshot dengan cakupan whole-pod tidak dapat dipulihkan ke node dengan fitur CPU yang berbeda.

  • Kompatibilitas versi: versi kernel GKE Sandbox dan versi driver GPU harus cocok dengan versi yang diambil dalam snapshot asli.

Pencocokan cakupan rootfs-only

Saat Anda mengonfigurasi kebijakan dengan cakupan rootfs-only (tersedia di GKE versi 1.35.3-gke.1031000 dan yang lebih baru), persyaratan pencocokan menjadi kurang ketat:

  • GKE tidak menghitung atau membandingkan hash spesifikasi Pod yang disaring. Pencocokan yang fleksibel ini memungkinkan Anda memulihkan snapshot ke Pod target dengan resource, lingkungan, atau kolom konfigurasi lain yang berbeda. Namun, versi image container dan node yang mendasarinya harus kompatibel.
  • Karena memori proses tidak dipulihkan, Anda dapat memulihkan snapshot yang diambil di satu kelompok mesin ke kelompok mesin yang berbeda (termasuk jenis mesin E2).

Pencocokan aturan pengelompokan

Jika kebijakan menggunakan kolom snapshotGroupingRules untuk mengelompokkan snapshot berdasarkan nilai label tertentu (seperti tenant atau lingkungan), Pod yang dipulihkan harus memiliki kunci dan nilai label yang cocok. Pengontrol snapshot Pod memilih snapshot hanya dari grup yang cocok. Untuk mengetahui informasi selengkapnya tentang cara menyiapkan label pengelompokan, lihat Mengonfigurasi setelan kebijakan snapshot Pod tambahan.

Memulihkan kesiapan dan pemuatan latar belakang

Saat Pod dipulihkan dari snapshot, kernel GKE Sandbox akan dipulihkan terlebih dahulu, yang biasanya memerlukan waktu beberapa detik. Untuk meminimalkan latensi startup, aplikasi akan segera dilanjutkan setelah kernel dipulihkan. Hal ini tidak menunggu memori aplikasi dimuat sepenuhnya. Memori aplikasi dipulihkan menggunakan mekanisme streaming latar belakang.

Jika aplikasi mencoba membaca bagian memori yang belum dimuat, maka akan terjadi kesalahan halaman. GKE Sandbox menangkap kesalahan ini, menjeda thread aplikasi, dan segera mengambil halaman memori yang diperlukan dari penyimpanan. Pengambilan on-demand ini diprioritaskan daripada streaming latar belakang.

Karena pemuatan latar belakang ini, akses memori mungkin mengalami latensi singkat selama beberapa detik pertama setelah pemulihan jika aplikasi meminta memori yang tidak di-streaming. Latensi ini akan hilang saat status memori disinkronkan sepenuhnya.

Perilaku pemuatan latar belakang ini juga berlaku untuk status GPU. Misalnya, Pod model bahasa besar (LLM) mungkin tampak dalam status Running dan merespons pemeriksaan jaringan meskipun memori GPU-nya masih diisi. Model tidak akan sepenuhnya responsif untuk inferensi hingga status GPU dipulihkan sepenuhnya. Karena penundaan ini, saat mengukur kecepatan pemulihan, pastikan Anda mengukur saat server model siap menyajikan permintaan. Anda dapat memverifikasi kesiapan server model menggunakan metrik seperti waktu hingga token pertama (TTFT) atau pemeriksaan kesiapan Pod.

Status GPU

Snapshot Pod mendukung pengambilan status GPU. Saat Anda memicu snapshot untuk Pod yang menggunakan GPU, alat NVIDIA cuda-checkpoint akan menyimpan status GPU ke dalam memori proses. Langkah ini membantu memastikan bahwa data yang disimpan di GPU, seperti bobot model, disertakan dalam snapshot. GKE menjeda Pod dan mengambil snapshot. Selama pemulihan, GKE membalikkan operasi ini.

Karena status GPU ditulis ke dalam memori proses, penggunaan memori Pod meningkat selama operasi snapshot dan pemulihan. Perhitungkan persyaratan memori tambahan ini saat Anda menetapkan batas memori untuk Pod.

Pertimbangan untuk Pod yang dipulihkan

Dari perspektif Kubernetes API, objek Pod baru dibuat. Saat Pod dimulai, jika ada snapshot yang sesuai untuk Pod, GKE akan memulihkan Pod dari snapshot tersebut, termasuk status memori dan proses aslinya. Namun, beberapa aspek status Pod harus berubah agar dapat berfungsi sebagai instance baru yang unik.

Pertimbangkan perubahan status berikut setelah pemulihan:

  • Antarmuka jaringan: Pod yang dipulihkan akan menerima alamat IP baru. Semua antarmuka dan rute dikonfigurasi ulang. Koneksi jaringan aktif yang ada pada saat snapshot akan ditutup saat pemulihan. Soket pemroses, koneksi loopback, dan koneksi soket domain Unix terus berfungsi.
  • Nama host: Pod yang dipulihkan mengasumsikan identitas baru dan menerima nama host baru.
  • Waktu aktual: waktu aktual melompat ke waktu saat ini.
  • Status aplikasi: status aplikasi harus unik untuk setiap Pod, seperti ID eksperimen atau seed angka acak, dan harus diinisialisasi ulang setelah pemulihan.
  • Secret: kunci enkripsi dan sertifikat yang dibuat sebelum Anda mengambil snapshot harus dibuat ulang.
  • Variabel lingkungan: Anda dapat mengubah variabel lingkungan antara snapshot dan pemulihan. Namun, karena variabel lingkungan disimpan dalam memori aplikasi, GKE Sandbox tidak dapat menemukan dan menggantinya dengan andal. Jika workload Anda mengandalkan variabel lingkungan baru setelah pemulihan, Pod harus memuat ulang variabel tersebut secara manual. Variabel lingkungan baru tersedia dalam file /proc/gvisor/spec_environ. Format filenya sama dengan /proc/<pid>/environ.

Multi-tenancy dan identitas

Snapshot Pod memerlukan binding Identity and Access Management (IAM) manual untuk setiap objek ServiceAccount Kubernetes Pod agar dapat menggunakan Cloud Storage. Binding IAM manual dapat memerlukan waktu untuk diterapkan, yang mungkin menjadi masalah jika Anda perlu mengambil snapshot segera setelah membuat Pod.

Untuk mengatasi penundaan dan menyederhanakan pengelolaan multi-tenant, alih-alih mengikat IAM ke objek ServiceAccount secara manual, Anda dapat menggunakan akun layanan node GKE untuk membuat token berumur singkat sesuai permintaan. Untuk mengonfigurasi snapshot Pod dengan pendekatan ini, gunakan kolom tokenSource di resource kustom PodSnapshotStorageConfig dengan salah satu nilai berikut:

  • podKSA (default): menggunakan binding IAM manual antara objek ServiceAccount Pod dan bucket Cloud Storage.
  • federatedP4SA: menggunakan token khusus jalur yang dibuat oleh akun layanan node.

Persyaratan

Untuk menggunakan snapshot Pod GKE, pastikan Anda memenuhi persyaratan berikut:

  • Pod harus berjalan di GKE Sandbox karena snapshot Pod bergantung pada lingkungan terisolasi yang disediakan GKE Sandbox.
  • Untuk cakupan snapshot whole-pod default, node tempat Pod dipulihkan harus memiliki seri mesin, vendor CPU, dan fitur CPU yang sama dengan node tempat snapshot diambil. Workload khusus CPU dapat menggunakan seri mesin non-E2 apa pun yang didukung oleh GKE Sandbox yang memenuhi persyaratan kompatibilitas hardware ini. Untuk mengetahui informasi selengkapnya, lihat Batasan.
  • Untuk menggunakan GPU dengan snapshot Pod, Anda juga harus memenuhi persyaratan berikut:
    • Pod GPU tunggal didukung di node GPU tunggal dan multi-GPU.
    • Pod Multi-GPU hanya didukung di GPU L4 (jenis mesin g2-standard-*).
    • Di GKE versi 1.35.0-gke.1738000 dan yang lebih lama, Pod yang berjalan di node multi-GPU harus menggunakan semua GPU yang tersedia di node tersebut. Pada versi 1.35.0-gke.1738000 dan yang lebih baru, Pod dapat menggunakan subset GPU pada node.
    • Untuk workload GPU, Anda harus menggunakan salah satu jenis mesin GPU yang didukung berikut:
      • g2-standard-4 (1 x L4)
      • g2-standard-8 (1 x L4)
      • g2-standard-12 (1 x L4)
      • g2-standard-16 (1 x L4)
      • g2-standard-32 (1 x L4)
      • g2-standard-48 (4 x L4)
      • g2-standard-96 (8 x L4)
      • a2-highgpu-1g (1 x A100-40GB)
      • a2-ultragpu-1g (1 x A100-80GB)
      • a3-highgpu-1g (1 x H100-80GB)

Batasan

Snapshot Pod GKE memiliki batasan berikut:

  • Saat Anda menggunakan cakupan snapshot whole-pod default, snapshot tidak dapat dipulihkan ke VM Compute Engine dengan fitur CPU (flag CPUID) yang berbeda dari VM tempat snapshot diambil:
    • Snapshot Pod dengan cakupan whole-pod tidak mendukung seri mesin E2, atau seri mesin lain yang secara dinamis menggabungkan prosesor Intel dan AMD atau generasi CPU. Snapshot sistem file (cakupan rootfs-only) mendukung seri mesin E2.
    • Bahkan dalam seri mesin non-E2 dan vendor CPU yang sama, Compute Engine mungkin menyediakan VM dengan platform CPU atau set fitur CPU per VM yang berbeda. Jika Pod dijadwalkan ke node dengan fitur CPU yang tidak cocok, pemulihan snapshot dengan cakupan whole-pod akan gagal.
  • Berbagi GPU dengan Multi-Instance GPU (MIG) tidak didukung.
  • Container sidecar driver CSI Cloud Storage FUSE tidak didukung dengan snapshot Pod.
  • Snapshot pod tidak mendukung TPU.

Langkah berikutnya