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.

Dokumen ini memberikan ringkasan konseptual tentang snapshot Pod GKE. Untuk mempelajari cara mengaktifkan dan menggunakan fitur ini, lihat Memulihkan dari snapshot Pod.

Kapan harus menggunakan snapshot Pod

Gunakan snapshot Pod untuk workload yang memiliki waktu inisialisasi yang lama, misalnya 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 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 replika baru dibuat, bukan menginisialisasi Pod dari status baru, Pod akan dipulihkan dari snapshot, melanjutkan eksekusi dari titik saat snapshot diambil.

Untuk menggunakan snapshot Pod, Anda membuat definisi resource kustom (CRD) Kubernetes untuk mengonfigurasi perilaku snapshot secara deklaratif. 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.

Konten snapshot

Tabel berikut menjelaskan apa yang disertakan dan tidak disertakan dalam snapshot Pod:

Kategori Disertakan dalam snapshot Tidak disertakan dalam snapshot
Status aplikasi Seluruh status aplikasi: semua deskriptor file terbuka, thread, register CPU, dan memori.
Sistem file Sistem file root container (rootfs), volume EmptyDir, dan pemasangan tmpfs. Apa pun yang tidak tercakup dalam kolom sebelumnya. Yang paling penting, volume persisten tidak di-checkpoint.
Jaringan Koneksi loopback, soket yang mendengarkan, dan soket Domain Unix. Koneksi eksternal tidak dipulihkan (koneksi akan dihentikan saat pemulihan). Aturan yang ditambahkan pengguna seperti iptables atau nftables, dan rute tidak dipulihkan.

Definisi resource kustom

Snapshot Pod dikonfigurasi secara deklaratif dengan CRD berikut:

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

Pemicu snapshot

Anda dapat memicu snapshot Pod dengan cara berikut:

  • Pemicu workload: aplikasi di dalam Pod memberi sinyal kepada agen GKE bahwa aplikasi siap untuk snapshot. Jenis pemicu ini dieksekusi satu kali dalam siklus workload, misalnya pada status siap workload. 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 baik untuk situasi saat Anda tidak dapat mengubah aplikasi untuk memberi sinyal kesiapan.

Pencocokan snapshot

Pencocokan Pod menentukan apakah snapshot Pod kompatibel dengan Pod tertentu. Pencocokan ini dicapai dengan membuat hash unik dari spesifikasi runtime penting Pod, yang juga disebut spesifikasi Pod yang disaring. Hash ini kemudian disematkan dalam snapshot Pod. Agar Pod berikutnya dapat dipulihkan dari snapshot Pod ini, Pod tersebut harus membuat hash yang identik dari spesifikasi Pod yang disaringnya sendiri. Proses ini membantu memastikan bahwa Pod yang di-checkpoint dan dipulihkan identik dalam konfigurasi runtime-nya.

Penyaringan menyederhanakan spesifikasi Pod dengan hanya mempertahankan kolom runtime penting, seperti image, sekaligus menghapus kolom yang tidak penting seperti nodeName atau nodeSelector. Anda harus memastikan bahwa nilai kolom penting ini konsisten antara Pod yang digunakan untuk checkpointing dan Pod yang dimaksudkan untuk pemulihan.

Kolom berikut dari objek Pod memengaruhi hash unik:

  • metadata:
    • annotations: hanya anotasi yang relevan dengan runtime gVisor, 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

Kriteria tambahan berikut harus cocok agar dianggap sebagai snapshot yang kompatibel:

  • Perangkat Keras: Pod baru harus berjalan di node yang memiliki seri mesin dan arsitektur yang identik dengan Pod asli. Seri mesin dan arsitektur harus sama. Jumlah CPU dan jumlah memori dapat berubah. Jenis mesin E2 tidak didukung karena arsitektur dasarnya yang dinamis.
  • Versi: versi kernel gVisor dan versi driver GPU harus cocok.

GKE mengelola kompatibilitas snapshot. Jika GKE menemukan snapshot yang kompatibel, GKE akan memulihkan Pod baru dari snapshot tersebut. Jika tidak ada snapshot yang kompatibel, Pod akan dimulai secara normal.

Kesiapan pemulihan dan pemuatan latar belakang

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

Jika aplikasi mencoba mengakses bagian memori yang belum dimuat, terjadi kesalahan halaman. gVisor 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 latar belakang ini, akses memori mungkin memiliki sedikit latensi selama beberapa detik pertama setelah pemulihan jika aplikasi memerlukan memori yang belum 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. Oleh karena itu, saat mengukur kecepatan pemulihan, pastikan Anda mengambil data saat server model telah dimulai. Anda dapat memeriksa kapan server model dimulai menggunakan metrik seperti Time-to-First-Token (TTFT) atau pemeriksaan kesiapan Pod.

Status GPU

Snapshot Pod mendukung pengambilan status GPU. Saat Anda memicu snapshot untuk Pod yang menggunakan GPU, alat cuda-checkpoint NVIDIA akan menyimpan status GPU ke dalam memori proses. Artinya, data apa pun yang disimpan di GPU, misalnya bobot model, disertakan dalam snapshot. Pod kemudian dijeda dan di-snapshot. Selama pemulihan, prosesnya dibalik.

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

Pertimbangan untuk Pod yang dipulihkan

Dari perspektif Kubernetes API, Pod baru akan dibuat. Saat Pod dimulai, jika ada snapshot yang sesuai untuk Pod, Pod akan dipulihkan 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 pemulihan. Soket yang mendengarkan, koneksi loopback, dan koneksi soket Domain Unix akan terus berfungsi.
  • Nama host: Pod yang dipulihkan mengasumsikan identitas baru dan menerima nama host baru.
  • Waktu jam dinding: waktu jam dinding akan 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 snapshot diambil 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 memperbaruinya secara manual. Variabel lingkungan baru tersedia dalam file /proc/gvisor/spec_environ. Format file sama dengan /proc/<pid>/environ.

Multi-tenancy dan identitas

Snapshot Pod memerlukan binding IAM manual untuk Kubernetes ServiceAccount (KSA) setiap Pod guna mengakses Cloud Storage. Binding IAM manual memerlukan waktu untuk diterapkan, yang mungkin menjadi masalah jika Anda perlu mengambil snapshot segera setelah membuat Pod.

Untuk membantu mengatasi penundaan dan menyederhanakan pengelolaan multi-tenancy, Anda dapat menggunakan akun layanan node GKE untuk membuat token berdurasi singkat sesuai permintaan, bukan mengikat IAM ke KSA secara manual. Untuk mengonfigurasi snapshot Pod dengan pendekatan ini, gunakan kolom tokenSource dalam objek PodSnapshotStorageConfig dengan salah satu nilai berikut:

  • podKSA (default): Binding IAM manual KSA Pod ke bucket Cloud Storage.
  • federatedP4SA: Menggunakan token khusus jalur yang dibuat oleh akun layanan node.

Batasan dan persyaratan

Snapshot Pod GKE memiliki batasan berikut:

  • Pod harus berjalan di GKE Sandbox karena snapshot Pod bergantung pada runtime container gVisor yang disediakan GKE Sandbox.
  • Snapshot Pod tidak mendukung jenis mesin E2.
  • Dukungan GPU untuk snapshot Pod memiliki persyaratan dan batasan berikut:
    • Pod GPU tunggal didukung di node GPU tunggal dan multi-GPU.
    • Pod multi-GPU hanya didukung di GPU L4 (jenis mesin g2-standard-*).
    • Berbagi GPU dengan Multi-Instance GPU (MIG) tidak didukung.
    • 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. Di versi 1.35.0-gke.1738000 dan yang lebih baru, Pod dapat menggunakan subset GPU di node.
    • Snapshot Pod mendukung jenis mesin 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)
  • Penggunaan container sidecar driver CSI Cloud Storage FUSE dengan snapshot Pod tidak didukung.
  • Snapshot Pod tidak mendukung jenis mesin TPU.

Langkah berikutnya