Container Service for Kubernetes:FAQ tentang pusat cadangan

Daftar isi

Operasi umum

Saat status tugas cadangan, tugas konversi StorageClass, atau tugas pemulihan adalah Gagal atau PartiallyFailed, Anda dapat mendapatkan pesan kesalahan menggunakan metode berikut:

• Arahkan pointer ke Gagal atau PartiallyFailed di kolom Status untuk melihat pesan kesalahan singkat, seperti RestoreError: permintaan snapshot lintas wilayah gagal.

• Untuk mendapatkan pesan kesalahan lebih rinci, jalankan perintah berikut untuk memeriksa peristiwa tugas, seperti RestoreError: proses advancedvolumesnapshot gagal avs: snapshot-hz, err: transisi dibatalkan dengan kesalahan: kebijakan RAM terkait ECS-snapshot hilang.

  • Tugas cadangan

    kubectl -n csdr describe applicationbackup <backup-name> 

  • Tugas konversi StorageClass

    kubectl -n csdr describe converttosnapshot <backup-name>

  • Tugas pemulihan

    kubectl -n csdr describe applicationrestore <restore-name>

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

Masalah

Konsol menampilkan pesan The Working Component Is Abnormal atau Failed To Fetch Current Data.

Penyebab

Instalasi komponen pusat cadangan tidak normal.

Solusi

• Periksa apakah node yang termasuk dalam kluster tersedia. Jika node yang termasuk dalam kluster tidak ada, pusat cadangan tidak dapat diterapkan.

• Periksa apakah kluster menggunakan FlexVolume. Jika kluster menggunakan FlexVolume, beralihlah ke CSI. Untuk informasi lebih lanjut, lihat Komponen migrate-controller di kluster yang menggunakan FlexVolume tidak dapat diluncurkan.

• Jika Anda menggunakan Backup Center dengan kubectl, pastikan konfigurasi YAML sudah benar. Untuk informasi lebih lanjut, lihat Gunakan kubectl untuk mencadangkan dan memulihkan aplikasi.

• Jika klaster Anda adalah ACK dedicated cluster atau klaster terdaftar, periksa apakah izin yang diperlukan telah diberikan. Untuk informasi lebih lanjut, lihat ACK dedicated cluster dan Registered cluster.

• Periksa apakah Deployment csdr-controller dan csdr-velero di namespace csdr gagal diterapkan karena batasan sumber daya atau penjadwalan. Jika ya, perbaiki masalah tersebut.

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

Masalah

Saat membuat atau menghapus tugas cadangan, tugas konversi StorageClass, atau tugas pemulihan, konsol menampilkan The Name Is Already Used. Change The Name And Try Again.

Penyebab

Saat Anda menghapus tugas di konsol, sumber daya deleterequest dibuat di kluster. Komponen kerja melakukan serangkaian operasi penghapusan, bukan hanya menghapus sumber daya cadangan yang sesuai. Hal yang sama berlaku untuk operasi baris perintah. Untuk informasi lebih lanjut, lihat Gunakan kubectl untuk mencadangkan dan memulihkan aplikasi.

Jika operasi penghapusan salah atau terjadi kesalahan selama pemrosesan sumber daya deleterequest, beberapa sumber daya di kluster tidak dapat dihapus. Dalam hal ini, pesan kesalahan yang menunjukkan keberadaan sumber daya dengan nama yang sama dikembalikan.

Solusi

• Hapus sumber daya dengan nama yang sama seperti yang diminta. Misalnya, jika pesan kesalahan deleterequests.csdr.alibabacloud.com "xxxxx-dbr" sudah ada dikembalikan, jalankan perintah berikut untuk menghapus sumber daya:

  kubectl -n csdr delete deleterequests xxxxx-dbr

• Buat tugas dengan nama baru.

Saya tidak dapat memilih cadangan yang ada saat saya memulihkan aplikasi di seluruh kluster

Masalah

Saya tidak dapat memilih tugas cadangan saat saya memulihkan aplikasi di seluruh kluster.

Penyebab

• Penyebab 1: Vault cadangan tidak terkait dengan kluster saat ini, yang berarti vault cadangan belum diinisialisasi.

  Sistem menginisialisasi vault cadangan dan menyinkronkan informasi dasar tentang vault cadangan, termasuk informasi bucket Object Storage Service (OSS), ke kluster. Kemudian, sistem menginisialisasi file cadangan dari vault cadangan di kluster. Anda hanya dapat memilih file cadangan dari vault cadangan untuk pemulihan setelah inisialisasi selesai.

• Penyebab 2: Inisialisasi vault cadangan gagal. Status sumber daya backuplocation di kluster saat ini adalah Unavailable.

• Penyebab 3: Tugas cadangan belum selesai atau tugas cadangan gagal.

Solusi

• Solusi 1:

Di halaman Create Restore Task, klik Initialize Vault di sebelah kanan Backup Vault. Setelah vault cadangan diinisialisasi, pilih tugas yang ingin Anda pulihkan.

• Solusi 2:

Jalankan perintah berikut untuk memeriksa status sumber daya backuplocation:

kubectl get -n csdr backuplocation <backuplocation-name>

Hasil yang Diharapkan:

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

Jika statusnya adalah Unavailable, lihat solusi di Status Tugas Gagal dan Kesalahan "VaultError: xxx" Dikembalikan.

Solusi 3:

Di konsol kluster cadangan, periksa apakah tugas cadangan berhasil, yang berarti status tugas cadangan adalah Selesai. Jika status tugas cadangan tidak normal, tangani masalah tersebut. Untuk informasi lebih lanjut, lihat Daftar isi.

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

Masalah

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

Penyebab

Logika autentikasi sumber daya cloud dari komponen migrate-controller di klaster 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 sumber daya cloud.

Solusi

• Jika Anda masuk dengan akun Alibaba Cloud, klik Otorisasi untuk menyelesaikan otorisasi.

• Jika Anda masuk dengan pengguna RAM, klik Copy Authorization Link dan kirimkan tautan tersebut ke akun Alibaba Cloud untuk menyelesaikan otorisasi.

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

Masalah

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

Penyebab

Konsol berinteraksi dengan server API untuk mengirimkan tugas cadangan dan pemulihan serta mendapatkan status tugas secara real-time. Daftar izin default untuk personel O&M kluster dan pengembang kekurangan beberapa izin yang dibutuhkan oleh komponen pusat cadangan. Akun utama atau administrator izin perlu memberikan izin-izin ini.

Solusi

Lihat Gunakan peran RBAC kustom untuk membatasi operasi sumber daya dalam 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 dihapus

Masalah

Komponen pusat cadangan gagal ditingkatkan atau dihapus, dan namespace csdr tetap dalam status Terminating.

Penyebab

Komponen pusat cadangan keluar secara tidak normal selama operasi, menyisakan tugas dalam status InProgress di namespace csdr. Bidang finalizers dari tugas-tugas ini mungkin mencegah sumber daya dihapus dengan lancar, menyebabkan namespace csdr tetap dalam status Terminating.

Solusi

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

  kubectl describe ns csdr

  Konfirmasikan bahwa tugas yang macet tidak lagi diperlukan dan hapus finalizers yang sesuai.

• Setelah memastikan bahwa namespace csdr telah dihapus:

  • Untuk skenario peningkatan komponen, Anda dapat menginstal ulang komponen migrate-controller dari pusat cadangan.

  • Untuk skenario penghapusan komponen, komponen tersebut seharusnya sudah dihapus.

Status tugas gagal dan kesalahan "kesalahan internal" dikembalikan

Masalah

Status tugas adalah Gagal dan kesalahan "kesalahan internal" dikembalikan.

Penyebab

Komponen atau layanan cloud bawah mengalami pengecualian tak terduga, seperti ketika layanan cloud tidak tersedia di wilayah saat ini.

Solusi

Jika pesan kesalahan adalah "HBR backup/restore internal error", periksa apakah fitur pencadangan kontainer tersedia di konsol Cloud Backup.

Untuk pertanyaan lain dari jenis ini, silakan ajukan tiket untuk diproses.

Status tugas gagal dan kesalahan "timeout pembuatan sumber daya kluster" dikembalikan

Masalah

Status tugas adalah Gagal dan kesalahan "timeout pembuatan sumber daya kluster" dikembalikan.

Penyebab

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

Solusi

1. Jalankan perintah berikut untuk menemukan sumber daya abnormal dan temukan penyebab berdasarkan peristiwa:

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

   Hasil yang diharapkan:

   ……menunggu PVC sementara default/demo-pvc-for-convert202311151045 untuk konversi terikat timeout

   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 identifikasi penyebab masalah:

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

   Berikut adalah penyebab umum masalah di pusat cadangan. Untuk informasi lebih lanjut, lihat Pemecahan masalah penyimpanan.

   • Sumber daya kluster atau node tidak mencukupi atau abnormal.

   • Kluster pemulihan tidak memiliki StorageClass yang sesuai. Gunakan fitur konversi StorageClass untuk memilih StorageClass yang ada di kluster pemulihan dan kemudian pulihkan aplikasi.

   • Penyimpanan bawah yang terkait dengan StorageClass tidak tersedia. Misalnya, jenis disk yang ditentukan tidak didukung di zona saat ini.

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

   • Saat Anda memulihkan aplikasi di kluster multi-zona, Anda memilih StorageClass yang volumeBindingMode-nya disetel ke Immediate.

Status tugas gagal dan kesalahan "status addon tidak normal" dikembalikan

Masalah

Status tugas adalah Gagal dan kesalahan "status addon tidak normal" dikembalikan.

Penyebab

Komponen di namespace csdr tidak normal.

Solusi

Lihat Penyebab 1 dan solusi: Komponen di namespace csdr tidak normal.

Status tugas gagal dan kesalahan "VaultError: xxx" dikembalikan

Masalah

Status tugas cadangan, pemulihan, atau konversi StorageClass adalah Gagal dan pesan kesalahan VaultError: vault cadangan tidak tersedia: xxx dikembalikan.

Penyebab

• Bucket OSS yang ditentukan tidak ada.

• Kluster tidak memiliki izin untuk mengakses OSS.

• Jaringan bucket OSS tidak dapat dijangkau.

Solusi

1. Masuk ke Konsol OSS dan periksa apakah bucket OSS yang terkait dengan vault cadangan ada.

   Jika bucket OSS tidak ada, buat bucket baru dan asosiasikan ulang. Untuk informasi lebih lanjut, lihat Buat bucket.

2. Periksa apakah kluster memiliki izin untuk mengakses OSS.

   • Klaster ACK Pro: Anda tidak perlu mengonfigurasi izin OSS. Pastikan nama bucket OSS yang terkait dengan vault cadangan kluster dimulai dengan cnfs-oss-**.

   • Kluster ACK khusus dan kluster terdaftar: Anda perlu mengonfigurasi izin OSS. Untuk informasi lebih lanjut, lihat Instal migrate-controller dan berikan izin.

   Untuk klaster ACK yang dikelola yang belum diinstal atau ditingkatkan ke v1.8.0 atau lebih baru menggunakan konsol, izin OSS terkait 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

   Hasil yang diharapkan:

   addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

   Jika hasil 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.

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

   • Untuk mengonfigurasi izin OSS, rujuk bagian kluster ACK khusus dan kluster terdaftar. Informasi lebih lanjut dapat ditemukan di Instal migrate-controller dan berikan izin.

   • Gunakan akun Alibaba Cloud untuk mengklik Otorisasi untuk menyelesaikan otorisasi. Anda hanya perlu melakukan operasi ini sekali untuk setiap akun Alibaba Cloud.

   Catatan

   Anda tidak dapat membuat vault cadangan yang menggunakan nama yang sama dengan yang telah dihapus. Anda tidak dapat mengaitkan vault cadangan dengan bucket OSS yang namanya tidak dalam format cnfs-oss-*. Jika Anda telah mengaitkan vault cadangan dengan bucket OSS yang namanya tidak dalam format cnfs-oss-*, buat vault cadangan dengan nama berbeda dan asosiasikan dengan bucket OSS yang namanya dalam 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, vault cadangan mengakses bucket OSS melalui jaringan internal.

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

   Dalam skenario berikut, vault cadangan harus mengakses bucket OSS melalui Internet:

   • Klaster dan bucket OSS ditempatkan di wilayah yang berbeda.

   • Klaster saat ini adalah klaster ACK Edge.

   • Klaster saat ini adalah klaster terdaftar dan tidak terhubung ke virtual private cloud (VPC) menggunakan Cloud Enterprise Network (CEN), Express Connect, atau Gateway VPN. Atau, klaster terhubung ke VPC tetapi tidak ada rute yang dikonfigurasi untuk menunjuk ke titik akhir OSS internal wilayah tersebut. Anda harus mengonfigurasi rute untuk menunjuk ke titik akhir OSS internal wilayah tersebut.

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

     • Untuk informasi lebih lanjut tentang pemetaan antara titik akhir OSS internal dan rentang IP virtual (VIP), lihat Titik akhir OSS internal dan rentang VIP.

   Jika vault cadangan harus mengakses bucket OSS melalui Internet, jalankan perintah berikut untuk mengubah metode akses menjadi akses Internet. Dalam kode berikut, <backuplocation-name> menentukan nama vault cadangan dan <region-id> menentukan wilayah tempat bucket OSS ditempatkan, 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 Gagal dan kesalahan "HBRError: periksa kesalahan vault HBR" dikembalikan

Masalah

Status tugas cadangan,pemulihan, atau konversi StorageClass adalah Gagal dan kesalahan "HBRError: periksa kesalahan vault HBR" dikembalikan.

Penyebab

Cloud Backup belum diaktifkan atau tidak memiliki izin yang diperlukan.

Solusi

1. Periksa apakah Cloud Backup telah diaktifkan. Untuk informasi lebih lanjut, lihat Activate Cloud Backup.

2. Jika klaster Anda berada di China (Ulanqab), China (Heyuan), atau China (Guangzhou), Anda harus memberikan Cloud Backup izin untuk mengakses API Gateway setelah mengaktifkan Cloud Backup. Untuk informasi lebih lanjut, lihat Langkah 3 (opsional): Otorisasi Cloud Backup untuk mengakses API Gateway.

3. Jika klaster Anda merupakan klaster khusus ACK atau klaster terdaftar, pastikan pengguna Resource Access Management (RAM) yang digunakan memiliki izin untuk mengakses Cloud Backup. Untuk informasi lebih lanjut mengenai cara melakukan otorisasi, lihat Instal migrate-controller dan berikan izin.

Status tugas adalah Gagal dan kesalahan "tugas hbr selesai dengan status tak terduga: FAILED, errMsg ClientNotExist" dikembalikan

Masalah

Status tugas cadangan, pemulihan, atau konversi StorageClass adalah Gagal dan mengembalikan pesan kesalahan tugas hbr selesai dengan status tak terduga: FAILED, errMsg ClientNotExist.

Penyebab

Klien Cloud Backup tidak berfungsi secara normal pada node yang sesuai. Hal ini menunjukkan bahwa replika DaemonSet hbr-client pada node di namespace csdr tidak dalam kondisi normal.

Solusi

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

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

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

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

   Jika output berisi "SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge tidak ada, harap buat peran ini., lihat Langkah 3 (opsional): Otorisasi Cloud Backup untuk Mengakses API Gateway untuk memberikan izin.

3. Jika log output berisi jenis kesalahan SDK lainnya, ajukan tiket untuk diproses lebih lanjut.

Tugas tetap dalam status InProgress untuk waktu yang lama

Penyebab 1 dan solusi: Komponen di namespace csdr tidak normal

Periksa status komponen dan identifikasi penyebab anomali.

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

   kubectl get pod -n csdr

2. Jalankan perintah berikut untuk memeriksa mengapa komponen sedang me-restart atau tidak dapat dijalankan:

   kubectl describe pod <nama-pod> -n csdr

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

Saat Anda mencadangkan volume disk yang dipasang ke aplikasi Anda, jika tugas cadangan tetap dalam keadaan InProgress untuk waktu yang lama, jalankan perintah berikut untuk menanyakan sumber daya VolumeSnapshot yang baru dibuat di kluster:

kubectl get volumesnapshot -n <backup-namespace>

Contoh keluaran:

NAMA                    SIAPDIGUNAKAN      SUMBERPVC         SUMBERSNAPSHOTCONTENT         ...
<volumesnapshot-name>   true                              <volumesnapshotcontent-name>  ...

Jika bidang READYTOUSE dari semua sumber daya volumesnapshot tetap bernilai false untuk waktu yang lama, lakukan langkah-langkah berikut:

1. Masuk ke Konsol ECS dan periksa apakah fitur snapshot disk telah diaktifkan.

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

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

2. Periksa apakah komponen Container Storage Interface (CSI) dari klaster berjalan dengan normal.

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

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

   Klaster ACK terkelola

   1. Masuk ke Konsol RAM sebagai pengguna RAM yang memiliki hak administratif.

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

   3. Di halaman Roles, cari AliyunCSManagedBackupRestoreRole di kotak pencarian dan periksa apakah kebijakan otorisasi peran tersebut mencakup konten kebijakan 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 tidak ada, kunjungi halaman Otorisasi Cepat RAM untuk membuat peran RAM.

      • Jika peran AliyunCSManagedBackupRestoreRole ada tetapi konten kebijakan tidak lengkap, berikan izin sebelumnya kepada peran tersebut. Untuk informasi lebih lanjut, lihat Buat kebijakan kustom dan Berikan izin kepada peran RAM.

   Klaster ACK khusus

   1. Masuk ke Konsol Container Service for Kubernetes (ACK). Di panel navigasi di sebelah kiri, klik Clusters.

   2. Di halaman Clusters, temukan klaster yang Anda inginkan dan klik namanya. Di panel di sebelah kiri, klik Cluster Information.

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

   4. Di tab Permissions, periksa apakah izin snapshot disk berfungsi dengan normal.

      Jika kebijakan k8sMasterRolePolicy-Csi-*** tidak ada atau tidak mencakup izin berikut, lampirkan kebijakan snapshot disk berikut ke peran RAM master. Untuk informasi lebih lanjut, lihat Buat kebijakan 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"
     }

   • Setelah konfigurasi izin selesai, jika masalah masih belum terselesaikan, silakan ajukan tiket untuk diproses.

   Klaster terdaftar

   Hanya klaster terdaftar yang semua nodenya adalah instance Elastic Compute Service (ECS) Alibaba Cloud yang dapat menggunakan fitur snapshot disk. Periksa apakah izin terkait diberikan saat Anda menginstal plug-in penyimpanan CSI. Untuk informasi lebih lanjut, lihat Langkah 1: Berikan pengguna RAM izin untuk mengelola plug-in CSI.

Penyebab 3 dan solusi: Volume penyimpanan selain volume disk digunakan

Pada migrate-controller versi 1.7.7 dan versi lebih baru, cadangan volume disk dapat dipulihkan lintas wilayah. Cadangan dari tipe volume lainnya tidak dapat dipulihkan lintas wilayah. Jika Anda menggunakan layanan penyimpanan yang mendukung akses Internet, seperti OSS, Anda dapat membuat PV dan PVC yang diatur secara statis, lalu memulihkan aplikasi tersebut. Untuk informasi lebih lanjut, lihat Mount a statically provisioned ossfs 1.0 volume.

Status tugas cadangan gagal dan kesalahan "cadangan sudah ada di Bucket OSS" dikembalikan

Masalah

Status tugas cadangan adalah Gagal dan kesalahan "backup already exists in OSS bucket" dikembalikan.

Penyebab

Cadangan dengan nama yang sama disimpan di Bucket OSS yang terkait dengan vault cadangan.

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

• Cadangan dalam tugas cadangan yang sedang berlangsung dan tugas cadangan yang gagal tidak disinkronkan ke kluster lain.

• Jika Anda menghapus cadangan di kluster selain kluster cadangan, file cadangan di Bucket OSS diberi label tetapi tidak dihapus. File cadangan yang diberi label tidak akan disinkronkan ke kluster yang baru terhubung.

• Kluster saat ini tidak terhubung dengan vault cadangan yang menyimpan cadangan, yang berarti bahwa vault cadangan belum diinisialisasi.

Solusi

Buat vault cadangan dengan nama baru.

Status tugas cadangan gagal dan kesalahan "get target namespace failed" dikembalikan

Masalah

Status tugas cadangan adalah Gagal dan kesalahan "get target namespace failed" dikembalikan.

Penyebab

Dalam banyak kasus, kesalahan ini terjadi pada tugas cadangan yang dibuat pada waktu yang dijadwalkan. Penyebabnya bervariasi berdasarkan cara Anda memilih namespace.

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

• Jika Anda memilih Exclude, tidak ada namespace selain namespace yang dipilih yang ada di dalam kluster.

Solusi

Ubah rencana cadangan untuk mengganti metode yang digunakan untuk memilih namespace dan ubah namespace yang telah Anda pilih.

Status tugas cadangan gagal dan kesalahan "velero backup process timeout" dikembalikan

Masalah

Status tugas cadangan adalah Gagal dan kesalahan "velero backup process timeout" dikembalikan.

Penyebab

• Penyebab 1: Subtugas dari cadangan aplikasi mengalami waktu habis. Durasi subtugas bervariasi berdasarkan jumlah sumber daya kluster dan latensi respons server API. Pada migrate-controller 1.7.7 dan versi lebih baru, periode waktu habis default untuk subtugas adalah 60 menit.

• Penyebab 2: Kelas penyimpanan bucket yang digunakan oleh vault cadangan adalah Archive Storage, Cold Archive, atau Deep Cold Archive. Untuk memastikan konsistensi data selama proses cadangan, file yang mencatat metadata harus diperbarui oleh komponen pusat cadangan pada server OSS. Komponen pusat cadangan tidak dapat memperbarui file yang belum dipulihkan.

Solusi

• Solusi 1: Ubah konfigurasi global periode waktu habis subtugas di kluster cadangan.

  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 waktu habis menjadi 100 menit:

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

  Setelah Anda mengubah periode waktu habis, jalankan perintah berikut untuk me-restart csdr-controller agar perubahan diterapkan:

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

• Solusi 2: Ubah kelas penyimpanan bucket yang digunakan oleh vault cadangan menjadi Standard.

  Jika Anda ingin menyimpan data cadangan di Archive Storage, Anda dapat mengonfigurasi aturan siklus hidup untuk secara otomatis mengonversi kelas penyimpanan dan memulihkan data sebelum pemulihan. Untuk informasi lebih lanjut, lihat Konversi kelas penyimpanan.

Status tugas cadangan gagal dan kesalahan "HBR backup request failed" dikembalikan

Masalah

Status tugas cadangan adalah Gagal dan kesalahan "HBR backup request failed" dikembalikan.

Penyebab

• Penyebab 1: Plugin penyimpanan yang digunakan oleh klaster tidak kompatibel.

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

• Penyebab 3: Klien Cloud Backup mengalami anomali, yang menyebabkan tugas pencadangan atau pemulihan untuk volume sistem file, seperti volume OSS, File Storage NAS (NAS) volumes, Cloud Parallel File Storage (CPFS) volumes, atau volume lokal, mengalami waktu habis atau gagal.

Solusi

• Solusi 1: Jika klaster Anda menggunakan plugin 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 ajukan tiket untuk bantuan.

• Solusi 2: Silakan ajukan tiket untuk diproses.

• Solusi 3: Lakukan langkah-langkah berikut:

  1. Masuk ke Konsol Cloud Backup.

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

  3. Di bilah navigasi atas, pilih wilayah.

  4. Di tab Job Name, pilih Job Name dari daftar drop-down di sebelah kotak pencarian. Masukkan <backup-name>-hbr di kotak pencarian, lalu klik ikon pencarian. Setelah tugas cadangan ditampilkan, Anda dapat memeriksa statusnya. Jika tugas berada dalam keadaan abnormal, penyebab anomali akan ditampilkan. Untuk informasi lebih lanjut, lihat Back up ACK clusters.

     Catatan

     Jika Anda ingin menanyakan tugas konversi StorageClass atau tugas cadangan, cari nama cadangan yang sesuai.

Status tugas cadangan gagal dan kesalahan "HBR get empty backup info" dikembalikan

Masalah

Status tugas cadangan adalah Failed, dan kesalahan "HBR get empty backup info" dilaporkan.

Penyebab

Dalam skenario cloud hybrid, pusat cadangan menggunakan jalur pemasangan volume Kubernetes standar sebagai jalur cadangan data secara default. Sebagai contoh, untuk driver penyimpanan CSI standar, jalur pemasangan default adalah /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Hal yang sama berlaku untuk driver penyimpanan yang didukung secara resmi oleh Kubernetes, seperti NFS dan FlexVolume.

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

Solusi

Masuk ke node tempat volume dipasang dan ikuti langkah-langkah berikut untuk memecahkan masalah:

1. Periksa apakah jalur root kubelet dari node telah diubah.

   1. Jalankan perintah berikut untuk menanyakan perintah startup kubelet:

      ps -elf | grep kubelet

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

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

   2. Jika perintah startup tidak berisi informasi jalur root, periksa isi file startup layanan kubelet /etc/systemd/system/kubelet.service. Jika file tersebut berisi bidang EnvironmentFile, seperti:

      EnvironmentFile=-/etc/kubernetes/kubelet

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

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

      Jalur root kubelet adalah /xxx.

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

2. Jalankan perintah berikut untuk memeriksa apakah jalur root kubelet merupakan tautan simbolis ke jalur lain:

   ls -al <root-dir>

   Jika keluarannya mirip dengan konten berikut:

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

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

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

   Pastikan bahwa jalur pemasangan volume <root-dir>/pods/<pod-uid>/volumes ada dan bahwa sub-jalur jenis volume penyimpanan target ada di bawah jalur 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 jalur root kubelet sebenarnya yang Anda peroleh dengan menanyakan konfigurasi dan tautan simbolis.

Status tugas cadangan gagal dan kesalahan "pemeriksaan file cadangan di Bucket OSS gagal" atau "unggah file cadangan ke Bucket OSS gagal" atau "unduh file cadangan dari Bucket OSS gagal" dikembalikan

Masalah

Status tugas cadangan adalah Gagal, dengan kesalahan "unggah file cadangan ke Bucket OSS gagal".

Penyebab

Kesalahan dikembalikan oleh server OSS ketika komponen memeriksa, mengunggah, atau mengunduh file cadangan di Bucket OSS yang terkait dengan vault cadangan. Masalah ini dapat disebabkan oleh salah satu faktor berikut:

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

• Penyebab 2: Beberapa izin baca dan tulis tidak tersedia saat menginstal komponen dan mengonfigurasi izin untuk klaster khusus ACK dan klaster terdaftar.

• Penyebab 3: Kredensial autentikasi pengguna RAM yang digunakan untuk mengonfigurasi izin klaster khusus ACK dan klaster terdaftar telah 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 detail lebih lanjut tentang kebijakan izin yang diperlukan oleh komponen, lihat Langkah 1: Konfigurasikan izin.

• Solusi 3: Pastikan kredensial autentikasi pengguna RAM yang digunakan untuk mengonfigurasi izin masih aktif. Jika telah dicabut, peroleh kredensial autentikasi baru dan perbarui isi Secret alibaba-addon-secret di namespace csdr, lalu jalankan operasi berikut untuk memulai ulang widget:

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

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

Masalah

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

Penyebab

Saat Anda menggunakan komponen velero untuk mencadangkan aplikasi (sumber daya dalam kluster), komponen tersebut gagal mencadangkan beberapa sumber daya.

Solusi

Jalankan perintah berikut untuk mengidentifikasi sumber daya 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 konten di bidang Errors dan Warnings dalam output.

Jika tidak ada penyebab langsung dari 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>

Jika Anda tidak dapat memperbaiki masalah berdasarkan alasan kegagalan atau log abnormal, ajukan tiket untuk diproses.

Status tugas cadangan adalah PartiallyFailed dan pesan error "PROCESS hbr partially completed" dikembalikan

Masalah

Status tugas cadangan adalah PartiallyFailed dan pesan error "PROCESS hbr partially completed" dikembalikan.

Penyebab

Saat Anda menggunakan Cloud Backup untuk mencadangkan volume sistem file, seperti volume OSS, volume NAS, volume CPFS, atau volume lokal, Cloud Backup gagal mencadangkan beberapa sumber daya. Masalah ini dapat muncul karena salah satu penyebab berikut:

• Penyebab 1: Plugin penyimpanan yang digunakan oleh beberapa volume tidak didukung.

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

Solusi

1. Masuk ke Konsol Cloud Backup.

2. Di panel navigasi di sebelah kiri, pilih Backup > Container Backup. Pada halaman Container Backup, klik tab Backup Jobs.

3. Di bilah navigasi atas, pilih sebuah wilayah.

4. Pada tab Job Name, pilih Job Name dari daftar drop-down di sebelah kotak pencarian, masukkan <backup-name>-hbr di kotak pencarian, dan klik ikon pencarian. Jika pencadangan volume gagal atau sebagian gagal, Anda dapat melihat penyebabnya. Untuk informasi lebih lanjut, lihat Cadangkan klaster ACK.

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

Masalah

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

Penyebab

StorageClass 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 StorageClass yang diinginkan di kluster saat ini.

3. Jalankan tugas pemulihan lagi dan konfigurasikan konversi StorageClass.

Status tugas konversi StorageClass gagal dan pesan kesalahan "only support convert to storageclass with CSI diskplugin or nasplugin provisioner" ditampilkan

Masalah

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

Penyebab

StorageClass 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 untuk jenis disk dan NAS secara default. Jika Anda memiliki kebutuhan pemulihan lainnya, silakan hubungi dukungan terkait ajukan tiket.

• Jika Anda menggunakan layanan penyimpanan yang mendukung akses Internet, seperti OSS, Anda dapat membuat PV dan PVC yang di-provision secara statis, lalu pulihkan aplikasi tanpa langkah konversi StorageClass. Untuk informasi lebih lanjut, lihat Mount a statically provisioned ossfs 1.0 volume.

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

Masalah

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

Penyebab

Cluster saat ini merupakan cluster multi-zona. StorageClass yang digunakan telah dikonversi ke volume disk, dengan volumeBindingMode diatur ke Immediate. Jika Anda menggunakan volume disk dalam cluster multi-zona, pod tidak dapat dijadwalkan ke node tertentu dan akan tetap berstatus Pending setelah volume disk dibuat dan dipasang ke pod. Untuk informasi lebih lanjut tentang bidang 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 StorageClass disk:

   • Jika Anda menggunakan konsol, pilih alicloud-disk. alicloud-disk secara default menggunakan StorageClass alicloud-disk-topology-alltype.

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

3. Jalankan tugas pemulihan lagi dan konfigurasikan konversi StorageClass.

Status tugas pemulihan gagal dan pesan error "penulisan multi-node hanya didukung untuk volume blok" dikembalikan

Masalah

Status tugas pemulihan atau konversi StorageClass adalah Gagal dan pesan error "penulisan multi-node hanya didukung untuk volume blok. Untuk pengguna Kubernetes, jika tidak yakin, gunakan mode akses ReadWriteOnce dalam PersistentVolumeClaim untuk volume disk" dikembalikan.

Penyebab

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

Aplikasi yang akan dicadangkan memasang volume yang AccessMode-nya adalah ReadWriteMany atau ReadOnlyMany (sebagian besar penyimpanan jaringan yang mendukung banyak pemasangan, seperti OSS atau NAS). Saat Anda memulihkan aplikasi ke penyimpanan disk Alibaba Cloud yang secara default tidak mendukung banyak pemasangan, CSI dapat melempar error di atas.

Secara khusus, tiga skenario berikut dapat menyebabkan error ini:

Skenario 1: Versi CSI dari kluster cadangan lebih lama (atau kluster menggunakan plug-in penyimpanan FlexVolume). Versi CSI yang lebih lama tidak memeriksa bidang AccessModes dari volume disk Alibaba Cloud selama pemasangan, yang menyebabkan volume disk asli melaporkan error ketika dipulihkan di kluster dengan versi CSI yang lebih baru.

Skenario 2: StorageClass kustom yang digunakan oleh volume cadangan tidak ada di kluster pemulihan. 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 menentukan secara manual bahwa volume cadangan dipulihkan sebagai volume disk Alibaba Cloud.

Solusi

Skenario 1: Mulai dari v1.8.4, komponen cadangan mendukung konversi otomatis bidang AccessModes volume disk menjadi ReadWriteOnce. Tingkatkan komponen pusat cadangan dan pulihkan aplikasi lagi.

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

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

Status tugas pemulihan gagal dan pesan error "only disk type PVs support cross-region restore in current version" dikembalikan

Masalah

Status tugas pemulihan adalah Gagal dan pesan error "only disk type PVs support cross-region restore in current version" dikembalikan.

Penyebab

Pada migrate-controller versi 1.7.7 dan yang lebih baru, cadangan volume disk dapat dipulihkan lintas wilayah. Cadangan dari jenis volume lainnya tidak dapat dipulihkan lintas wilayah.

Solusi

• Jika Anda menggunakan layanan penyimpanan yang mendukung akses Internet, seperti OSS, Anda dapat membuat PV dan PVC yang di-provision secara statis dan kemudian memulihkan aplikasi. Untuk informasi lebih lanjut, lihat Mount a statically provisioned ossfs 1.0 volume.

• Jika Anda perlu memulihkan data penyimpanan jenis lain lintas wilayah, silakan submit a ticket.

Status tugas pemulihan gagal dan kesalahan "ECS snapshot cross region request failed" dikembalikan

Masalah

Status tugas pemulihan adalah Gagal dan kesalahan "ECS snapshot cross region request failed" dikembalikan.

Penyebab

Pada migrate-controller versi 1.7.7 dan versi lebih baru, cadangan volume disk dapat dipulihkan lintas wilayah, tetapi izin untuk menggunakan snapshot disk Elastic Compute Service (ECS) belum diberikan.

Solusi

Jika klaster Anda adalah klaster ACK khusus atau klaster terdaftar yang terhubung ke klaster Kubernetes mandiri yang ditempatkan pada Instance ECS, Anda harus memberikan izin untuk menggunakan snapshot disk ECS. Untuk informasi lebih lanjut, lihat Klaster terdaftar.

Status tugas pemulihan gagal dan kesalahan "accessMode of PVC xxx is xxx" dikembalikan

Masalah

Status tugas pemulihan adalah Gagal dan kesalahan "accessMode of PVC xxx is xxx" dikembalikan.

Penyebab

AccessMode dari volume disk yang akan dipulihkan diatur ke ReadOnlyMany (multi-mount baca-saja) atau ReadWriteMany (multi-mount baca-tulis).

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 baca-saja.

Untuk informasi lebih lanjut tentang penyimpanan disk, lihat Gunakan volume disk yang disediakan secara dinamis.

Solusi

• Jika Anda menggunakan fitur konversi StorageClass untuk mengonversi volume yang mendukung multi-mount, seperti volume OSS atau NAS, menjadi volume disk, dan Anda ingin memastikan bahwa replika bisnis Anda yang berbeda dapat berbagi data pada volume tersebut secara normal, kami sarankan Anda membuat tugas pemulihan baru dan pilih alibabacloud-cnfs-nas sebagai tipe target untuk konversi StorageClass. Dengan cara ini, volume NAS yang dikelola oleh CNFS digunakan. Untuk informasi lebih lanjut, lihat Gunakan CNFS untuk mengelola sistem file NAS (disarankan).

• Jika versi CSI saat Anda mencadangkan PV disk rendah (tanpa deteksi AccessMode), dan volume persisten yang dicadangkan itu sendiri tidak memenuhi persyaratan pembuatan CSI saat ini, Anda harus memprioritaskan penggunaan volume disk yang disediakan secara dinamis untuk mentransformasi beban kerja asli Anda. Ini membantu menghindari ancaman pelepasan paksa disk saat penjadwalan ke node lain. Jika Anda memiliki lebih banyak pertanyaan atau kebutuhan tentang skenario multi-mount, silakan ajukan Tiket untuk bantuan.

Status tugas pemulihan selesai tetapi beberapa sumber daya tidak dibuat di kluster pemulihan

Masalah

Status tugas pemulihan adalah Completed tetapi beberapa sumber daya tidak dibuat di kluster pemulihan.

Penyebab

• Penyebab 1: Sumber daya tidak dicadangkan.

• Penyebab 2: Sumber daya dikecualikan selama pemulihan berdasarkan konfigurasi.

• Penyebab 3: Subtugas pemulihan aplikasi sebagian gagal.

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

Solusi

Solusi 1:

Jalankan perintah berikut untuk melihat detail cadangan:

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

Periksa apakah sumber daya target dicadangkan. Jika sumber daya target tidak dicadangkan, periksa apakah itu dikecualikan karena namespace, sumber daya, atau konfigurasi lain yang ditentukan dalam tugas cadangan, lalu cadangkan sumber daya tersebut lagi. Secara default, sumber daya tingkat kluster dari aplikasi (pods) yang berjalan di namespace yang tidak dipilih tidak dicadangkan. Jika Anda ingin mencadangkan semua sumber daya tingkat kluster, lihat Cadangan tingkat kluster.

Solusi 2:

Jika sumber daya target tidak dipulihkan, periksa apakah itu dikecualikan karena namespace, sumber daya, atau konfigurasi lain yang ditentukan dalam tugas pemulihan, lalu pulihkan sumber daya tersebut lagi.

Solusi 3:

Jalankan perintah berikut untuk mengidentifikasi sumber daya 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 dalam bidang Errors dan Warnings di hasil keluaran. Jika Anda tidak dapat memperbaiki masalah berdasarkan alasan kegagalan, ajukan tiket untuk diproses.

Solusi 4:

Periksa audit sumber daya terkait untuk menentukan apakah itu dihapus secara tidak normal setelah dibuat.

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

migrate-controller tidak mendukung kluster yang menggunakan FlexVolume. Untuk menggunakan fitur pusat cadangan, gunakan salah satu metode berikut untuk bermigrasi dari FlexVolume ke CSI:

• Gunakan csi-compatible-controller untuk bermigrasi dari FlexVolume ke CSI

• Migrasikan FlexVolume ke CSI untuk kluster yang tidak menyimpan data

• Migrasikan volume NAS yang di-provision secara statis dari Flexvolume ke CSI

• Migrasikan volume NAS yang di-provision secara statis dari Flexvolume ke CSI

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

Jika Andaperlu mencadangkan aplikasi di klaster yang menggunakan FlexVolume dan memulihkan aplikasi tersebut di klaster yang menggunakan CSI selama migrasi dari FlexVolume ke CSI, lihat Gunakan pusat cadangan untuk memigrasikan aplikasi di klaster ACK yang menjalankan versi Kubernetes lama.

Apakah saya dapat memodifikasi vault cadangan?

Anda tidak dapat memodifikasi vault cadangan. Jika Anda ingin memodifikasi vault cadangan, Anda hanya dapat menghapus yang saat ini ada dan membuat vault cadangan dengan nama lain.

Karena vault cadangan dibagi, ia mungkin berada dalam keadaan Backup atau Restore kapan saja. Jika Anda memodifikasi parameter dari vault cadangan, sistem mungkin gagal menemukan data yang diperlukan saat mencadangkan atau memulihkan aplikasi. Oleh karena itu, Anda tidak dapat memodifikasi vault cadangan atau membuat vault cadangan yang menggunakan nama yang sama.

Apakah saya dapat mengaitkan vault cadangan dengan Bucket OSS yang namanya tidak dalam format cnfs-oss-*?

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

1. Jika Anda ingin mengaitkan vault cadangan dengan Bucket OSS yang namanya bukan dalam format cnfs-oss-*, Anda harus mengonfigurasi izin untuk komponen tersebut. Untuk informasi lebih lanjut, lihat ACK dedicated cluster.

2. Setelah Anda memberikan izin, jalankan perintah berikut untuk memulai ulang komponen layanan cadangan:

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

   Jika Anda telah membuat vault cadangan yang dikaitkan dengan Bucket OSS yang namanya bukan dalam format cnfs-oss-*, tunggu hingga pemeriksaan konektivitas selesai dan status berubah menjadi Available sebelum Anda mencoba mencadangkan atau memulihkan aplikasi. Interval pemeriksaan konektivitas adalah sekitar lima menit. Anda dapat menjalankan perintah berikut untuk memeriksa status vault cadangan:

   kubectl -n csdr get backuplocation

   Hasil yang diharapkan:

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

Bagaimana cara menentukan siklus cadangan saat saya membuat rencana cadangan?

Siklus cadangan mendukung ekspresi crontab (seperti 1 4 * * *) atau pencadangan berbasis interval (seperti 6j30m), yang berarti cadangan dibuat setiap 6 jam 30 menit.

Berikut ini menjelaskan cara menguraikan 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 bidang yang diberikan. Contoh ekspresi crontab:

• 1 4 * * *: Buat cadangan pada pukul 04:01 setiap hari.

• 0 2 15 * 1: Buat cadangan pada pukul 02:00 pada hari ke-15 setiap bulan.

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

Apa saja perubahan yang dilakukan pada file YAML sumber daya saat saya menjalankan tugas pemulihan?

Saat memulihkan sumber daya, perubahan berikut akan diterapkan pada file YAML sumber daya:

Perubahan 1:

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

Perubahan 2:

Bagaimana cara saya melihat sumber daya cadangan?

Sumber daya dalam cadangan aplikasi kluster

File YAML di dalam kluster disimpan di Bucket OSS yang terkait dengan vault cadangan. Anda dapat menggunakan salah satu metode berikut untuk melihat sumber daya cadangan:

• Jalankan perintah berikut di kluster tempat file cadangan disinkronkan untuk melihat sumber daya cadangan:

  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

• Lihat sumber daya cadangan di konsol ACK:

  1. Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.

  2. Di halaman Clusters, temukan kluster yang diinginkan dan klik namanya. Di panel sebelah kiri, pilih Operations > Application Backup.

  3. Di halaman Application Backup, klik tab Backup Records. Di kolom Backup Records, klik catatan cadangan yang ingin Anda lihat.

Sumber daya dalam cadangan volume disk

1. Masuk ke Konsol ECS.

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

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

4. Di halaman Snapshots, cari snapshot berdasarkan ID disk.

Sumber daya dalam cadangan non-volume disk

1. Masuk ke Konsol Cloud Backup.

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

3. Di bilah navigasi atas, pilih wilayah.

4. Lihat informasi dasar terkait cadangan kluster.

   • Clusters: Daftar kluster yang telah dicadangkan dan dilindungi. Klik ACK Cluster ID untuk melihat persistent volume claims (PVC) yang dilindungi. Untuk informasi lebih lanjut tentang PVC, lihat Persistent Volume Claim (PVC).

     Jika Client Status tidak normal, Cloud Backup tidak berfungsi sebagaimana mestinya di kluster ACK. Buka halaman DaemonSets di konsol ACK untuk menyelesaikan masalah tersebut.

   • Backup Jobs: Status pekerjaan pencadangan.

     

Apakah saya dapat mencadangkan aplikasi dalam kluster yang menjalankan versi Kubernetes sebelumnya dan memulihkan aplikasi tersebut di kluster yang menjalankan versi Kubernetes yang lebih baru?

Ya, Anda bisa.

Secara default, ketika mencadangkan sumber daya, semua versi API yang didukung oleh sumber daya tersebut akan dicadangkan. Sebagai contoh, Deployment di kluster yang menjalankan Kubernetes 1.16 mendukung extensions/v1beta1, apps/v1beta1, apps/v1beta2, dan apps/v1. Saat mencadangkan Deployment tersebut, vault cadangan akan menyimpan keempat versi API tanpa memedulikan versi yang digunakan saat membuat Deployment. Fitur KubernetesConvert digunakan untuk konversi versi API.

Saat memulihkan sumber daya, versi API yang direkomendasikan oleh kluster pemulihan digunakan untuk proses pemulihan. Sebagai contoh, jika Anda memulihkan Deployment sebelumnya di kluster yang menjalankan Kubernetes 1.28 dan versi API yang direkomendasikan adalah apps/v1, maka Deployment yang dipulihkan akan menggunakan apps/v1.

Apakah trafik secara otomatis beralih ke instance SLB selama pemulihan?

Tidak, trafik tidak akan beralih secara otomatis.

Secara default, setelah listener dinonaktifkan atau instance SLB baru digunakan, trafik tidak beralih secara otomatis ke instance SLB baru. Jika Anda menggunakan layanan cloud lain atau penemuan layanan pihak ketiga dan ingin mencegah penemuan layanan otomatis mengalihkan trafik ke instance SLB baru, Anda dapat mengecualikan sumber daya Layanan selama pencadangan, lalu menerapkannya secara manual saat perlu beralih trafik.

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

• csdr adalah namespace dari Pusat cadangan. Jika Anda mencadangkan dan memulihkan namespace ini secara langsung, komponen akan gagal berfungsi di kluster pemulihan. Selain itu, Pusat cadangan memiliki logika sinkronisasi cadangan, sehingga Anda tidak perlu memigrasikan cadangan secara manual ke kluster baru.

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

• kube-system, kube-public, dan kube-node-lease adalah namespace sistem default dari kluster Kubernetes. Karena adanya perbedaan dalam parameter dan konfigurasi antar kluster, namespace ini tidak dapat dipulihkan di lintas kluster. Pusat cadangan dirancang untuk mencadangkan dan memulihkan aplikasi, bukan komponen sistem. Sebelum menjalankan tugas pemulihan, Anda harus menginstal dan mengonfigurasi komponen sistem di kluster pemulihan, seperti:

  • Komponen penarikan gambar tanpa kata sandi Container Registry: Berikan izin dan konfigurasikan acr-configuration di kluster pemulihan.

  • Ingress Application Load Balancer (ALB): Konfigurasikan ALBConfigs.

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

Apakah pusat cadangan menggunakan snapshot disk ECS untuk mencadangkan volume disk? Apa tipe default dari snapshot tersebut?

Dalam skenario berikut, pusat cadangan secara default menggunakan snapshot disk Elastic Compute Service (ECS) untuk mencadangkan volume disk:

1. Klaster merupakan ACK managed cluster atau ACK dedicated cluster.

2. Klaster menjalankan Kubernetes versi 1.18 atau yang lebih baru serta menggunakan CSI versi 1.18 atau yang lebih baru.

Dalam skenario lain, pusat cadangan secara default menggunakan Cloud Backup untuk mencadangkan volume disk.

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 cadangan. Mulai 12 Oktober 2023 pukul 11:00, Alibaba Cloud tidak lagi membebankan biaya untuk penyimpanan atau operasi akses instan snapshot di semua wilayah. Untuk informasi lebih lanjut, lihat Gunakan fitur akses instan.

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

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

Oleh karena itu, untuk menggunakan fitur cadangan 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 tersebut, Anda dapat mengonfigurasi periode validitas snapshot default dengan langkah-langkah berikut:

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

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

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

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

   • Jika VolumeSnapshotClass sudah 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 cadangan volume disk yang dibuat di dalam kluster akan menghasilkan snapshot disk dengan periode validitas sesuai dengan bidang retentionDays.

   Penting

   Agar periode validitas snapshot disk ECS yang dibuat dari cadangan sama dengan periode validitas yang ditentukan dalam konfigurasi cadangan, disarankan untuk meningkatkan komponen csi-provisioner ke versi 1.20.6 atau yang lebih baru.

Dalam skenario apa saya perlu mencadangkan volume saat saya mencadangkan aplikasi?

Apa itu pencadangan data volume?

Data volume dicadangkan ke penyimpanan cloud menggunakan snapshot disk ECS atau layanan Cloud Backup. Saat 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 memiliki persyaratan sumber data bersama, Anda dapat memilih untuk tidak mencadangkan data volume dan memastikan bahwa daftar sumber daya yang dikecualikan dalam cadangan tidak termasuk sumber daya PVC dan PV. Selama pemulihan, volume diterapkan ke kluster baru berdasarkan file YAML asli.

Dalam skenario apa saya perlu mencadangkan volume?

• Anda ingin menerapkan replikasi data dan pemulihan bencana.

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

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

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

• Plugin atau versi penyimpanan dari kluster cadangan dan kluster pemulihan sangat berbeda, dan file YAML tidak dapat dipulihkan secara langsung.

Apa risiko tidak mencadangkan volume untuk aplikasi stateful?

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

• Untuk volume dengan kebijakan pengklaiman Delete:

  Mirip dengan saat Anda menerapkan PVC untuk pertama kali, jika kluster pemulihan memiliki StorageClass yang sesuai, CSI secara otomatis membuat PV baru. Sebagai contoh, untuk penyimpanan disk, disk kosong baru dipasang ke aplikasi yang dipulihkan. Untuk volume statis yang tidak memiliki StorageClass yang ditentukan atau jika kluster pemulihan tidak memiliki StorageClass yang sesuai, PVC dan pod yang dipulihkan tetap dalam status Pending sampai Anda secara manual membuat PV atau StorageClass yang sesuai.

• Untuk volume dengan kebijakan pengklaiman Retain:

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

Anda dapat menjalankan perintah berikut untuk menanyakan kebijakan pengklaiman volume:

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

Hasil 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, ketika Anda mencadangkan volume penyimpanan selain volume disk Alibaba Cloud, Cloud Backup digunakan untuk cadangan dan pemulihan data. Dalam hal ini, tugas Cloud Backup harus dijalankan pada sebuah node. Kebijakan penjadwalan default dari ACK Scheduler sama dengan Kubernetes scheduler. Anda juga dapat mengonfigurasi tugas agar hanya dijadwalkan ke node tertentu berdasarkan kebutuhan bisnis Anda.

Kebijakan penjadwalan node Pusat cadangan

• Kebijakan exclude (default): Secara default, semua node dapat digunakan untuk pencadangan dan pemulihan. Jika Anda tidak ingin tugas Cloud Backup dijadwalkan pada 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 mencakup hal-hal berikut: Secara default, node tanpa label tidak dapat digunakan untuk pencadangan dan pemulihan. Tambahkan label csdr.alibabacloud.com/agent-included="true" ke node yang diizinkan untuk menjalankan tugas 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 pencadangan dan pemulihan. Prioritas penjadwalan adalah 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. Node dengan label csdr.alibabacloud.com/agent-excluded="true" memiliki prioritas paling rendah.

Mengubah 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 dalam 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 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 diterapkan:

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

Apakah skenario untuk cadangan aplikasi dan perlindungan data?

Cadangan aplikasi:

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

• Opsional: Saat mencadangkan aplikasi, Anda juga dapat mencadangkan volume yang dipasang ke aplikasi tersebut.

  Catatan

  Fitur cadangan aplikasi tidak mencakup pencadangan volume yang tidak dipasang ke pod.

  Jika ingin mencadangkan aplikasi beserta semua volumenya, Anda dapat membuat tugas cadangan perlindungan data.

• Anda ingin memigrasikan aplikasi antar kluster serta memulihkannya dengan cepat untuk pemulihan bencana.

Perlindungan data:

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

• Anda ingin memulihkan PVC secara independen dari data cadangan. Saat menggunakan pusat cadangan untuk memulihkan PVC yang dihapus, disk baru akan dibuat dengan data identik dengan file cadangan. Dalam hal ini, parameter pemasangan PVC baru tetap tidak berubah, sehingga PVC baru dapat langsung dipasang ke aplikasi.

• Anda ingin menerapkan replikasi data dan pemulihan bencana.

Apakah pusat cadangan mendukung enkripsi data untuk Bucket OSS yang terkait? Bagaimana cara memberikan izin untuk menggunakan Key Management Service (KMS) untuk enkripsi sisi server?

Bucket OSS mendukung enkripsi sisi server dan enkripsi sisi klien. Namun, pusat cadangan hanya mendukung enkripsi sisi server untuk Bucket OSS. Anda dapat mengaktifkan enkripsi sisi server secara manual untuk Bucket OSS yang dihubungkan dengan pusat cadangan dan mengonfigurasi metode enkripsi melalui konsol OSS. Untuk detail lebih lanjut tentang enkripsi sisi server dan cara mengaktifkannya, lihat Enkripsi sisi server.

• Jika Anda menggunakan kunci utama pelanggan (CMK) yang dikelola oleh KMS untuk enkripsi dan dekripsi serta menggunakan kunci Anda sendiri (BYOK), yaitu menentukan ID CMK, Anda perlu memberikan izin kepada pusat cadangan untuk mengakses KMS. Ikuti langkah-langkah berikut:

  • Buat kebijakan kustom. Untuk informasi lebih lanjut, lihat Buat kebijakan kustom.

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

    Kebijakan di atas memberikan izin kepada pusat cadangan untuk memanggil semua kunci KMS di bawah ID akun Alibaba Cloud. Jika Anda memerlukan konfigurasi Resource yang lebih rinci, lihat Informasi otorisasi.

  • Untuk klaster khusus ACK dan klaster terdaftar, berikan izin kepada pengguna RAM yang digunakan selama instalasi. Untuk informasi lebih lanjut, lihat Berikan izin kepada pengguna RAM. Untuk klaster lainnya, berikan izin kepada peran AliyunCSManagedBackupRestoreRole. Untuk informasi lebih lanjut, 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, tidak diperlukan izin tambahan.

Bagaimana cara mengubah gambar yang digunakan oleh aplikasi selama pemulihan?

Asumsikan bahwa gambar yang digunakan oleh aplikasi dalam cadangan adalah: docker.io/library/app1:v1.

• Mengubah alamat repositori gambar (registry)

  Dalam skenario cloud hybrid, Anda mungkin perlu menyebarkan aplikasi di beberapa penyedia layanan cloud atau memigrasikan aplikasi dari pusat data ke cloud. Dalam hal ini, Anda harus mengunggah gambar yang digunakan oleh aplikasi ke repositori gambar di Container Registry.

  Gunakan bidang imageRegistryMapping untuk menentukan alamat repositori gambar. Sebagai contoh, konfigurasi berikut mengubah gambar menjadi registry.cn-beijing.aliyuncs.com/my-registry/app1:v1.

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

• Mengubah repositori gambar (repository) dan versi

  Mengubah repositori gambar dan versi merupakan fitur lanjutan. Sebelum membuat tugas pemulihan, tentukan detail perubahan dalam ConfigMap.

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

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: <Nama ConfigMap>
    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 gambar, gunakan pengaturan berikut.
    # "case1": "app1,app2"
    # Jika Anda hanya ingin mengubah versi gambar, gunakan pengaturan berikut.
    # "case1": "v1:v2"
    # Jika Anda hanya ingin mengubah gambar dalam repositori gambar, gunakan pengaturan berikut.
    # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

  Jika terdapat beberapa persyaratan perubahan, Anda dapat melanjutkan dengan mengonfigurasi case2, case3, dan seterusnya di bidang data.

  Setelah ConfigMap dibuat, buat tugas pemulihan seperti biasa dan biarkan bidang imageRegistryMapping kosong.

  Catatan

  Perubahan ini berlaku untuk semua tugas pemulihan di kluster. Kami menyarankan Anda mengonfigurasi modifikasi dengan granularitas lebih baik sesuai deskripsi sebelumnya. Sebagai contoh, konfigurasikan perubahan gambar dalam satu repositori. Jika ConfigMap tidak lagi diperlukan, hapuslah.