Container Service for Kubernetes:FAQ tentang pusat cadangan

Memahami status pekerjaan

Sebelum melakukan troubleshooting, pahami arti setiap status berikut:

• Failed: Pekerjaan tidak selesai. Periksa detail error menggunakan perintah di atas.

• PartiallyFailed: Pekerjaan selesai tetapi gagal memproses beberapa resource. Periksa bidang Errors dan Warnings dalam detail pekerjaan.

• Completed: Pekerjaan selesai. Jika beberapa resource tidak muncul di kluster pemulihan, periksa bidang Warnings — resource tersebut mungkin dikecualikan oleh konfigurasi atau didaur ulang oleh logika bisnis.

• InProgress: Pekerjaan masih berjalan. Jika pekerjaan tetap dalam status ini dalam waktu lama, lihat Mengapa pekerjaan saya macet di InProgress?.

Mengapa konsol menampilkan "The working component is abnormal" atau "Failed to fetch current data"?

Komponen pusat cadangan tidak terinstal dengan benar. Periksa hal-hal berikut:

• Kluster memiliki node. Pusat cadangan tidak dapat diterapkan jika tidak ada node.

• Jika kluster menggunakan FlexVolume, alihkan ke CSI terlebih dahulu. Lihat Komponen migrate-controller di kluster FlexVolume tidak dapat dimulai.

• Jika Anda menggunakan kubectl, verifikasi bahwa konfigurasi YAML Anda benar. Lihat Gunakan kubectl untuk mencadangkan dan memulihkan aplikasi.

• Untuk kluster khusus ACK dan kluster terdaftar, verifikasi bahwa izin yang diperlukan telah diberikan. Lihat Kluster khusus ACK dan Kluster terdaftar.

• Periksa apakah deployment csdr-controller dan csdr-velero di namespace csdr gagal karena sumber daya tidak mencukupi atau kendala penjadwalan, lalu selesaikan masalah tersebut.

Mengapa konsol menampilkan "Nama telah digunakan. Ubah nama dan coba lagi"?

Saat Anda menghapus tugas, sistem membuat resource deleterequest di kluster dan menjalankan serangkaian operasi penghapusan — bukan hanya menghapus resource cadangan itu sendiri. Jika penghapusan gagal atau terganggu, beberapa resource mungkin tetap ada di kluster dengan nama yang sama, sehingga menyebabkan error ini.

Jalankan perintah berikut untuk menghapus resource yang bentrok. Misalnya, jika error-nya adalah deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists:

kubectl -n csdr delete deleterequests xxxxx-dbr

Kemudian buat tugas dengan nama baru.

Mengapa saya tidak dapat memilih cadangan yang ada saat memulihkan lintas kluster?

Penyebab paling umum adalah penyimpanan cadangan belum diinisialisasi di kluster target. Di halaman Restore, temukan Backup Vault dan klik Initialize Backup Vault. Setelah inisialisasi selesai, pilih cadangan dan lakukan pemulihan.

Jika inisialisasi gagal, resource backuplocation di kluster target menunjukkan status Unavailable. Jalankan perintah berikut untuk memeriksa:

kubectl get -n csdr backuplocation <backuplocation-name>

Output yang diharapkan:

NAME                    PHASE       LAST VALIDATED   AGE
<backuplocation-name>   Available   3m36s            38m

Jika statusnya Unavailable, lihat Mengapa pekerjaan saya gagal dengan "VaultError: xxx"?.

Jika status penyimpanan cadangan baik-baik saja, pastikan di konsol kluster sumber bahwa pekerjaan cadangan menunjukkan status Completed. Pekerjaan cadangan yang gagal atau sedang berjalan tidak dapat dipilih untuk pemulihan lintas kluster.

Mengapa konsol menampilkan "Peran layanan yang dibutuhkan oleh komponen saat ini belum diotorisasi" (AddonRoleNotAuthorized)?

Mulai dari migrate-controller versi 1.8.0, logika otentikasi sumber daya cloud untuk kluster ACK yang dikelola telah diperbarui. Saat pertama kali menginstal atau meningkatkan ke versi ini, Akun Alibaba Cloud harus menyelesaikan otorisasi.

• Jika Anda masuk dengan Akun Alibaba Cloud, klik Authorize.

• Jika Anda masuk sebagai Pengguna RAM, klik Copy Authorization Link dan kirimkan kepada pemilik Akun Alibaba Cloud untuk otorisasi.

Mengapa konsol menampilkan "Akun saat ini belum diberikan izin RBAC kluster yang diperlukan untuk operasi ini" (APISERVER.403)?

Konsol berinteraksi dengan server API untuk mengirim dan memantau pekerjaan cadangan dan pemulihan. Set izin default untuk insinyur O&M dan pengembang tidak mencakup beberapa izin yang dibutuhkan oleh pusat cadangan.

Berikan izin ClusterRole berikut kepada operator pusat cadangan. Untuk petunjuknya, lihat Gunakan peran RBAC kustom untuk membatasi operasi resource di kluster.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csdr-console
rules:
  - apiGroups: ["csdr.alibabacloud.com","velero.io"]
    resources: ['*']
    verbs: ["get","create","delete","update","patch","watch","list","deletecollection"]
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get","list"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get","list"]

Mengapa komponen pusat cadangan gagal ditingkatkan atau di-uninstall, dan namespace csdr tetap dalam status Terminating?

Pusat cadangan keluar secara abnormal, menyebabkan pekerjaan tetap dalam status InProgress. Bidang finalizers pada pekerjaan tersebut menghalangi penghapusan resource.

Jalankan perintah berikut untuk mengidentifikasi penyebab pemblokiran namespace:

kubectl describe ns csdr

Pastikan pekerjaan yang macet tidak lagi diperlukan dan hapus finalizers-nya. Setelah namespace csdr dihapus:

• Untuk peningkatan, instal ulang komponen migrate-controller.

• Untuk uninstall, komponen tersebut kini telah dihapus.

Mengapa pekerjaan saya gagal dengan "internal error"?

Komponen atau layanan cloud yang mendasarinya mengalami pengecualian tak terduga. Misalnya, layanan cloud mungkin tidak tersedia di wilayah saat ini.

Jika error-nya adalah HBR backup/restore internal error, periksa Konsol Cloud Backup untuk memverifikasi bahwa fitur cadangan kontainer tersedia di wilayah Anda.

Mengapa pekerjaan saya gagal dengan "create cluster resources timeout"?

Selama konversi StorageClass atau pemulihan, pusat cadangan membuat pod, PVC, dan PV sementara. Jika resource ini tetap dalam status tidak tersedia terlalu lama, error timeout ini terjadi.

1. Identifikasi resource yang macet:

      kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>

   Misalnya, output seperti wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out berarti PVC demo-pvc-for-convert202311151045 di namespace default tidak terikat.

2. Periksa status PVC untuk menemukan akar penyebabnya:

      kubectl -n default describe pvc demo-pvc-for-convert202311151045

Penyebab umum meliputi:

• Sumber daya kluster atau node tidak mencukupi.

• Kluster pemulihan tidak memiliki kelas penyimpanan yang diperlukan. Gunakan fitur konversi StorageClass untuk memilih kelas penyimpanan yang tersedia sebelum memulihkan.

• Penyimpanan dasar dari kelas penyimpanan tidak tersedia — misalnya, tipe disk yang ditentukan tidak didukung di zona saat ini.

• Sistem File Jaringan Container (CNFS) yang terkait dengan alibabacloud-cnfs-nas tidak normal. Lihat Gunakan CNFS untuk mengelola sistem file NAS (disarankan).

• Anda memilih kelas penyimpanan dengan volumeBindingMode: Immediate di kluster multi-zona.

Untuk panduan troubleshooting penyimpanan, lihat Troubleshoot storage issues.

Mengapa pekerjaan saya gagal dengan "addon status is abnormal"?

Komponen di namespace csdr tidak normal. Periksa statusnya:

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

Untuk langkah penyelesaian, lihat Mengapa pekerjaan saya macet di InProgress?.

Mengapa pekerjaan saya gagal dengan "VaultError: xxx"?

Error ini berarti penyimpanan cadangan tidak dapat mengakses bucket OSS. Periksa hal-hal berikut:

1. Verifikasi keberadaan bucket OSS.

Masuk ke Konsol OSS dan pastikan bucket yang terkait dengan penyimpanan cadangan ada. Jika tidak ada, buat bucket baru dan asosiasikan ulang. Lihat Create buckets.

Anda tidak dapat membuat penyimpanan cadangan dengan nama yang sama seperti yang telah dihapus, atau mengasosiasikan penyimpanan cadangan dengan bucket OSS yang namanya tidak mengikuti format cnfs-oss-*. Jika Anda memiliki penyimpanan cadangan yang sudah ada yang diasosiasikan dengan bucket bernama salah, buat penyimpanan cadangan baru dengan nama berbeda dan asosiasikan dengan bucket cnfs-oss-*.

2. Verifikasi izin akses OSS.

• Untuk kluster ACK Pro, tidak diperlukan konfigurasi izin OSS jika nama bucket OSS dimulai dengan cnfs-oss-.

• Untuk kluster khusus ACK dan kluster terdaftar, konfigurasikan izin OSS seperti yang dijelaskan di Install migrate-controller and grant permissions.

Untuk kluster ACK yang dikelola di mana komponen diinstal atau ditingkatkan ke v1.8.0 atau lebih baru di luar konsol, jalankan perintah berikut untuk memeriksa apakah izin OSS telah dikonfigurasi:

kubectl get secret -n kube-system | grep addon.aliyuncsmanagedbackuprestorerole.token

Output yang diharapkan:

addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

Jika output-nya cocok, izin sudah diberikan. Jika tidak, berikan izin dengan salah satu metode berikut:

• Ikuti petunjuk untuk kluster khusus ACK dan kluster terdaftar. Lihat Install the backup service component and configure permissions.

• Klik Authorize untuk mengotorisasi Akun Alibaba Cloud Anda. Ini hanya perlu dilakukan sekali per akun.

3. Periksa konfigurasi jaringan.

kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network

• network: internal — penyimpanan cadangan mengakses OSS melalui jaringan internal.

• network: public — penyimpanan cadangan mengakses OSS melalui Internet. Jika ini menyebabkan timeout, verifikasi bahwa kluster dapat mengakses Internet. Lihat Enable an existing ACK cluster to access the Internet.

Penyimpanan cadangan harus menggunakan akses jaringan publik dalam skenario berikut:

• Kluster dan bucket OSS berada di wilayah yang berbeda.

• Kluster adalah kluster ACK Edge.

• Kluster adalah kluster terdaftar yang tidak terhubung ke VPC melalui Cloud Enterprise Network (CEN), Express Connect, atau VPN — atau rute ke blok CIDR OSS internal wilayah tersebut tidak dikonfigurasi.

Untuk beralih ke akses jaringan publik, jalankan:

kubectl patch -n csdr backuplocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'
kubectl patch -n csdr backupstoragelocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'

Ganti <region-id> dengan wilayah bucket OSS, seperti cn-hangzhou.

Mengapa pekerjaan saya gagal dengan "HBRError: check HBR vault error"?

Cloud Backup belum diaktifkan atau tidak memiliki izin yang diperlukan.

1. Aktifkan layanan Cloud Backup. Lihat Enable Cloud Backup.

2. Untuk kluster di Tiongkok (Ulanqab), Tiongkok (Heyuan), atau Tiongkok (Guangzhou), otorisasi juga Cloud Backup untuk mengakses API Gateway setelah aktivasi. Lihat (Optional) Step 3: Authorize the Cloud Backup service to access API Gateway.

3. Untuk kluster khusus ACK dan kluster terdaftar, verifikasi bahwa izin RAM Cloud Backup telah diberikan. Lihat Install the migrate-controller backup service component and configure permissions.

Mengapa pekerjaan saya gagal dengan "HBRError: ... code: 400, Illegal request. Please modify the parameters"?

Repository Cloud Backup ack-backup-data di wilayah tersebut telah dihapus.

Saat Anda pertama kali membuat cadangan di suatu wilayah, pusat cadangan secara otomatis membuat repository ack-backup-data untuk menyimpan cadangan. Jika repository ini dihapus, pekerjaan berikutnya akan gagal dengan error ini.

1. Di semua kluster yang menggunakan pusat cadangan di wilayah yang terdampak, hapus catatan penyimpanan cadangan:

      kubectl -ncsdr delete backuplocation --all
      kubectl -ncsdr delete backupstoragelocation --all

2. Kembali ke kluster dan buat cadangan baru. Komponen secara otomatis membuat repository ack-backup-data baru dan mengasosiasikannya dengan penyimpanan cadangan.

Mengapa pekerjaan saya gagal dengan "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist"?

Klien Cloud Backup (DaemonSet hbr-client) di node dalam namespace csdr tidak berjalan dengan benar.

1. Periksa pod hbr-client yang tidak normal:

      kubectl -n csdr get pod -lapp=hbr-client

2. Jika ada pod dalam status tidak normal, periksa apakah penyebabnya adalah alamat IP pod, memori, atau CPU yang tidak mencukupi. Untuk pod dalam status CrashLoopBackOff, lihat log-nya:

      kubectl -n csdr logs -p <hbr-client-pod-name>

   Jika log berisi SDKError: StatusCode: 403, Code: MagpieBridgeSlrNotExist, ikuti (Optional) Step 3: Authorize Cloud Backup to access API Gateway untuk memberikan izin yang diperlukan.

3. Untuk error SDK lainnya, gunakan kode error EC untuk troubleshooting. Lihat Troubleshoot issues using EC error codes.

Mengapa pekerjaan saya macet di InProgress?

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

kubectl get volumesnapshot -n <backup-namespace>

Mengapa pencadangan saya gagal dengan "backup already exists in OSS bucket"?

Cadangan dengan nama yang sama sudah ada di bucket OSS yang terkait dengan penyimpanan cadangan. Buat cadangan dengan nama baru.

Cadangan mungkin tidak terlihat di kluster saat ini karena beberapa alasan: milik pekerjaan yang sedang berjalan atau gagal (yang tidak disinkronkan lintas kluster), dihapus di kluster berbeda (file ditandai tetapi tidak dihapus dari OSS), atau kluster saat ini tidak diasosiasikan dengan penyimpanan cadangan tempat cadangan tersebut disimpan.

Mengapa pencadangan saya gagal dengan "get target namespace failed"?

Ini biasanya terjadi pada pekerjaan pencadangan terjadwal. Pemilihan namespace tidak valid:

• Jika Anda memilih Include, semua namespace yang dipilih telah dihapus.

• Jika Anda memilih Exclude, namespace yang dikecualikan tidak lagi ada di kluster.

Perbarui rencana cadangan untuk memperbaiki pemilihan namespace.

Mengapa pencadangan saya gagal dengan "velero backup process timeout"?

Dua penyebab umum:

Kelas penyimpanan bucket OSS: Jika kelas penyimpanan bucket adalah Archive, Cold Archive, atau Deep Cold Archive, pusat cadangan tidak dapat memperbarui file metadata (file yang diarsipkan harus dipulihkan terlebih dahulu). Ubah kelas penyimpanan bucket menjadi Standard. Untuk menyimpan data arsip dengan biaya lebih rendah, konfigurasikan aturan siklus hidup untuk mengonversi kelas penyimpanan secara otomatis. Lihat Convert storage classes.

Timeout subtask: Timeout default untuk subtask pencadangan adalah 60 menit (migrate-controller 1.7.7 dan lebih baru). Jika kluster Anda memiliki banyak resource atau server API memiliki latensi tinggi, tingkatkan nilai ini di ConfigMap csdr-config:

kubectl edit -n csdr cm csdr-config

Tambahkan velero_timeout_minutes ke bagian applicationBackup. Misalnya, untuk mengatur timeout 100 menit:

apiVersion: v1
data:
  applicationBackup: |
    ...
    velero_timeout_minutes: 100

Restart controller agar perubahan berlaku:

kubectl -n csdr delete pod -l control-plane=csdr-controller

Mengapa pencadangan saya gagal dengan "HBR backup request failed"?

Tiga kemungkinan penyebab:

Plug-in penyimpanan tidak kompatibel: Jika kluster Anda menggunakan plug-in penyimpanan CSI non-Alibaba Cloud, atau PV bukan tipe volume Kubernetes standar (seperti NFS atau LocalVolume), ajukan tiket untuk bantuan.

Volume mode block: Cloud Backup tidak mendukung volume yang VolumeMode-nya adalah Block. Jika kluster Anda menggunakan CSI, snapshot disk digunakan untuk pencadangan data secara default, dan snapshot disk mendukung volume mode Block. Jika tipe plug-in penyimpanan salah, alihkan ke CSI, instal ulang komponen cadangan, dan jalankan pencadangan lagi.

Masalah klien Cloud Backup: Untuk volume sistem file (OSS, NAS, CPFS, atau lokal), klien Cloud Backup mungkin mengalami timeout atau gagal. Untuk menyelidiki:

1. Masuk ke Konsol Cloud Backup.

2. Buka Backup > Container Backup dan klik tab Backup Jobs.

3. Pilih wilayah di bilah navigasi atas.

4. Cari <backup-name>-hbr untuk melihat status pekerjaan dan alasan kegagalannya. Lihat Back up ACK clusters.

Untuk menanyakan pekerjaan konversi StorageClass atau pencadangan, cari nama cadangan.

Mengapa pencadangan saya gagal dengan "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST"?

Untuk CSI pihak ketiga atau tipe penyimpanan yang dikelola sendiri (NFS, Ceph):

Pusat cadangan menggunakan path mount volume Kubernetes standar sebagai path pencadangan data. Untuk CSI standar, path default-nya adalah /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Jika path root kubelet di kluster Anda telah diubah, Cloud Backup mungkin tidak menemukan data.

Masuk ke node tempat volume dipasang dan lakukan troubleshooting:

1. Temukan path root kubelet. Jalankan:

   • Jika perintah startup mencakup --root-dir, nilai tersebut adalah path root kubelet.

   • Jika mencakup --config, periksa file konfigurasi untuk bidang root-dir.

   • Jika keduanya tidak ada, periksa /etc/systemd/system/kubelet.service untuk referensi EnvironmentFile, lalu periksa file tersebut untuk ROOT_DIR.

   • Jika tidak ditemukan apa pun, path root kubelet adalah default /var/lib/kubelet.

      ps -elf | grep kubelet

2. Periksa apakah path root adalah tautan simbolik:

      ls -al <root-dir>

   Jika output menunjukkan sesuatu seperti kubelet -> /var/lib/container/kubelet, path root sebenarnya adalah /var/lib/container/kubelet.

3. Pastikan data volume target ada di bawah path root di <root-dir>/pods/<pod-uid>/volumes.

4. Atur variabel lingkungan KUBELET_ROOT_PATH di deployment csdr/csdr-controller ke path root kubelet sebenarnya.

Untuk penyimpanan HostPath:

HostPath tidak membuat path mount di bawah path root kubelet. Komponen cadangan tidak dapat membaca data dari path node secara default. Ajukan tiket untuk bantuan.

Mengapa pencadangan saya gagal dengan "check backup files in OSS bucket failed", "upload backup files to OSS bucket failed", atau "download backup files from OSS bucket failed"?

Server OSS mengembalikan error selama operasi file pada bucket penyimpanan cadangan. Tiga kemungkinan penyebab:

Izin KMS tidak ada: Jika Anda mengaktifkan enkripsi sisi server dengan CMK KMS pada bucket OSS, pusat cadangan membutuhkan izin tambahan. Lihat Apakah pusat cadangan mendukung enkripsi KMS untuk bucket OSS yang terkait?.

Izin OSS tidak lengkap: Untuk kluster khusus ACK dan kluster terdaftar, periksa kebijakan izin Pengguna RAM yang digunakan selama instalasi komponen. Lihat Step 1: Configure permissions.

Kredensial otentikasi dicabut: Untuk kluster khusus ACK dan kluster terdaftar, pastikan kredensial otentikasi Pengguna RAM masih berlaku. Jika telah dicabut, dapatkan kredensial baru, perbarui Secret alibaba-addon-secret di namespace csdr, dan restart komponen:

kubectl -nkube-system delete pod -lapp=migrate-controller

Mengapa pencadangan saya menunjukkan PartiallyFailed dengan "PROCESS velero partially completed"?

Beberapa resource kluster gagal dicadangkan. Jalankan perintah berikut untuk melihat resource mana yang gagal dan alasannya:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name>

Periksa bidang Errors dan Warnings dalam output dan perbaiki masalahnya. Untuk log tambahan:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero backup logs <backup-name>

Mengapa pencadangan saya menunjukkan PartiallyFailed dengan "PROCESS hbr partially completed"?

Cloud Backup gagal mencadangkan beberapa volume sistem file (OSS, NAS, CPFS, atau volume lokal). Hal ini dapat terjadi karena:

• Plug-in penyimpanan yang digunakan oleh beberapa volume tidak didukung.

• File dihapus selama pencadangan, menyebabkan kegagalan konsistensi.

Untuk menyelidiki, cari <backup-name>-hbr di tab Backup Jobs di Konsol Cloud Backup. Pilih wilayah yang benar dan tinjau status pekerjaan serta alasan kegagalannya. Lihat Back up ACK clusters.

Mengapa konversi StorageClass saya gagal dengan "storageclass xxx not exists"?

Kelas penyimpanan target yang dipilih untuk konversi tidak ada di kluster saat ini.

1. Reset tugas konversi StorageClass:

      cat << EOF | kubectl apply -f -
      apiVersion: csdr.alibabacloud.com/v1beta1
      kind: DeleteRequest
      metadata:
        name: reset-convert
        namespace: csdr
      spec:
        deleteObjectName: "<backup-name>"
        deleteObjectType: "Convert"
      EOF

2. Buat kelas penyimpanan yang diperlukan di kluster.

3. Jalankan pekerjaan pemulihan lagi dengan konfigurasi konversi StorageClass.

Mengapa konversi StorageClass saya gagal dengan "only support convert to storageclass with CSI diskplugin or nasplugin provisioner"?

Konversi StorageClass hanya mendukung tipe volume disk dan NAS Alibaba Cloud CSI sebagai target. Untuk kebutuhan lain, ajukan tiket.

Jika Anda menggunakan layanan penyimpanan yang mendukung akses jaringan publik (seperti OSS), buat PV dan PVC yang disediakan secara statis dan pulihkan aplikasi tanpa konversi StorageClass. Lihat Use an ossfs 1.0 statically provisioned volume.

Mengapa konversi StorageClass saya gagal dengan "current cluster is multi-zoned"?

Di kluster multi-zona, jika Anda mengonversi ke kelas penyimpanan tipe disk yang volumeBindingMode-nya adalah Immediate, CSI membuat PV di zona tetap. Pod tidak dapat dijadwalkan ke zona berbeda, sehingga tetap dalam status Pending.

1. Reset tugas konversi StorageClass (gunakan perintah yang sama seperti di atas).

2. Pilih kelas penyimpanan yang benar:

   • Konsol: Pilih alicloud-disk. Default-nya adalah alicloud-disk-topology-alltype.

   • Baris perintah: Gunakan alicloud-disk-topology-alltype. Anda juga dapat mengatur volumeBindingMode ke WaitForFirstConsumer untuk memastikan PV dibuat di zona yang sama dengan pod.

3. Jalankan pekerjaan pemulihan lagi.

Mengapa pemulihan saya gagal dengan "multi-node writing is only supported for block volume"?

Aplikasi yang akan dipulihkan memiliki volume yang AccessMode-nya adalah ReadWriteMany atau ReadOnlyMany. Saat memulihkan ke penyimpanan disk Alibaba Cloud (yang secara default tidak mendukung pemasangan ganda), CSI memblokir pemasangan.

Hal ini terjadi dalam tiga skenario:

• Versi CSI lama atau FlexVolume di kluster cadangan: Versi CSI sebelumnya tidak memeriksa AccessModes selama pemasangan. Volume gagal saat dipulihkan ke kluster dengan versi CSI yang lebih baru. Mulai dari v1.8.4, komponen cadangan secara otomatis mengonversi AccessModes volume disk menjadi ReadWriteOnce. Tingkatkan komponen dan pulihkan lagi.

• Kelas penyimpanan tidak ada di kluster pemulihan: Volume dicocokkan ke volume disk Alibaba Cloud secara default. Buat kelas penyimpanan dengan nama yang sama di kluster pemulihan sebelum memulihkan, atau gunakan konversi StorageClass untuk menentukan target.

• Konversi StorageClass manual ke disk: Tambahkan parameter convertToAccessModes untuk mengonversi AccessModes menjadi ReadWriteOnce. Lihat convertToAccessModes.

Mengapa pemulihan saya gagal dengan "only disk type PVs support cross-region restore in current version"?

Pemulihan lintas wilayah hanya didukung untuk volume disk (migrate-controller 1.7.7 dan lebih baru). Untuk jenis penyimpanan lain yang mendukung akses Internet (seperti OSS), buat PV dan PVC yang disediakan secara statis dan pulihkan aplikasi. Lihat Use an ossfs 1.0 statically provisioned volume.

Mengapa pemulihan saya gagal dengan "ECS snapshot cross region request failed"?

Pemulihan lintas wilayah untuk volume disk memerlukan izin snapshot disk ECS, yang secara default tidak diberikan untuk semua jenis kluster.

Untuk kluster khusus ACK dan kluster terdaftar yang terhubung ke Kubernetes yang dikelola sendiri yang diterapkan pada instance ECS, berikan izin snapshot disk ECS. Lihat Registered cluster.

Mengapa pemulihan saya gagal dengan "accessMode of PVC xxx is xxx"?

Volume disk yang dipulihkan memiliki AccessMode ReadOnlyMany atau ReadWriteMany. CSI memberlakukan aturan berikut:

• Hanya volume dengan multiAttach yang diaktifkan yang dapat dipasang ke beberapa instance.

• Volume dengan VolumeMode: Filesystem (ext4 atau xfs) hanya dapat dipasang ke beberapa instance dalam mode read-only.

Dua pendekatan yang direkomendasikan:

• Jika Anda mengonversi volume multi-mount (seperti OSS atau NAS) ke penyimpanan disk, buat pekerjaan pemulihan baru dan pilih alibabacloud-cnfs-nas sebagai target untuk konversi StorageClass. Ini menggunakan volume NAS yang dikelola CNFS, yang mendukung pemasangan ganda. Lihat Use CNFS to manage NAS file systems (recommended).

• Jika PV disk yang dicadangkan sendiri tidak memenuhi persyaratan CSI saat ini (dicadangkan saat versi CSI lebih rendah dan deteksi AccessMode tidak diberlakukan), migrasikan beban kerja Anda untuk menggunakan volume disk yang disediakan secara dinamis untuk menghindari pelepasan disk paksa selama penjadwalan.

Status pemulihan saya Completed, tetapi beberapa resource hilang. Mengapa?

Status Completed tidak menjamin semua resource dipulihkan. Periksa setiap kemungkinan penyebab:

Resource tersebut tidak dicadangkan. Jalankan perintah berikut untuk memeriksa cadangan:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --details

Resource tingkat kluster dari pod yang berjalan di namespace yang tidak dipilih untuk pencadangan tidak dicadangkan secara default. Untuk konfigurasi pencadangan tingkat kluster, lihat Cluster-level backup.

Resource tersebut dikecualikan selama pemulihan. Periksa apakah namespace, tipe resource, atau filter lain dalam pekerjaan pemulihan mengecualikan resource tersebut, lalu jalankan ulang pemulihan.

Subtask pemulihan sebagian gagal. Jalankan perintah berikut untuk mengidentifikasi kegagalan:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe restore <restore-name>

Perbaiki masalah di bidang Errors dan Warnings.

Resource tersebut didaur ulang setelah dibuat. Periksa log audit untuk resource tersebut untuk menentukan apakah resource tersebut dihapus setelah dibuat, karena ownerReferences atau logika bisnis.

Komponen migrate-controller di kluster FlexVolume tidak dapat dimulai

Komponen migrate-controller tidak mendukung kluster FlexVolume. Migrasikan ke CSI sebelum menggunakan pusat cadangan:

• Migrasikan dari FlexVolume ke CSI menggunakan komponen csi-compatible-controller

• Migrasikan FlexVolume tanpa kluster penyimpanan ke CSI

• Migrasikan volume NAS yang disediakan secara statis dari FlexVolume ke CSI

• Migrasikan volume OSS yang disediakan secara statis dari FlexVolume ke CSI

• Untuk kasus lain, bergabunglah dengan grup pengguna DingTalk (ID grup: 35532895) untuk konsultasi.

Untuk mencadangkan aplikasi di kluster FlexVolume dan memulihkannya ke kluster CSI selama migrasi, lihat Gunakan pusat cadangan untuk migrasi aplikasi di kluster Kubernetes yang menjalankan versi lama.

Dapatkah saya memodifikasi penyimpanan cadangan?

Tidak. Untuk melakukan perubahan, hapus penyimpanan cadangan saat ini dan buat yang baru dengan nama berbeda.

Karena penyimpanan cadangan adalah resource yang dibagikan yang mungkin sedang digunakan kapan saja, memodifikasi parameternya berisiko menyebabkan data tidak dapat diakses selama pencadangan atau pemulihan yang sedang berlangsung. Anda juga tidak dapat membuat penyimpanan cadangan baru dengan nama yang sama seperti yang telah dihapus.

Dapatkah saya menggunakan bucket OSS yang namanya tidak dalam format "cnfs-oss-*"?

Untuk kluster selain kluster khusus ACK dan kluster terdaftar, pusat cadangan memiliki akses baca/tulis ke bucket OSS yang namanya dalam format cnfs-oss-* secara default. Menggunakan bucket dengan nama berbeda memerlukan konfigurasi tambahan.

1. Konfigurasikan izin OSS untuk komponen. Lihat Kluster khusus ACK.

2. Restart komponen layanan cadangan:

      kubectl -n csdr delete pod -l control-plane=csdr-controller
      kubectl -n csdr delete pod -l component=csdr

Setelah membuat penyimpanan cadangan dengan nama bucket non-standar, tunggu hingga pemeriksaan konektivitas selesai (sekitar lima menit) sebelum memulai operasi pencadangan atau pemulihan. Periksa status penyimpanan cadangan:

kubectl -n csdr get backuplocation

Output yang diharapkan:

NAME                    PHASE       LAST VALIDATED   AGE
a-test-backuplocation   Available   7s               6d1h

Bagaimana cara menentukan jadwal pencadangan saat membuat rencana cadangan?

Jadwal pencadangan mendukung dua format:

• Ekspresi Cron: Misalnya, 1 4 * * * menjalankan pencadangan pada pukul 04.01 setiap hari.

• Interval: Misalnya, 6h30m menjalankan pencadangan setiap 6 jam 30 menit.

Referensi format Cron:

 *  *  *  *  *
 |  |  |  |  |
 |  |  |  |  ·----- hari dalam minggu (0 - 6, Minggu sampai Sabtu)
 |  |  |  ·-------- bulan (1 - 12)
 |  |  .----------- hari dalam bulan (1 - 31)
 |  ·-------------- jam (0 - 23)
 ·----------------- menit (0 - 59)

Contoh: 0 2 15 * 1 menjalankan pencadangan pada pukul 02.00 tanggal 15 setiap bulan.

Perubahan apa saja yang dilakukan pekerjaan pemulihan terhadap resource YAML yang dicadangkan?

Pekerjaan pemulihan melakukan penyesuaian otomatis berikut:

Ukuran volume disk: Jika volume disk lebih kecil dari 20 GiB, ukurannya ditingkatkan menjadi 20 GiB.

Layanan: Dipulihkan berdasarkan tipe Service:

• Layanan NodePort: Port layanan dipertahankan secara default selama pemulihan lintas kluster.

• Layanan LoadBalancer:

  • Saat ExternalTrafficPolicy adalah Local, HealthCheckNodePort menggunakan port acak. Untuk mempertahankan port asli, atur spec.preserveNodePorts: true dalam pekerjaan pemulihan.

  • Jika Layanan menggunakan instance SLB yang ada dari kluster cadangan, Layanan yang dipulihkan menggunakan instance SLB yang sama tetapi menonaktifkan pendengarnya. Konfigurasikan pendengar di konsol SLB.

  • Jika instance SLB dikelola oleh CCM di kluster cadangan, CCM membuat instance SLB baru. Lihat Considerations for configuring a LoadBalancer Service.

Bagaimana cara melihat resource dalam cadangan?

Cadangan aplikasi kluster:

Jalankan di kluster yang memiliki file cadangan disinkronkan:

kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1
kubectl -n csdr exec -it csdr-velero-xxx -c velero -- ./velero describe backup <backup-name> --details

Atau gunakan konsol ACK: buka kluster Anda > Operations > Application Backup > Backup Records, lalu klik catatan cadangan.

Cadangan volume disk:

Di Konsol ECS, buka Storage & Snapshots > Snapshots dan kueri snapshot berdasarkan ID disk.

Cadangan volume non-disk:

Di Konsol Cloud Backup, buka Backup > Container Backup dan pilih wilayah. Tab Clusters mencantumkan kluster yang dicadangkan dan PVC-nya. Tab Backup Jobs menunjukkan status pekerjaan.

Jika Client Status tidak normal, Cloud Backup tidak berjalan dengan benar di kluster ACK. Buka halaman DaemonSets di konsol ACK untuk troubleshooting.

Dapatkah saya mencadangkan dari versi Kubernetes lama dan memulihkan ke versi yang lebih baru?

Ya. Secara default, semua versi API yang didukung oleh resource dicadangkan. Misalnya, Deployment di Kubernetes 1.16 mendukung extensions/v1beta1, apps/v1beta1, apps/v1beta2, dan apps/v1. Keempat versi tersebut disimpan di penyimpanan cadangan terlepas dari versi yang digunakan untuk membuatnya. Fitur KubernetesConvert menangani konversi versi API selama pemulihan.

Saat memulihkan, versi API yang direkomendasikan oleh kluster pemulihan digunakan. Misalnya, memulihkan ke Kubernetes 1.28 menggunakan apps/v1 untuk Deployment.

Apakah trafik secara otomatis dialihkan ke instance SLB selama pemulihan?

Tidak. Setelah pemulihan, pendengar SLB dinonaktifkan atau instance SLB baru dibuat (tergantung pada konfigurasi aslinya). Trafik tidak dialihkan secara otomatis.

Jika Anda menggunakan mekanisme penemuan layanan lain dan ingin mengontrol kapan trafik dialihkan, kecualikan resource Service selama pencadangan dan terapkan secara manual saat Anda siap mengalihkan.

Mengapa resource di csdr, ack-csi-fuse, kube-system, kube-public, dan kube-node-lease tidak dicadangkan secara default?

• csdr: Ini adalah namespace milik pusat cadangan sendiri. Mencadangkannya secara langsung akan menyebabkan komponen gagal di kluster pemulihan. Sinkronisasi cadangan ditangani secara otomatis — Anda tidak perlu memigrasikan cadangan secara manual.

• ack-csi-fuse: Namespace ini menjalankan pod klien FUSE yang dikelola oleh CSI. CSI di kluster baru secara otomatis menyinkronkan klien ini selama pemulihan penyimpanan.

• kube-system, kube-public, kube-node-lease: Ini adalah namespace sistem Kubernetes. Karena perbedaan parameter dan konfigurasi kluster, memulihkan namespace ini lintas kluster tidak didukung. Sebelum menjalankan pekerjaan pemulihan, instal dan konfigurasikan komponen sistem di kluster pemulihan secara manual — misalnya, komponen tarik gambar tanpa password Container Registry (acr-configuration) dan komponen ALB Ingress (ALBConfig).

Apakah pusat cadangan menggunakan snapshot disk ECS untuk volume disk? Apa tipe snapshot default-nya?

Pusat cadangan menggunakan snapshot disk ECS secara default dalam skenario berikut:

• Kluster adalah kluster ACK yang dikelola atau khusus.

• Kluster menjalankan Kubernetes 1.18 atau lebih baru dan menggunakan CSI 1.18 atau lebih baru.

Dalam skenario lain, Cloud Backup digunakan untuk pencadangan data disk.

Snapshot disk ECS yang dibuat oleh pusat cadangan memiliki fitur akses instans yang diaktifkan secara default. Periode validitas snapshot sesuai dengan periode validitas yang ditentukan dalam konfigurasi cadangan. Mulai 12 Oktober 2023 pukul 11.00, Alibaba Cloud tidak lagi membebankan biaya untuk penyimpanan akses instans snapshot atau operasinya di wilayah mana pun. Lihat Use the instant access feature.

Mengapa periode validitas snapshot disk ECS berbeda dari yang saya tentukan dalam konfigurasi cadangan?

Konfigurasi periode validitas bergantung pada komponen csi-provisioner. Jika csi-provisioner lebih lama dari versi 1.20.6, VolumeSnapshot dibuat tanpa pengaturan periode validitas atau akses instans — sehingga konfigurasi cadangan tidak memengaruhi snapshot disk.

Tingkatkan csi-provisioner ke 1.20.6 atau lebih baru untuk memastikan periode validitas diterapkan dengan benar.

Jika peningkatan tidak memungkinkan, konfigurasikan periode validitas snapshot default sebagai gantinya:

1. Perbarui migrate-controller ke v1.7.10 atau lebih baru.

2. Periksa apakah VolumeSnapshotClass dengan pengaturan retensi 30 hari ada:

      kubectl get volumesnapshotclass csdr-disk-snapshot-with-default-ttl

3. Jika tidak ada, atau jika ada tetapi retentionDays tidak diatur ke 30, terapkan hal berikut:

      apiVersion: snapshot.storage.k8s.io/v1
      deletionPolicy: Retain
      driver: diskplugin.csi.alibabacloud.com
      kind: VolumeSnapshotClass
      metadata:
        name: csdr-disk-snapshot-with-default-ttl
      parameters:
        retentionDays: "30"

Semua pencadangan volume disk di kluster kemudian akan membuat snapshot dengan periode retensi yang ditetapkan di retentionDays.

Apa itu pencadangan data volume, dan kapan saya membutuhkannya?

Apa fungsinya: Pencadangan data volume menyalin data volume ke penyimpanan cloud menggunakan snapshot disk ECS atau Cloud Backup. Saat Anda memulihkan aplikasi, disk atau sistem file NAS baru dibuat dari salinan ini. Aplikasi yang dipulihkan dan aplikasi asli memiliki data yang independen — perubahan pada satu tidak memengaruhi yang lain.

Jika Anda tidak memerlukan isolasi data atau jika penyimpanan Anda sudah menyediakan akses lintas zona atau lintas wilayah (seperti OSS), Anda dapat melewatkan pencadangan data volume. File YAML PVC dan PV tetap disertakan dalam pencadangan aplikasi secara default.

Kapan menggunakannya:

• Pemulihan bencana atau catatan data versi.

• Aplikasi menggunakan volume disk (disk dasar hanya dapat dipasang ke satu node).

• Anda memerlukan pencadangan dan pemulihan lintas wilayah (sebagian besar tipe penyimpanan selain OSS tidak mendukung akses lintas wilayah).

• Anda memerlukan isolasi data antara aplikasi asli dan yang dipulihkan.

• Plug-in atau versi penyimpanan berbeda secara signifikan antara kluster cadangan dan pemulihan, sehingga pemulihan YAML langsung tidak praktis.

Risiko tidak mencadangkan volume untuk aplikasi berstatus:

• Volume dengan kebijakan reclaim `Delete`: CSI membuat PV baru yang kosong selama pemulihan. Volume yang disediakan secara statis tanpa kelas penyimpanan yang cocok tetap dalam status Pending hingga Anda membuat PV atau kelas penyimpanan secara manual.

• Volume dengan kebijakan reclaim `Retain`: Resource dipulihkan dalam urutan PV terlebih dahulu. Untuk penyimpanan multi-mount (NAS, OSS), sistem file atau bucket asli digunakan kembali. Untuk disk, ada risiko pelepasan disk paksa.

Untuk memeriksa kebijakan reclaim volume Anda:

kubectl get pv -o=custom-columns=CLAIM:.spec.claimRef.name,NAMESPACE:.spec.claimRef.namespace,NAME:.metadata.name,RECLAIMPOLICY:.spec.persistentVolumeReclaimPolicy

Bagaimana cara memilih node untuk pencadangan sistem file dalam perlindungan data?

Secara default, pekerjaan Cloud Backup dapat berjalan di node apa pun kecuali node virtual. Hanya satu pekerjaan pencadangan volume yang berjalan di node dalam satu waktu.

Tiga kebijakan penjadwalan node tersedia:

Untuk memberi label node:

# Exclude a node
kubectl label node <node-name> csdr.alibabacloud.com/agent-excluded="true"

# Include a node (for the include policy)
kubectl label node <node-name> csdr.alibabacloud.com/agent-included="true"

Untuk mengubah kebijakan, edit ConfigMap csdr-config:

kubectl -n csdr edit cm csdr-config

Tambahkan node_schedule_policy ke bagian applicationBackup:

apiVersion: v1
data:
  applicationBackup: |
    backup_max_worker_num: 15
    restore_max_worker_num: 5
    delete_max_worker_num: 30
    schedule_max_worker_num: 20
    convert_max_worker_num: 15
    node_schedule_policy: include  # Valid values: include, exclude, prefer
  pvBackup: |
    batch_snapshot_max_num: 20
    enable_ecs_snapshot: "true"
kind: ConfigMap

Restart controller agar perubahan berlaku:

kubectl -n csdr delete pod -lapp=csdr-controller

Apa perbedaan antara pencadangan aplikasi dan perlindungan data?

Pencadangan aplikasi digunakan untuk mencadangkan beban kerja Kubernetes — termasuk aplikasi, Layanan, dan file konfigurasi di namespace. Secara opsional sertakan data volume untuk volume yang dipasang. Gunakan pencadangan aplikasi untuk migrasi aplikasi antar kluster atau memulihkan aplikasi untuk pemulihan bencana.

Pencadangan aplikasi tidak mencadangkan volume yang tidak dipasang ke pod. Untuk mencadangkan semua volume, buat pekerjaan pencadangan perlindungan data.

Perlindungan data digunakan untuk mencadangkan volume penyimpanan — PVC dan PV — secara independen dari beban kerja aplikasi. Gunakan perlindungan data untuk memulihkan PVC yang dihapus sebagai operasi mandiri, atau untuk menerapkan replikasi data dan pemulihan bencana di lapisan penyimpanan.

Bagaimana cara mengecualikan volume persisten tertentu dari pencadangan dan pemulihan?

Beberapa volume, seperti penyimpanan log atau penyimpanan ketersediaan tinggi (OSS), tidak perlu dicadangkan. Berikut adalah alur kerja untuk mencadangkan namespace yang berisi Volume A (tidak perlu dicadangkan) dan Volume B (perlu dicadangkan):

Alur pencadangan:

1. Gunakan perlindungan data untuk mencadangkan Volume B — ini mencadangkan YAML dan datanya.

2. Gunakan pencadangan aplikasi untuk memilih namespace dengan Backup Volume diatur ke Disable. Ini mencadangkan file YAML untuk Volume A dan Volume B tanpa menyalin data.

   Jika Anda tidak ingin Volume A dipulihkan di kluster target sama sekali, tambahkan pvc, pv ke Excluded Resources dalam konfigurasi lanjutan.

Alur pemulihan:

1. Pulihkan cadangan perlindungan data di kluster target. Ini memulihkan YAML dan data Volume B.

2. Pulihkan cadangan aplikasi di kluster target. Ini memulihkan YAML Volume A dan semua resource aplikasi lainnya. CSI kemudian membuat sumber penyimpanan baru atau menggunakan kembali yang ada berdasarkan kebijakan reclaim Volume A.

Setelah kedua pemulihan selesai, aplikasi, Volume A, dan Volume B (dengan datanya) semuanya berjalan di kluster target.

Apakah pusat cadangan mendukung enkripsi KMS untuk bucket OSS yang terkait?

Pusat cadangan mendukung enkripsi sisi server untuk bucket OSS. Aktifkan di konsol OSS. Lihat Server-side encryption.

Jika Anda menggunakan CMK yang dikelola KMS (BYOK) dengan ID CMK tertentu, berikan izin pusat cadangan untuk mengakses KMS:

1. Buat kebijakan izin kustom:

      {
        "Version": "1",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "kms:List*",
              "kms:DescribeKey",
              "kms:GenerateDataKey",
              "kms:Decrypt"
            ],
            "Resource": [
              "acs:kms:*:141661496593****:*"
            ]
          }
        ]
      }

   Ini memberikan akses ke semua kunci KMS di bawah Akun Alibaba Cloud. Untuk kontrol resource yang lebih granular, lihat Authorization information.

2. Lampirkan kebijakan:

   • Untuk kluster khusus ACK dan kluster terdaftar: lampirkan ke Pengguna RAM yang digunakan selama instalasi. Lihat Grant permissions to a RAM user.

   • Untuk kluster lain: lampirkan ke peran AliyunCSManagedBackupRestoreRole. Lihat Grant permissions to a RAM role.

Jika Anda menggunakan kunci KMS yang dikelola oleh OSS atau kunci yang sepenuhnya dikelola oleh OSS, tidak diperlukan izin tambahan.

Bagaimana cara mengubah gambar kontainer yang digunakan selama pemulihan?

Ubah alamat registri gambar:

Untuk penyebaran cloud hibrid atau migrasi dari on-premises ke cloud, gunakan bidang imageRegistryMapping untuk memetakan ulang alamat registri gambar. Misalnya, untuk mengubah docker.io/library/ menjadi registry.cn-beijing.aliyuncs.com/my-registry/:

docker.io/library/: registry.cn-beijing.aliyuncs.com/my-registry/

Ubah repositori atau versi gambar:

Buat ConfigMap di namespace csdr sebelum menjalankan pemulihan:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <configuration-name>
  namespace: csdr
  labels:
    velero.io/plugin-config: ""
    velero.io/change-image-name: RestoreItemAction
data:
  "case1": "app1:v1,app2:v2"
  # Change only the repository: "case1": "app1,app2"
  # Change only the version: "case1": "v1:v2"
  # Change a specific registry image: "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

Untuk beberapa perubahan, tambahkan case2, case3, dan seterusnya ke bidang data. Setelah membuat ConfigMap, jalankan pekerjaan pemulihan dengan bidang imageRegistryMapping dibiarkan kosong.

Perubahan ini berlaku untuk semua pekerjaan pemulihan di kluster. Gunakan pola spesifik (seperti membatasi ke registri tertentu) untuk menghindari perubahan yang tidak diinginkan. Hapus ConfigMap saat tidak lagi diperlukan.