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

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 tersebut, termasuk cara pemicuan snapshot 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 beban kerja: 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 sesering 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 sama.

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 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 jaringan dikonfigurasi ulang. Koneksi jaringan aktif yang ada pada saat snapshot ditutup saat dipulihkan. Socket pendengar terus berfungsi.
  • Nama host: Pod yang dipulihkan mengasumsikan identitas baru dan menerima nama host baru.
  • Status aplikasi: status aplikasi yang harus unik untuk setiap Pod, seperti ID eksperimen atau seed angka acak, 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.

Status yang berubah setelah pemulihan

Tidak semua status dipertahankan saat dipulihkan. Bagian berikut dari status Pod berubah sehingga Pod dapat mengasumsikan identitas baru:

  • 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 terus berfungsi.
  • Nama host: Pod yang dipulihkan mengasumsikan identitas baru dan menerima nama host baru.
  • Waktu aktual: Waktu aktual melompat ke waktu saat ini.

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.
  • Snapshot Pod berfungsi dengan Pod GPU tunggal. Hanya konfigurasi multi-GPU berikut yang didukung:
    • 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 GPU sebagian tidak didukung. Jika node memiliki beberapa GPU, Pod harus menggunakan semuanya. Misalnya, Anda tidak dapat menggunakan snapshot Pod dengan empat Pod yang masing-masing menggunakan satu GPU di mesin empat GPU.
  • Penggunaan container sidecar driver CSI Cloud Storage FUSE dengan snapshot Pod tidak didukung.

Langkah berikutnya