Container Service for Kubernetes:FAQ Pusat Cadangan

Indeks

Operasi umum

Jika status tugas cadangan, konversi kelas penyimpanan, atau tugas pemulihan adalah Failed atau Partially Failed, gunakan metode berikut untuk mengambil pesan error.

• Arahkan kursor ke status Failed atau Partially Failed di kolom Status Tugas untuk melihat ringkasan error, seperti RestoreError: snapshot cross region request failed.

• Untuk informasi error yang lebih detail, jalankan salah satu perintah berikut untuk mengkueri catatan event dari resource terkait. Catatan event menyediakan pesan error detail, seperti RestoreError: process advancedvolumesnapshot failed avs: snapshot-hz, err: transition canceled with error: the ECS-snapshot related ram policy is missing.

  • Tugas cadangan

    kubectl -n csdr describe applicationbackup <backup-name> 

  • Tugas konversi kelas penyimpanan

    kubectl -n csdr describe converttosnapshot <backup-name>

  • Tugas pemulihan

    kubectl -n csdr describe applicationrestore <restore-name>

Konsol menampilkan "Error komponen" atau "Gagal menarik data"

Gejala

Konsol menampilkan Component error atau Failed to pull data.

Penyebab

Komponen Pusat Cadangan tidak terinstal dengan benar.

Solusi

• Periksa apakah terdapat node di kluster. Jika tidak ada node, Pusat Cadangan tidak dapat dideploy.

• Jika kluster Anda menggunakan plugin penyimpanan FlexVolume, migrasikan ke plugin CSI. Untuk informasi lebih lanjut, lihat Komponen migrate-controller pada kluster FlexVolume gagal dimulai.

• Jika Anda menggunakan alat baris perintah kubectl untuk mengelola Pusat Cadangan, periksa konfigurasi YAML Anda untuk kesalahan. Untuk informasi lebih lanjut, lihat Cadangkan dan pulihkan aplikasi kluster menggunakan kubectl.

• Jika kluster Anda adalah Kluster ACK Dedicated atau Kluster Terdaftar, pastikan izin yang diperlukan telah dikonfigurasi. Untuk informasi lebih lanjut, lihat Kluster ACK Dedicated dan Kluster Terdaftar.

• Verifikasi bahwa aplikasi stateless csdr-controller dan csdr-velero sedang berjalan di namespace csdr. Jika tidak, atasi kegagalan deployment, yang mungkin disebabkan oleh batasan resource atau kendala penjadwalan.

Error konsol: Resource dengan nama yang sama sudah ada

Gejala

Saat Anda membuat atau menghapus cadangan, konversi kelas penyimpanan, atau tugas pemulihan, konsol menampilkan pesan The name has been used. Change the name and try again..

Penyebab

Menghapus tugas dari konsol menghasilkan sumber daya deleterequest di kluster. Komponen pekerja kemudian menjalankan serangkaian operasi penghapusan yang tidak hanya mencakup penghapusan sumber daya cadangan terkait. Proses serupa berlaku untuk operasi yang dilakukan melalui alat baris perintah. Untuk informasi selengkapnya, lihat Mencadangkan dan memulihkan sumber daya menggunakan alat baris perintah.

Jika operasi penghapusan gagal atau terjadi error saat memproses resource deleterequest, beberapa resource mungkin tetap berada di kluster. Resource sisa ini menyebabkan error "Resource dengan nama yang sama sudah ada".

Solusi

• Hapus resource yang bertentangan yang ditentukan dalam pesan error. Misalnya, jika errornya adalah deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists, jalankan perintah berikut untuk menghapusnya:

  kubectl -n csdr delete deleterequests xxxxx-dbr

• Buat tugas yang sesuai dengan nama baru.

Tidak dapat memilih cadangan untuk pemulihan lintas kluster

Gejala

Saat mencoba memulihkan aplikasi lintas kluster, tidak ada cadangan yang tersedia untuk dipilih.

Penyebab

• Penyebab 1: Repositori cadangan tidak dikaitkan dengan kluster saat ini karena belum diinisialisasi.

  Proses inisialisasi repositori mengirimkan konfigurasi repositori cadangan, seperti bucket OSS yang terkait, ke kluster saat ini. Kluster kemudian mendaftarkan cadangan yang telah selesai dari repositori tersebut. Anda harus menginisialisasi repositori di kluster target sebelum dapat memilih cadangannya untuk pekerjaan pemulihan.

• Penyebab 2: Jika inisialisasi repositori gagal, status resource backuplocation di kluster saat ini menjadi Unavailable.

• Penyebab 3: Tugas cadangan belum selesai atau gagal.

Solusi

• Solusi 1:

Di halaman Create Restoration Task, klik Backup Vaults di sebelah Initialize Backup Vault. Setelah repositori cadangan diinisialisasi, pilih cadangan yang diinginkan.

• 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 adalah Unavailable, rujuk solusi di Status tugas adalah Failed, dan pesan error berisi "VaultError: xxx".

Solusi 3:

Di konsol kluster sumber, konfirmasi bahwa tugas cadangan memiliki status Completed. Jika status cadangan tidak normal, identifikasi dan atasi penyebabnya. Untuk informasi lebih lanjut, rujuk Indeks.

Error konsol: Peran layanan belum diotorisasi

Gejala

Saat Anda mengakses konsol pencadangan aplikasi, Anda menerima pesan error yang menyatakan bahwa peran layanan yang diperlukan belum diotorisasi. Kode errornya adalah AddonRoleNotAuthorized.

Penyebab

Masalah ini terjadi karena versi 1.8.0 komponen migrate-controller untuk pusat cadangan memperkenalkan logika autentikasi baru untuk resource cloud di kluster ACK yang dikelola. Pertama kali kluster di akun Alibaba Cloud diinstal atau ditingkatkan ke versi ini, akun tersebut harus memberikan izin yang diperlukan.

Solusi

• Jika Anda masuk menggunakan akun Alibaba Cloud, klik Buka Otorisasi untuk memberikan izin yang diperlukan.

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

Izin RBAC kluster yang hilang di Konsol

Gejala

Saat Anda mengakses konsol pencadangan aplikasi, Anda menerima error APISERVER.403. Pesan tersebut menunjukkan bahwa akun Anda tidak memiliki izin RBAC kluster yang diperlukan dan memerlukan otorisasi dari akun utama atau administrator izin.

Penyebab

Konsol berinteraksi dengan server API untuk membuat dan mengelola tugas cadangan dan pemulihan serta mengambil statusnya. Izin RBAC default yang diberikan kepada operator dan pengembang kluster tidak mencakup izin tertentu yang diperlukan oleh komponen pusat cadangan. Akun utama atau administrator izin harus memberikan izin ini.

Solusi

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

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

Kegagalan peningkatan atau penghapusan komponen Pusat Cadangan

Gejala

Komponen Pusat Cadangan gagal ditingkatkan atau dihapus, dan namespace csdr tetap dalam status Terminating.

Penyebab

Saat komponen Pusat Cadangan berhenti secara tidak terduga, tugas-tugasnya dapat tertinggal dalam status InProgress di namespace csdr. finalizers pada resource kluster untuk tugas-tugas tersebut dapat menghalangi penghapusannya, sehingga namespace csdr terjebak dalam status Terminating.

Solusi

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

  kubectl describe ns csdr

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

• Setelah namespace csdr dihapus:

  • Untuk peningkatan komponen, instal ulang komponen migrate-controller.

  • Untuk penghapusan komponen, penghapusan telah selesai.

Tugas gagal dengan "internal error"

Gejala

Status tugas adalah Failed, dan pesan error berisi "internal error".

Penyebab

Penyebabnya adalah error tak terduga pada komponen atau produk cloud yang bergantung. Misalnya, produk cloud mungkin belum diaktifkan di wilayah saat ini.

Solusi

Jika pesan errornya adalah "HBR backup/restore internal error", buka konsol Cloud Backup untuk memeriksa apakah pencadangan kontainer telah diaktifkan.

Tugas gagal dengan error "create cluster resources timeout"

Gejala

Status tugas adalah Failed, dengan pesan error "create cluster resources timeout".

Penyebab

Tugas konversi StorageClass atau pemulihan membuat resource sementara, seperti Pod, PersistentVolumeClaim, dan PersistentVolume. Jika resource ini tidak tersedia tepat waktu, tugas gagal dengan error "create cluster resources timeout".

Solusi

1. Jalankan perintah berikut untuk memeriksa Events resource dan menentukan penyebab kegagalan.

   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

   Output tersebut menunjukkan bahwa PersistentVolumeClaim yang digunakan untuk konversi StorageClass, demo-pvc-for-convert202311151045 di namespace default, gagal memasuki status Bound dalam periode timeout.

2. Jalankan perintah berikut untuk memeriksa status PersistentVolumeClaim dan menemukan penyebab masalahnya.

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

   Berikut adalah penyebab umum masalah ini di Pusat Cadangan. Untuk informasi lebih lanjut, lihat Troubleshoot masalah penyimpanan.

   • Resource tidak mencukupi atau status kluster atau node tidak normal.

   • Kluster pemulihan tidak memiliki StorageClass yang diperlukan. Gunakan fitur konversi StorageClass untuk memilih StorageClass yang ada di kluster pemulihan, lalu coba lagi operasi pemulihan.

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

   • CNFS yang terkait dengan alibabacloud-cnfs-nas tidak sehat. Lihat Kelola sistem file NAS menggunakan CNFS.

   • Memilih StorageClass dengan volumeBindingMode diatur ke Immediate saat memulihkan ke kluster multi-AZ.

Tugas gagal dengan error "addon status is abnormal"

Gejala

Status tugas adalah Failed, dengan pesan error "addon status is abnormal".

Penyebab

Komponen di namespace csdr tidak berjalan dengan benar.

Solusi

Lihat Penyebab 1 dan solusi: Komponen di namespace csdr tidak berjalan dengan benar.

Tugas gagal dengan pesan "VaultError: xxx"

Gejala

Tugas cadangan, pemulihan, atau konversi StorageClass gagal dengan pesan error VaultError: backup vault is unavailable: xxx.

Penyebab

• Bucket OSS tidak ada.

• Izin OSS tidak dikonfigurasi untuk kluster.

• Kluster tidak dapat mengakses Bucket OSS melalui jaringan.

Solusi

1. Masuk ke Konsol Manajemen OSS dan verifikasi bahwa Bucket OSS yang terkait dengan penyimpanan cadangan ada.

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

2. Verifikasi bahwa izin OSS untuk kluster telah dikonfigurasi.

   • Kluster ACK Pro: Anda tidak perlu mengonfigurasi izin OSS. Sebagai gantinya, pastikan Bucket OSS yang terkait dengan penyimpanan cadangan menggunakan awalan cnfs-oss-**.

   • Kluster ACK Dedicated dan kluster terdaftar: Anda harus mengonfigurasi izin OSS. Untuk instruksi, lihat Instal komponen layanan cadangan dan konfigurasi izin.

   Jika Anda menginstal atau meningkatkan komponen ke v1.8.0 atau lebih baru pada kluster ACK yang dikelola tanpa menggunakan konsol, kluster mungkin kehilangan izin OSS yang diperlukan. Anda dapat menjalankan perintah berikut untuk memeriksa:

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

   Output yang diharapkan:

   addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

   Jika perintah mengembalikan output ini, kluster hanya perlu menggunakan Bucket OSS dengan awalan cnfs-oss-*, dan tidak diperlukan izin OSS tambahan.

   Jika perintah tidak mengembalikan output ini, berikan izin yang diperlukan dengan menggunakan salah satu metode berikut:

   • Konfigurasi izin OSS seperti yang Anda lakukan untuk kluster ACK Dedicated atau kluster terdaftar. Untuk instruksi, lihat Instal komponen layanan cadangan dan konfigurasi izin.

   • Gunakan akun Alibaba Cloud Anda untuk mengklik Buka Otorisasi dan selesaikan proses otorisasi. Anda hanya perlu melakukan otorisasi ini sekali per akun Alibaba Cloud.

   Catatan

   Penyimpanan cadangan tidak dapat dibuat ulang dengan nama yang sama, atau dikaitkan dengan Bucket OSS yang namanya tidak mengikuti konvensi penamaan cnfs-oss-**. Jika Anda sebelumnya telah mengaitkan bucket yang tidak mengikuti konvensi penamaan ini, Anda harus membuat penyimpanan cadangan baru dengan nama berbeda dan mengaitkannya dengan bucket yang memenuhi persyaratan penamaan.

3. Jalankan perintah berikut untuk memeriksa konfigurasi jaringan kluster.

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

   Outputnya harus mirip dengan berikut:

   network: internal

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

   • Jika nilai jaringan adalah public, penyimpanan cadangan mengakses Bucket OSS melalui jaringan publik. Jika Anda menggunakan jaringan publik dan error spesifiknya adalah timeout, periksa apakah kluster telah mengaktifkan akses jaringan publik. Untuk informasi lebih lanjut, lihat Aktifkan akses jaringan publik untuk kluster.

   Dalam tiga skenario berikut, penyimpanan cadangan harus mengakses Bucket OSS melalui jaringan publik:

   • Kluster dan Bucket OSS berada di wilayah yang berbeda.

   • Kluster adalah kluster ACK Edge.

   • Kluster adalah kluster terdaftar yang tidak terhubung ke VPC cloud melalui metode seperti Cloud Enterprise Network (CEN), Express Connect, atau VPN. Skenario ini juga mencakup kluster terdaftar yang terhubung ke VPC cloud tetapi tidak memiliki rute ke jaringan internal OSS di wilayah tersebut, sehingga Anda harus mengonfigurasi satu.

     • Untuk informasi lebih lanjut tentang cara menghubungkan pusat data lokal ke VPC cloud, lihat Metode koneksi.

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

   Jika Anda harus menggunakan jaringan publik untuk mengakses Bucket OSS, Anda dapat menjalankan perintah berikut untuk mengubah mode akses. Dalam perintah berikut, ganti <backuplocation-name> dengan nama penyimpanan cadangan Anda dan <region-id> dengan ID wilayah tempat Bucket OSS berada, 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>"}}]'

Tugas gagal dengan "HBRError: check HBR vault error"

Gejala

Tugas cadangan, pemulihan, atau konversi kelas penyimpanan gagal, dan pesan error berisi "HBRError: check HBR vault error".

Penyebab

Layanan HBR belum diaktifkan, atau izin yang diperlukan belum dikonfigurasi dengan benar.

Solusi

1. Verifikasi bahwa layanan HBR telah diaktifkan. Untuk instruksi, lihat Aktifkan HBR.

2. Jika kluster Anda berada di wilayah seperti China (Ulanqab), China (Heyuan), atau China (Guangzhou), Anda juga harus memberikan izin Gerbang API kepada layanan HBR setelah diaktifkan. Untuk instruksi, lihat (Opsional) Langkah 3: Berikan izin Gerbang API kepada layanan HBR.

3. Jika kluster Anda adalah kluster ACK dedicated atau kluster terdaftar, verifikasi bahwa izin RAM HBR yang diperlukan telah diberikan. Untuk detail tentang izin ini dan cara memberikannya, lihat Instal komponen layanan cadangan migrate-controller dan konfigurasi izin.

Tugas gagal dengan "HBRError: ... code: 400, Illegal request"

Gejala

Tugas cadangan, pemulihan, atau konversi kelas penyimpanan gagal dengan error "HBRError: ... code: 400, Illegal request. Please modify the parameters".

Penyebab

Penyimpanan cadangan ack-backup-data untuk Cloud Backup telah dihapus dari wilayah kluster.

Pertama kali Anda menggunakan Pusat Cadangan di suatu wilayah, komponen secara otomatis menyediakan penyimpanan cadangan bernama ack-backup-data untuk menyimpan cadangan yang dibuat oleh Pusat Cadangan. Cadangan ini secara otomatis dihapus berdasarkan periode retensi cadangan yang ditentukan.

Solusi

1. Jalankan perintah berikut pada semua kluster di wilayah saat ini yang menggunakan Pusat Cadangan untuk menghapus catatan repositori cadangan.

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

2. Di kluster tempat Anda ingin membuat cadangan, mulai tugas cadangan baru. Komponen secara otomatis membuat ulang penyimpanan cadangan ack-backup-data dan mengaitkannya dengan repositori cadangan Anda.

Tugas gagal dengan error "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist"

Gejala

Tugas cadangan, pemulihan, atau konversi kelas penyimpanan gagal dengan pesan error yang berisi hbr task finished with unexpected status: FAILED, errMsg ClientNotExist.

Penyebab

Klien Cloud Backup gagal dideploy di node target. Ini menunjukkan bahwa Pod untuk DaemonSet hbr-client di namespace csdr tidak berjalan dengan benar di node tersebut.

Solusi

1. Jalankan perintah berikut untuk memeriksa adanya Pod hbr-client yang bermasalah:

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

2. Jika ada Pod dalam status tidak normal, pertama-tama periksa apakah masalah disebabkan oleh resource yang tidak mencukupi, seperti IP Pod, memori, atau CPU. Jika Pod memiliki status CrashLoopBackOff, jalankan perintah berikut untuk melihat log-nya.

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

   Jika output berisi "SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge doesn't exist, please create this role. ", berikan izin yang diperlukan kepada layanan Cloud Backup. Untuk instruksi, lihat (Opsional) Langkah 3: Berikan izin Gerbang API kepada layanan Cloud Backup.

3. Jika output log berisi jenis error SDK lainnya, Anda dapat melakukan troubleshooting dengan menggunakan kode error EC dalam respons.

   Untuk informasi lebih lanjut, lihat Troubleshoot menggunakan kode error EC.

Tugas macet dalam status InProgress

Penyebab 1 dan solusi: Komponen tidak normal di namespace csdr

Periksa status komponen untuk mengidentifikasi penyebab masalah.

1. Jalankan perintah berikut untuk memeriksa apakah ada komponen di namespace csdr yang restart atau gagal dimulai.

   kubectl get pod -n csdr

2. Jalankan perintah berikut untuk menemukan penyebab restart atau kegagalan startup.

   kubectl describe pod <pod-name> -n csdr

Penyebab 2 dan solusi: Izin snapshot belum dikonfigurasi untuk pencadangan cloud disk

Jika tugas pencadangan data untuk aplikasi yang menggunakan volume Cloud Disk macet dalam status InProgress, jalankan perintah berikut untuk memeriksa adanya resource volumesnapshot yang baru dibuat di kluster.

kubectl get volumesnapshot -n <backup-namespace>

Berikut adalah contoh output yang diharapkan:

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

Jika status READYTOUSE semua resource volumesnapshot tetap false untuk periode yang lama, lakukan langkah-langkah berikut.

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

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

   • Jika sudah diaktifkan, lanjutkan ke langkah berikutnya.

2. Verifikasi bahwa komponen CSI kluster berjalan normal.

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

3. Verifikasi bahwa izin yang diperlukan untuk menggunakan snapshot cloud disk telah dikonfigurasi.

   Kluster yang dikelola

   1. Masuk ke Konsol RAM sebagai administrator RAM.

   2. Di panel navigasi kiri, pilih Identities > Roles. Anda dapat memfilter peran berdasarkan jenis atau mencari peran tertentu. Peran terkait layanan yang dibuat secara otomatis juga tercantum di halaman ini dan dapat diambil dengan memanggil operasi API ListRoles atau perintah CLI yang sesuai.

   3. Di halaman Role, cari AliyunCSManagedBackupRestoreRole dan verifikasi bahwa kebijakan izinnya berisi 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 tidak ada, buka halaman Otorisasi Cepat untuk Manajemen Akses Resource (RAM) untuk mengotorisasi peran tersebut.

      • Jika peran AliyunCSManagedBackupRestoreRole ada tetapi kebijakannya tidak lengkap, berikan izin yang diperlukan kepada peran tersebut. Untuk informasi lebih lanjut, lihat Buat kebijakan izin kustom dan Kelola izin peran RAM.

   Kluster dedicated

   1. Masuk ke Konsol Container Service dan di panel navigasi kiri, klik Clusters.

   2. Di halaman Clusters, klik nama kluster Anda. Di navigasi kiri, klik Cluster Information.

   3. Pada halaman Cluster Information, temukan parameter master RAM role dan klik tautan di sampingnya.

   4. Di tab Permission Management, periksa izin snapshot cloud disk.

      Jika kebijakan izin k8sMasterRolePolicy-Csi-*** tidak ada atau tidak mencakup izin yang diperlukan, berikan kebijakan izin snapshot cloud disk berikut kepada peran RAM master. Untuk informasi lebih lanjut, lihat Buat kebijakan izin kustom dan Kelola izin 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

   Fitur snapshot cloud disk hanya tersedia untuk kluster terdaftar di mana semua node adalah instance ECS Alibaba Cloud. Verifikasi bahwa izin yang diperlukan telah diberikan saat Anda menginstal plugin penyimpanan CSI. Untuk informasi lebih lanjut, lihat Konfigurasi izin RAM untuk komponen CSI.

Penyebab 3 dan solusi: Jenis volume tidak didukung

Mulai dari v1.7.7, komponen migrate-controller Pusat Cadangan mendukung pemulihan lintas wilayah untuk pencadangan data Cloud Disk. Pemulihan lintas wilayah untuk jenis data lain belum didukung. Jika Anda menggunakan produk penyimpanan yang dapat diakses melalui jaringan publik, seperti OSS Alibaba Cloud, Anda dapat membuat Persistent Volume Claim dan Persistent Volume secara statis sebelum memulihkan aplikasi. Untuk informasi lebih lanjut, lihat Gunakan volume statis dengan ossfs 1.0.

Error "backup already exists in OSS bucket"

Gejala

Cadangan gagal, menunjukkan status Failed dan pesan error yang berisi "backup already exists in OSS bucket".

Penyebab

Cadangan dengan nama yang sama sudah ada di Bucket OSS yang terkait dengan repositori cadangan.

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

• Sistem tidak menyinkronkan cadangan yang sedang berlangsung atau gagal ke kluster lain.

• Saat Anda menghapus cadangan dari kluster selain tempat pembuatannya, sistem hanya memberi tag untuk penghapusan alih-alih benar-benar menghapusnya dari Bucket OSS. Sistem tidak menyinkronkan cadangan yang ditandai ini ke kluster yang baru dikaitkan.

• Kluster saat ini tidak dikaitkan dengan repositori cadangan yang berisi cadangan yang ada. Dengan kata lain, repositori belum menyelesaikan inisialisasi.

Solusi

Buat repositori cadangan dengan nama baru.

Cadangan gagal dengan "get target namespace failed"

Gejala

Cadangan gagal dengan status Failed dan pesan error "get target namespace failed".

Penyebab

Masalah ini biasanya terjadi pada pekerjaan cadangan terjadwal. Alasan kegagalannya tergantung pada metode pemilihan namespace.

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

• Jika Anda menggunakan metode Exclude, hanya namespace yang dikecualikan yang tersisa di kluster.

Solusi

Edit rencana cadangan untuk memperbaiki pemilihan namespace.

Cadangan gagal dengan error 'velero backup process timeout'

Gejala

Status cadangan adalah Failed, dan pesan error berisi 'velero backup process timeout'.

Penyebab

• Penyebab 1: Subtugas pencadangan aplikasi timeout. Durasi subtugas ini tergantung pada faktor seperti ketersediaan resource kluster dan latensi API Server. Sejak v1.7.7, komponen migrate-controller pusat cadangan secara default memiliki timeout 60 menit.

• Penyebab 2: Kelas penyimpanan bucket yang digunakan oleh repositori cadangan adalah Archive, Cold Archive, atau Deep Cold Archive. Untuk memastikan proses pencadangan yang konsisten, komponen harus memperbarui file metadata di server OSS. Operasi ini tidak didukung untuk objek yang belum dipulihkan.

Solusi

• Solusi 1: Ubah pengaturan timeout global untuk subtugas cadangan di kluster cadangan.

  Jalankan perintah berikut untuk menambahkan item konfigurasi velero_timeout_minutes (dalam menit) ke applicationBackup.

  kubectl edit -n csdr cm csdr-config

  Misalnya, untuk mengatur timeout menjadi 100 menit, lakukan perubahan berikut:

  apiVersion: v1
  data:
    applicationBackup: |
      ... # Diabaikan untuk singkatnya
      velero_timeout_minutes: 100

  Setelah Anda mengubah konfigurasi, 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 repositori cadangan menjadi Standard.

  Untuk menyimpan data cadangan di kelas penyimpanan arsip, konfigurasikan aturan siklus hidup untuk secara otomatis mengubah kelas penyimpanan. Anda kemudian harus memulihkan data sebelum pemulihan. Untuk informasi lebih lanjut, lihat Ubah kelas penyimpanan.

Pekerjaan cadangan gagal: "HBR backup request failed"

Gejala

Status pekerjaan cadangan adalah Failed, dan pesan error berisi "HBR backup request failed".

Penyebab

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

• Penyebab 2: Cloud Backup tidak mendukung pencadangan volume yang memiliki volumeMode diatur ke Block. Untuk informasi lebih lanjut, lihat volumeMode.

• Penyebab 3: Masalah dengan klien Cloud Backup menyebabkan timeout atau kegagalan saat Anda mencadangkan atau memulihkan data sistem file, seperti data dari OSS, NAS, CPFS, atau volume lokal.

Solusi

• Solusi 1: Masalah kompatibilitas dapat terjadi jika kluster Anda menggunakan plugin penyimpanan CSI non-Alibaba Cloud atau volume yang bukan jenis Kubernetes standar, seperti NFS atau LocalVolume. Dalam kasus ini, ajukan tiket untuk bantuan.

• Solusi 2: Mode Block biasanya hanya diperlukan untuk volume cloud disk. Saat kluster menggunakan plugin penyimpanan CSI, Cloud Backup secara default menggunakan snapshot cloud disk untuk pencadangan data, dan metode ini mendukung volume mode Block. Jika Anda menggunakan plugin penyimpanan yang tidak kompatibel, beralihlah ke CSI, instal ulang komponen cadangan, lalu coba lagi pencadangan tersebut.

• Solusi 3: Ikuti langkah-langkah berikut:

  1. Masuk ke Konsol Cloud Backup.

  2. Di panel navigasi kiri, pilih Cadangan > Container Backup, lalu klik tab Pekerjaan Cadangan.

  3. Di bilah navigasi atas, pilih wilayah.

  4. Di tab Pekerjaan Cadangan, klik daftar drop-down di sebelah kotak pencarian, pilih Job Name, lalu cari <backup-name>-hbr untuk memeriksa status dan penyebab pekerjaan cadangan. Untuk informasi lebih lanjut, lihat Cadangan Container Service for Kubernetes (ACK).

     Catatan

     Untuk mengkueri pekerjaan transisi kelas penyimpanan atau pekerjaan cadangan, cari berdasarkan nama cadangan yang sesuai.

Error cadangan: "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST"

Gejala

Status cadangan adalah Failed, dan pesan error berisi "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST".

Penyebab

• Untuk CSI dari penyedia cloud lain atau jenis penyimpanan yang dikelola sendiri seperti NFS atau Ceph:

  Dalam skenario cloud hibrida, pusat cadangan secara default menggunakan jalur mount volume Kubernetes standar. Untuk driver penyimpanan CSI standar, jalur mount default adalah /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Logika yang sama berlaku untuk driver penyimpanan Kubernetes yang didukung secara resmi lainnya, seperti NFS dan FlexVolume.

  /var/lib/kubelet adalah direktori root kubelet default. Jika Anda mengubah jalur ini di kluster Kubernetes Anda, layanan cloud backup mungkin tidak dapat mengakses data tersebut.

• Untuk penyimpanan HostPath:

  Volume HostPath tidak membuat jalur mount di bawah direktori root kubelet. Sebagai gantinya, pod secara langsung memount jalur yang ditentukan di node. Secara default, komponen cadangan tidak dapat membaca data dari jalur node, sehingga pencadangan gagal.

Solusi

• Untuk CSI dari penyedia cloud lain atau jenis penyimpanan yang dikelola sendiri seperti NFS atau Ceph:

  Masuk ke node tempat volume dimount untuk troubleshooting:

  1. Periksa apakah direktori root kubelet di node telah diubah.

     1. Jalankan perintah berikut untuk memeriksa perintah startup kubelet:

        ps -elf | grep kubelet

        Jika perintah startup mencakup parameter --root-dir, nilainya adalah direktori root kubelet.

        Jika perintah mencakup parameter --config, nilainya adalah jalur ke file konfigurasi kubelet. Di file ini, nilai field root-dir menentukan direktori root kubelet.

     2. Jika perintah startup tidak berisi informasi direktori root, periksa file unit layanan kubelet di /etc/systemd/system/kubelet.service. Jika berisi field EnvironmentFile, misalnya:

        EnvironmentFile=-/etc/kubernetes/kubelet

        Ini berarti file konfigurasi variabel lingkungan adalah /etc/kubernetes/kubelet. Periksa file ini untuk konten berikut:

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

        Di sini, /xxx adalah direktori root kubelet.

     3. Jika tidak ditemukan perubahan terkait, direktori root kubelet adalah default /var/lib/kubelet.

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

     ls -al <root-dir>

     Jika outputnya mirip dengan berikut:

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

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

  3. Periksa bahwa data volume target ada di direktori root.

     Periksa bahwa jalur mount volume <root-dir>/pods/<pod-uid>/volumes ada dan berisi subdirektori untuk jenis penyimpanan target, 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, mengganti /var/lib/container/kubelet dalam nilai dengan direktori root kubelet sebenarnya yang Anda identifikasi dari konfigurasi dan tautan simbolik.

• Untuk penyimpanan HostPath:

  Ajukan tiket.

Kegagalan pencadangan: Error akses file OSS

Gejala

Status cadangan adalah Failed dan pesan error berisi "upload backup files to OSS bucket failed."

Penyebab

Masalah ini terjadi ketika komponen menerima error dari server OSS saat mencoba memeriksa, mengunggah, atau mengunduh file dengan bucket OSS untuk penyimpanan cadangan. Penyebab yang mungkin:

• Penyebab 1: Enkripsi data diaktifkan untuk bucket OSS, tetapi izin KMS yang diperlukan belum diberikan.

• Penyebab 2: Izin baca dan tulis yang diperlukan untuk kluster ACK dedicated dan kluster terdaftar belum diberikan selama instalasi komponen.

• Penyebab 3: Kredensial akses pengguna RAM yang digunakan untuk mengonfigurasi izin untuk kluster ACK dedicated atau terdaftar telah dicabut.

Solusi

• Solusi 1: Lihat Memberikan izin KMS yang diperlukan untuk bucket OSS terenkripsi.

• Solusi 2: Verifikasi kebijakan izin pengguna RAM yang digunakan untuk mengonfigurasi izin. Untuk kebijakan izin yang diperlukan oleh komponen, lihat Langkah 1: Konfigurasi izin.

• Solusi 3: Verifikasi bahwa kredensial akses pengguna RAM yang digunakan untuk mengonfigurasi izin telah diaktifkan. Jika kredensial telah dicabut, peroleh kredensial baru, perbarui Secret alibaba-addon-secret di namespace csdr, lalu restart komponen dengan menjalankan perintah berikut:

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

Pencadangan PartiallyFailed dengan pesan Velero

Gejala

Status cadangan adalah PartiallyFailed, dan pesan berisi "PROCESS velero partially completed".

Penyebab

Ini terjadi ketika komponen velero gagal mencadangkan beberapa resource dalam kluster aplikasi.

Solusi

Jalankan perintah berikut untuk mengidentifikasi resource yang gagal dan penyebabnya.

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

Gunakan informasi di field Errors dan Warnings dari output untuk menyelesaikan masalah.

Jika output tidak mengidentifikasi penyebabnya, jalankan perintah berikut untuk mendapatkan log cadangan.

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

Pekerjaan cadangan PartiallyFailed dengan error "PROCESS hbr partially completed"

Gejala

Status pekerjaan cadangan adalah PartiallyFailed dengan error "PROCESS hbr partially completed".

Penyebab

Masalah ini terjadi ketika Cloud Backup gagal mencadangkan beberapa resource dari sistem file seperti OSS, NAS, CPFS, atau volume penyimpanan lokal.

• Penyebab 1: Beberapa volume data menggunakan plugin penyimpanan yang 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 kiri, pilih Cadangan > Container Backup, lalu klik tab Pekerjaan Cadangan.

3. Di bilah navigasi atas, pilih wilayah.

4. Di tab Pekerjaan Cadangan, pilih Job Name dari filter pencarian, lalu cari <backup-name>-hbr untuk menyelidiki mengapa pencadangan volume penyimpanan gagal. Untuk informasi lebih lanjut, lihat Cadangkan kluster Container Service for Kubernetes (ACK).

Konversi kelas penyimpanan gagal: "storageclass xxx not exists"

Gejala

Status konversi kelas penyimpanan adalah Failed, dengan pesan error "storageclass xxx not exists".

Penyebab

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

Solusi

1. Jalankan perintah berikut untuk mengatur ulang tugas konversi kelas penyimpanan.

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

2. Buat kelas penyimpanan yang hilang di kluster saat ini.

3. Jalankan ulang tugas pemulihan dan konfigurasikan konversi kelas penyimpanan.

Konversi kelas penyimpanan gagal dengan provisioner yang tidak didukung

Gejala

Status konversi kelas penyimpanan adalah Failed, dan pesan error berisi "only support convert to storageclass with CSI diskplugin or nasplugin provisioner".

Penyebab

Masalah ini terjadi karena kelas penyimpanan target yang dipilih tidak menggunakan provisioner CSI Alibaba Cloud untuk volume cloud disk atau NAS.

Solusi

• Versi saat ini hanya mendukung pembuatan dan pemulihan snapshot untuk volume cloud disk, NAS, dan OSS. Untuk memulihkan jenis volume lain, ajukan tiket.

• Atau, untuk produk penyimpanan yang dapat diakses publik seperti OSS Alibaba Cloud, Anda dapat menggunakan mount statis untuk membuat PersistentVolume dan PersistentVolumeClaim. Metode ini memungkinkan Anda memulihkan aplikasi secara langsung tanpa langkah konversi kelas penyimpanan. Untuk informasi lebih lanjut, lihat Gunakan volume statis dengan ossfs 1.0.

Konversi kelas penyimpanan gagal dengan error "multi-zoned"

Gejala

Status konversi kelas penyimpanan adalah Failed, dan pesan error berisi "current cluster is multi-zoned".

Penyebab

Masalah ini terjadi saat Anda mengonversi ke kelas penyimpanan cloud disk di kluster multi-AZ, dan kelas penyimpanan target memiliki volumeBindingMode diatur ke Immediate. Di kluster multi-AZ, pengaturan ini dapat membuat volume penyimpanan di zona ketersediaan yang berbeda dari tempat pod dijadwalkan. Ketidakcocokan ini mencegah pod dijadwalkan ke node target, sehingga pod tetap dalam status Pending. Untuk informasi lebih lanjut tentang field volumeBindingMode, lihat kelas penyimpanan.

Solusi

1. Jalankan perintah berikut untuk mengatur ulang tugas konversi kelas penyimpanan.

   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 perlu mengonversi ke kelas penyimpanan cloud disk:

   • Di konsol, pilih alicloud-disk. alicloud-disk secara default menggunakan kelas penyimpanan alicloud-disk-topology-alltype.

   • Dari baris perintah, pilih alicloud-disk-topology-alltype. Ini adalah kelas penyimpanan default yang disediakan oleh plugin penyimpanan CSI. Anda juga dapat membuat kelas penyimpanan kustom dengan volumeBindingMode diatur ke WaitForFirstConsumer.

3. Coba lagi konversi kelas penyimpanan.

Tugas pemulihan gagal dengan error "multi-node writing"

Gejala

Tugas pemulihan atau konversi kelas penyimpanan gagal dengan pesan error berikut: "multi-node writing is only supported for block volume. For Kubernetes users, if unsure, use ReadWriteOnce access mode in PersistentVolumeClaim for disk volume".

Penyebab

Driver CSI memvalidasi accessModes volume cloud disk selama proses mount untuk mencegah detach paksa. Detach paksa dapat terjadi jika node mencoba memount disk yang sedang digunakan. Driver melarang penggunaan ReadWriteMany atau ReadOnlyMany untuk jenis volume ini.

Driver CSI dapat memicu error ini saat memulihkan aplikasi ke cloud disk Alibaba Cloud, karena disk ini secara default tidak mendukung attachment multi-node. Hal ini terjadi jika volume aplikasi yang dicadangkan menggunakan pengaturan accessModes ReadWriteMany atau ReadOnlyMany. Pengaturan ini umum untuk penyimpanan jaringan multi-attach, seperti OSS atau NAS.

Secara khusus, error ini dapat terjadi dalam tiga skenario berikut:

Skenario 1: Kluster cadangan menggunakan versi lama driver CSI atau plugin penyimpanan FlexVolume. Versi lama driver CSI tidak memvalidasi field accessModes untuk volume cloud disk selama proses mount. Akibatnya, error terjadi saat memulihkan volume asli ke kluster yang menjalankan versi CSI yang lebih baru.

Skenario 2: Kelas penyimpanan kustom yang digunakan oleh volume yang dicadangkan tidak ada di kluster tujuan. Akibatnya, volume dipulihkan secara default sebagai volume cloud disk Alibaba Cloud.

Skenario 3: Selama pemulihan, Anda menggunakan fitur konversi kelas penyimpanan untuk memulihkan volume yang dicadangkan sebagai volume cloud disk Alibaba Cloud.

Solusi

Skenario 1: Mulai dari versi v1.8.4, komponen cadangan secara otomatis mengonversi field accessModes volume cloud disk ke ReadWriteOnce. Tingkatkan komponen Pusat Cadangan lalu coba lagi pemulihan.

Skenario 2: Memulihkan kelas penyimpanan secara otomatis di kluster tujuan dapat menyebabkan data tidak dapat diakses atau ditimpa. Untuk mencegah hal ini, buat kelas penyimpanan dengan nama yang sama di kluster tujuan sebelum memulihkan, atau gunakan fitur konversi kelas penyimpanan untuk menentukan kelas penyimpanan target.

Skenario 3: Saat memulihkan volume penyimpanan jaringan sebagai volume cloud disk, gunakan parameter convertToAccessModes untuk mengatur accessModes ke ReadWriteOnce. Untuk informasi lebih lanjut, lihat convertToAccessModes: Daftar accessModes target.

Tugas pemulihan gagal dengan error lintas wilayah

Gejala

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

Penyebab

Sejak v1.7.7, komponen migrate-controller Pusat Cadangan mendukung pemulihan lintas wilayah untuk pencadangan cloud disk. Pemulihan lintas wilayah untuk jenis data lain belum didukung.

Solusi

• Untuk produk penyimpanan yang dapat diakses melalui jaringan publik, seperti OSS Alibaba Cloud, buat persistent volume claim dan persistent volume menggunakan mounting statis sebelum memulihkan aplikasi. Untuk informasi lebih lanjut, lihat Gunakan volume statis ossfs 1.0.

Pekerjaan pemulihan gagal: "ECS snapshot cross region request failed"

Gejala

Pekerjaan pemulihan memiliki status Failed, dan pesan error mencakup "ECS snapshot cross region request failed".

Penyebab

Sejak versi 1.7.7, komponen migrate-controller Pusat Cadangan telah mendukung pemulihan lintas wilayah untuk pencadangan cloud disk. Error ini menunjukkan bahwa izin yang diperlukan untuk snapshot cloud disk ECS tidak ada.

Solusi

Untuk kluster ACK dedicated atau kluster terdaftar yang menjalankan Kubernetes yang dikelola sendiri pada instance ECS, Anda harus melampirkan kebijakan izin yang diperlukan untuk snapshot cloud disk ECS. Untuk informasi lebih lanjut, lihat kluster terdaftar.

Tugas pemulihan gagal dengan error accessMode PVC

Gejala

Tugas pemulihan gagal dengan pesan error yang berisi "accessMode of PVC xxx is xxx".

Penyebab

Jika Anda ingin memulihkan volume cloud disk, AccessMode-nya harus diatur ke ReadOnlyMany atau ReadWriteMany.

Saat volume penyimpanan cloud disk dipulihkan, plugin penyimpanan CSI harus memount-nya. Versi CSI saat ini memiliki batasan berikut:

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

• Volume penyimpanan dengan VolumeMode Filesystem (yaitu, dimount menggunakan sistem file seperti ext4 atau xfs) hanya mendukung mounting read-only di beberapa node.

Untuk informasi lebih lanjut tentang penyimpanan cloud disk, lihat Gunakan volume cloud disk dinamis.

Solusi

• Jika Anda menggunakan fitur transisi kelas penyimpanan untuk mengonversi volume penyimpanan yang mendukung beberapa jenis mount, seperti volume OSS atau NAS, ke cloud disk, kami sarankan Anda membuat tugas pemulihan baru untuk mempertahankan berbagi data di antara replika. Dalam tugas ini, pilih alibabacloud-cnfs-nas sebagai jenis target untuk transisi kelas penyimpanan untuk menggunakan volume penyimpanan NAS yang dikelola oleh CNFS. Untuk informasi lebih lanjut, lihat Kelola sistem file NAS menggunakan CNFS.

• Jika cadangan volume penyimpanan cloud disk Anda dibuat menggunakan versi CSI sebelumnya yang tidak memeriksa AccessMode, dan volume yang dicadangkan itu sendiri tidak memenuhi persyaratan pembuatan versi CSI saat ini, kami sarankan Anda memprioritaskan refaktoring layanan asli Anda untuk menggunakan volume penyimpanan cloud disk dinamis untuk menghindari risiko detach paksa saat volume dijadwalkan ke node lain.

Beberapa resource hilang setelah pemulihan

Gejala

Status tugas pemulihan adalah Completed, tetapi beberapa resource hilang dari kluster pemulihan.

Penyebab

• Penyebab 1: Resource tersebut tidak dicadangkan.

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

• Penyebab 3: Subtugas pemulihan aplikasi sebagian gagal.

• Penyebab 4: Resource tersebut berhasil dipulihkan tetapi kemudian dihapus oleh garbage collection 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 resource target dicadangkan. Jika tidak, periksa apakah resource tersebut dikecualikan oleh konfigurasi cadangan (misalnya, pengaturan untuk namespace dan resource yang disertakan atau dikecualikan), lalu buat cadangan baru. Secara default, resource tingkat kluster untuk aplikasi (Pod) di namespace yang tidak dipilih tidak dicadangkan. Untuk mencadangkan semua resource tingkat kluster, lihat cadangan tingkat kluster.

Solusi 2:

Jika resource target tidak dipulihkan, periksa apakah resource tersebut dikecualikan oleh konfigurasi pemulihan (misalnya, pengaturan untuk namespace dan resource yang disertakan atau dikecualikan), lalu mulai tugas pemulihan baru.

Solusi 3:

Jalankan perintah berikut untuk mengidentifikasi resource yang gagal dan alasan 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> 

Tinjau pesan di field Errors dan Warnings dari output untuk menyelesaikan masalah.

Solusi 4:

Periksa log audit resource untuk menentukan apakah resource tersebut dihapus secara tidak terduga setelah dibuat.

migrate-controller gagal dimulai di kluster Flexvolume

Komponen migrate-controller Pusat Cadangan tidak kompatibel dengan kluster Flexvolume. Untuk menggunakan Pusat Cadangan, migrasikan plugin Flexvolume ke CSI menggunakan salah satu metode berikut.

• Migrasi Flexvolume ke CSI menggunakan komponen csi-compatible-controller

• Migrasi Flexvolume ke CSI untuk kluster tanpa penyimpanan persisten

• Migrasi volume penyimpanan statis NAS berbasis Flexvolume ke CSI

• Migrasi volume penyimpanan statis OSS berbasis Flexvolume ke CSI

• Untuk skenario yang tidak tercakup di sini, bergabunglah dengan grup pengguna DingTalk kami (ID Grup: 35532895).

Untuk mencadangkan beban kerja dari kluster Flexvolume dan memulihkannya ke kluster CSI selama migrasi Flexvolume-ke-CSI, lihat Migrasi aplikasi dari versi Kubernetes sebelumnya menggunakan Pusat Cadangan.

Memodifikasi penyimpanan cadangan

Pusat Cadangan tidak mendukung modifikasi penyimpanan cadangan. Untuk mengubah konfigurasi vault, Anda harus menghapus vault yang ada dan membuat yang baru dengan nama berbeda.

Penyimpanan cadangan adalah resource bersama yang mungkin sedang melakukan operasi Backup atau Restore kapan saja. Memodifikasi parameternya saat digunakan dapat menyebabkan operasi ini gagal, karena sistem mungkin tidak dapat menemukan data. Untuk memastikan integritas data dan mencegah kegagalan operasional, penyimpanan cadangan tidak dapat dimodifikasi atau dibuat ulang dengan nama yang sama.

Lokasi cadangan dan bucket yang tidak mengikuti format "cnfs-oss-*"

Untuk jenis kluster selain kluster ACK dedicated dan kluster terdaftar, komponen Pusat Cadangan memiliki izin baca dan tulis default untuk bucket OSS yang dinamai dengan awalan cnfs-oss-*. Untuk mencegah penimpaan data, kami sarankan membuat bucket OSS khusus untuk Pusat Cadangan yang mengikuti konvensi penamaan cnfs-oss-*.

1. Untuk mengaitkan lokasi cadangan dengan bucket OSS yang tidak mengikuti format penamaan "cnfs-oss-*", Anda harus mengonfigurasi izin untuk komponen tersebut. Untuk informasi lebih lanjut, lihat Kluster ACK dedicated.

2. Setelah Anda mengonfigurasi izin, jalankan perintah berikut untuk me-restart 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 lokasi cadangan yang dikaitkan dengan bucket OSS yang tidak mengikuti format penamaan "cnfs-oss-*", tunggu hingga pemeriksaan konektivitas selesai dan status berubah menjadi Available sebelum melakukan cadangan atau pemulihan. Pemeriksaan konektivitas berjalan sekitar setiap lima menit. Untuk mengkueri status lokasi cadangan, jalankan perintah berikut.

   kubectl -n csdr get backuplocation

   Output yang diharapkan:

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

Jadwal cadangan

Jadwal cadangan dapat berupa ekspresi cron (misalnya, 1 4 * * *) atau jadwal berbasis interval (misalnya, 6h30m membuat cadangan setiap 6 jam 30 menit).

Ekspresi cron menentukan jadwal menggunakan lima field. Tanda bintang (*) berfungsi sebagai wildcard, yang mewakili nilai apa pun yang valid untuk suatu field.

• 1 4 * * *: Membuat cadangan setiap hari pukul 04.01.

• 0 2 15 * 1: Membuat cadangan setiap tanggal 15 setiap bulan dan setiap hari Senin pukul 02.00.

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

Penyesuaian default untuk resource YAML

Selama tugas pemulihan, sistem melakukan penyesuaian default berikut terhadap resource YAML:

Penyesuaian 1:

Jika volume penyimpanan cloud disk lebih kecil dari 20 GiB, tugas pemulihan meningkatkan kapasitasnya menjadi 20 GiB.

Penyesuaian 2:

Lihat resource cadangan

Resource cadangan aplikasi

File YAML untuk resource kluster disimpan di Bucket OSS yang terkait dengan repositori cadangan. Anda dapat melihat resource yang dicadangkan dengan salah satu cara berikut.

• Di kluster mana pun yang menyinkronkan cadangan, jalankan perintah berikut untuk melihat resource tersebut.

  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 resource tersebut di konsol Container Service for Kubernetes (ACK).

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

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

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

Resource cadangan volume cloud disk

1. Masuk ke Konsol ECS.

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

3. Di pojok kiri atas halaman, pilih wilayah dan kelompok resource.

4. Di halaman Snapshot, cari snapshot berdasarkan ID cloud disk.

Resource cadangan volume non-cloud disk

1. Masuk ke Konsol Cloud Backup.

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

3. Di bilah navigasi atas, pilih wilayah.

4. Lihat cadangan kontainer.

   • Tab Clusters mencantumkan kluster Anda yang dilindungi. Klik ACK Cluster ID untuk melihat klaim volume persisten (PVC) yang dilindungi. Untuk informasi lebih lanjut, lihat Klaim volume persisten (PVC).

     Jika Client Status tidak normal, ini menunjukkan bahwa layanan Cloud Backup tidak berjalan dengan benar di kluster ACK. Untuk mengatasi hal ini, buka halaman DaemonSets di konsol ACK. Daftar mencakup kolom seperti ID Kluster ACK, Kluster ACK, Jenis Jaringan, Status Klien, Keterangan, dan Tindakan. Status Klien Ready menunjukkan bahwa klien kluster berhasil terdaftar. Di kolom Tindakan, Anda dapat mengklik Lihat Klaim Penyimpanan yang Dilindungi untuk detail lebih lanjut.

   • Tab Backup Jobs menampilkan status berjalan pekerjaan cadangan.

     Anda dapat memfilter pekerjaan di tab ini berdasarkan ID Kluster ACK. Daftar pekerjaan mencakup kolom seperti Pekerjaan Cadangan/ID, ID Kluster ACK, Nama/Vault ID, Klaim Volume Persisten/ID, Ukuran Data Sumber, Penggunaan Vault, Kecepatan Cadangan, Periode Waktu, Status, dan Tindakan. Tab ini memberikan detail untuk setiap pekerjaan cadangan, seperti ukuran data sumber, penggunaan vault setelah deduplikasi, kecepatan transfer, waktu eksekusi, dan progres.

Cadangan dan pemulihan lintas versi

Ya.

Selama pencadangan, semua apiVersions yang didukung untuk setiap resource ditangkap secara default. Misalnya, resource Deployment di kluster Kubernetes 1.16 mendukung versi API extensions/v1beta1, apps/v1beta1, apps/v1beta2, dan apps/v1. Repositori cadangan menyimpan keempat representasi resource Deployment tersebut, terlepas dari versi mana yang awalnya digunakan untuk deployment. Fitur Convert Kubernetes yang mendasarinya menangani proses ini.

Selama pemulihan, resource dipulihkan menggunakan apiVersion yang disukai oleh kluster target. Misalnya, karena apiVersion yang disukai untuk Deployment di kluster Kubernetes 1.28 adalah apps/v1, proses tersebut memulihkan cadangan sebagai Deployment apps/v1.

Traffic load balancer selama pemulihan

No.

Secara default, baik menonaktifkan pendengaran paksa maupun membuat instance SLB baru tidak secara otomatis mengalihkan traffic ke kluster cadangan. Jika Anda menggunakan produk cloud lain atau penemuan layanan pihak ketiga dan ingin mencegah pengalihan traffic otomatis, pertimbangkan untuk mengecualikan resource Service dari cadangan. Ini memungkinkan Anda melakukan deployment manual untuk mengalihkan traffic saat siap.

Pengecualian cadangan default

• Namespace csdr adalah namespace kerja untuk Pusat Cadangan. Mencadangkan dan memulihkan namespace ini secara langsung dapat menyebabkan komponen Pusat Cadangan tidak berfungsi di kluster pemulihan. Selain itu, Pusat Cadangan secara otomatis menyinkronkan cadangan, sehingga migrasi cadangan secara manual ke kluster baru tidak diperlukan.

• Namespace ack-csi-fuse adalah namespace kerja untuk komponen penyimpanan CSI dan menjalankan Pod klien FUSE yang dikelola oleh CSI. Saat Anda memulihkan penyimpanan di kluster baru, CSI di kluster tersebut secara otomatis menyediakan Pod klien yang diperlukan. Oleh karena itu, pencadangan dan pemulihan manual tidak diperlukan.

• Namespace kube-system, kube-public, dan kube-node-lease adalah namespace sistem default di kluster Kubernetes. Karena parameter dan konfigurasi kluster bervariasi antar lingkungan, namespace ini tidak dapat dipulihkan begitu saja dari satu kluster ke kluster lain. Pusat Cadangan dirancang untuk mencadangkan dan memulihkan aplikasi bisnis, bukan infrastruktur kluster yang mendasarinya. Sebelum memulai tugas pemulihan, Anda harus menginstal dan mengonfigurasi komponen sistem yang diperlukan di kluster pemulihan. Misalnya:

  • Komponen bebas kredensial ACR: Otorisasi ulang dan konfigurasikan acr-configuration untuk kluster pemulihan.

  • Komponen ALB Ingress: Pra-konfigurasikan ALBConfig dan pengaturan lainnya.

  Mencadangkan komponen sistem secara langsung dari namespace kube-system ke kluster baru dapat menyebabkan kegagalan.

Cadangan dengan snapshot cloud disk ECS

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

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

2. Kluster menjalankan versi 1.18 atau lebih baru dan menggunakan plugin penyimpanan CSI versi 1.18 atau lebih baru.

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

Secara default, snapshot cloud disk yang dibuat oleh Pusat Cadangan memiliki fitur ketersediaan snapshot cepat yang diaktifkan. Periode retensinya sesuai dengan yang ditentukan dalam konfigurasi cadangan. Sejak pukul 11.00 pada 12 Oktober 2023, Alibaba Cloud tidak lagi membebankan biaya penyimpanan atau permintaan untuk fitur ketersediaan snapshot cepat di semua wilayah. Untuk informasi lebih lanjut, lihat ketersediaan snapshot cepat.

Periode retensi snapshot ECS yang tidak konsisten

Pembuatan snapshot cloud disk bergantung pada komponen csi-provisioner kluster (atau komponen managed-csiprovisioner). Jika versi komponen csi-provisioner lebih lama dari 1.20.6, komponen tersebut tidak mendukung penentuan periode retensi atau mengaktifkan fitur ketersediaan snapshot cepat saat membuat resource snapshot terkait (VolumeSnapshot). Akibatnya, periode retensi yang ditentukan dalam konfigurasi cadangan tidak berlaku untuk snapshot cloud disk ECS.

Oleh karena itu, untuk menggunakan fitur pencadangan data untuk volume cloud disk, tingkatkan komponen csi-provisioner ke versi 1.20.6 atau lebih baru.

Jika Anda tidak dapat meningkatkan komponen csi-provisioner di kluster Anda, Anda dapat mengonfigurasi periode retensi snapshot default dengan mengikuti langkah-langkah berikut:

1. Tingkatkan komponen migrate-controller pusat cadangan ke versi 1.7.10 atau lebih baru.

2. Jalankan perintah berikut untuk memeriksa apakah kelas snapshot dengan periode retensi default 30 hari ada di kluster.

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

   • Jika kelas snapshot tidak ada, buat kelas snapshot csdr-disk-snapshot-with-default-ttl menggunakan manifes YAML berikut.

   • Jika sudah ada, cukup atur retentionDays di kelas snapshot 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 Anda menerapkan konfigurasi ini, cadangan volume cloud disk di kluster ini akan membuat snapshot dengan periode retensi yang sesuai dengan nilai retentionDays.

   Penting

   Untuk memastikan periode retensi snapshot cloud disk ECS dari cadangan selalu sesuai dengan konfigurasi cadangan, tingkatkan komponen csi-provisioner ke versi 1.20.6 atau lebih baru.

Kapan harus mencadangkan data volume penyimpanan

Apa itu pencadangan volume penyimpanan?

Mencadangkan data volume penyimpanan berarti menyimpan isinya ke penyimpanan cloud menggunakan layanan seperti snapshot cloud disk ECS atau HBR. Selama pemulihan, data ini kemudian dimuat ke cloud disk atau volume NAS baru untuk digunakan oleh aplikasi yang dipulihkan. Proses ini memastikan bahwa aplikasi yang dipulihkan dan aplikasi asli tidak berbagi sumber data, yang memungkinkan keduanya beroperasi secara independen.

Jika Anda tidak perlu menyalin data atau jika Anda memerlukan sumber data bersama, Anda dapat memilih untuk tidak mencadangkan data volume penyimpanan. Dalam kasus ini, pastikan bahwa resource PVC dan PV tidak ada dalam daftar pengecualian di konfigurasi cadangan Anda. Selama pemulihan, proses pemulihan menerapkan volume penyimpanan langsung ke kluster baru berdasarkan konfigurasi YAML aslinya.

Kasus penggunaan

• Untuk pemulihan bencana (DR) dan versioning data.

• Saat menggunakan cloud disk, karena cloud disk hanya dapat dilampirkan ke satu node.

• Untuk pencadangan dan pemulihan lintas wilayah, karena sebagian besar jenis penyimpanan kecuali OSS tidak memiliki akses lintas wilayah.

• Saat isolasi data diperlukan antara aplikasi sumber dan aplikasi yang dipulihkan.

• Saat terdapat perbedaan signifikan dalam plugin penyimpanan atau versinya antara kluster sumber dan kluster pemulihan yang mencegah pemulihan langsung dari YAML asli.

Risiko tidak mencadangkan data

Jika Anda tidak mencadangkan data volume penyimpanan dan cadangan mencakup aplikasi berstatus, pemulihan berperilaku sebagai berikut:

• Untuk volume penyimpanan dengan kebijakan reclaim Delete:

  Proses ini mirip dengan deployment PVC awal. Jika kelas penyimpanan yang cocok ada di kluster pemulihan, driver CSI secara otomatis menyediakan PV baru. Misalnya, dengan penyimpanan cloud disk, sistem melampirkan cloud disk baru yang kosong ke aplikasi yang dipulihkan. Untuk PV yang disediakan secara statis tanpa kelas penyimpanan yang ditentukan, atau jika kluster pemulihan tidak memiliki kelas penyimpanan yang cocok, PVC dan pod yang dipulihkan akan tetap dalam status Pending hingga Anda membuat PV atau kelas penyimpanan yang diperlukan secara manual.

• Untuk volume penyimpanan dengan kebijakan reclaim Retain:

  Selama pemulihan, proses pemulihan memulihkan PV lalu PVC secara berurutan berdasarkan konfigurasi YAML aslinya. Untuk penyimpanan multi-attach seperti NAS atau OSS, ini memungkinkan aplikasi yang dipulihkan menggunakan kembali sistem file atau bucket asli. Namun, untuk cloud disk, ini berisiko detach paksa.

Anda dapat menjalankan perintah berikut untuk mengkueri kebijakan reclaim volume penyimpanan:

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

Pilih node untuk pencadangan sistem file

Cloud Backup mencadangkan dan memulihkan volume, kecuali cloud disk, dengan menjalankan tugas di node. Kebijakan penjadwalan default Scheduler ACK sesuai dengan scheduler Kubernetes komunitas. Anda juga dapat mengonfigurasi kebijakan untuk membatasi tugas ke node tertentu.

Kebijakan penjadwalan node

• kebijakan exclude (default): Secara default, semua node dapat digunakan untuk cadangan dan pemulihan. Jika Anda tidak ingin tugas cloud backup dijadwalkan ke node tertentu, Anda perlu menambahkan 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 yang tidak diberi tag tidak dapat digunakan untuk cadangan dan pemulihan. Anda harus menambahkan tag csdr.alibabacloud.com/agent-included="true" ke node yang diizinkan untuk melakukan tugas cloud backup.

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

• prefer: Secara default, node mana pun dapat menjalankan tugas cadangan dan pemulihan. Prioritas penjadwalan adalah sebagai berikut:

  1. Prioritas pertama: Node dengan label csdr.alibabacloud.com/agent-included="true".

  2. Prioritas kedua: Node tanpa label khusus.

  3. Prioritas terakhir: Node dengan label csdr.alibabacloud.com/agent-excluded="true".

Ubah kebijakan penjadwalan node

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

   kubectl -n csdr edit cm csdr-config

   Di bagian applicationBackup, tambahkan parameter node_schedule_policy seperti yang ditunjukkan pada contoh berikut:

   Contoh

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: csdr-config
     namespace: csdr
   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, prefer.
     pvBackup: |
       batch_snapshot_max_num: 20
       enable_ecs_snapshot: "true"

2. Jalankan perintah berikut untuk me-restart Deployment csdr-controller agar perubahan diterapkan.

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

Pencadangan aplikasi dan perlindungan data

Pencadangan aplikasi:

• Pendekatan ini menargetkan beban kerja di kluster Anda. Ini mencadangkan resource kluster, termasuk aplikasi, layanan, dan file konfigurasi.

• Anda juga dapat mencadangkan data di volume penyimpanan yang dimount oleh aplikasi Anda.

  Catatan

  Pencadangan aplikasi tidak mencakup data di volume penyimpanan yang tidak dimount oleh Pod.

  Untuk mencadangkan aplikasi dengan semua data volume penyimpanannya, Anda juga dapat membuat cadangan perlindungan data.

• Fitur ini ideal untuk migrasi kluster dan memungkinkan pemulihan aplikasi yang cepat dalam skenario pemulihan bencana.

Perlindungan data:

• Pendekatan ini secara khusus menargetkan data volume penyimpanan. Cadangan hanya mencakup klaim volume persisten dan volume persisten.

• Memulihkan cadangan membuat klaim volume persisten baru yang dapat dimount langsung oleh aplikasi Anda. Volume yang dipulihkan ini berisi salinan data terpisah, independen dari yang asli. Jika klaim volume persisten dihapus secara tidak sengaja, pemulihan dari pusat cadangan menyediakan cloud disk baru dengan data yang identik dengan kondisinya saat pencadangan. Klaim volume persisten yang dipulihkan mempertahankan semua parameter mount asli, kecuali instance cloud disk yang mendasarinya, sehingga aplikasi Anda dapat memount-nya tanpa perubahan apa pun.

• Fitur ini untuk replikasi data dan pemulihan bencana.

Melewatkan pencadangan dan pemulihan untuk volume tertentu

Di lingkungan produksi, data dari volume penyimpanan tertentu, seperti data log, dianggap dapat dibuang selama migrasi atau pemulihan bencana.

Anda dapat melewatkan pencadangan dan pemulihan data untuk layanan prioritas rendah yang menggunakan sumber penyimpanan tangguh. Misalnya, layanan penyimpanan seperti OSS menyediakan skalabilitas besar, akses lintas zona ketersediaan atau lintas wilayah, dan kemampuan pemulihan bencana bawaan dengan beberapa replika.

Pertimbangkan namespace yang berisi dua volume: volume penyimpanan A, yang tidak memerlukan cadangan, dan volume penyimpanan B, yang memerlukannya.

Proses pencadangan

1. Gunakan fitur perlindungan data untuk memilih volume penyimpanan B, yang mencadangkan konfigurasi YAML dan data yang sesuai untuk volume penyimpanan B. Untuk informasi lebih lanjut, lihat Cadangkan dan pulihkan aplikasi dalam kluster.

   Catatan

   Saat Anda mencadangkan data, sistem menggunakan snapshot atau layanan cloud backup untuk membuat cadangan independen. Volume penyimpanan yang dipulihkan dari cadangan ini adalah salinan terpisah yang berisi data yang sama dengan aslinya. Perubahan pada salah satu tidak memengaruhi yang lain.

2. Gunakan fitur pencadangan aplikasi untuk memilih namespace yang berisi aplikasi Anda. Untuk opsi Volume Backup, pilih Disable. Tindakan ini mencadangkan konfigurasi YAML untuk volume penyimpanan A dan volume penyimpanan B secara default. Untuk informasi lebih lanjut, lihat Cadangkan dan pulihkan aplikasi dalam kluster.

   Catatan

   Jika Anda tidak perlu menerapkan volume penyimpanan A di kluster baru, tentukan pvc, pv di field Excluded Resources di pengaturan lanjutan untuk menghindari pemulihan konfigurasi YAML-nya.

Proses pemulihan

Proses pemulihan mirip dengan menerapkan aplikasi baru. Anda harus memulihkan volume penyimpanan dan data sebelum memulihkan beban kerja yang menggunakannya.

1. Di kluster tujuan, pulihkan cadangan perlindungan data. Ini memulihkan konfigurasi YAML dan data untuk volume penyimpanan B. Untuk informasi lebih lanjut, lihat Cadangkan dan pulihkan aplikasi dalam kluster.

2. Di kluster tujuan, pulihkan cadangan aplikasi. Tindakan ini memulihkan YAML untuk volume penyimpanan A dan resource aplikasi lainnya. Berdasarkan kebijakan reclaim PV asli untuk volume penyimpanan A, driver CSI menyediakan sumber penyimpanan baru atau menggunakan kembali yang ada. Untuk informasi lebih lanjut, lihat bagian "Apa risiko tidak mencadangkan data volume penyimpanan untuk aplikasi berstatus?" dalam topik Dalam skenario apa saya harus mencadangkan data volume penyimpanan dalam pencadangan aplikasi?.

Anda sekarang telah memulihkan aplikasi, volume penyimpanan A, dan volume penyimpanan B (termasuk datanya).

Enkripsi Bucket OSS dan izin KMS

Anda dapat mengenkripsi Bucket OSS dengan enkripsi sisi server atau enkripsi sisi klien. Saat ini, Pusat Cadangan hanya mendukung enkripsi sisi server untuk Bucket OSS. Anda dapat mengaktifkan dan mengonfigurasi enkripsi sisi server untuk bucket yang terkait secara manual di konsol OSS. Untuk detail tentang enkripsi sisi server untuk Bucket OSS dan konfigurasinya, lihat Enkripsi Sisi Server.

• Jika Anda menggunakan kunci yang dihosting KMS untuk enkripsi dan dekripsi, dan menggunakan Bring Your Own Key (BYOK) dengan menentukan ID CMK, Anda harus memberikan izin KMS tambahan kepada Pusat Cadangan. Ikuti langkah-langkah berikut:

  • Buat kebijakan kustom dengan konten berikut. Lihat Buat Kebijakan Kustom untuk instruksi.

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

    Kebijakan ini memberikan izin untuk menggunakan semua kunci KMS di bawah ID akun Alibaba Cloud yang ditentukan. Untuk kontrol resource yang lebih granular, lihat Informasi Otorisasi.

  • Untuk kluster ACK dedicated atau kluster terdaftar, berikan kebijakan ini kepada pengguna RAM yang digunakan selama instalasi (lihat Kelola Izin Pengguna RAM). Untuk jenis kluster lain, berikan kebijakan kepada peran RAM AliyunCSManagedBackupRestoreRole (lihat Kelola Izin Peran RAM).

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

Ubah image selama pemulihan

Asumsikan aplikasi dalam cadangan Anda menggunakan image berikut: docker.io/library/app1:v1

• Ubah registri image

  Dalam skenario cloud hibrida, saat menerapkan aplikasi lintas penyedia cloud atau memigrasikan aplikasi dari IDC ke cloud, Anda harus terlebih dahulu mengunggah image yang diperlukan ke repositori cloud, seperti Alibaba Cloud Container Registry (ACR).

  Gunakan field imageRegistryMapping untuk mengonfigurasi pemetaan registri. Misalnya, konfigurasi berikut mengubah jalur image menjadi registry.cn-beijing.aliyuncs.com/my-registry/app1:v1.

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

• Ubah repositori image, tag, atau atribut lainnya

  Ini adalah konfigurasi lanjutan. Anda harus mendefinisikan aturan transformasi dalam ConfigMap sebelum memulai pemulihan.

  Misalnya, untuk mengubah image menjadi app2:v2, buat konfigurasi berikut:

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: <config-name>
    namespace: csdr
    labels:
      velero.io/plugin-config: ""
      velero.io/change-image-name: RestoreItemAction
  data:
    "case1": "app1:v1,app2:v2"
    # Untuk mengubah hanya repositori:
    # "case1": "app1,app2"
    # Untuk mengubah hanya tag:
    # "case1": "v1:v2"
    # Untuk mengubah image dari registri tertentu:
    # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

  Jika Anda perlu melakukan beberapa penyesuaian, Anda dapat terus mengonfigurasi case2, case3, dan seterusnya di data.

  Setelah membuat ConfigMap, buat tugas pemulihan seperti biasa, tetapi biarkan field imageRegistryMapping kosong.

  Catatan

  Konfigurasi ini berlaku untuk semua tugas pemulihan di kluster. Untuk menghindari perubahan yang tidak diinginkan, gunakan aturan transformasi spesifik. Komentar memberikan contoh, seperti membatasi cakupan ke registri tertentu. Hapus ConfigMap saat tidak lagi diperlukan.