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.

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

Kapan menggunakan snapshot Pod

Gunakan snapshot Pod untuk beban kerja yang memiliki waktu inisialisasi yang lama, misalnya 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 titik waktu tertentu. Saat replika baru dibuat, bukan menginisialisasi Pod dari status baru, Pod 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.

Isi 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. Terutama, volume persisten tidak di-checkpoint.
Jaringan Koneksi loopback, soket pendengar, dan soket Domain Unix. Koneksi eksternal tidak dipulihkan (koneksi ini 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 diambil snapshotnya berdasarkan pemilih label Kubernetes. Resource ini berisi sebagian besar opsi konfigurasi untuk fitur tersebut, termasuk cara pemicuan snapshot dan kebijakan retensi.
  • PodSnapshotManualTrigger: (opsional) jika tidak menggunakan pemicu workload, menentukan pemicu manual untuk membuat snapshot bagi Pod tertentu.

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 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 cocok untuk situasi saat Anda tidak dapat mengubah aplikasi untuk memberi sinyal kesiapan.

Pencocokan snapshot

Pencocokan Pod menentukan apakah snapshot Pod kompatibel dengan Pod tertentu. Kecocokan ini dicapai dengan membuat hash unik dari spesifikasi runtime penting Pod, yang juga disebut spesifikasi Pod yang disederhanakan. Hash ini kemudian disematkan dalam snapshot Pod. Agar Pod yang lebih baru 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.

Distilasi menyederhanakan spesifikasi Pod dengan hanya mempertahankan kolom runtime penting, seperti image, sambil menghapus kolom yang tidak penting seperti nodeName atau nodeSelector. Anda harus memastikan bahwa nilai kolom penting ini konsisten antara Pod yang digunakan untuk pembuatan titik pemeriksaan dan Pod yang ditujukan 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:

  • Hardware: Pod baru harus berjalan di node yang memiliki seri dan arsitektur mesin yang identik dengan Pod asli. Seri dan arsitektur mesin harus sama. Jumlah CPU dan jumlah memori dapat berubah. Jenis mesin E2 tidak didukung karena arsitektur dasarnya yang dinamis.
  • Pembuatan 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.

Memulihkan kesiapan dan pemuatan di latar belakang

Saat Pod dipulihkan dari snapshot, kernel gVisor 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 dengan 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 di 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 mencatat saat server model telah dimulai. Anda dapat memeriksa kapan server model dimulai dengan 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 menyimpan status GPU ke dalam memori proses. Artinya, semua data yang disimpan di GPU, misalnya bobot model, disertakan dalam snapshot. Pod kemudian dijeda dan diambil snapshot-nya. Selama pemulihan, prosesnya dibalik.

Karena status GPU ditulis ke dalam memori proses, penggunaan memori Pod 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 asli dan status proses. 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 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 secara andal. Jika workload Anda mengandalkan variabel lingkungan baru setelah pemulihan, 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 IAM manual untuk setiap ServiceAccount Kubernetes (KSA) Pod guna mengakses Cloud Storage. Binding IAM manual memerlukan waktu untuk disebarkan, yang mungkin menjadi masalah jika Anda perlu mengambil snapshot segera setelah membuat Pod.

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

  • podKSA (default): Pengikatan IAM manual KSA Pod ke bucket Cloud Storage.
  • federatedP4SA: Gunakan 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 oleh 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.
    • 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.
    • 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