Prompt dan konteks
Kubernetes v1.36 telah menaikkan taraf VolumeGroupSnapshot, VolumeGroupSnapshotContent dan VolumeGroupSnapshotClass kepada groupsnapshot.storage.k8s.io/v1. Penemu duga ingin mengetahui cara beberapa PersistentVolumeClaim membentuk satu titik pemulihan, peranan yang dipegang oleh pemacu CSI, dan cara anda menangani jurang antara konsistensi peringkat storan dan peringkat aplikasi.
Perkara yang dinilai oleh penemu duga
- Sama ada anda membezakan konsistensi nahas (crash consistency), konsistensi aplikasi dan konsistensi akhirnya (eventual consistency).
- Sama ada anda boleh menerangkan sempadan antara pengawal Kubernetes, external snapshot controller dan pemacu CSI.
- Sama ada anda mengenal pasti prasyarat seperti sokongan CSI, kapasiti, topologi dan had kitaran hayat snapshot.
- Sama ada anda mengubah objektif pemulihan, metrik latih tubi dan pembalikan kegagalan (failure rollback) kepada proses yang boleh dilaksanakan.
Soalan untuk dijelaskan terlebih dahulu
Sahkan sama ada pangkalan data menyokong sandaran dalam talian, sama ada setiap volum menggunakan pemacu CSI yang sama, serta keperluan RPO, RTO dan tingkah laku rentas zon. Sahkan juga sama ada sistem storan mengekalkan urutan penulisan atau sama ada aplikasi mesti melakukan flush, membekukan atau menjeda penulisan terlebih dahulu.
Jawapan 30 saat
Saya akan menggunakan empat lapisan: aplikasi mencipta titik konsistensi; Kubernetes merekodkan set PVC dengan VolumeGroupSnapshot; pemacu CSI mencipta snapshot kumpulan dalam storan; dan pemulihan memulihkan volum baharu serta mengesahkannya. API ini adalah GA dalam v1.36, tetapi ia menyelaraskan snapshot volum yang konsisten terhadap nahas; ia tidak menggantikan log pangkalan data, pengurusan kunci atau latih tubi pemulihan berkala.
Penerangan mendalam langkah demi langkah
1. Wujudkan titik konsistensi
Pangkalan data melakukan tindakan sandaran yang boleh dibuktikan, seperti membekukan penulisan seketika, melakukan flush WAL atau mencipta checkpoint. Rekodkan kedudukan transaksi, masa snapshot dan versi aplikasi sebelum mencipta snapshot kumpulan. Snapshot storan sahaja tanpa penyelarasan aplikasi boleh menjadi konsisten pada cakera sedangkan keadaan perniagaan tidak konsisten.
2. Cipta dan perhatikan snapshot kumpulan
Cipta VolumeGroupSnapshot untuk PVC bagi satu tika (instance) pangkalan data dan tunggu status sedia (ready). Pengawal menyelaraskan objek Kubernetes; pemacu CSI melakukan operasi storan dan mesti menyokong API sambungan volume-group snapshot. Rekodkan pemegang snapshot setiap ahli, kapasiti, topologi dan ralat supaya kejayaan separa tidak disalah anggap sebagai kebolehpulihan.
3. Pulihkan dan sahkan
Cipta PVC baharu untuk setiap ahli sambil mengekalkan pemetaan pangkalan data ke volum. Mulakan pangkalan data dalam persekitaran yang diasingkan, sahkan kedudukan WAL, bilangan jadual, checksum dan pertanyaan perniagaan utama, kemudian tukar trafik. Pemulihan rentas zon juga mesti mengesahkan bahawa replika snapshot boleh dibaca dan pemacu CSI menerima topologi sasaran.
4. Sempadan operasi
Tentukan pengekalan, penyulitan dan kawalan akses; pantau tempoh masa snapshot dan kadar kegagalan. Layan snapshot sebagai bahan pemulihan dan bukannya arkib kekal: eksportnya ke media bebas dan ukur RPO serta RTO sebenar melalui latih tubi. Sebelum memadamkan PVC, objek snapshot atau objek bahagian belakang, sahkan dasar tebus guna (reclaim policy) tidak akan memadamkan titik pemulihan yang masih digunakan.
Contoh jawapan yang mantap
Saya akan menentukan objektif pemulihan terlebih dahulu dan memilih PVC yang diuruskan oleh satu pemacu CSI. Aplikasi mencipta checkpoint dan merekodkan kedudukan WAL-nya, menjeda penulisan seketika apabila diperlukan; kemudian kita mencipta groupsnapshot.storage.k8s.io/v1 VolumeGroupSnapshot. Pengawal menyelaraskan objek Kubernetes, manakala pemacu CSI dan sistem storan menyediakan semantik kumpulan. Saya akan mengesahkan versi pemacu, topologi, kapasiti dan kuota snapshot, serta menetapkan amaran pada status sedia setiap ahli.
Pemulihan tidak sekali-kali menulis ganti volum pengeluaran. Ia mencipta PVC baharu daripada snapshot kumpulan, memulakan pangkalan data dalam ruang nama yang diasingkan, mengesahkan WAL, checksum dan pertanyaan perniagaan, dan hanya selepas itu menukar trafik. Jika mana-mana ahli gagal, kumpulan tersebut tidak boleh digunakan dan aliran kerja akan berundur balik (rollback); snapshot separa tidak dianggap sebagai sandaran yang lengkap. Latih tubi berjadual membuktikan RPO dan RTO, manakala pengarkiban bebas, penyulitan dan keistimewaan paling rendah menghalang sistem snapshot daripada menjadi titik kegagalan tunggal (single point of failure) atau punca kebocoran.
Kesilapan lazim
- Menganggap GA bermakna setiap pemacu storan menyokong ciri tersebut secara automatik; ia masih bergantung pada CSI dan pelaksanaan storan.
- Menerangkan penciptaan sahaja, tanpa pengendalian kegagalan peringkat ahli, topologi dan kitaran hayat.
- Memanggil konsistensi nahas sebagai konsistensi aplikasi dan mengabaikan proses flush, WAL atau checkpoint.
- Hanya menyimpan metadata snapshot dan tidak pernah memulakan pangkalan data yang dipulihkan dalam persekitaran yang diasingkan.
Soalan susulan dan jawapan
Bagaimana jika snapshot salah satu volum ahli gagal?
Tandakan snapshot kumpulan sebagai tidak boleh digunakan, kekalkan peristiwa dan pemegang yang dicipta, bersihkan sumber terbiar (orphaned resources), dan cuba semula. Pemulihan hanya menerima set ahli yang lengkap, manakala kejayaan separa dilaporkan untuk amaran dan audit kapasiti.
Mengapa tidak mengambil snapshot setiap PVC secara berasingan?
Snapshot individu tidak mempunyai titik pemulihan yang dikongsi bersama, jadi urutan penulisan rentas volum boleh menyimpang. Snapshot kumpulan mewakilkan set ahli dan operasi kumpulan kepada storan, manakala checkpoint aplikasi masih diperlukan untuk konsistensi perniagaan.
Bagaimanakah anda membuktikan pelan ini memenuhi RPO dan RTO?
Lakukan pemulihan dalam kluster yang diasingkan mengikut jadual tetap, rekodkan masa dari checkpoint hingga perkhidmatan boleh menerima pertanyaan, hanyutan kedudukan data (data-position drift) dan kadar kegagalan. Keputusan latih tubi menjadi pintu pelepasan (release gates); jika ambang tidak dipenuhi, laraskan kekerapan snapshot, laluan arkib atau prosedur peralihan.