Perintah dan konteks
Kubernetes v1.36 mempromosikan VolumeGroupSnapshot, VolumeGroupSnapshotContent, dan VolumeGroupSnapshotClass ke groupsnapshot.storage.k8s.io/v1. Pewawancara ingin mengetahui bagaimana beberapa PersistentVolumeClaim membentuk satu titik pemulihan, apa yang dikelola oleh driver CSI, dan bagaimana Anda menangani kesenjangan antara konsistensi tingkat penyimpanan dan tingkat aplikasi.
Apa yang dievaluasi pewawancara
- Apakah Anda membedakan crash consistency, application consistency, dan eventual consistency.
- Apakah Anda dapat menjelaskan batasan antara pengontrol Kubernetes, external snapshot controller, dan driver CSI.
- Apakah Anda mengidentifikasi prasyarat seperti dukungan CSI, kapasitas, topologi, dan batasan siklus hidup snapshot.
- Apakah Anda mengubah target pemulihan, metrik simulasi, dan rollback kegagalan menjadi proses yang dapat dieksekusi.
Pertanyaan untuk diklarifikasi terlebih dahulu
Konfirmasikan apakah database mendukung pencadangan online, apakah setiap volume menggunakan driver CSI yang sama, serta RPO, RTO, dan perilaku lintas-zona yang diperlukan. Konfirmasikan juga apakah sistem penyimpanan mempertahankan urutan penulisan atau apakah aplikasi harus melakukan flush, freeze, atau menjeda penulisan terlebih dahulu.
Jawaban 30 detik
Saya akan menggunakan empat lapisan: aplikasi membuat titik konsistensi; Kubernetes mencatat kumpulan PVC dengan VolumeGroupSnapshot; driver CSI membuat snapshot grup di penyimpanan; dan pemulihan memulihkan volume baru serta memvalidasinya. API ini sudah GA di v1.36, tetapi fungsinya mengoordinasikan snapshot volume yang crash-consistent; ini tidak menggantikan log database, pengelolaan kunci, atau simulasi pemulihan berkala.
Pembahasan mendalam langkah demi langkah
1. Menetapkan titik konsistensi
Database melakukan tindakan pencadangan yang dapat dibuktikan, seperti membekukan penulisan sementara waktu, melakukan flush WAL, atau membuat checkpoint. Catat posisi transaksi, waktu snapshot, dan versi aplikasi sebelum membuat snapshot grup. Snapshot khusus penyimpanan tanpa koordinasi aplikasi dapat konsisten di tingkat disk sementara status bisnisnya tidak konsisten.
2. Membuat dan memantau snapshot grup
Buat VolumeGroupSnapshot untuk PVC dari satu instans database dan tunggu statusnya siap (ready). Pengontrol mengoordinasikan objek Kubernetes; driver CSI melakukan operasi penyimpanan dan harus mendukung API ekstensi volume-group snapshot. Catat handle snapshot, kapasitas, topologi, dan kesalahan dari setiap anggota agar keberhasilan parsial tidak disalahartikan sebagai kemampuan pemulihan.
3. Memulihkan dan memvalidasi
Buat PVC baru untuk setiap anggota sambil mempertahankan pemetaan database-ke-volume. Jalankan database di lingkungan yang terisolasi, validasi posisi WAL, jumlah tabel, checksum, dan kueri bisnis utama, lalu alihkan lalu lintas data. Pemulihan lintas-zona juga harus memverifikasi bahwa replika snapshot dapat dibaca dan driver CSI menerima topologi target.
4. Batasan operasional
Tentukan retensi, enkripsi, dan kontrol akses; pantau durasi snapshot dan tingkat kegagalan. Perlakukan snapshot sebagai materi pemulihan, bukan arsip permanen: ekspor ke media independen dan ukur RPO serta RTO aktual melalui simulasi. Sebelum menghapus PVC, objek snapshot, atau objek backend, konfirmasikan bahwa reclaim policy tidak akan menghapus titik pemulihan yang masih digunakan.
Contoh jawaban yang kuat
Saya akan menentukan target pemulihan terlebih dahulu dan memilih PVC yang dikelola oleh satu driver CSI. Aplikasi membuat checkpoint dan mencatat posisi WAL-nya, menjeda penulisan secara singkat jika diperlukan; kemudian kita membuat groupsnapshot.storage.k8s.io/v1 VolumeGroupSnapshot. Pengontrol mengoordinasikan objek Kubernetes, sementara driver CSI dan sistem penyimpanan menyediakan semantik grup. Saya akan memverifikasi versi driver, topologi, kapasitas, dan kuota snapshot, serta mengatur peringatan pada status ready setiap anggota.
Pemulihan tidak pernah menimpa volume produksi. Pemulihan membuat PVC baru dari snapshot grup, menjalankan database di namespace terisolasi, memvalidasi WAL, checksum, dan kueri bisnis, dan baru setelah itu mengalihkan lalu lintas data. Jika ada anggota yang gagal, grup tersebut tidak dapat digunakan dan alur kerja di-rollback; snapshot parsial tidak dianggap sebagai pencadangan lengkap. Simulasi terjadwal membuktikan RPO dan RTO, sementara pengarsipan independen, enkripsi, dan hak akses terendah (least privilege) mencegah sistem snapshot menjadi titik kegagalan tunggal (single point of failure) atau kebocoran data.
Kesalahan umum
- Mengasumsikan GA berarti setiap driver penyimpanan mendukung fitur tersebut secara otomatis; ini tetap bergantung pada implementasi CSI dan penyimpanan.
- Hanya menjelaskan proses pembuatan, tanpa penanganan kegagalan tingkat anggota, topologi, dan siklus hidup.
- Menyebut crash consistency sebagai application consistency dan mengabaikan proses flush, WAL, atau checkpoint.
- Hanya menyimpan metadata snapshot dan tidak pernah menjalankan database yang dipulihkan di lingkungan terisolasi.
Pertanyaan lanjutan dan jawabannya
Bagaimana jika snapshot pada salah satu volume anggota gagal?
Tandai snapshot grup sebagai tidak dapat digunakan, pertahankan event dan handle yang telah dibuat, bersihkan sumber daya yang tidak terikat (orphaned resources), lalu coba lagi. Pemulihan hanya menerima set anggota yang lengkap, sedangkan keberhasilan parsial dilaporkan untuk peringatan dan audit kapasitas.
Mengapa tidak mengambil snapshot setiap PVC secara terpisah?
Snapshot individual tidak memiliki titik pemulihan bersama, sehingga urutan penulisan lintas-volume dapat menyimpang. Snapshot grup mendelegasikan kumpulan anggota dan operasi grup ke penyimpanan, sementara checkpoint aplikasi tetap diperlukan untuk konsistensi bisnis.
Bagaimana Anda membuktikan bahwa rencana tersebut memenuhi RPO dan RTO?
Lakukan pemulihan di kluster terisolasi dengan jadwal tetap, catat waktu dari checkpoint hingga layanan dapat dikueri, deviasi posisi data, dan tingkat kegagalan. Hasil simulasi menjadi kriteria rilis (release gates); jika ambang batas terlewat, sesuaikan frekuensi snapshot, jalur arsip, atau prosedur cutover.