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 dipulihkan dari snapshot, sehingga beban kerja 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 pembuatan checkpoint dan pemulihan. Untuk informasi selengkapnya tentang peran umum dan contoh tugas yang dirujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

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

  1. Mempersiapkan snapshot Pod
  2. Memicu snapshot Pod
  3. Memulihkan beban kerja dari snapshot Pod

Kapan snapshot Pod digunakan

Gunakan snapshot Pod untuk workload yang memiliki waktu inisialisasi yang lama. Contohnya mencakup beban kerja 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 mulai yang 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, alih-alih menginisialisasi Pod dari status baru, GKE memulihkan Pod dari snapshot. Pemulihan ini berarti Pod melanjutkan eksekusi dari titik saat snapshot diambil.

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 digunakan dan menyelesaikan masalah. Cloud Storage menyimpan snapshot Pod Anda.

Isi snapshot

Tabel berikut mencantumkan apa saja yang disertakan dan tidak disertakan dalam snapshot Pod:

Kategori Disertakan Dikecualikan
Status aplikasi
  • Memori proses
  • Thread eksekusi
  • Register CPU
  • Membuka deskriptor file
 Tidak ada (semua status proses dalam memori diambil)
Sistem file
  • Sistem file root container (rootfs)
  • emptyDir volume
  • Dudukan tmpfs
  • Objek PersistentVolumeClaim
  • Volume atau jenis penyimpanan lain yang tidak tercantum sebagai disertakan
Jaringan
  • Koneksi loopback
  • Soket pendengar
  • 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 diambil snapshotnya berdasarkan pemilih label Kubernetes. Resource kustom ini berisi sebagian besar opsi konfigurasi untuk fitur, termasuk cara pemicuan snapshot, cakupan snapshot, dan kebijakan retensi.
  • PodSnapshotManualTrigger (opsional): jika Anda tidak menggunakan pemicu workload, tentukan pemicu manual untuk membuat snapshot bagi 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 ke agen GKE bahwa aplikasi siap untuk snapshot. Jenis pemicu ini dieksekusi satu kali dalam siklus workload, misalnya pada status workload siap. Pendekatan ini paling baik 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 menandakan kesiapan.

Pencocokan dan kompatibilitas snapshot

Untuk membantu memastikan bahwa snapshot kompatibel dengan workload yang dipulihkan, GKE melakukan pencocokan kompatibilitas antara Pod yang di-checkpoint asli 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 Anda (whole-pod atau rootfs-only).

Pencocokan cakupan whole-pod (default)

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

  • Hash spesifikasi yang disederhanakan: GKE membuat hash unik berdasarkan pada 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 identik dalam konfigurasi runtime-nya.

    Kolom berikut dari objek Pod adalah bagian dari spesifikasi yang disederhanakan 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 sub-kolom)
        • stdin
        • stdinOnce
        • tty
      • initContainers: sub-kolom 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 dan arsitektur CPU yang identik dengan Pod yang di-checkpoint asli (misalnya, N2 ke N2, atau G2 ke G2).

  • 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 tidak terlalu ketat:

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

Pencocokan aturan pengelompokan

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

Memulihkan kesiapan dan pemuatan di 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 dilanjutkan segera setelah kernel dipulihkan. 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 mencegat kesalahan ini, menjeda thread aplikasi, dan segera mengambil halaman memori yang diperlukan dari penyimpanan. Pengambilan sesuai permintaan ini diprioritaskan daripada streaming latar belakang.

Karena pemuatan di 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 melayani 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 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, maka GKE akan memulihkan Pod dari snapshot tersebut, termasuk memori dan status proses asli. 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 menerima alamat IP baru. Semua antarmuka dan rute dikonfigurasi ulang. Koneksi jaringan aktif yang ada pada saat snapshot diambil akan ditutup saat dipulihkan. Soket pendengar, koneksi loopback, dan koneksi soket domain Unix akan terus berfungsi.
  • Nama host: Pod yang dipulihkan mengasumsikan identitas baru dan menerima nama host baru.
  • Waktu aktual: waktu aktual akan dipercepat 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 beban kerja Anda mengandalkan variabel lingkungan baru setelah pemulihan, maka Pod harus memperbaruinya secara manual. Variabel lingkungan baru tersedia di 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 Kubernetes ServiceAccount Pod agar dapat menggunakan Cloud Storage. Binding IAM manual 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 yang berlaku 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 menggunakan GPU dengan snapshot Pod, Anda 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-*).
    • Pada 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 di node.
    • Anda harus menggunakan salah satu jenis mesin 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:

  • Snapshot pod tidak mendukung jenis mesin E2 saat menggunakan cakupan snapshot whole-pod default. Snapshot sistem file (rootfs-only) mendukung jenis mesin E2.
  • 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