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 mengaktifkan dan menggunakan fitur ini, lihat dokumen berikut:

  1. Mempersiapkan snapshot Pod
  2. Memicu snapshot Pod
  3. Memulihkan workload dari snapshot Pod

Kapan 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 titik 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.

CustomResourceDefinitions

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, cakupan snapshot, dan kebijakan retensi.
  • PodSnapshotManualTrigger: (opsional) jika Anda 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 dan kompatibilitas snapshot

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

Kompatibilitas ditentukan oleh aturan berikut:

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

Pencocokan cakupan whole-pod (default)

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

  1. Hash spesifikasi yang disaring: GKE membuat hash unik berdasarkan kolom runtime penting dalam spesifikasi Pod. Agar pemulihan berhasil, Pod target harus membuat hash yang identik dari spesifikasi yang disaring. Pemeriksaan ini memastikan bahwa Pod yang di-checkpoint dan dipulihkan identik dalam konfigurasi runtime-nya.

    Kolom berikut dari objek Pod adalah bagian dari spesifikasi yang disaring dan 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

  2. Kompatibilitas hardware: Pod target harus berjalan di node dengan seri mesin dan arsitektur CPU yang identik dengan Pod checkpointed asli (misalnya, N2 ke N2, atau G2 ke G2).

  3. Kompatibilitas versi: versi kernel gVisor 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 disaring. Pencocokan yang lebih fleksibel ini memungkinkan Anda memulihkan snapshot ke Pod target yang memiliki resource, lingkungan, atau kolom konfigurasi lain yang berbeda dari Pod checkpointed asli, asalkan image container dan versi node yang mendasarinya kompatibel.
  • Karena memori proses tidak dipulihkan, Anda dapat memulihkan snapshot yang diambil pada satu grup mesin ke grup mesin lain (termasuk jenis mesin E2).

Pencocokan aturan pengelompokan

Jika kebijakan menggunakan kolom snapshotGroupingRules untuk mengelompokkan snapshot berdasarkan nilai label tertentu (misalnya, berdasarkan penyewa atau lingkungan), Pod yang dipulihkan harus memiliki kunci dan nilai label yang sama persis. 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.

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. Karena penundaan ini, saat mengukur kecepatan pemulihan, pastikan Anda mengambil waktu 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 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 diubah agar 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 bergantung pada 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 berumur pendek 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 saat menggunakan cakupan snapshot whole-pod default. Snapshot sistem file (rootfs-only) 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)
  • Container sidecar driver CSI FUSE Cloud Storage tidak didukung dengan snapshot Pod.
  • Snapshot Pod tidak mendukung jenis mesin TPU.

Langkah berikutnya