Container Service for Kubernetes：FAQ Pusat Cadangan

Daftar isi

Operasi umum

Saat status pekerjaan backup, tugas konversi StorageClass, atau pekerjaan restore berada dalam status Failed atau PartiallyFailed, Anda dapat mengambil pesan kesalahan menggunakan metode berikut:

• Arahkan pointer ke Failed atau PartiallyFailed di kolom Status untuk melihat pesan kesalahan singkat, seperti RestoreError: snapshot cross region request failed.

• Untuk mengambil pesan kesalahan yang lebih detail, jalankan perintah berikut untuk mengkueri event tugas tersebut. Contoh pesan kesalahan: RestoreError: process advancedvolumesnapshot failed avs: snapshot-hz, err: transition canceled with error: the ECS-snapshot related ram policy is missing.

  • Pekerjaan Pencadangan

    kubectl -n csdr describe applicationbackup <backup-name> 

  • Tugas konversi StorageClass

    kubectl -n csdr describe converttosnapshot <backup-name>

  • Pekerjaan restore

    kubectl -n csdr describe applicationrestore <restore-name>

Konsol menampilkan "Komponen kerja tidak normal" atau "Gagal mengambil data saat ini"

Masalah

Konsol menampilkan kesalahan: The components are abnormal atau Failed to retrieve the data.

Penyebab

Komponen Pusat Cadangan tidak diinstal dengan benar.

Solusi

• Periksa apakah terdapat node di kluster. Pusat Cadangan tidak dapat diterapkan jika tidak ada node.

• Jika kluster menggunakan FlexVolume, Anda harus beralih ke CSI. Untuk informasi selengkapnya, lihat Komponen migrate-controller di kluster yang menggunakan FlexVolume tidak dapat diluncurkan.

• Jika Anda menggunakan Pusat Cadangan dengan kubectl, periksa apakah konfigurasi YAML sudah benar. Untuk informasi selengkapnya, lihat Gunakan kubectl untuk mencadangkan dan memulihkan aplikasi.

• Jika kluster Anda adalah kluster khusus ACK atau kluster terdaftar, periksa apakah izin yang diperlukan telah diberikan. Untuk informasi selengkapnya, lihat Kluster khusus ACK dan Kluster terdaftar.

• Periksa apakah aplikasi stateless csdr-controller dan csdr-velero di namespace csdr gagal diterapkan karena batasan resource atau penjadwalan. Jika iya, selesaikan masalah tersebut.

Konsol menampilkan kesalahan berikut: Nama telah digunakan. Ubah nama dan coba lagi

Masalah

Konsol menampilkan kesalahan The name has been used. Change the name and try again jika Anda menentukan nama duplikat saat membuat atau menghapus backup, konversi StorageClass, atau pekerjaan restore.

Penyebab

Saat Anda menghapus tugas melalui konsol, sumber daya deleterequest dibuat di kluster. Komponen tersebut kemudian menjalankan serangkaian operasi penghapusan yang tidak hanya mencakup penghapusan sumber daya cadangan terkait. Prosedur yang sama juga berlaku untuk operasi melalui baris perintah. Untuk informasi selengkapnya, lihat Menggunakan kubectl untuk mencadangkan dan memulihkan aplikasi.

Jika operasi penghapusan salah atau terjadi kesalahan saat resource deleterequest sedang diproses, beberapa resource di kluster mungkin tidak dihapus. Hal ini menyebabkan pesan kesalahan yang menunjukkan bahwa resource dengan nama yang sama sudah ada.

Solusi

• Hapus resource dengan nama yang sama seperti yang ditunjukkan dalam prompt. Misalnya, jika pesan kesalahan deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists dikembalikan, jalankan perintah berikut untuk menghapus resource tersebut:

  kubectl -n csdr delete deleterequests xxxxx-dbr

• Buat tugas dengan nama baru.

Saya tidak dapat memilih cadangan yang ada saat memulihkan aplikasi lintas kluster

Masalah

Saya tidak dapat memilih pekerjaan backup saat memulihkan aplikasi lintas kluster.

Penyebab

• Penyebab 1: Penyimpanan cadangan tidak dikaitkan dengan kluster saat ini. Artinya, penyimpanan cadangan belum diinisialisasi.

  Sistem menginisialisasi penyimpanan cadangan dan menyinkronkan informasi dasarnya, termasuk informasi bucket OSS, ke kluster. Kemudian, sistem menginisialisasi file backup dari penyimpanan cadangan di kluster. Anda hanya dapat memilih file backup untuk pemulihan setelah inisialisasi selesai.

• Penyebab 2: Inisialisasi penyimpanan cadangan gagal. Status resource backuplocation di kluster saat ini adalah Unavailable.

• Penyebab 3: Pekerjaan backup tidak lengkap atau gagal.

Solusi

• Solusi 1:

Pada halaman Restore, temukan Backup Vault dan klik Initialize Backup Vault. Setelah penyimpanan cadangan diinisialisasi, pilih pekerjaan untuk dipulihkan.

• Solusi 2:

Jalankan perintah berikut untuk memeriksa status resource backuplocation.

kubectl get -n csdr backuplocation <backuplocation-name> 

Output yang diharapkan:

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

Jika statusnya Unavailable, lihat solusi di Status tugas adalah Failed dan kesalahan "VaultError: xxx" dikembalikan.

Solusi 3:

Di konsol kluster backup, pastikan pekerjaan backup memiliki status Completed. Jika status backup bukan Completed, lakukan troubleshooting masalah tersebut. Untuk informasi selengkapnya, lihat index.

Konsol menampilkan "Peran layanan yang diperlukan oleh komponen saat ini belum diotorisasi"

Masalah

Saat Anda mengakses konsol backup aplikasi, konsol menampilkan pesan "Peran layanan yang diperlukan oleh komponen saat ini belum diotorisasi" dan mengembalikan kode kesalahan AddonRoleNotAuthorized.

Penyebab

Logika autentikasi resource cloud untuk komponen migrate-controller di kluster ACK yang dikelola dioptimalkan di migrate-controller 1.8.0. Saat Anda menginstal atau meningkatkan komponen ke versi ini untuk pertama kalinya, akun Alibaba Cloud harus menyelesaikan otorisasi resource cloud.

Solusi

• Jika Anda login dengan akun Alibaba Cloud, klik Authorize untuk menyelesaikan otorisasi.

• Jika Anda login sebagai pengguna RAM, klik Copy Authorization Link dan kirim tautan tersebut ke akun Alibaba Cloud untuk otorisasi.

Konsol menampilkan "Akun saat ini belum diberikan izin RBAC kluster yang diperlukan untuk operasi ini"

Masalah

Saat Anda mengakses konsol backup aplikasi, konsol menampilkan "Akun saat ini belum diberikan izin RBAC kluster yang diperlukan untuk operasi ini. Hubungi akun utama atau administrator izin untuk otorisasi." Kode kesalahan adalah APISERVER.403.

Penyebab

Konsol berinteraksi dengan server API untuk mengirimkan pekerjaan backup dan restore serta mengambil status pekerjaan secara real-time. Daftar izin default untuk insinyur O&M kluster dan pengembang tidak mencakup beberapa izin yang diperlukan oleh komponen Pusat Cadangan. Akun utama atau administrator izin perlu memberikan izin tersebut.

Solusi

Lihat Gunakan RBAC kustom untuk membatasi operasi pada resource kluster dan berikan izin ClusterRole berikut kepada operator Pusat Cadangan:

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

Komponen pusat cadangan gagal ditingkatkan atau di-uninstall

Masalah

Komponen Pusat Cadangan gagal ditingkatkan atau di-uninstall, dan namespace csdr tetap dalam status Terminating.

Penyebab

Komponen Pusat Cadangan keluar secara abnormal selama operasi, sehingga meninggalkan pekerjaan dalam status InProgress di namespace csdr. Field finalizers dari pekerjaan tersebut mungkin mencegah resource dihapus, yang menyebabkan namespace csdr tetap dalam status Terminating.

Solusi

• Jalankan perintah berikut untuk memeriksa mengapa namespace csdr berada dalam status Terminating:

  kubectl describe ns csdr

  Konfirmasi bahwa pekerjaan yang macet tidak lagi diperlukan dan hapus finalizers-nya.

• Setelah Anda memastikan bahwa namespace csdr dihapus:

  • Untuk peningkatan komponen, Anda dapat menginstal ulang komponen migrate-controller Pusat Cadangan.

  • Untuk uninstall komponen, komponen seharusnya sekarang telah di-uninstall.

Status tugas adalah Failed dan kesalahan "internal error" dikembalikan

Masalah

Status tugas adalah Failed dan kesalahan "internal error" dikembalikan.

Penyebab

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

Solusi

Jika pesan kesalahan adalah "HBR backup/restore internal error", buka konsol Cloud Backup untuk memeriksa apakah fitur backup kontainer tersedia.

Status tugas adalah Failed dan kesalahan "create cluster resources timeout" dikembalikan

Masalah

Status tugas adalah Failed dan kesalahan "create cluster resources timeout" dikembalikan.

Penyebab

Selama konversi StorageClass atau pemulihan, pod sementara, klaim volume persisten (PVC), dan volume persisten (PV) mungkin dibuat. Jika resource ini tetap tidak tersedia untuk waktu yang lama setelah pembuatan, kesalahan "create cluster resources timeout" dikembalikan.

Solusi

1. Jalankan perintah berikut untuk menemukan resource yang abnormal dan mengidentifikasi penyebabnya berdasarkan event-nya:

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

   Output yang diharapkan:

   ……wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out

   Ini menunjukkan bahwa PVC yang digunakan untuk konversi StorageClass tetap tidak terikat untuk waktu yang lama. PVC berada di namespace default dan bernama demo-pvc-for-convert202311151045.

2. Jalankan perintah berikut untuk memeriksa status PVC dan mengidentifikasi penyebab masalahnya:

   kubectl -ndefault describe pvc demo-pvc-for-convert202311151045 

   Berikut adalah penyebab umum masalah di Pusat Cadangan. Untuk informasi selengkapnya, lihat Troubleshoot masalah penyimpanan.

   • Resource kluster atau node tidak mencukupi atau abnormal.

   • Kluster restore tidak memiliki storage class yang diperlukan. Gunakan fitur konversi StorageClass untuk memilih storage class yang ada di kluster restore, lalu pulihkan aplikasi.

   • Penyimpanan yang mendasari yang terkait dengan storage class tidak tersedia. Misalnya, tipe disk yang ditentukan tidak didukung di zona saat ini.

   • Container Network File System (CNFS) yang terkait dengan alibabacloud-cnfs-nas abnormal. Untuk informasi selengkapnya, lihat Gunakan CNFS untuk mengelola sistem file NAS (direkomendasikan).

   • Anda memilih storage class yang volumeBindingMode-nya diatur ke Immediate saat memulihkan aplikasi di kluster multi-zona.

Status tugas adalah Failed dan kesalahan "addon status is abnormal" dikembalikan

Masalah

Status tugas adalah Failed dan kesalahan "addon status is abnormal" dikembalikan.

Penyebab

Komponen di namespace csdr abnormal.

Solusi

Lihat Penyebab 1 dan solusi: Komponen di namespace csdr abnormal.

Status tugas adalah Failed dan kesalahan "VaultError: xxx" dikembalikan

Masalah

Status tugas backup, restore, atau konversi StorageClass adalah Failed dan pesan kesalahan VaultError: backup vault is unavailable: xxx dikembalikan.

Penyebab

• Bucket OSS yang ditentukan tidak ada.

• Kluster tidak memiliki izin untuk mengakses OSS.

• Jaringan bucket OSS tidak dapat dijangkau.

Solusi

1. Login ke konsol OSS dan periksa apakah bucket OSS yang terkait dengan penyimpanan cadangan ada.

   Jika bucket OSS tidak ada, buat bucket dan asosiasikan ulang. Untuk informasi selengkapnya, lihat Buat bucket.

2. Periksa apakah kluster memiliki izin untuk mengakses OSS.

   • Untuk kluster ACK Pro, Anda tidak perlu mengonfigurasi izin OSS, asalkan nama bucket OSS yang terkait dengan penyimpanan cadangan kluster dimulai dengan cnfs-oss-**.

   • Untuk kluster khusus ACK atau kluster terdaftar, Anda harus mengonfigurasi izin OSS. Untuk informasi selengkapnya, lihat Instal migrate-controller dan berikan izin.

   Untuk kluster ACK yang dikelola di mana komponen diinstal atau ditingkatkan ke v1.8.0 atau lebih baru tanpa menggunakan konsol, izin terkait OSS mungkin hilang. Anda dapat menjalankan perintah berikut untuk memeriksa apakah kluster memiliki izin untuk mengakses OSS:

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

   Output yang diharapkan:

   addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

   Jika konten yang dikembalikan sama dengan output yang diharapkan di atas, kluster memiliki izin untuk mengakses OSS. Anda hanya perlu menentukan bucket OSS yang namanya dalam format cnfs-oss-* untuk kluster tersebut.

   Jika konten yang dikembalikan tidak sama dengan output yang diharapkan, gunakan salah satu metode berikut untuk memberikan izin:

   • Lihat petunjuk untuk kluster khusus ACK dan kluster terdaftar untuk mengonfigurasi izin OSS. Untuk informasi selengkapnya, lihat Instal komponen layanan backup dan konfigurasikan izin.

   • Klik Authorize untuk menyelesaikan otorisasi untuk akun Alibaba Cloud Anda. Anda hanya perlu melakukan operasi ini sekali untuk setiap akun Alibaba Cloud.

   Catatan

   Anda tidak dapat membuat penyimpanan cadangan dengan nama yang sama seperti yang dihapus. Anda juga tidak dapat mengaitkan penyimpanan cadangan dengan bucket OSS yang namanya tidak mengikuti format cnfs-oss-**. Jika Anda memiliki penyimpanan cadangan yang sudah ada yang dikaitkan dengan bucket OSS yang namanya salah, Anda harus membuat penyimpanan cadangan baru dengan nama berbeda dan mengaitkannya dengan bucket OSS yang mengikuti format cnfs-oss-**.

3. Jalankan perintah berikut untuk memeriksa konfigurasi jaringan kluster.

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

   Outputnya mirip dengan konten berikut:

   network: internal

   • Jika nilai network adalah internal, penyimpanan cadangan mengakses bucket OSS melalui jaringan internal.

   • Jika nilai network adalah public, penyimpanan cadangan mengakses bucket OSS melalui Internet. Jika penyimpanan cadangan mengakses bucket OSS melalui Internet dan pesan kesalahan menunjukkan timeout, periksa apakah kluster dapat mengakses Internet. Untuk informasi selengkapnya, lihat Aktifkan kluster ACK yang ada untuk mengakses Internet.

   Penyimpanan cadangan harus mengakses bucket OSS melalui jaringan publik dalam skenario berikut:

   • Kluster dan bucket OSS diterapkan di wilayah yang berbeda.

   • Kluster saat ini adalah kluster ACK Edge.

   • Kluster saat ini adalah kluster terdaftar yang tidak terhubung ke virtual private cloud (VPC) menggunakan Cloud Enterprise Network (CEN), Express Connect, atau VPN. Kemungkinan lain adalah kluster terhubung ke VPC, tetapi tidak ada rute yang dikonfigurasi ke blok CIDR OSS internal wilayah tersebut. Dalam kasus ini, Anda harus mengonfigurasi rute ke blok CIDR OSS internal.

     • Untuk informasi selengkapnya tentang cara menghubungkan pusat data lokal ke VPC, lihat Metode yang digunakan untuk menghubungkan pusat data ke Alibaba Cloud.

     • Untuk informasi selengkapnya tentang pemetaan antara endpoint OSS internal dan blok CIDR alamat IP virtual (VIP), lihat Akses OSS menggunakan nama domain bucket.

   Jika penyimpanan cadangan harus mengakses bucket OSS melalui jaringan publik, jalankan perintah berikut untuk mengubah metode akses ke akses jaringan publik. Dalam kode berikut, <backuplocation-name> menentukan nama penyimpanan cadangan dan <region-id> menentukan wilayah tempat bucket OSS diterapkan, seperti cn-hangzhou.

   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>"}}]'

Status tugas adalah Failed dan kesalahan "HBRError: check HBR vault error" dikembalikan

Gejala

Status tugas backup, restore, atau konversi StorageClass adalah Failed dan kesalahan "HBRError: check HBR vault error" dikembalikan.

Penyebab

Cloud Backup tidak diaktifkan atau kekurangan izin yang diperlukan.

Solusi

1. Konfirmasi bahwa Anda telah mengaktifkan layanan Cloud Backup. Untuk informasi selengkapnya, lihat Aktifkan Cloud Backup.

2. Jika Kluster Anda berada di Wilayah seperti Tiongkok (Ulanqab), Tiongkok (Heyuan), atau Tiongkok (Guangzhou), Anda juga harus mengotorisasi layanan Cloud Backup untuk mengakses API Gateway setelah Anda mengaktifkan layanan tersebut. Untuk informasi selengkapnya, lihat (Opsional) Langkah 3: Mengotorisasi layanan Cloud Backup untuk mengakses API Gateway.

3. Jika Kluster Anda adalah Kluster ACK Dedicated atau Kluster terdaftar, pastikan izin RAM Cloud Backup yang relevan diberikan. Untuk informasi selengkapnya, lihat Instal komponen layanan backup migrate-controller dan konfigurasikan izin.

Status tugas adalah Failed dan kesalahan "HBRError: ... code: 400, Illegal request. Please modify the parameters" dikembalikan

Masalah

Status tugas backup, restore, atau konversi StorageClass adalah Failed dan kesalahan "HBRError: ... code: 400, Illegal request. Please modify the parameters" dikembalikan.

Penyebab

Repository ack-backup-data layanan Cloud Backup di wilayah tempat kluster tugas yang gagal berada telah dihapus.

Saat Anda menggunakan Pusat Cadangan untuk membuat backup di wilayah untuk pertama kalinya, komponen secara otomatis membuat repository bernama ack-backup-data di wilayah tersebut untuk menyimpan backup yang dibuat oleh Pusat Cadangan. Backup tersebut secara otomatis dihapus setelah periode validitas yang ditentukan berakhir.

Solusi

1. Di semua kluster yang menggunakan Pusat Cadangan di wilayah saat ini, jalankan perintah berikut untuk menghapus catatan penyimpanan cadangan yang diinisialisasi.

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

2. Kembali ke kluster yang ingin Anda backup dan buat backup. Komponen secara otomatis membuat repository layanan Cloud Backup ack-backup-data dan mengaitkannya dengan penyimpanan cadangan.

Status tugas adalah Failed dan kesalahan "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist" dikembalikan

Masalah

Status tugas backup, restore, atau konversi StorageClass adalah Failed dan pesan kesalahan hbr task finished with unexpected status: FAILED, errMsg ClientNotExist dikembalikan.

Penyebab

Klien Cloud Backup diterapkan secara abnormal pada node yang sesuai. Artinya, replika DaemonSet hbr-client di namespace csdr pada node tersebut abnormal.

Solusi

1. Jalankan perintah berikut untuk memeriksa apakah terdapat pod hbr-client yang abnormal di kluster:

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

2. Jika pod berada dalam status abnormal, pertama-tama periksa apakah masalah disebabkan oleh alamat IP pod, memori, atau resource CPU yang tidak mencukupi. Jika status pod adalah CrashLoopBackOff, jalankan perintah berikut untuk melihat log pod tersebut:

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

   Jika keluaran berisi "SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge doesn't exist, please create this role. ", lihat (Opsional) Langkah 3: Memberi otorisasi Cloud Backup untuk mengakses Gerbang API untuk memberikan izin ke Cloud Backup.

3. Jika output log berisi jenis kesalahan SDK lainnya, Anda dapat melakukan troubleshooting menggunakan kode kesalahan EC (Error

   Code). Untuk informasi selengkapnya, lihat Troubleshoot masalah menggunakan kode kesalahan EC.

Tugas tetap dalam status InProgress untuk periode waktu yang lama

Penyebab 1 dan solusi: Komponen di namespace csdr abnormal

Periksa status komponen dan identifikasi penyebab abnormalitasnya.

1. Jalankan perintah berikut untuk memeriksa apakah komponen di namespace csdr sedang restart atau tidak dapat dimulai:

   kubectl get pod -n csdr

2. Jalankan perintah berikut untuk memeriksa mengapa komponen sedang restart atau tidak dapat dimulai:

   kubectl describe pod <pod-name> -n csdr

Penyebab 2 dan solusi: Izin snapshot kluster tidak dikonfigurasi untuk backup volume disk

Saat Anda menggunakan fitur backup data untuk aplikasi yang memiliki volume disk yang dipasang, jika pekerjaan backup tetap dalam status InProgress untuk waktu yang lama, jalankan perintah berikut untuk mengkueri resource VolumeSnapshot yang baru dibuat di kluster:

kubectl get volumesnapshot -n <backup-namespace>

Contoh output:

NAME                    READYTOUSE      SOURCEPVC         SOURCESNAPSHOTCONTENT         ...
<volumesnapshot-name>   true                              <volumesnapshotcontent-name>  ...

Jika field READYTOUSE dari semua resource volumesnapshot tetap false untuk waktu yang lama, lakukan langkah-langkah berikut:

1. Login ke konsol ECS dan periksa apakah fitur snapshot disk diaktifkan.

   • Jika fitur snapshot disk belum diaktifkan, aktifkan di wilayah yang sesuai. Untuk informasi selengkapnya, lihat Aktifkan Snapshot.

   • Jika fitur snapshot disk sudah diaktifkan, lanjutkan ke langkah berikutnya.

2. Periksa apakah komponen CSI kluster berjalan sebagaimana mestinya.

   kubectl -nkube-system get pod -l app=csi-provisioner

3. Periksa apakah izin untuk menggunakan snapshot disk telah dikonfigurasi.

   Kluster yang dikelola

   1. Login ke konsol RAM sebagai pengguna RAM yang memiliki hak administratif.

   2. Di panel navigasi sebelah kiri, pilih Identities > Roles.

   3. Di halaman Roles, cari AliyunCSManagedBackupRestoreRole di kotak pencarian dan verifikasi bahwa kebijakan otorisasi peran tersebut mencakup konten berikut:

      {
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "hbr:CreateVault",
              "hbr:CreateBackupJob",
              "hbr:DescribeVaults",
              "hbr:DescribeBackupJobs2",
              "hbr:DescribeRestoreJobs",
              "hbr:SearchHistoricalSnapshots",
              "hbr:CreateRestoreJob",
              "hbr:AddContainerCluster",
              "hbr:DescribeContainerCluster",
              "hbr:CancelBackupJob",
              "hbr:CancelRestoreJob",
              "hbr:DescribeRestoreJobs2"
            ],
            "Resource": "*"
          },
          {
            "Effect": "Allow",
            "Action": [
              "ecs:CreateSnapshot",
              "ecs:DeleteSnapshot",
              "ecs:DescribeSnapshotGroups",
              "ecs:CreateAutoSnapshotPolicy",
              "ecs:ApplyAutoSnapshotPolicy",
              "ecs:CancelAutoSnapshotPolicy",
              "ecs:DeleteAutoSnapshotPolicy",
              "ecs:DescribeAutoSnapshotPolicyEX",
              "ecs:ModifyAutoSnapshotPolicyEx",
              "ecs:DescribeSnapshots",
              "ecs:DescribeInstances",
              "ecs:CopySnapshot",
              "ecs:CreateSnapshotGroup",
              "ecs:DeleteSnapshotGroup"
            ],
            "Resource": "*"
          },
          {
            "Effect": "Allow",
            "Action": [
              "oss:PutObject",
              "oss:GetObject",
              "oss:DeleteObject",
              "oss:GetBucket",
              "oss:ListObjects",
              "oss:ListBuckets",
              "oss:GetBucketStat"
            ],
            "Resource": "acs:oss:*:*:cnfs-oss*"
          }
        ],
        "Version": "1"
      }

      • Jika peran AliyunCSManagedBackupRestoreRole hilang, buka halaman Otorisasi Cepat RAM untuk memberikan peran AliyunCSManagedBackupRestoreRole.

      • Jika peran AliyunCSManagedBackupRestoreRole ada tetapi konten kebijakannya tidak lengkap, berikan izin di atas kepada peran tersebut. Untuk informasi selengkapnya, lihat Buat kebijakan kustom dan Berikan izin kepada peran RAM.

   Kluster khusus

   1. Login ke konsol Container Service for Kubernetes (ACK). Di panel navigasi kiri, klik Clusters.

   2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Cluster Information.

   3. Di halaman Cluster Information, temukan parameter Master RAM Role dan klik tautan di sebelah kanan.

   4. Di tab Permission Management, Anda dapat memeriksa status izin snapshot disk.

      Jika kebijakan izin k8sMasterRolePolicy-Csi-*** tidak ada atau tidak mencakup izin berikut, berikan kebijakan izin snapshot disk berikut kepada Peran RAM Master. Untuk informasi selengkapnya, lihat Buat kebijakan izin kustom dan Berikan izin kepada peran RAM.

      {
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "hbr:CreateVault",
              "hbr:CreateBackupJob",
              "hbr:DescribeVaults",
              "hbr:DescribeBackupJobs2",
              "hbr:DescribeRestoreJobs",
              "hbr:SearchHistoricalSnapshots",
              "hbr:CreateRestoreJob",
              "hbr:AddContainerCluster",
              "hbr:DescribeContainerCluster",
              "hbr:CancelBackupJob",
              "hbr:CancelRestoreJob",
              "hbr:DescribeRestoreJobs2"
            ],
            "Resource": "*"
          },
          {
            "Effect": "Allow",
            "Action": [
              "ecs:CreateSnapshot",
              "ecs:DeleteSnapshot",
              "ecs:DescribeSnapshotGroups",
              "ecs:CreateAutoSnapshotPolicy",
              "ecs:ApplyAutoSnapshotPolicy",
              "ecs:CancelAutoSnapshotPolicy",
              "ecs:DeleteAutoSnapshotPolicy",
              "ecs:DescribeAutoSnapshotPolicyEX",
              "ecs:ModifyAutoSnapshotPolicyEx",
              "ecs:DescribeSnapshots",
              "ecs:DescribeInstances",
              "ecs:CopySnapshot",
              "ecs:CreateSnapshotGroup",
              "ecs:DeleteSnapshotGroup"
            ],
            "Resource": "*"
          },
          {
            "Effect": "Allow",
            "Action": [
              "oss:PutObject",
              "oss:GetObject",
              "oss:DeleteObject",
              "oss:GetBucket",
              "oss:ListObjects",
              "oss:ListBuckets",
              "oss:GetBucketStat"
            ],
            "Resource": "acs:oss:*:*:cnfs-oss*"
          }
        ],
        "Version": "1"
      }

   Kluster terdaftar

   Hanya kluster terdaftar yang nodenya semuanya merupakan instance Elastic Compute Service (ECS) Alibaba Cloud yang dapat menggunakan fitur snapshot disk. Periksa apakah izin terkait telah diberikan saat Anda menginstal plug-in penyimpanan CSI. Untuk informasi selengkapnya, lihat Konfigurasikan izin RAM untuk komponen CSI.

Penyebab 3 dan solusi: Menggunakan volume penyimpanan selain volume disk

Komponen migrate-controller Pusat Cadangan mendukung pemulihan lintas wilayah untuk backup volume disk di versi 1.7.7 dan yang lebih baru. Backup jenis volume lain tidak dapat dipulihkan lintas wilayah. Jika Anda menggunakan layanan penyimpanan yang mendukung akses Internet, seperti OSS, Anda dapat membuat PV dan PVC yang diprovisi secara statis lalu memulihkan aplikasi. Untuk informasi selengkapnya, lihat Gunakan volume yang diprovisi secara statis ossfs 1.0.

Status tugas backup adalah Failed dan kesalahan "backup already exists in OSS bucket" dikembalikan

Masalah

Status pekerjaan backup adalah Failed dan kesalahan "backup already exists in OSS bucket" dikembalikan.

Penyebab

Backup dengan nama yang sama disimpan di bucket OSS yang terkait dengan penyimpanan cadangan.

Backup mungkin tidak terlihat di kluster saat ini karena alasan berikut:

• Backup dalam pekerjaan backup yang sedang berlangsung dan pekerjaan backup yang gagal tidak disinkronkan ke kluster lain.

• Jika Anda menghapus backup di kluster selain kluster backup sumber, file backup di bucket OSS diberi label tetapi tidak dihapus. File backup yang diberi label ini tidak disinkronkan ke kluster yang baru dikaitkan.

• Kluster saat ini tidak dikaitkan dengan penyimpanan cadangan yang menyimpan backup tersebut. Artinya, penyimpanan cadangan belum diinisialisasi.

Solusi

Buat penyimpanan cadangan dengan nama baru.

Status tugas backup adalah Failed dan kesalahan "get target namespace failed" dikembalikan

Masalah

Status pekerjaan backup adalah Failed dan kesalahan "get target namespace failed" dikembalikan.

Penyebab

Dalam kebanyakan kasus, kesalahan ini terjadi pada pekerjaan backup yang dibuat pada waktu terjadwal. Penyebabnya bervariasi tergantung pada cara Anda memilih namespace.

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

• Jika Anda memilih Exclude, namespace yang dipilih dikecualikan dari kluster.

Solusi

Modifikasi rencana backup untuk mengubah metode yang digunakan untuk memilih namespace dan ubah namespace yang telah Anda pilih.

Status tugas backup adalah Failed dan kesalahan "velero backup process timeout" dikembalikan

Masalah

Status pekerjaan backup adalah Failed dan kesalahan "velero backup process timeout" dikembalikan.

Penyebab

• Penyebab 1: Subtugas backup aplikasi melebihi waktu. Durasi subtugas bervariasi tergantung pada jumlah resource kluster dan latensi respons server API. Di migrate-controller 1.7.7 dan yang lebih baru, periode timeout default subtugas adalah 60 menit.

• Penyebab 2: Storage class bucket yang digunakan oleh penyimpanan cadangan adalah Archive, Cold Archive, atau Deep Cold Archive. Untuk memastikan konsistensi data selama proses backup, komponen Pusat Cadangan harus memperbarui file metadata di server OSS. Komponen Pusat Cadangan tidak dapat memperbarui file yang belum dipulihkan dari Archive Storage.

Solusi

• Solusi 1: Modifikasi konfigurasi global periode timeout subtugas di kluster backup.

  Jalankan perintah berikut untuk menambahkan item konfigurasi velero_timeout_minutes ke applicationBackup. Satuannya adalah menit.

  kubectl edit -n csdr cm csdr-config

  Sebagai contoh, blok kode berikut mengatur periode timeout menjadi 100 menit:

  apiVersion: v1
  data:
    applicationBackup: |
      ... #Detail tidak ditampilkan.
      velero_timeout_minutes: 100

  Setelah Anda memodifikasi periode timeout, jalankan perintah berikut untuk me-restart csdr-controller agar modifikasi berlaku:

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

• Solusi 2: Ubah storage class bucket yang digunakan oleh penyimpanan cadangan menjadi Standard.

  Jika Anda ingin menyimpan data backup di Archive Storage, Anda dapat mengonfigurasi aturan siklus hidup untuk secara otomatis mengonversi storage class. Anda harus memulihkan data sebelum dapat melakukan pemulihan. Untuk informasi selengkapnya, lihat Konversi storage class.

Status tugas backup adalah Failed dan kesalahan "HBR backup request failed" dikembalikan

Masalah

Status pekerjaan backup adalah Failed dan kesalahan "HBR backup request failed" dikembalikan.

Penyebab

• Penyebab 1: Plug-in penyimpanan yang digunakan oleh kluster tidak kompatibel.

• Penyebab 2: Cloud Backup tidak mendukung pencadangan volume yang volumeMode-nya adalah Block. Untuk informasi selengkapnya, lihat Volume Mode.

• Penyebab 3: Klien Cloud Backup abnormal, yang menyebabkan pekerjaan backup atau restore untuk volume sistem file, seperti volume OSS, NAS, CPFS, atau lokal, melebihi waktu atau gagal.

Solusi

• Solusi 1: Jika kluster Anda menggunakan plug-in penyimpanan CSI non-Alibaba Cloud, atau jika volume persisten (PV) bukan volume penyimpanan Kubernetes umum seperti NFS atau LocalVolume, dan Anda mengalami masalah kompatibilitas, silakan kirim tiket untuk bantuan.

• Solusi 2: Dalam kebanyakan kasus, hanya penyimpanan disk yang memerlukan volume dalam mode Block. Jika plug-in penyimpanan kluster Anda adalah CSI, snapshot disk digunakan untuk backup data secara default. Snapshot disk mendukung backup volume dalam mode Block. Jika tipe plug-in penyimpanan salah, alihkan plug-in penyimpanan ke CSI, instal ulang komponen backup, lalu lakukan backup lagi.

• Solusi 3: Lakukan langkah-langkah berikut:

  1. Login ke konsol Cloud Backup.

  2. Di panel navigasi kiri, pilih Backup > Container Backup. Di halaman Backup Kontainer, klik tab Backup Jobs.

  3. Di bilah navigasi atas, pilih wilayah.

  4. Di tab Backup Jobs, klik menu drop-down di sebelah kotak pencarian, pilih Job Name, lalu cari <backup-name>-hbr untuk melihat status pekerjaan backup dan alasan statusnya. Untuk informasi selengkapnya, lihat Backup kluster ACK.

     Catatan

     Jika Anda ingin mengkueri pekerjaan konversi StorageClass atau backup, cari nama backup yang sesuai.

Status tugas backup adalah Failed, dan kesalahan "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST" dikembalikan

Masalah

Status pekerjaan backup adalah Failed, dan kesalahan "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST" dikembalikan.

Penyebab

• Untuk CSI vendor cloud lain atau tipe penyimpanan yang dikelola sendiri seperti NFS dan Ceph:

  Dalam skenario cloud hibrida, Pusat Cadangan menggunakan path mount volume Kubernetes standar sebagai path backup data secara default. Misalnya, untuk driver penyimpanan CSI standar, path mount default adalah /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Hal yang sama berlaku untuk driver penyimpanan yang didukung resmi oleh Kubernetes, seperti NFS dan FlexVolume.

  Dalam kasus ini, /var/lib/kubelet adalah path root kubelet default. Jika Anda memodifikasi path ini di kluster Kubernetes Anda, Cloud Backup mungkin tidak dapat mengakses data yang perlu dicadangkan.

• Untuk tipe penyimpanan HostPath:

  Penyimpanan HostPath tidak membuat path mount di bawah path root kubelet. Sebaliknya, pod langsung memasang path node yang ditentukan. Secara default, komponen backup tidak dapat membaca data dari path node, yang menyebabkan backup gagal.

Solusi

• Untuk CSI vendor cloud lain atau tipe penyimpanan yang dikelola sendiri seperti NFS dan Ceph:

  Login ke node tempat volume dipasang dan lakukan langkah-langkah berikut untuk troubleshooting masalah:

  1. Periksa apakah path root kubelet node diubah

     1. Jalankan perintah berikut untuk mengkueri perintah startup kubelet

        ps -elf | grep kubelet

        Jika perintah startup berisi parameter --root-dir, nilai parameter ini adalah path root kubelet.

        Jika perintah startup berisi parameter --config, nilai parameter ini adalah file konfigurasi kubelet. Jika file tersebut berisi field root-dir, nilai field ini adalah path root kubelet.

     2. Jika perintah startup tidak berisi informasi path root, kueri konten file startup layanan kubelet /etc/systemd/system/kubelet.service. Jika file berisi field EnvironmentFile, seperti:

        EnvironmentFile=-/etc/kubernetes/kubelet

        File konfigurasi variabel lingkungan adalah /etc/kubernetes/kubelet. Kueri konten file konfigurasi. Jika file berisi konten berikut:

        ROOT_DIR="--root-dir=/xxx"

        Path root kubelet adalah /xxx.

     3. Jika Anda tidak dapat menemukan perubahan apa pun, path root kubelet adalah path default /var/lib/kubelet.

  2. Jalankan perintah berikut untuk memeriksa apakah path root kubelet adalah tautan simbolik ke path lain:

     ls -al <root-dir>

     Jika outputnya mirip dengan konten berikut:

     lrwxrwxrwx   1 root root   26 Dec  4 10:51 kubelet -> /var/lib/container/kubelet

     Path root sebenarnya adalah /var/lib/container/kubelet.

  3. Verifikasi bahwa data volume penyimpanan target ada di bawah path root.

     Pastikan bahwa path mount volume <root-dir>/pods/<pod-uid>/volumes ada dan subpath tipe volume penyimpanan target ada di bawah path tersebut, seperti kubernetes.io~csi atau kubernetes.io~nfs.

  4. Tambahkan variabel lingkungan KUBELET_ROOT_PATH = /var/lib/container/kubelet/pods ke aplikasi stateless csdr/csdr-controller. /var/lib/container/kubelet adalah path root kubelet sebenarnya yang Anda ambil dengan mengkueri konfigurasi dan tautan simbolik.

• Untuk tipe penyimpanan HostPath:

  Silakan kirim tiket.

Status tugas backup adalah Failed dan kesalahan "check backup files in OSS bucket failed" atau "upload backup files to OSS bucket failed" atau "download backup files from OSS bucket failed" dikembalikan

Masalah

Status pekerjaan backup adalah Failed dan kesalahan "upload backup files to OSS bucket failed" dikembalikan.

Penyebab

Server OSS mengembalikan kesalahan saat komponen memeriksa, mengunggah, atau mengunduh file backup di bucket OSS yang terkait dengan penyimpanan cadangan. Masalah ini mungkin timbul dari salah satu penyebab berikut:

• Penyebab 1: Enkripsi data diaktifkan untuk bucket OSS, tetapi izin KMS terkait tidak diberikan.

• Penyebab 2: Beberapa izin baca dan tulis hilang saat Anda menginstal komponen dan mengonfigurasi izin untuk kluster khusus ACK dan kluster terdaftar.

• Penyebab 3: Kredensial autentikasi pengguna RAM yang digunakan untuk mengonfigurasi izin untuk kluster khusus ACK dan kluster terdaftar dicabut.

Solusi

• Solusi 1: Lihat Apakah Pusat Cadangan mendukung enkripsi data untuk bucket OSS terkait? Bagaimana cara memberikan izin untuk menggunakan Key Management Service (KMS) untuk enkripsi sisi server?

• Solusi 2: Periksa kebijakan izin Pengguna RAM yang digunakan untuk mengonfigurasi izin. Untuk informasi selengkapnya tentang kebijakan izin yang diperlukan oleh komponen, lihat Langkah 1: Mengonfigurasi izin.

• Solusi 3: Konfirmasi apakah kredensial autentikasi pengguna RAM yang digunakan untuk mengonfigurasi izin diaktifkan. Jika telah dicabut, dapatkan kredensial autentikasi baru dan perbarui konten Secret alibaba-addon-secret di namespace csdr. Lalu, lakukan operasi berikut untuk me-restart komponen:

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

Status tugas backup adalah PartiallyFailed dan kesalahan "PROCESS velero partially completed" dikembalikan

Masalah

Status pekerjaan backup adalah PartiallyFailed dan kesalahan "PROCESS velero partially completed" dikembalikan.

Penyebab

Saat Anda menggunakan komponen velero untuk mencadangkan aplikasi, yaitu resource di kluster, komponen gagal mencadangkan beberapa resource tersebut.

Solusi

Jalankan perintah berikut untuk mengidentifikasi resource yang gagal dicadangkan dan penyebab kegagalannya:

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

Perbaiki masalah berdasarkan informasi di field Errors dan Warnings pada output.

Jika tidak ada penyebab langsung kegagalan yang ditampilkan, jalankan perintah berikut untuk mendapatkan log pengecualian terkait:

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

Status tugas backup adalah PartiallyFailed dan kesalahan "PROCESS hbr partially completed" dikembalikan

Masalah

Status pekerjaan backup adalah PartiallyFailed dan pesan kesalahan "PROCESS hbr partially completed" dikembalikan.

Penyebab

Saat Anda menggunakan Cloud Backup untuk mencadangkan volume sistem file, seperti volume OSS, NAS, CPFS, atau lokal, Cloud Backup gagal mencadangkan beberapa resource. Masalah ini mungkin timbul dari salah satu penyebab berikut:

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

• Penyebab 2: Cloud Backup tidak menjamin konsistensi data. Jika file dihapus selama backup, backup mungkin gagal.

Solusi

1. Login ke konsol Cloud Backup.

2. Di panel navigasi kiri, pilih Backup > Container Backup. Di halaman Backup Kontainer, klik tab Backup Jobs.

3. Di bilah navigasi atas, pilih wilayah.

4. Di tab Backup Jobs, klik menu drop-down di sebelah kotak pencarian, pilih Job Name, lalu cari <backup-name>-hbr untuk menentukan mengapa backup volume persisten gagal atau sebagian gagal. Untuk informasi selengkapnya, lihat Backup kluster ACK.

Status tugas konversi StorageClass adalah Failed dan kesalahan "storageclass xxx not exists" dikembalikan

Masalah

Status tugas konversi StorageClass adalah Failed dan kesalahan "storageclass xxx not exists" dikembalikan.

Penyebab

Storage class target yang Anda pilih untuk konversi StorageClass tidak ada di kluster saat ini.

Solusi

1. Jalankan perintah berikut untuk mengatur 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 storage class yang diinginkan di kluster saat ini.

3. Jalankan pekerjaan restore lagi dan konfigurasikan konversi StorageClass.

Status tugas konversi StorageClass adalah Failed dan kesalahan "only support convert to storageclass with CSI diskplugin or nasplugin provisioner" dikembalikan

Masalah

Status tugas konversi StorageClass adalah Failed dan pesan kesalahan "only support convert to storageclass with CSI diskplugin or nasplugin provisioner" dikembalikan.

Penyebab

Storage class target yang Anda pilih untuk konversi StorageClass bukan volume disk CSI Alibaba Cloud atau volume NAS.

Solusi

• Versi saat ini hanya mendukung pembuatan dan pemulihan snapshot secara default untuk tipe disk, NAS, dan OSS. Jika Anda memiliki persyaratan pemulihan lain, silakan hubungi dukungan dengan mengirim tiket.

• Jika Anda menggunakan layanan penyimpanan yang mendukung akses jaringan publik, seperti OSS, Anda dapat membuat PV dan PVC yang diprovisi secara statis lalu memulihkan aplikasi tanpa langkah konversi StorageClass. Untuk informasi selengkapnya, lihat Gunakan volume yang diprovisi secara statis ossfs 1.0.

Status tugas konversi StorageClass adalah Failed dan kesalahan "current cluster is multi-zoned" dikembalikan

Masalah

Status tugas konversi StorageClass adalah Failed dan kesalahan "current cluster is multi-zoned" dikembalikan.

Penyebab

Kluster saat ini adalah kluster multi-zona. Saat Anda mengonversi ke StorageClass tipe disk, volumeBindingMode dari StorageClass target adalah Immediate. Jika Anda menggunakan StorageClass jenis ini di kluster multi-zona, pod tidak dapat dijadwalkan ke node yang ditentukan dan tetap dalam status Pending setelah volume persisten dibuat. Untuk informasi selengkapnya tentang field volumeBindingMode, lihat StorageClass.

Solusi

1. Jalankan perintah berikut untuk mengatur 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. Jika Anda ingin mengonversi ke storage class disk:

   • Jika Anda menggunakan konsol, pilih alicloud-disk. Storage class default untuk alicloud-disk adalah alicloud-disk-topology-alltype.

   • Jika Anda menggunakan baris perintah, pilih tipe alicloud-disk-topology-alltype. alicloud-disk-topology-alltype adalah storage class default yang disediakan oleh plug-in penyimpanan CSI. Anda juga dapat mengatur volumeBindingMode ke WaitForFirstConsumer.

3. Jalankan pekerjaan restore lagi dan konfigurasikan konversi StorageClass.

Status tugas restore adalah Failed dan kesalahan "multi-node writing is only supported for block volume" dikembalikan

Masalah

Status pekerjaan restore atau konversi StorageClass adalah Failed dan pesan kesalahan "multi-node writing is only supported for block volume. For Kubernetes users, if unsure, use ReadWriteOnce access mode in PersistentVolumeClaim for disk volume" dikembalikan.

Penyebab

Untuk mencegah risiko detasemen disk paksa saat disk dipasang ke node lain, CSI memeriksa konfigurasi AccessModes volume disk selama pemasangan dan melarang penggunaan ReadWriteMany atau ReadOnlyMany.

Aplikasi yang akan dicadangkan memasang volume yang AccessMode-nya adalah ReadWriteMany atau ReadOnlyMany. Hal ini umum untuk penyimpanan jaringan yang mendukung pemasangan ganda, seperti OSS atau NAS. Saat Anda memulihkan aplikasi ke penyimpanan disk Alibaba Cloud, yang secara default tidak mendukung pemasangan ganda, CSI mungkin mengembalikan kesalahan di atas.

Secara khusus, tiga skenario berikut dapat menyebabkan kesalahan ini:

Skenario 1: Versi CSI kluster backup lebih awal, atau kluster menggunakan plug-in penyimpanan FlexVolume. Versi CSI yang lebih awal tidak memeriksa field AccessModes volume disk Alibaba Cloud selama pemasangan. Hal ini menyebabkan volume disk asli melaporkan kesalahan saat dipulihkan di kluster dengan versi CSI yang lebih baru.

Skenario 2: Storage class kustom yang digunakan oleh volume backup tidak ada di kluster restore. Menurut aturan pencocokan tertentu, volume dipulihkan sebagai volume disk Alibaba Cloud secara default di kluster baru.

Skenario 3: Selama pemulihan, Anda menggunakan fitur konversi StorageClass untuk secara manual menentukan bahwa volume backup dipulihkan sebagai volume disk Alibaba Cloud.

Solusi

Skenario 1: Mulai dari v1.8.4, komponen backup mendukung konversi otomatis field AccessModes volume disk ke ReadWriteOnce. Tingkatkan komponen Pusat Cadangan lalu pulihkan aplikasi lagi.

Skenario 2: Pemulihan otomatis storage class oleh komponen di kluster tujuan dapat berisiko menyebabkan data tidak dapat diakses atau data tertimpa. Buat storage class dengan nama yang sama di kluster tujuan sebelum pemulihan, atau gunakan fitur konversi StorageClass untuk menentukan storage class yang akan digunakan selama pemulihan.

Skenario 3: Saat Anda memulihkan volume penyimpanan jaringan sebagai volume disk, konfigurasikan parameter convertToAccessModes untuk mengonversi AccessModes ke ReadWriteOnce. Untuk informasi selengkapnya, lihat convertToAccessModes: daftar AccessModes target.

Status tugas restore adalah Failed dan kesalahan "only disk type PVs support cross-region restore in current version" dikembalikan

Masalah

Status pekerjaan restore adalah Failed dan pesan kesalahan "only disk type PVs support cross-region restore in current version" dikembalikan.

Penyebab

Di migrate-controller 1.7.7 dan versi yang lebih baru, backup volume disk dapat dipulihkan lintas wilayah. Backup jenis volume lain tidak dapat dipulihkan lintas wilayah.

Solusi

• Jika Anda menggunakan layanan penyimpanan yang mendukung akses Internet, seperti OSS, Anda dapat membuat PV dan PVC yang diprovisi secara statis lalu memulihkan aplikasi. Untuk informasi selengkapnya, lihat Gunakan volume yang diprovisi secara statis ossfs 1.0.

Status tugas restore adalah Failed dan kesalahan "ECS snapshot cross region request failed" dikembalikan

Masalah

Status pekerjaan restore adalah Failed dan kesalahan "ECS snapshot cross region request failed" dikembalikan.

Penyebab

Di migrate-controller 1.7.7 dan versi yang lebih baru, backup volume disk dapat dipulihkan lintas wilayah, tetapi izin untuk menggunakan snapshot disk ECS tidak diberikan.

Solusi

Jika kluster Anda adalah kluster khusus ACK atau kluster terdaftar yang terhubung ke kluster Kubernetes yang dikelola sendiri yang diterapkan pada instance ECS, Anda harus memberikan izin untuk menggunakan snapshot disk ECS. Untuk informasi selengkapnya, lihat Kluster terdaftar.

Status tugas restore adalah Failed dan kesalahan "accessMode of PVC xxx is xxx" dikembalikan

Masalah

Status pekerjaan restore adalah Failed dan kesalahan "accessMode of PVC xxx is xxx" dikembalikan.

Penyebab

AccessMode volume disk yang akan dipulihkan diatur ke ReadOnlyMany (multi-mount read-only) atau ReadWriteMany (multi-mount read-write).

Saat Anda memulihkan volume disk, volume baru dipasang menggunakan CSI. Perhatikan hal-hal berikut saat menggunakan versi CSI saat ini:

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

• Volume yang VolumeMode-nya diatur ke Filesystem (dipasang menggunakan sistem file seperti ext4 atau xfs) hanya dapat dipasang ke beberapa instance dalam mode read-only.

Untuk informasi selengkapnya tentang penyimpanan disk, lihat Gunakan volume disk yang diprovisi secara dinamis.

Solusi

• Jika Anda menggunakan fitur konversi StorageClass untuk mengonversi volume yang mendukung pemasangan ganda, seperti volume OSS atau NAS, ke volume disk, dan Anda ingin memastikan bahwa replika aplikasi yang berbeda dapat berbagi data pada volume secara normal, kami sarankan Anda membuat pekerjaan restore baru dan memilih alibabacloud-cnfs-nas sebagai tipe target untuk konversi StorageClass. Dengan cara ini, volume NAS yang dikelola oleh CNFS digunakan. Untuk informasi selengkapnya, lihat Gunakan CNFS untuk mengelola sistem file NAS (direkomendasikan).

• Jika versi CSI rendah saat Anda mencadangkan volume persisten disk (tanpa deteksi AccessMode) dan volume persisten yang dicadangkan sendiri tidak memenuhi persyaratan pembuatan CSI saat ini, Anda harus memprioritaskan penggunaan volume disk yang diprovisi secara dinamis untuk mengubah beban kerja asli Anda guna menghindari ancaman detasemen disk paksa saat penjadwalan ke node lain.

Status tugas restore adalah Completed tetapi beberapa resource tidak dibuat di kluster restore

Masalah

Status pekerjaan restore adalah Completed tetapi beberapa resource tidak dibuat di kluster restore.

Penyebab

• Penyebab 1: Resource tersebut tidak dicadangkan.

• Penyebab 2: Resource tersebut dikecualikan selama pemulihan berdasarkan konfigurasi.

• Penyebab 3: Subtugas pemulihan aplikasi sebagian gagal.

• Penyebab 4: Resource berhasil dipulihkan tetapi didaur ulang karena konfigurasi ownerReferences atau logika bisnis lainnya.

Solusi

Solusi 1:

Jalankan perintah berikut untuk melihat detail 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

Periksa apakah resource target dicadangkan. Jika resource target tidak dicadangkan, periksa apakah resource tersebut dikecualikan karena namespace, resource, atau konfigurasi lain yang ditentukan dalam pekerjaan backup. Lalu, cadangkan resource tersebut lagi. Secara default, resource tingkat kluster dari aplikasi yang berjalan (pod) di namespace yang tidak dipilih tidak dicadangkan. Jika Anda ingin mencadangkan semua resource tingkat kluster, lihat Backup tingkat kluster.

Solusi 2:

Jika resource target tidak dipulihkan, periksa apakah resource tersebut dikecualikan karena namespace, resource, atau konfigurasi lain yang ditentukan dalam pekerjaan restore, lalu pulihkan resource tersebut lagi.

Solusi 3:

Jalankan perintah berikut untuk mengidentifikasi resource yang gagal dipulihkan dan penyebab kegagalannya:

 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 sesuai dengan petunjuk di field Errors dan Warnings pada output.

Solusi 4:

Periksa log audit resource yang sesuai untuk menentukan apakah resource tersebut dihapus secara abnormal setelah dibuat.

Komponen migrate-controller di kluster yang menggunakan FlexVolume tidak dapat diluncurkan

Komponen migrate-controller tidak mendukung kluster yang menggunakan FlexVolume. Untuk menggunakan fitur Pusat Cadangan, gunakan salah satu metode berikut untuk migrasi dari FlexVolume ke CSI:

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

• Migrasi FlexVolume tanpa kluster penyimpanan ke CSI

• Migrasi volume NAS yang diprovisi secara statis dari Flexvolume ke CSI

• Migrasi volume OSS yang diprovisi secara statis dari FlexVolume ke CSI

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

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

Dapatkah saya memodifikasi penyimpanan cadangan?

Tidak, Anda tidak dapat memodifikasi penyimpanan cadangan. Untuk melakukan perubahan, Anda harus menghapus penyimpanan cadangan saat ini dan membuat yang baru dengan nama berbeda.

Karena penyimpanan cadangan adalah resource yang dibagikan, resource tersebut mungkin berada dalam status Backup atau Restore kapan saja. Jika Anda memodifikasi parameter vault, sistem mungkin tidak dapat menemukan data yang diperlukan selama backup atau restore aplikasi. Oleh karena itu, Anda tidak dapat memodifikasi penyimpanan cadangan atau membuat yang baru dengan nama yang sama.

Dapatkah saya mengaitkan penyimpanan cadangan dengan bucket OSS yang namanya bukan dalam format "cnfs-oss-*"?

Untuk kluster selain kluster khusus ACK dan kluster terdaftar, komponen Pusat Cadangan memiliki izin baca dan tulis pada bucket OSS yang namanya dalam format cnfs-oss-* secara default. Untuk mencegah backup menimpa data yang ada di bucket, kami sarankan Anda membuat bucket OSS khusus yang namanya dalam format cnfs-oss-* untuk Pusat Cadangan.

1. Jika Anda ingin mengaitkan penyimpanan cadangan dengan Bucket OSS yang namanya bukan dalam format "cnfs-oss-*", Anda harus mengonfigurasi izin untuk komponen tersebut. Untuk informasi selengkapnya, lihat Kluster khusus ACK.

2. Setelah Anda memberikan izin, jalankan perintah berikut untuk me-restart komponen layanan backup:

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

   Jika Anda telah membuat penyimpanan cadangan yang dikaitkan dengan bucket OSS yang namanya bukan dalam format "cnfs-oss-*", tunggu hingga pemeriksaan konektivitas selesai dan status berubah menjadi Available sebelum mencoba mencadangkan atau memulihkan aplikasi. Interval pemeriksaan konektivitas sekitar lima menit. Anda dapat menjalankan perintah berikut untuk mengkueri 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 siklus backup saat membuat rencana backup?

Siklus backup mendukung ekspresi Crontab, seperti 1 4 * * *, atau backup berbasis interval, seperti 6h30m, yang berarti backup dibuat setiap 6 jam 30 menit.

Berikut ini menjelaskan cara mengurai ekspresi Crontab. Nilai opsionalnya sama dengan ekspresi Crontab standar, kecuali nilai opsional untuk menit adalah 0 hingga 59. * menunjukkan nilai apa pun yang tersedia untuk field yang diberikan. Contoh ekspresi Crontab:

• 1 4 * * *: Buat backup pada pukul 04.01 setiap hari.

• 0 2 15 * 1: Buat backup pada pukul 02.00 pada tanggal 15 setiap bulan.

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

Perubahan apa saja yang dilakukan pada file YAML resource saat menjalankan pekerjaan restore?

Saat Anda memulihkan resource, perubahan berikut dilakukan pada file YAML resource:

Perubahan 1:

Jika ukuran volume disk kurang dari 20 GiB, ukuran volume diubah menjadi 20 GiB.

Perubahan 2:

Bagaimana cara melihat resource backup?

Resource dalam backup aplikasi kluster

File YAML di kluster disimpan di bucket OSS yang terkait dengan penyimpanan cadangan. Anda dapat menggunakan salah satu metode berikut untuk melihat resource backup:

• Jalankan perintah berikut di kluster tempat file backup disinkronkan untuk melihat resource backup:

  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

• Anda dapat melihat ini di konsol Container Service.

  1. Login ke konsol ACK. Di panel navigasi kiri, pilih Clusters.

  2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Operations > Application Backup.

  3. Di halaman Application Backup, klik tab Backup Records. Di kolom Backup Records, klik catatan backup.

Resource dalam backup volume disk

1. Login ke konsol ECS.

2. Di panel navigasi kiri, pilih Storage & Snapshots > Snapshots.

3. Di bilah navigasi atas, pilih wilayah dan kelompok sumber daya dari resource yang ingin Anda kelola.

4. Di halaman Snapshot, kueri snapshot berdasarkan ID disk.

Resource dalam backup volume non-disk

1. Login ke konsol Cloud Backup.

2. Di panel navigasi kiri, pilih Backup > Container Backup.

3. Di bilah navigasi atas, pilih wilayah.

4. Lihat informasi dasar backup kluster.

   • Clusters: Daftar kluster yang telah dicadangkan dan dilindungi. Klik ACK Cluster ID untuk melihat klaim volume persisten (PVC) yang dilindungi. Untuk informasi selengkapnya tentang PVC, lihat Klaim volume persisten (PVC).

     Jika Client Status abnormal, Cloud Backup tidak berjalan sebagaimana mestinya di kluster ACK. Buka halaman DaemonSets di konsol ACK untuk troubleshooting masalah.

   • Backup Jobs: Status pekerjaan backup.

     

Dapatkah saya mencadangkan aplikasi di kluster yang menjalankan versi Kubernetes lama dan memulihkan aplikasi di kluster yang menjalankan versi Kubernetes yang lebih baru?

Ya, ini didukung.

Secara default, saat Anda mencadangkan resource, semua versi API yang didukung oleh resource tersebut dicadangkan. Misalnya, deployment di kluster yang menjalankan Kubernetes 1.16 mendukung extensions/v1beta1, apps/v1beta1, apps/v1beta2, dan apps/v1. Saat Anda mencadangkan deployment tersebut, penyimpanan cadangan menyimpan keempat versi API tersebut terlepas dari versi yang Anda gunakan saat membuat deployment. Fitur KubernetesConvert digunakan untuk konversi versi API.

Saat Anda memulihkan resource, versi API yang direkomendasikan oleh kluster restore digunakan untuk pemulihan. Misalnya, jika Anda memulihkan deployment tersebut di kluster yang menjalankan Kubernetes 1.28 dan versi API yang direkomendasikan adalah apps/v1, deployment yang dipulihkan akan menggunakan apps/v1.

Apakah traffic secara otomatis dialihkan ke instance SLB selama pemulihan?

Tidak.

Secara default, setelah listener dinonaktifkan atau instance SLB baru digunakan, traffic tidak secara otomatis dialihkan ke instance SLB baru. Jika Anda menggunakan layanan cloud lain atau penemuan layanan pihak ketiga dan tidak ingin penemuan layanan otomatis mengalihkan traffic ke instance SLB baru, Anda dapat mengecualikan resource Service selama backup dan menerapkannya secara manual saat Anda perlu mengalihkan traffic.

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

• csdr adalah namespace Pusat Cadangan. Jika Anda langsung mencadangkan dan memulihkan namespace ini, komponen akan gagal berfungsi di kluster restore. Selain itu, Pusat Cadangan memiliki logika sinkronisasi backup, yang berarti Anda tidak perlu memigrasikan backup secara manual ke kluster baru.

• ack-csi-fuse adalah namespace komponen penyimpanan CSI dan digunakan untuk menjalankan pod klien FUSE yang dikelola oleh CSI. Saat Anda memulihkan penyimpanan di kluster baru, CSI kluster baru secara otomatis menyinkronkan ke klien yang sesuai. Anda tidak perlu mencadangkan dan memulihkan namespace ini secara manual.

• kube-system, kube-public, dan kube-node-lease adalah namespace sistem default kluster Kubernetes. Karena perbedaan parameter dan konfigurasi kluster, Anda tidak dapat memulihkan namespace ini lintas kluster. Selain itu, Pusat Cadangan digunakan untuk mencadangkan dan memulihkan aplikasi. Sebelum menjalankan pekerjaan restore, Anda harus menginstal dan mengonfigurasi komponen sistem di kluster restore, seperti:

  • Komponen pengambilan citra Container Registry tanpa kata sandi: Anda perlu memberikan izin dan mengonfigurasi acr-configuration di kluster restore.

  • Komponen ALB Ingress: Anda perlu mengonfigurasi ALBConfig.

  Jika Anda langsung mencadangkan komponen sistem di namespace kube-system ke kluster baru, komponen sistem mungkin gagal berjalan di kluster baru.

Apakah pusat cadangan menggunakan snapshot disk ECS untuk mencadangkan volume disk? Apa jenis snapshot defaultnya?

Dalam skenario berikut, Pusat Cadangan menggunakan snapshot disk ECS untuk mencadangkan volume disk secara default:

1. Kluster adalah kluster ACK yang dikelola atau kluster khusus ACK.

2. Kluster menjalankan Kubernetes 1.18 atau yang lebih baru dan menggunakan CSI 1.18 atau yang lebih baru.

Dalam skenario lain, Pusat Cadangan menggunakan Cloud Backup untuk mencadangkan data disk secara default.

Snapshot disk yang dibuat oleh Pusat Cadangan memiliki fitur akses instan yang diaktifkan secara default. Periode validitas snapshot disk sama dengan periode validitas yang ditentukan dalam konfigurasi backup secara default. Mulai 12 Oktober 2023 pukul 11.00, Alibaba Cloud tidak lagi membebankan biaya untuk penyimpanan akses instan snapshot atau operasi akses instan snapshot di semua wilayah. Untuk informasi selengkapnya, lihat Gunakan fitur akses instan.

Mengapa periode validitas snapshot disk ECS yang dibuat dari backup berbeda dengan periode validitas yang ditentukan dalam konfigurasi backup?

Pembuatan snapshot disk bergantung pada komponen csi-provisioner atau managed-csiprovisioner kluster. Jika versi komponen csi-provisioner lebih awal dari 1.20.6, Anda tidak dapat menentukan periode validitas atau mengaktifkan fitur akses instan snapshot saat membuat VolumeSnapshots. Dalam kasus ini, periode validitas dalam konfigurasi backup tidak memengaruhi snapshot disk.

Oleh karena itu, saat Anda menggunakan fitur backup data volume untuk volume disk, Anda harus meningkatkan komponen csi-provisioner ke versi 1.20.6 atau yang lebih baru.

Jika csi-provisioner tidak dapat ditingkatkan ke versi ini, Anda dapat mengonfigurasi periode validitas snapshot default dengan cara berikut:

1. Perbarui komponen Pusat Cadangan migrate-controller ke v1.7.10 atau yang lebih baru.

2. Jalankan perintah berikut untuk memeriksa apakah VolumeSnapshotClass dengan retentionDays 30 ada di kluster:

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

   • Jika VolumeSnapshotClass tidak ada, Anda dapat menggunakan YAML berikut untuk membuat VolumeSnapshotClass bernama csdr-disk-snapshot-with-default-ttl.

   • Jika VolumeSnapshotClass ada, atur parameter retentionDays dari VolumeSnapshotClass default csdr-disk-snapshot-with-default-ttl menjadi 30.

     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"

3. Setelah konfigurasi selesai, semua backup volume disk yang dibuat di kluster akan membuat snapshot disk dengan periode validitas yang sama dengan field retentionDays.

   Penting

   Jika Anda ingin periode validitas snapshot disk ECS yang dibuat dari backup sama dengan periode validitas yang ditentukan dalam konfigurasi backup, kami sarankan Anda meningkatkan komponen csi-provisioner ke versi 1.20.6 atau yang lebih baru.

Apa itu backup data volume, dan dalam skenario apa saya perlu mencadangkan volume saat mencadangkan aplikasi?

Apa itu backup data volume?

Data volume dicadangkan ke penyimpanan cloud menggunakan snapshot disk ECS atau layanan Cloud Backup. Saat Anda memulihkan aplikasi, data disimpan di disk baru atau sistem file NAS untuk digunakan oleh aplikasi yang dipulihkan. Aplikasi yang dipulihkan dan aplikasi asli tidak berbagi sumber data dan tidak saling memengaruhi.

Jika Anda tidak perlu menyalin data atau jika Anda memiliki persyaratan sumber data bersama, Anda dapat memilih untuk tidak mencadangkan data volume. Dalam kasus ini, pastikan bahwa daftar resource yang dikecualikan dalam backup tidak mencakup resource PVC atau PV. Selama pemulihan, volume diterapkan ke kluster baru berdasarkan file YAML aslinya.

Dalam skenario apa saya perlu mencadangkan volume?

• Pemulihan bencana dan catatan versi.

• Tipe penyimpanan adalah volume disk karena disk dasar hanya dapat dipasang ke satu node saja.

• Anda ingin menerapkan backup dan pemulihan lintas wilayah. Dalam kebanyakan kasus, tipe penyimpanan selain OSS tidak mendukung akses lintas wilayah.

• Anda ingin mengisolasi data antara aplikasi backup dan aplikasi yang dipulihkan.

• Plug-in penyimpanan atau versi kluster backup dan kluster restore sangat berbeda, dan file YAML tidak dapat dipulihkan secara langsung.

Apa risiko tidak mencadangkan volume untuk aplikasi berstatus?

Jika Anda tidak mencadangkan volume saat mencadangkan aplikasi berstatus, perilaku berikut terjadi selama pemulihan:

• Untuk volume yang kebijakan reclaim-nya adalah Delete:

  Mirip dengan saat Anda menerapkan PVC untuk pertama kalinya, jika kluster restore memiliki storage class yang sesuai, CSI secara otomatis membuat PV baru. Misalnya, untuk penyimpanan disk, disk kosong baru dipasang ke aplikasi yang dipulihkan. Untuk volume statis yang tidak memiliki storage class yang ditentukan atau jika kluster restore tidak memiliki storage class yang sesuai, PVC dan pod yang dipulihkan tetap dalam status Pending hingga Anda membuat PV atau storage class yang sesuai secara manual.

• Untuk volume yang kebijakan reclaim-nya adalah Retain:

  Selama pemulihan, resource dipulihkan dalam urutan PV terlebih dahulu lalu PVC berdasarkan file YAML aslinya. Untuk penyimpanan yang mendukung pemasangan ganda, seperti NAS dan OSS, sistem file atau bucket asli dapat langsung digunakan kembali. Untuk disk, mungkin ada risiko detasemen disk paksa.

Anda dapat menjalankan perintah berikut untuk mengkueri kebijakan reclaim volume:

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

Output yang diharapkan:

CLAIM               NAMESPACE           NAME                                       RECLAIMPOLICY
www-web-0           default             d-2ze53mvwvrt4o3xxxxxx                     Delete
essd-pvc-0          default             d-2ze5o2kq5yg4kdxxxxxx                     Delete
www-web-1           default             d-2ze7plpd4247c5xxxxxx                     Delete
pvc-oss             default             oss-e5923d5a-10c1-xxxx-xxxx-7fdf82xxxxxx   Retain

Bagaimana cara memilih node yang dapat digunakan untuk mencadangkan sistem file dalam perlindungan data?

Secara default, saat Anda mencadangkan volume penyimpanan selain volume disk Alibaba Cloud, Cloud Backup digunakan untuk backup dan pemulihan data. Dalam skenario ini, tugas Cloud Backup harus dieksekusi di node. Kebijakan penjadwalan default Scheduler ACK sama dengan scheduler Kubernetes komunitas. Anda juga dapat mengonfigurasi tugas agar hanya dijadwalkan ke node tertentu jika diperlukan.

Kebijakan penjadwalan node pusat cadangan

• kebijakan exclude (default): Secara default, semua node dapat digunakan untuk backup dan pemulihan. Jika Anda tidak ingin pekerjaan Cloud Backup dijadwalkan ke node tertentu, tambahkan label csdr.alibabacloud.com/agent-excluded="true" ke node tersebut.

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

• kebijakan include: Secara default, node tanpa label tidak dapat digunakan untuk backup dan pemulihan. Tambahkan label csdr.alibabacloud.com/agent-included="true" ke node yang diizinkan untuk mengeksekusi pekerjaan Cloud Backup.

  kubectl label node <node-name-1> <node-name-2>  csdr.alibabacloud.com/agent-included="true"

• kebijakan prefer: Secara default, semua node dapat digunakan untuk backup dan pemulihan. Prioritas penjadwalan sebagai berikut:

  1. Node dengan label csdr.alibabacloud.com/agent-included="true" memiliki prioritas tertinggi.

  2. Node tanpa label khusus memiliki prioritas kedua tertinggi.

  3. Dijadwalkan ke node yang memiliki label csdr.alibabacloud.com/agent-excluded="true".

Ubah kebijakan pemilihan node

1. Jalankan perintah berikut untuk mengedit ConfigMap csdr-config:

   kubectl -n csdr edit cm csdr-config

   Tambahkan konfigurasi node_schedule_policy ke konfigurasi applicationBackup. Contoh:

   Klik untuk melihat contoh lengkap

   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  # Tambahkan konfigurasi ini. Nilai yang valid: include, exclude, dan prefer.
     pvBackup: |
       batch_snapshot_max_num: 20
       enable_ecs_snapshot: "true"
   kind: ConfigMap

2. Jalankan perintah berikut untuk me-restart deployment csdr-controller agar konfigurasi berlaku:

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

Apa saja skenario untuk backup aplikasi dan perlindungan data?

Backup aplikasi:

• Anda ingin mencadangkan bisnis Anda di kluster, termasuk aplikasi, layanan, dan file konfigurasi.

• Opsi: Saat mencadangkan aplikasi, Anda juga ingin mencadangkan volume yang dipasang ke aplikasi tersebut.

  Catatan

  Fitur backup aplikasi tidak mencadangkan volume yang tidak dipasang ke pod.

  Jika Anda ingin mencadangkan aplikasi dan semua volume, Anda dapat membuat pekerjaan backup perlindungan data.

• Anda ingin migrasi aplikasi antar kluster dan memulihkan aplikasi dengan cepat untuk pemulihan bencana.

Perlindungan data:

• Anda ingin mencadangkan volume, termasuk hanya PVC dan PV.

• Anda ingin memulihkan PVC, yang independen dari data backup. Saat Anda menggunakan Pusat Cadangan untuk memulihkan PVC yang dihapus, disk baru dibuat dan data pada disk identik dengan data dalam file backup. Dalam kasus ini, parameter mount PVC baru tetap tidak berubah. PVC baru dapat langsung dipasang ke aplikasi.

• Anda ingin menerapkan replikasi data dan pemulihan bencana.

Bagaimana cara mengecualikan beberapa volume persisten dari backup dan pemulihan?

Di lingkungan produksi, data di beberapa volume, seperti data log, dianggap sekali pakai dan tidak perlu dipertahankan selama migrasi atau pemulihan bencana.

Untuk beberapa sumber penyimpanan yang menyediakan fitur seperti penyimpanan massal, akses lintas zona atau lintas wilayah, dan pemulihan bencana multi-salinan, seperti OSS, Anda juga dapat mempertimbangkan untuk melewati backup dan pemulihan data untuk layanan prioritas rendah.

Asumsikan namespace bisnis yang akan dicadangkan berisi Volume A (data tidak perlu dicadangkan) dan Volume B (data perlu dicadangkan):

Alur backup

1. Gunakan fitur perlindungan data untuk memilih volume persisten B untuk backup. Fitur perlindungan data secara bersamaan mencadangkan file YAML dan data yang sesuai dari volume persisten B. Lihat Cadangkan dan pulihkan aplikasi di kluster.

   Catatan

   Mencadangkan data berarti menghasilkan sumber backup independen dari sumber data Volume B menggunakan snapshot atau Cloud Backup. Volume yang dipulihkan dari sumber backup memiliki konten yang sama dengan volume aslinya, tetapi keduanya adalah dua salinan terpisah dan tidak saling memengaruhi.

2. Anda dapat menggunakan fitur backup aplikasi untuk memilih namespace yang berisi aplikasi yang ingin Anda cadangkan. Untuk fitur Backup Volume, pilih Disable. Fitur backup aplikasi kemudian akan mencadangkan file YAML untuk volume persisten A dan B secara default. Untuk informasi selengkapnya, lihat Cadangkan dan pulihkan aplikasi di kluster.

   Catatan

   Jika Anda tidak perlu memulihkan Volume A ke kluster baru, Anda dapat menentukan pvc, pv di Excluded Resources dalam konfigurasi lanjutan.

Alur pemulihan

Mirip dengan menerapkan aplikasi baru di kluster, Anda perlu memulihkan volume dan data sebelum memulihkan beban kerja lapis atas.

1. Pulihkan perlindungan data di kluster target. Ini akan memulihkan file YAML dan data volume persisten B. Untuk informasi selengkapnya, lihat Cadangkan dan pulihkan aplikasi dalam kluster.

2. Pulihkan backup aplikasi di kluster target. Tindakan ini memulihkan file YAML PV A dan resource aplikasi lainnya. Container Storage Interface (CSI) kemudian menggunakan kebijakan reclaim PV A untuk membuat sumber penyimpanan baru secara dinamis atau menggunakan yang sudah ada. Untuk informasi selengkapnya, lihat bagian Apa saja risiko potensial tidak mencadangkan data volume persisten untuk aplikasi berstatus? di Kapan Anda harus mencadangkan data volume persisten dalam backup aplikasi?

Pada titik ini, aplikasi, Volume A, dan Volume B (dan datanya) dipulihkan.

Apakah pusat cadangan mendukung enkripsi data untuk bucket OSS terkait? Bagaimana cara memberikan izin untuk menggunakan KMS untuk enkripsi sisi server?

Bucket OSS mendukung enkripsi sisi server dan enkripsi berbasis klien. Namun, Pusat Cadangan hanya mendukung enkripsi sisi server untuk bucket OSS. Anda dapat mengaktifkan enkripsi sisi server secara manual untuk bucket yang dilampirkan dan mengonfigurasi metode enkripsi di konsol OSS. Untuk informasi selengkapnya tentang enkripsi sisi server untuk bucket OSS dan cara mengaktifkannya, lihat Enkripsi sisi server.

• Jika Anda menggunakan kunci master pelanggan (CMK) yang dikelola oleh KMS untuk enkripsi dan dekripsi serta menggunakan kunci Anda sendiri (BYOK), yang berarti Anda menentukan ID CMK, Anda perlu memberikan izin Pusat Cadangan untuk mengakses KMS. Ikuti langkah-langkah berikut:

  • Buat kebijakan izin kustom sebagai berikut. Untuk informasi selengkapnya, lihat Buat kebijakan izin kustom.

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

    Kebijakan akses di atas memungkinkan Anda memanggil semua kunci KMS di bawah ID akun Alibaba Cloud. Jika Anda memerlukan konfigurasi Resource yang lebih detail, lihat Informasi otorisasi.

  • Untuk kluster khusus ACK dan kluster terdaftar, berikan izin kepada pengguna RAM yang digunakan selama instalasi. Untuk informasi selengkapnya, lihat Berikan izin kepada pengguna RAM. Untuk kluster lain, berikan izin kepada peran AliyunCSManagedBackupRestoreRole. Untuk informasi selengkapnya, lihat Berikan izin kepada peran RAM.

• Jika Anda menggunakan kunci KMS yang dikelola oleh OSS atau menggunakan kunci yang sepenuhnya dikelola oleh OSS untuk enkripsi dan dekripsi, Anda tidak perlu memberikan izin tambahan.

Bagaimana cara mengubah citra yang digunakan oleh aplikasi selama pemulihan?

Asumsikan citra yang digunakan oleh aplikasi dalam backup adalah: docker.io/library/app1:v1

• Ubah alamat repositori citra (registry)

  Dalam skenario cloud hibrida, Anda mungkin perlu menerapkan aplikasi di beberapa penyedia cloud atau migrasi aplikasi dari pusat data ke cloud. Dalam kasus ini, Anda harus mengunggah citra aplikasi ke repositori citra di Alibaba Cloud Container Registry (ACR).

  Anda harus menggunakan field imageRegistryMapping untuk menentukan alamat repositori citra. Misalnya, konfigurasi berikut mengubah citra menjadi registry.cn-beijing.aliyuncs.com/my-registry/app1:v1.

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

• Ubah repositori citra (repository) dan versi

  Jenis penyesuaian ini adalah konfigurasi lanjutan yang mengharuskan Anda mendefinisikan kebijakan penyesuaian di ConfigMap sebelum pemulihan.

  Jika Anda ingin mengubah repositori citra menjadi app2:v2, buat konfigurasi berikut:

  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"
    # Jika Anda hanya ingin mengubah repositori, gunakan pengaturan berikut.
    # "case1": "app1,app2"
    # Jika Anda hanya ingin mengubah versi, gunakan pengaturan berikut.
    # "case1": "v1:v2"
    # Jika Anda hanya ingin mengubah citra di registry, gunakan pengaturan berikut.
    # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

  Jika Anda memiliki beberapa persyaratan perubahan, Anda dapat terus mengonfigurasi case2, case3, dan seterusnya di field data.

  Setelah ConfigMap dibuat, buat pekerjaan restore seperti biasa dan biarkan field imageRegistryMapping kosong.

  Catatan

  Perubahan berlaku untuk semua pekerjaan restore di kluster. Kami sarankan Anda mengonfigurasi modifikasi detail berdasarkan komentar di atas, seperti membatasi cakupan perubahan ke registry tertentu. Jika konfigurasi tidak lagi diperlukan, hapus konfigurasi tersebut.