Mencadangkan dan memulihkan cluster dengan bmctl

Halaman ini menjelaskan cara menggunakan bmctl untuk mencadangkan dan memulihkan cluster yang dibuat dengan Google Distributed Cloud (khusus software) di bare metal. Petunjuk ini berlaku untuk semua jenis cluster.

Proses pencadangan dan pemulihan bmctl tidak mencakup volume persisten. Volume apa pun yang dibuat oleh penyedia volume lokal (LVP) tidak berubah.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care. Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang 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 menambahkan informasi cluster dari penyimpanan etcd dan sertifikat PKI untuk cluster yang ditentukan ke file tar. Penyimpanan etcd adalah penyimpanan pendukung Kubernetes untuk semua data cluster dan berisi semua objek Kubernetes dan objek kustom yang diperlukan untuk mengelola status cluster. Sertifikat PKI digunakan untuk 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 file terekspos secara tidak sengaja, 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.

Untuk mencadangkan cluster:

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

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

    Gunakan perintah berikut untuk memeriksa cluster Anda:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Ganti kode berikut:

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

  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 memiliki nama seperti cluster-test.
    • ADMIN_KUBECONFIG: jalur file kubeconfig untuk admin cluster.

  3. Periksa bagian Status di output perintah untuk Conditions berjenis 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 cadangan dibuat. Misalnya, jika nama cluster adalah testuser, file cadangan memiliki nama seperti testuser_backup_2006-01-02T150405Z0700.tar.gz.

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

File cadangan akan berakhir setelah satu tahun dan proses pemulihan cluster tidak berfungsi dengan file cadangan yang sudah berakhir.

Memulihkan cluster

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

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 sehat, 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 sehat, 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 memberikan petunjuk yang jelas tentang langkah selanjutnya. Jika workstation tempat Anda menjalankan perintah bmctl tidak memiliki banyak RAM, Anda mungkin tidak memiliki cukup memori 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 pengguna yang menjalankan perintah harus menjadi pengguna root (atau menggunakan sudo).

Izin file tidak ada 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 ditulis.

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.

Memperbarui kunci SSH setelah pencadangan akan merusak proses pemulihan

Operasi terkait SSH selama proses pemulihan mungkin gagal jika kunci SSH diubah 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 mengganti kunci SSH.