Container Service for Kubernetes:FAQ tentang pusat cadangan

Mengapa konsol menampilkan "Komponen kerja tidak normal" atau "Gagal mengambil data saat ini"?

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

• Verifikasi bahwa kluster memiliki node. Pusat cadangan tidak dapat diterapkan di kluster yang tidak memiliki node.

• Jika kluster menggunakan FlexVolume, alihkan ke CSI (Container Storage Interface) 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 backup itu sendiri. Jika penghapusan gagal atau terganggu, beberapa resource mungkin tetap ada di kluster dengan nama yang sama, sehingga menyebabkan kesalahan ini.

Jalankan perintah berikut untuk menghapus resource yang bertabrakan. Misalnya, jika kesalahannya 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 backup yang ada saat memulihkan lintas kluster?

Salah satu kemungkinan penyebabnya adalah penyimpanan cadangan belum diinisialisasi di kluster target. Di halaman Create Restoration Task, temukan Backup Vaults dan klik Initialize Backup Vault. Setelah inisialisasi selesai, pilih backup 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, konfirmasi di konsol kluster sumber bahwa pekerjaan backup menunjukkan status Completed. Pekerjaan backup 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 1.8.0, logika autentikasi resource 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 Otorisasi.

• 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 backup 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 Batasi operasi resource di kluster menggunakan RBAC kustom.

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, meninggalkan pekerjaan dalam status InProgress. Bidang finalizers pada pekerjaan ini menghalangi penghapusan resource.

Jalankan perintah berikut untuk mengidentifikasi apa yang menghalangi namespace:

kubectl describe ns csdr

Konfirmasi bahwa pekerjaan yang terjebak tidak lagi diperlukan dan hapus finalizers-nya. Setelah namespace csdr dihapus:

• Untuk peningkatan, instal ulang komponen migrate-controller.

• Untuk uninstall, komponen 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 kesalahannya adalah HBR backup/restore internal error, periksa konsol Cloud Backup untuk memverifikasi bahwa fitur backup kontainer tersedia di wilayah Anda.

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

Selama konversi StorageClass atau pemulihan, pusat cadangan membuat pod sementara, klaim volume persisten (PVC), dan volume persisten (PV). Jika resource ini tetap dalam status tidak tersedia terlalu lama, terjadi kesalahan timeout ini.

1. Identifikasi resource yang terjebak:

   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 Kontainer (CNFS) yang terkait dengan alibabacloud-cnfs-nas tidak normal. Lihat Metode 3: Gunakan sistem file NAS yang sudah ada.

• Kelas penyimpanan dengan volumeBindingMode: Immediate dipilih di kluster multi-zona.

Untuk panduan troubleshooting penyimpanan, lihat Troubleshoot masalah penyimpanan.

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 terjebak dalam InProgress?

Mengapa pekerjaan saya gagal dengan "VaultError: xxx"?

Kesalahan ini berarti penyimpanan cadangan tidak dapat mengakses bucket Object Storage Service (OSS). Lakukan pemeriksaan berikut secara berurutan.

1. Verifikasi keberadaan bucket OSS.

Masuk ke konsol OSS dan konfirmasi bahwa bucket yang terkait dengan penyimpanan cadangan ada. Jika tidak ada, buat bucket baru dan asosiasikan ulang. Lihat Buat bucket.

2. Verifikasi izin akses OSS.

Langkah yang diperlukan bergantung pada jenis kluster Anda:

• Kluster ACK Pro: Tidak diperlukan konfigurasi izin OSS jika nama bucket OSS diawali dengan cnfs-oss-.

• Kluster khusus ACK dan kluster terdaftar: Konfigurasikan izin OSS seperti yang dijelaskan di Instal migrate-controller dan konfigurasikan izin.

• Kluster ACK yang dikelola: Jika 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 outputnya cocok, izin sudah diberikan. Jika tidak, berikan izin dengan salah satu metode berikut:

  • Ikuti petunjuk untuk kluster khusus ACK dan kluster terdaftar. Lihat Instal migrate-controller dan konfigurasikan izin.

  • Klik Otorisasi untuk mengotorisasi akun Alibaba Cloud Anda. Anda hanya perlu melakukannya 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 Aktifkan akses Internet untuk kluster ACK yang sudah ada.

Penyimpanan cadangan harus menggunakan akses jaringan publik dalam skenario berikut:

• Kluster dan bucket OSS berada di wilayah 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 belum dikonfigurasi. Dalam kasus ini, konfigurasikan rute ke blok CIDR OSS internal wilayah tersebut.

  • Untuk informasi tentang menghubungkan pusat data lokal ke VPC, lihat Gabungkan beberapa metode koneksi untuk membangun cloud hibrida kelas enterprise.

  • Untuk pemetaan antara titik akhir internal OSS dan blok CIDR VIP, lihat Akses OSS melalui titik akhir dan domain bucket.

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"?

Layanan Cloud Backup belum diaktifkan atau tidak memiliki izin yang diperlukan.

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

2. Untuk kluster di China (Ulanqab), China (Heyuan), atau China (Guangzhou), otorisasi juga Cloud Backup untuk mengakses API Gateway setelah aktivasi. Lihat (Opsional) Langkah 3: Berikan izin Cloud Backup untuk menggunakan API Gateway.

3. Untuk kluster khusus ACK dan kluster terdaftar, verifikasi bahwa izin RAM Cloud Backup (Resource Access Management) telah diberikan. Lihat Instal migrate-controller dan konfigurasikan izin.

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 backup di suatu wilayah, pusat cadangan secara otomatis membuat repository ack-backup-data untuk menyimpan backup. Jika repository ini dihapus, pekerjaan selanjutnya akan gagal dengan kesalahan ini.

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

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

2. Kembali ke kluster dan buat backup 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 (Opsional) Langkah 3: Berikan izin API Gateway kepada Cloud Backup untuk memberikan izin yang diperlukan.

3. Untuk kesalahan SDK lainnya, gunakan kode kesalahan EC untuk troubleshooting. Lihat Troubleshooting mandiri menggunakan kode kesalahan.

Mengapa pekerjaan saya terjebak dalam InProgress?

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

kubectl get volumesnapshot -n <backup-namespace>

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

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

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

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

Hal ini biasanya terjadi pada pekerjaan backup terjadwal. Pemilihan namespace tidak valid:

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

• Jika Anda memilih Exclude, kluster tidak memiliki namespace selain namespace yang dikecualikan.

Perbarui rencana backup untuk memperbaiki pemilihan namespace.

Mengapa backup 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 backup di kelas penyimpanan Archive, konfigurasikan aturan siklus hidup untuk mengonversi kelas penyimpanan secara otomatis, dan cairkan data yang diarsipkan sebelum operasi pemulihan. Lihat Konversi kelas penyimpanan.

Timeout subtugas: Timeout default untuk subtugas backup 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

Mulai ulang controller agar perubahan berlaku:

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

Mengapa backup 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 jenis volume Kubernetes standar (seperti NFS atau LocalVolume), kirim tiket untuk bantuan.

Volume mode blok: Cloud Backup tidak mendukung volume yang VolumeMode-nya Block. Jika kluster Anda menggunakan CSI, snapshot disk digunakan untuk backup data secara default, dan snapshot disk mendukung volume mode Blok. Jika jenis plug-in penyimpanan salah, alihkan ke CSI, instal ulang komponen backup, dan jalankan backup 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. Pilih Job Name dari daftar drop-down di depan kotak pencarian, lalu cari <backup-name>-hbr untuk melihat status pekerjaan dan alasan kegagalannya. Lihat Backup kluster ACK.

Untuk mencari pekerjaan konversi StorageClass atau backup, cari dengan nama backup.

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

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

Pusat cadangan menggunakan path mount volume Kubernetes standar sebagai path backup 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 tersebut.

Masuk ke node tempat volume dipasang dan lakukan troubleshooting:

1. Temukan path root kubelet:

   ps -elf | grep kubelet

   Interpretasikan output sebagai berikut:

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

   • Jika perintah startup mencakup --config, periksa file konfigurasi untuk field root-dir.

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

   • Jika tidak ditemukan, path root kubelet adalah default /var/lib/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. Konfirmasi bahwa 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 backup tidak dapat membaca data dari path node secara default. Kirim tiket untuk bantuan.

Mengapa backup 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 kesalahan selama operasi file pada bucket penyimpanan cadangan. Tiga kemungkinan penyebab:

Izin KMS tidak ada: Jika Anda mengaktifkan enkripsi sisi server dengan kunci master pelanggan (CMK) Key Management Service (KMS) pada bucket OSS, pusat cadangan memerlukan izin tambahan. Lihat Apakah pusat cadangan mendukung enkripsi KMS untuk bucket OSS yang terasosiasi?.

Izin OSS tidak lengkap: Untuk kluster khusus ACK dan kluster terdaftar, periksa kebijakan izin pengguna RAM yang digunakan selama instalasi komponen. Lihat Langkah 1: Konfigurasikan izin.

Kredensial autentikasi dicabut: Untuk kluster khusus ACK dan kluster terdaftar, konfirmasi bahwa kredensial autentikasi pengguna RAM masih berlaku. Jika telah dicabut, dapatkan kredensial baru, perbarui Secret alibaba-addon-secret di namespace csdr, dan mulai ulang komponen:

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

Mengapa backup 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 backup 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 backup, menyebabkan kegagalan konsistensi.

Untuk menyelidiki, buka tab Backup Jobs di konsol Cloud Backup, pilih wilayah yang benar, pilih Job Name dari daftar drop-down di depan kotak pencarian, dan cari <backup-name>-hbr. Tinjau status pekerjaan dan alasan kegagalannya. Lihat Backup kluster ACK.

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

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

1. Atur ulang 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 jenis volume disk dan NAS CSI Alibaba Cloud sebagai target. Untuk kebutuhan lainnya, kirim 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 Gunakan volume yang disediakan secara statis ossfs 1.0.

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 Immediate, CSI membuat PV di zona tetap. Pod tidak dapat dijadwalkan ke zona berbeda, sehingga tetap dalam status Pending.

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

2. Pilih kelas penyimpanan yang benar:

   • Konsol: Pilih alicloud-disk, yang secara default menggunakan kelas penyimpanan alicloud-disk-topology-alltype.

   • Baris perintah: Gunakan alicloud-disk-topology-alltype. Atau, atur 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 ReadWriteMany atau ReadOnlyMany. Saat memulihkan ke penyimpanan disk Alibaba Cloud (yang secara default tidak mendukung pemasangan ganda), CSI memvalidasi konfigurasi AccessModes volume disk selama pemasangan dan memblokir pemasangan tersebut. Hal ini mencegah disk dipasang oleh node lain selama pemasangan, yang dapat menyebabkan disk dilepas paksa.

Hal ini terjadi dalam tiga skenario:

• Versi CSI lama atau FlexVolume di kluster backup: 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 backup 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. Memulihkan kelas penyimpanan secara otomatis dapat menyebabkan data tidak dapat diakses atau ditimpa. 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 Gunakan volume yang disediakan secara statis ossfs 1.0.

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

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

Untuk kluster khusus ACK dan kluster terdaftar yang terhubung ke Kubernetes yang dikelola sendiri yang di-deploy di instance ECS, berikan izin snapshot disk ECS. Lihat Kluster terdaftar.

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

Volume disk yang dipulihkan memiliki AccessMode ReadOnlyMany atau ReadWriteMany. CSI menerapkan 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 Gunakan CNFS untuk mengelola sistem file NAS (direkomendasikan).

• Jika PV disk yang dicadangkan tidak memenuhi persyaratan CSI saat ini (dicadangkan saat versi CSI lebih rendah dan deteksi AccessMode tidak diterapkan), 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 telah dipulihkan. Periksa setiap kemungkinan penyebab:

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

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 backup tidak dicadangkan secara default. Untuk konfigurasi backup tingkat kluster, lihat Backup tingkat kluster.

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

Subtugas 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 guna 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 lainnya, hubungi kami di grup DingTalk (ID: 35532895).

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.

Apakah saya dapat memodifikasi penyimpanan cadangan?

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

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

Apakah saya dapat 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. Untuk menghindari backup menimpa data yang sudah ada di bucket, buat bucket OSS khusus dengan nama dalam format cnfs-oss-* untuk pusat cadangan.

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

2. Mulai ulang komponen layanan backup:

   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 backup 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 backup saat membuat rencana backup?

Jadwal backup mendukung dua format:

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

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

Referensi format Cron:

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

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

Perubahan apa yang dilakukan pekerjaan pemulihan pada 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 jenis 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 Server Load Balancer (SLB) yang ada dari kluster backup, Layanan yang dipulihkan menggunakan instance SLB yang sama tetapi menonaktifkan pendengarnya. Konfigurasikan pendengar di konsol SLB.

  • Jika instance SLB dikelola oleh Cloud Controller Manager (CCM) di kluster backup, CCM membuat instance SLB baru. Lihat Pertimbangan untuk mengonfigurasi Layanan LoadBalancer.

Bagaimana cara melihat resource dalam backup?

Backup aplikasi kluster:

Jalankan di kluster yang memiliki file backup 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 > Operasi > Application Backup > Backup Records, lalu klik catatan backup.

Backup volume disk:

Di konsol ECS, buka Penyimpanan & Snapshot > Snapshot dan kueri snapshot berdasarkan ID disk.

Backup volume non-disk:

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

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

Apakah saya dapat 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 Deployments.

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 backup dan deploy secara manual saat Anda siap untuk beralih.

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 backup ditangani secara otomatis — Anda tidak perlu memigrasikan backup 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. Mencadangkan komponen sistem kube-system secara langsung ke kluster baru dapat menyebabkannya tidak berfungsi. 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 jenis 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 lainnya, Cloud Backup digunakan untuk backup 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 backup. Mulai 12 Oktober 2023 pukul 11.00, Alibaba Cloud tidak lagi membebankan biaya untuk penyimpanan atau operasi akses instans snapshot di wilayah mana pun. Lihat Gunakan fitur akses instans.

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

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 backup 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 yang 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 backup volume disk di kluster kemudian akan membuat snapshot dengan periode retensi yang ditetapkan di retentionDays.

Apa itu backup data volume, dan kapan saya membutuhkannya?

Fungsinya: Backup 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 independen — perubahan pada satu tidak memengaruhi yang lain.

Jika Anda tidak memerlukan salinan data atau sumber data bersama, Anda dapat melewati backup data volume. File YAML PVC dan PV tetap disertakan dalam backup aplikasi secara default. Pastikan resource PVC dan PV tidak ada dalam daftar pengecualian backup sehingga selama pemulihan, volume diterapkan ke kluster baru dari YAML aslinya.

Kapan menggunakannya:

• Diperlukan pemulihan bencana atau catatan data versi.

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

• Diperlukan backup dan pemulihan lintas wilayah (sebagian besar jenis penyimpanan selain OSS tidak mendukung akses lintas wilayah).

• Diperlukan isolasi data antara aplikasi asli dan yang dipulihkan.

• Plug-in atau versi penyimpanan antara kluster backup dan pemulihan berbeda signifikan, 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 backup sistem file dalam perlindungan data?

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

Tiga kebijakan penjadwalan node tersedia:

Untuk memberi label node:

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

# Sertakan node (untuk kebijakan include)
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  # Nilai valid: include, exclude, prefer
  pvBackup: |
    batch_snapshot_max_num: 20
    enable_ecs_snapshot: "true"
kind: ConfigMap

Mulai ulang controller agar perubahan berlaku:

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

Apa perbedaan antara backup aplikasi dan perlindungan data?

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

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

Perlindungan data 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 backup 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 backup) dan Volume B (perlu backup):

Alur backup:

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

2. Gunakan backup aplikasi untuk memilih namespace dengan Volume Backup 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 backup perlindungan data di kluster target. Ini memulihkan YAML dan data Volume B.

2. Pulihkan backup aplikasi di kluster target. Ini memulihkan YAML Volume A dan semua resource aplikasi lainnya. CSI kemudian membuat sumber penyimpanan baru atau menggunakan yang sudah 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 terasosiasi?

Pusat cadangan mendukung enkripsi sisi server untuk bucket OSS. Aktifkan di konsol OSS. Lihat Enkripsi sisi server.

Jika Anda menggunakan CMK yang dikelola KMS (bawa kunci sendiri, atau 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 Informasi otorisasi.

2. Lampirkan kebijakan:

   • Untuk kluster khusus ACK dan kluster terdaftar: lampirkan ke pengguna RAM yang digunakan selama instalasi. Lihat Berikan izin kepada pengguna RAM.

   • Untuk kluster lainnya: lampirkan ke peran AliyunCSManagedBackupRestoreRole. Lihat Berikan izin kepada peran RAM.

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 hibrida atau migrasi dari lokal ke cloud, gunakan field 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"
  # Ubah hanya repositori: "case1": "app1,app2"
  # Ubah hanya versi: "case1": "v1:v2"
  # Ubah gambar registri tertentu: "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

Untuk beberapa perubahan, tambahkan case2, case3, dan seterusnya ke field data. Setelah membuat ConfigMap, jalankan pekerjaan pemulihan dengan field 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.

Bagaimana cara menyesuaikan resource yang tersedia untuk sub-komponen di namespace csdr?

Konfigurasi resource default untuk csdr-controller adalah:

resources:
  limits:
    cpu: "1"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

Konfigurasi resource default untuk csdr-velero adalah:

resources:
  limits:
    cpu: "1"
    memory: 2Gi
  requests:
    cpu: 500m
    memory: 128Mi

Konfigurasi Deployment untuk csdr-controller dan csdr-velero, termasuk resource-nya, dikelola oleh komponen migrate-controller di namespace kube-system. Mengeditnya secara langsung akan diatur ulang. Untuk mengubah konfigurasi resource, tambahkan parameter berikut ke args container migrate-controller:

name: migrate-controller
args:
  - --velero-pod-cpu-limit=500m
  - --velero-pod-mem-limit=512Mi
  - --velero-pod-cpu-request=250m
  - --velero-pod-mem-request=256Mi
  - --csdr-pod-cpu-limit=500m
  - --csdr-pod-mem-limit=512Mi
  - --csdr-pod-cpu-request=250m
  - --csdr-pod-mem-request=256Mi

Setiap parameter bersifat opsional. Parameter yang dihilangkan mempertahankan nilai default-nya. Pastikan setiap limit lebih besar dari atau sama dengan request yang sesuai.

Di kluster besar, menurunkan velero-pod-mem-limit dapat menyebabkan csdr-velero kehabisan memori selama inisialisasi dan pemulihan. Pertimbangkan untuk mengonfigurasi parameter disable-informer-cache sebagai gantinya. Lihat Mengapa pekerjaan saya terjebak dalam InProgress?