Mencadangkan dan memulihkan cluster dengan bmctl

Alat command line bmctl memungkinkan Anda mencadangkan dan memulihkan cluster yang dibuat dengan software Distributed Cloud khusus untuk bare metal guna mempersiapkan disaster recovery atau memulihkan cluster yang rusak di semua jenis cluster. Memulihkan dari cadangan adalah upaya terakhir yang mereset cluster dan menimpa informasi cluster yang ada. Pulihkan dari cadangan hanya jika cluster mengalami kegagalan fatal. Hubungi Cloud Customer Care untuk mendapatkan bantuan dalam memutuskan tindakan terbaik.

Yang dicadangkan dan tidak dicadangkan

Proses pencadangan dan pemulihan bmctl beroperasi di lapisan bidang kontrol Kubernetes dan berbeda dari solusi pencadangan lainnya. Solusi pencadangan non-Kubernetes menangkap data workload, penyimpanan persisten, dan sistem operasi host mesin fisik. Proses pencadangan dan pemulihan bmctl memulihkan cluster Kubernetes Anda tanpa mencadangkan komponen lainnya.

Peringatan: Menggunakan file cadangan untuk memulihkan cluster adalah upaya terakhir. Proses pemulihan akan mereset cluster yang ada dan menimpa informasi cluster. Pulihkan dari file cadangan hanya jika cluster mengalami kegagalan fatal. Hubungi Cloud Customer Care untuk mendapatkan bantuan dalam memutuskan tindakan terbaik.

Status bidang kontrol (dicadangkan oleh proses pencadangan bmctl)

bmctl mencadangkan objek berikut:

• penyimpanan etcd. Semua resource Kubernetes dan objek kustom yang menentukan konfigurasi cluster dan status yang dipilih (misalnya, spesifikasi pod, deployment, ConfigMap, dan secret).
• Sertifikat PKI. Sertifikat yang digunakan untuk komunikasi yang aman dalam cluster.
• File konfigurasi dan manifes node. Konfigurasi yang terkait dengan node cluster.

Penyimpanan Workload dan VM Runtime (tidak dicadangkan oleh proses pencadangan bmctl)

bmctl tidak mencadangkan data berikut:

• Status runtime pod dan container aktif. bmctl tidak menyimpan proses aktif dan data aplikasi dalam memori. Setelah pemulihan, Kubernetes memulai ulang pod dari spesifikasi etcd. Setiap status dalam memori yang belum disimpan akan hilang.
• Penyimpanan volume persisten. bmctl tidak mencadangkan data yang disimpan di volume persisten, volume yang dibuat oleh penyedia volume lokal (LVP), atau driver penyimpanan eksternal.
• Disk virtual machine. bmctl tidak mencadangkan konten hard drive virtual VM, seperti database, file, atau status sistem operasi di dalam VM.

Anda harus menggunakan mekanisme pencadangan native Kubernetes atau dalam tamu untuk melindungi data aplikasi dan status virtual machine. Jika driver penyimpanan yang mendasarinya mendukung snapshot volume CSI, gunakan Snapshot Volume Kubernetes standar untuk membuat salinan point-in-time dari volume persisten. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi penyimpanan, lihat Ringkasan penyimpanan.

Jalankan agen pencadangan di dalam sistem operasi tamu virtual machine VM Runtime atau deploy alat pencadangan native aplikasi dalam workload Kubernetes.

Sistem operasi host fisik (tidak didukung)

Perlakukan sistem operasi Linux fisik pada node Google Distributed Cloud sebagai infrastruktur sekali pakai. Arsitektur jaringan Kubernetes tidak mendukung pemulihan image OS tingkat host. Oleh karena itu, Google tidak mendukung penginstalan agen pencadangan tingkat host pihak ketiga langsung di OS host atau pemulihan node fisik dari cadangan image tingkat OS atau snapshot disk.

Jika Anda menginstal agen pencadangan fisik pihak ketiga langsung di OS Linux host, Anda dapat menimbulkan risiko serius.

Banyak agen pencadangan menginstal modul kernel eksklusif atau driver filter tingkat blok untuk melacak perubahan dan mengunci blok disk lokal selama operasi snapshot yang dapat menyebabkan masalah berikut:

• Database etcd tidak dapat menambahkan ke write-ahead log-nya, heartbeat node mengalami waktu tunggu habis, konsensus Raft gagal, dan cluster menjadi tidak stabil.
• Driver kernel pihak ketiga yang tidak didukung bertentangan dengan rutinitas kernel tingkat rendah dan runtime container, sehingga menyebabkan upgrade cluster gagal.
• Memulihkan node fisik dari cadangan image atau snapshot disk melanggar protokol konsensus Raft. Database etcd menjadi tidak sinkron dengan log di node bidang kontrol dan terjadi kerusakan status cluster yang parah.
• Worker node menjadi tidak sinkron dengan sumber kebenaran server API, alamat IP Dataplane V2 (Cilium) bertabrakan, dan traffic dihapus.

Untuk memulihkan node fisik yang mengalami kegagalan sistem operasi atau hardware, jangan pulihkan image OS. Sebagai gantinya, hapus node dari cluster dengan benar, instal ulang sistem operasi dasar yang bersih, dan tambahkan kembali node ke node pool. Untuk petunjuk pemulihan mendetail, lihat Mereset node yang gagal.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care. Anda juga dapat melihat Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang referensi dukungan, termasuk referensi berikut:

• Persyaratan untuk membuka kasus dukungan.
• Alat untuk membantu Anda memecahkan masalah, seperti konfigurasi lingkungan, log, dan metrik.
• Komponen yang didukung.

Mencadangkan cluster

Perintah bmctl backup cluster mengemas data etcd dan sertifikat PKI cluster ke dalam file tar. Database etcd adalah datastore pusat untuk semua data cluster, yang berisi semua objek Kubernetes dan resource kustom yang diperlukan untuk mengelola status cluster. Sertifikat PKI melakukan autentikasi melalui TLS. Data ini dicadangkan dari bidang kontrol cluster atau dari salah satu bidang kontrol untuk deployment ketersediaan tinggi (HA).

File tar cadangan berisi kredensial sensitif, termasuk kunci akun layanan dan kunci SSH Anda. Simpan file cadangan di lokasi yang aman. Untuk mencegah eksposur file yang tidak diinginkan, proses pencadangan Google Distributed Cloud hanya menggunakan file dalam memori.

Cadangkan cluster Anda secara rutin untuk memastikan data snapshot Anda relatif baru. Sesuaikan frekuensi pencadangan untuk mencerminkan frekuensi perubahan signifikan pada cluster Anda.

Versi bmctl yang Anda gunakan untuk mencadangkan cluster harus cocok dengan versi cluster pengelola.

Jika Anda menginstal Agen Node di cluster, direktori /tmp di node admin dan semua node target harus memiliki ruang kosong sebesar 12 GB. Jika Anda tidak dapat mengubah ukuran direktori /tmp untuk node target, lihat Mengubah kapasitas penyimpanan lokal untuk node target. Jika Anda tidak dapat mengubah ukuran direktori /tmp untuk node admin, lihat Mengubah kapasitas penyimpanan lokal untuk node admin.

Untuk mencadangkan cluster:

1. Pastikan cluster Anda beroperasi dengan benar, dengan kredensial dan konektivitas SSH yang berfungsi ke semua node.

   Tujuan proses pencadangan adalah untuk menangkap cluster Anda dalam status baik yang diketahui, sehingga Anda dapat memulihkan operasi jika terjadi kegagalan fatal.

   Gunakan perintah berikut untuk memeriksa cluster Anda:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang ingin Anda cadangkan.
   • ADMIN_KUBECONFIG: jalur file kubeconfig untuk cluster admin.

2. Jalankan perintah berikut untuk memastikan cluster target tidak dalam status rekonsiliasi:

   kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang akan dicadangkan.
   • CLUSTER_NAMESPACE: namespace untuk cluster. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace akan memiliki nama seperti cluster-test.
   • ADMIN_KUBECONFIG: jalur file kubeconfig untuk cluster admin.

3. Periksa bagian Status di output perintah untuk Conditions jenis Reconciling.

   Seperti yang ditunjukkan dalam contoh berikut, status False untuk Conditions ini berarti cluster stabil dan siap dicadangkan.

   ...
   Status:
     ...
     Cluster State:  Running
     ...
     Control Plane Node Pool Status:
       ...
       Conditions:
         Last Transition Time:  2023-11-03T16:37:15Z
         Observed Generation:   1
         Reason:                ReconciliationCompleted
         Status:                False
         Type:                  Reconciling
     ...
   

4. Jalankan perintah berikut untuk mencadangkan cluster:

   bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang akan dicadangkan.
   • ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.

   Secara default, file tar cadangan disimpan ke direktori ruang kerja (bmctl-workspace, secara default) di workstation admin Anda. File tar diberi nama CLUSTER_NAME_backup_TIMESTAMP.tar.gz, dengan CLUSTER_NAME adalah nama cluster yang dicadangkan dan TIMESTAMP adalah tanggal dan waktu pencadangan dibuat. Misalnya, jika nama cluster adalah testuser, file cadangan akan memiliki nama seperti testuser_backup_2006-01-02T150405Z0700.tar.gz.

   Untuk menentukan nama dan lokasi yang berbeda untuk file cadangan Anda, gunakan flag --backup-file.

File cadangan akan habis masa berlakunya setelah satu tahun dan proses pemulihan cluster tidak akan berfungsi dengan file cadangan yang sudah tidak berlaku.

Memulihkan cluster

Memulihkan cluster dari cadangan adalah upaya terakhir dan harus digunakan saat cluster mengalami kegagalan fatal dan tidak dapat dikembalikan ke layanan dengan cara lain. Misalnya, data etcd rusak atau Pod etcd berada dalam loop error.

Catatan: Untuk meningkatkan performa cluster, Google Distributed Cloud menggunakan instance etcd terpisah untuk menyimpan objek Event. Objek Event ini memiliki time to live (TTL) satu jam. Operasi pemulihan cluster membuat instance etcd-events baru yang kosong, sehingga Anda kehilangan objek Event yang ada. Namun, hilangnya objek Event tidak berdampak pada operasi cluster. Peristiwa harus diperlakukan sebagai data tambahan yang bersifat informatif dan berdasarkan upaya terbaik saja.

File tar cadangan berisi kredensial sensitif, termasuk kunci akun layanan dan kunci SSH Anda. Untuk mencegah eksposur file yang tidak diinginkan, proses pemulihan Google Distributed Cloud hanya menggunakan file dalam memori.

Versi bmctl yang Anda gunakan untuk memulihkan cluster harus cocok dengan versi cluster pengelola.

Untuk memulihkan cluster:

1. Pastikan semua mesin node yang tersedia untuk cluster pada saat pencadangan beroperasi dengan benar dan dapat dijangkau.

2. Pastikan konektivitas SSH antar-node berfungsi dengan kunci SSH yang digunakan pada saat pencadangan.

   Kunci SSH ini diaktifkan kembali sebagai bagian dari proses pemulihan.

3. Pastikan kunci akun layanan yang digunakan pada saat pencadangan masih aktif.

   Kunci akun layanan ini diaktifkan kembali untuk cluster yang dipulihkan.

4. Untuk memulihkan cluster admin, hybrid, atau mandiri, jalankan perintah berikut:

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang Anda pulihkan.
   • BACKUP_FILE: jalur dan nama file cadangan yang Anda gunakan.

5. Untuk memulihkan cluster pengguna, jalankan perintah berikut:

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang Anda pulihkan.
   • BACKUP_FILE: jalur dan nama file cadangan yang Anda gunakan.
   • ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.

Di akhir proses pemulihan, file kubeconfig baru akan dibuat untuk cluster yang dipulihkan.

Setelah pemulihan selesai, gunakan langkah-langkah berikut untuk memverifikasi bahwa pemulihan berhasil:

1. Jalankan perintah berikut untuk memverifikasi kesiapan node dan pod sistem yang berjalan dengan file kubeconfig yang dihasilkan:

   Ada dua jenis pod etcd:

   • etcd-HOST_NAME, yang sesuai dengan Pod etcd utama
   • etcd-events-HOST_NAME, yang sesuai dengan Pod etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. Untuk setiap pod etcd, jalankan perintah berikut untuk memverifikasi kondisi etcd:

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Untuk anggota etcd yang responsif, responsnya akan terlihat seperti berikut:

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. Untuk setiap Pod etcd-events, jalankan perintah berikut untuk memverifikasi kondisi etcd-events:

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Untuk anggota etcd-events yang responsif, responsnya akan terlihat seperti berikut:

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

Memecahkan masalah

Jika Anda mengalami masalah dengan proses pencadangan atau pemulihan, bagian berikut dapat membantu Anda memecahkan masalah tersebut.

Jika Anda memerlukan bantuan tambahan, hubungi Dukungan Google.

Kehabisan memori selama pencadangan atau pemulihan

Anda mungkin menerima pesan error selama proses pencadangan atau pemulihan yang tidak terlalu jelas atau tidak jelas tentang langkah berikutnya. Jika workstation tempat Anda menjalankan perintah bmctl tidak memiliki banyak RAM, Anda mungkin tidak memiliki memori yang cukup untuk melakukan proses pencadangan atau pemulihan.

Google Distributed Cloud versi 1.13 dan yang lebih baru dapat menggunakan parameter --use-disk dalam perintah pencadangan. Untuk mempertahankan izin file, parameter ini mengubah izin file, sehingga mengharuskan pengguna yang menjalankan perintah menjadi pengguna root (atau menggunakan sudo).

Izin tidak ada pada file selama pemulihan

Setelah tugas pemulihan berhasil, penghapusan bootstrap dapat gagal dengan pesan error yang mirip dengan contoh berikut:

  Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Error ini dapat berarti bahwa beberapa direktori yang diperlukan oleh pemulihan tidak dapat ditulisi.

Google Distributed Cloud versi 1.14 dan yang lebih baru memiliki pesan error yang lebih jelas tentang direktori mana yang harus dapat ditulis. Pastikan direktori yang dilaporkan dapat ditulis, dan perbarui izin pada direktori sesuai kebutuhan.

Pemuatan ulang kunci SSH setelah pencadangan akan menghentikan proses pemulihan

Operasi terkait SSH selama proses pemulihan mungkin gagal jika kunci SSH diperbarui setelah pencadangan dilakukan. Dalam hal ini, kunci SSH baru menjadi tidak valid untuk proses pemulihan.

Untuk mengatasi masalah ini, Anda dapat menambahkan kembali kunci SSH asli untuk sementara, lalu melakukan pemulihan. Setelah proses pemulihan selesai, Anda dapat merotasi kunci SSH.

Tidak dapat membuat cadangan untuk node Agen Node

Jika Anda menggunakan Agen Node dan menerima error bahwa pembuatan cadangan gagal membuat file arsip, seperti ini:

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

Pastikan ada ruang kosong sebesar 12 GB di direktori /tmp pada node admin dan semua node target. Jika Anda tidak dapat mengubah ukuran direktori /tmp untuk node target, lihat Meningkatkan kapasitas penyimpanan lokal untuk cadangan Agen Node.

Setelah Anda mengonfirmasi bahwa ada ruang kosong sebesar 12 GB di direktori /tmp untuk node admin dan semua node target, coba pencadangan lagi.