Container Service for Kubernetes:Cross-version application migration with the backup center

Notes

• Le cluster de sauvegarde et le cluster de restauration doivent se trouver dans la même région. Le cluster de sauvegarde doit exécuter Kubernetes 1.16 ou une version ultérieure. Pour éviter les problèmes de compatibilité des versions d'API, nous vous recommandons de ne pas utiliser le centre de sauvegarde pour migrer des applications d'une version Kubernetes plus récente vers une version plus ancienne.

• Le centre de sauvegarde ne sauvegarde pas les ressources en cours de suppression.

• Pour restaurer des données sur un volume Network Attached Storage (NAS) géré par Container Network File System (CNFS), vous devez créer un StorageClass si vous envisagez de définir le paramètre StorageClass sur alibabacloud-cnfs-nas lors de la restauration. Pour plus d'informations, consultez la rubrique Gérer les systèmes de fichiers NAS à l'aide de CNFS.

• Lors de la restauration d'une application, les ressources sont prioritairement restaurées à l'aide de la version apiVersion recommandée pour la version Kubernetes du cluster de restauration. Si une ressource ne possède pas de version apiVersion prise en charge par les deux versions de cluster, vous devez déployer manuellement cette ressource. Par exemple :

  • Un Deployment dans un cluster Kubernetes 1.16 prend en charge les versions d'API extensions/v1beta1, apps/v1beta1, apps/v1beta2 et apps/v1. Lors de la restauration vers un cluster Kubernetes 1.28, il est restauré à l'aide de la version apps/v1.

  • Un Ingress dans un cluster Kubernetes 1.16 prend en charge les versions d'API extensions/v1beta1 et networking.k8s.io/v1beta1. Vous ne pouvez pas le restaurer directement dans un cluster exécutant Kubernetes 1.22 ou une version ultérieure.

  Pour plus d'informations sur les modifications d'API entre les versions de Kubernetes, consultez les notes de publication d'ACK et le Guide de migration des API obsolètes.

  Important

  Dans un cluster Kubernetes 1.16, les groupes d'API tels que apps et rbac.authorization.k8s.io prennent déjà en charge la version v1. Lorsque vous migrez des applications vers un cluster Kubernetes 1.28, vous devez restaurer manuellement des ressources telles que Ingress et CronJob.

Cas d'utilisation

• Migration d'applications entre plug-ins de stockage

  Les clusters ACK exécutant Kubernetes 1.20 ou une version ultérieure ne prennent plus en charge le plug-in de stockage FlexVolume. Vous pouvez utiliser le centre de sauvegarde pour migrer des applications avec état d'un cluster FlexVolume vers un cluster CSI.

  Remarque

  Vous pouvez migrer des applications depuis des clusters utilisant le plug-in de stockage FlexVolume ou CSI, mais le cluster de restauration doit utiliser le plug-in de stockage CSI.

• Basculement entre clusters présentant des écarts de version Kubernetes importants

  Dans certains scénarios, vous devrez peut-être migrer des services d'un ancien cluster Kubernetes (1.16 ou version ultérieure) vers un nouveau cluster. Par exemple, vous pourriez changer le plug-in réseau de Flannel à Terway. Le centre de sauvegarde prend en charge la migration d'applications entre des versions très différentes et ajuste automatiquement les configurations de base, telles que la version apiVersion dans les modèles d'application, pour les adapter à la nouvelle version de Kubernetes.

Prérequis

• Activer Cloud Backup. Lors de la sauvegarde de volumes persistants NAS, OSS ou de disques locaux, ainsi que dans les scénarios de cloud hybride, le centre de sauvegarde doit utiliser Cloud Backup pour la sauvegarde de fichiers.

• Un cluster dans lequel le volume sera restauré a été créé. Pour garantir que vous puissiez utiliser des snapshots d'instances Elastic Compute Service (ECS) afin de restaurer les données de disque, nous vous recommandons de mettre à jour la version Kubernetes du cluster vers la version 1.18 ou une version ultérieure. Pour plus d'informations, consultez les rubriques Créer un cluster ACK managé, Créer un cluster ACK dédié (obsolète) ou Créer un cluster enregistré ACK One.

  Important

  • Le cluster de restauration doit utiliser le plug-in Container Storage Interface (CSI). La restauration d'applications n'est pas prise en charge dans les clusters qui utilisent FlexVolume ou qui utilisent csi-compatible-controller et FlexVolume.

  • Le centre de sauvegarde est utilisé pour sauvegarder et restaurer des applications. Avant d'exécuter une tâche de restauration, vous devez installer et configurer les composants système dans le cluster de restauration. Exemple :

    • aliyun-acr-credential-helper : vous devez accorder des permissions au cluster de restauration et configurer acr-configuration.

    • alb-ingress-controller : vous devez configurer un ALBConfig.

• Le composant de service de sauvegarde migrate-controller est installé et ses permissions sont configurées. Pour plus d'informations, consultez la rubrique Installer le composant de service de sauvegarde migrate-controller et configurer les permissions.

• Pour sauvegarder des volumes à l'aide de snapshots de disques cloud, vous devez installer le plug-in CSI version 1.1.0 ou ultérieure. Pour plus d'informations, consultez la rubrique Installer et mettre à niveau les composants CSI.

• Se connecter au cluster à l'aide de kubectl.

Flux de migration

Le flux de migration varie en fonction du plug-in de stockage utilisé par le cluster de sauvegarde. Les figures suivantes présentent les détails.

Cluster de sauvegarde sans applications de stockage

Cluster de sauvegarde utilisant FlexVolume

Cluster de sauvegarde utilisant CSI

Procédure

Cette rubrique illustre la migration d'applications, de configurations et de données de volume depuis un cluster ACK utilisant FlexVolume et exécutant Kubernetes 1.16 vers un cluster ACK utilisant CSI et exécutant Kubernetes 1.28. La migration s'effectue soit par changement de source de données, soit en conservant une source de données inchangée. Si vous migrez des applications qui n'utilisent pas de stockage ou si votre cluster de sauvegarde utilise déjà le plug-in de stockage CSI, vous pouvez ignorer les étapes marquées comme Facultatif.

kubectl patch pv/<pv-name> --type='json' -p '[{"op":"replace","path":"/spec/persistentVolumeReclaimPolicy","value":"Retain"}]'

Préparation de l'environnement

Étape 1 : Déploiement d'une application de test

1. Exécutez la commande suivante pour déployer un volume sur disque avec approvisionnement dynamique.

   Remplacez alicloud-disk-topology par le nom de la StorageClass de disque par défaut pour le plug-in de stockage FlexVolume dans votre cluster.

   cat << EOF | kubectl apply -f -
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: disk-essd
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: alicloud-disk-topology
     resources:
       requests:
         storage: 20Gi
   EOF

2. Exécutez la commande suivante pour déployer un volume NAS avec approvisionnement statique.

   Remplacez server par le point de montage du système de fichiers NAS de votre compte.

   cat << EOF | kubectl apply -f -
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-nas
   spec:
     capacity:
       storage: 5Gi
     storageClassName: nas
     accessModes:
       - ReadWriteMany
     flexVolume:
       driver: "alicloud/nas"
       options:
         server: "1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com"
         vers: "3"
         options: "nolock,tcp,noresvport"
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: pvc-nas
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: nas
     resources:
       requests:
         storage: 5Gi
   EOF

3. Exécutez la commande suivante pour déployer l'application. Cette application monte à la fois les volumes sur disque et NAS créés aux étapes précédentes.

   L'apiVersion du code ci-dessous utilise extensions/v1beta1. Cette apiVersion est obsolète dans les clusters version 1.28.

   cat << EOF | kubectl apply -f -
   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           ports:
           - containerPort: 80
           volumeMounts:
             - name: nas
               mountPath: /cold
             - name: disk
               mountPath: /hot
         volumes:
           - name: nas
             persistentVolumeClaim:
               claimName: pvc-nas
           - name: disk
             persistentVolumeClaim:
               claimName: disk-essd   
   EOF

4. Exécutez la commande suivante pour vérifier que l'application déployée a bien démarré.

   kubectl get pod -l app=nginx

   Sortie attendue :

   NAME                    READY   STATUS    RESTARTS   AGE
   nginx-5ffbc895b-xxxxx   1/1     Running   0          2m28s

Étape 2 : Installation du Backup Center dans le cluster de sauvegarde

1. Dans le cluster de sauvegarde, installez le composant de service de sauvegarde migrate-controller.

   Remarque

   • Pour les clusters exécutant Kubernetes 1.16 ou une version ultérieure, vous pouvez installer directement le composant de service de sauvegarde en version V1.7.6 ou supérieure depuis la marketplace des composants.

   • Si votre cluster de sauvegarde est un ACK Dedicated Cluster ou un cluster enregistré, ou s'il utilise un plug-in de stockage autre que CSI (tel que FlexVolume), vous devez configurer des autorisations supplémentaires. Pour plus d'informations, consultez la section Cluster enregistré.

2. (Facultatif) Si votre cluster utilise FlexVolume, exécutez la commande suivante pour confirmer que les autorisations requises sont configurées.

   kubectl -n csdr get secret alibaba-addon-secret

3. (Facultatif) Si votre cluster utilise FlexVolume, exécutez la commande suivante pour ajouter la variable d'environnement USE_FLEXVOLUME au migrate-controller dans le namespace kube-system.

   Important

   Dans un cluster FlexVolume, après l'installation du composant de service de sauvegarde migrate-controller, le pod migrate-controller se termine de manière inattendue et l'accès à la page Application Backup du cluster renvoie une erreur 404. Dans ce cas, vous devez modifier le fichier YAML du composant pour ajouter la variable d'environnement USE_FLEXVOLUME.

   kubectl -n kube-system patch deployment migrate-controller --type json -p '[{"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"USE_FLEXVOLUME","value":"true"}}]'

4. Exécutez les commandes suivantes pour confirmer que le composant de service de sauvegarde fonctionne correctement.

   kubectl -n kube-system get pod -l app=migrate-controller
   kubectl -n csdr get pod 

   Sortie attendue :

   NAME                                  READY   STATUS    RESTARTS   AGE
   migrate-controller-6c8b9c6cbf-967x7   1/1     Running   0          3m55s
   NAME                               READY   STATUS    RESTARTS   AGE
   csdr-controller-69787f6dc8-f886h   1/1     Running   0          3m39s
   csdr-velero-58494f6bf4-52mv6       1/1     Running   0          3m37s

Étape 3 : Création d'une sauvegarde dans le cluster de sauvegarde

1. Dans la même région que le cluster de sauvegarde, créez un bucket OSS nommé selon le format cnfs-oss-* pour stocker les sauvegardes. Pour plus d'informations, consultez la section Créer un bucket.

   Remarque

   Les ACK managed clusters disposent par défaut des autorisations nécessaires pour les buckets OSS dont le nom commence par cnfs-oss-*. Si le format de nommage de votre bucket ne respecte pas ces exigences, vous devez également configurer des autorisations supplémentaires. Pour plus d'informations, consultez la section Installer des composants et configurer les autorisations dans la console.

2. Créer un coffre de sauvegarde.

3. Exécutez la commande suivante pour créer une tâche de sauvegarde immédiate.

   Pour savoir comment configurer les paramètres de sauvegarde dans la console ACK, consultez la section Sauvegarder et restaurer des applications dans un cluster. Cette étape fournit une configuration recommandée pour l'exemple de scénario. Ajustez les paramètres en fonction de votre scénario spécifique.

   cat << EOF | kubectl apply -f -
   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationBackup
   metadata:
     annotations:
       csdr.alibabacloud.com/backuplocations: '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}'
     labels:
       csdr/schedule-name: fake-name
     name: <your-backup-name>
     namespace: csdr
   spec:
     excludedNamespaces:
     - csdr
     - kube-system
     - kube-public
     - kube-node-lease
     excludedResources:
     - storageclasses
     - clusterroles
     - clusterrolebindings
     - events
     - persistentvolumeclaims
     - persistentvolumes
     includeClusterResources: true
     pvBackup:
       defaultPvBackup: true
     storageLocation: <your-backup-vault-name>
     ttl: 720h0m0s
   EOF

   Paramètre	Description
   excludedNamespaces	Les namespaces à exclure de la sauvegarde. Nous vous recommandons d'exclure les namespaces suivants : csdr : le namespace de fonctionnement du centre de sauvegarde. Le centre de sauvegarde intègre une logique de synchronisation inter-cluster. Ne lancez pas manuellement des tâches, telles que des sauvegardes ou des restaurations, dans le namespace csdr. Cette action risque de provoquer un comportement inattendu. kube-system, kube-public et kube-node-lease sont des namespaces existant par défaut dans les clusters ACK. Leur restauration entre différents clusters est complexe en raison des divergences au niveau des paramètres et des configurations des clusters.
   excludedResources	Les ressources à exclure. Configurez ce paramètre selon vos besoins métier.
   includeClusterResources	Indique si les ressources au niveau du cluster, telles que les StorageClasses, les CRD et les webhooks, doivent être sauvegardées. true : sauvegarde toutes les ressources au niveau du cluster. false : sauvegarde uniquement les ressources au niveau du cluster référencées par des ressources au niveau du namespace dans le namespace sélectionné. Par exemple, lorsque vous sauvegardez un Pod, si le ServiceAccount référencé est autorisé par un ClusterRole, le ClusterRole est automatiquement sauvegardé. Lorsque vous sauvegardez une ressource personnalisée (CR), la définition de ressource personnalisée (CRD) est automatiquement sauvegardée. Remarque Par défaut, IncludeClusterResources est défini sur false pour les tâches de sauvegarde créées dans la console ACK.
   defaultPvBackup	Indique si les données de volume doivent être sauvegardées. true : sauvegarde l'application ainsi que les données contenues dans les volumes utilisés par les Pods en cours d'exécution. false : sauvegarde uniquement l'application. Important Pour les clusters exécutant Kubernetes et CSI en version 1.18 ou ultérieure, le centre de sauvegarde utilise par défaut des snapshots ECS pour sauvegarder les données des disques. Pour les autres types de stockage ou pour les données de disque dans les clusters exécutant Kubernetes en version supérieure ou égale à 1.16 mais inférieure à 1.18, Cloud Backup est utilisé. Pour les volumes non utilisés par des Pods en cours d'exécution, seule la méthode de source de données inchangée est disponible. Cela nécessite la création manuelle d'un PV statique et d'un PVC dans le nouveau cluster, ainsi que la spécification de la source de données d'origine, telle qu'un ID de disque ou un compartiment OSS. Si votre application exige une forte cohérence des données, suspendez les écritures de données pendant la période de sauvegarde. Vous pouvez également opter pour la méthode de source de données inchangée et ne sauvegarder que l'application.

4. Exécutez la commande suivante pour interroger l'état de la tâche de sauvegarde.

   kubectl -ncsdr describe applicationbackup <your-backup-name>

   Dans la sortie attendue, le paramètre Phase de Status passe à Completed, ce qui indique que la tâche de sauvegarde a été créée avec succès.

5. Exécutez les commandes suivantes pour confirmer la liste des ressources pour cette sauvegarde.

   kubectl -ncsdr get pod | grep csdr-velero
   kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe backup <your-backup-name> --details

   Vous pouvez vérifier la liste des ressources qui n'ont pas été sauvegardées et ajuster la configuration de sauvegarde pour relancer la sauvegarde.

   Resource List:
     apiextensions.k8s.io/v1/CustomResourceDefinition:
       - volumesnapshots.snapshot.storage.k8s.io
     v1/Endpoints:
       - default/kubernetes
     v1/Namespace:
       - default
     v1/PersistentVolume:
       - d-2ze88915lz1il01v1yeq
       - pv-nas
     v1/PersistentVolumeClaim:
       - default/disk-essd
       - default/pvc-nas
     v1/Secret:
       - default/default-token-n7jss
       - default/oss-secret
       - default/osssecret
     v1/Service:
       - default/kubernetes
     v1/ServiceAccount:
       - default/default
     ...

Étape 4 : Installer le centre de sauvegarde dans le cluster de restauration

1. Installez le centre de sauvegarde dans le cluster de restauration. Pour plus d'informations, consultez Étape 2 : Installer le centre de sauvegarde dans le cluster de sauvegarde.

2. Associez le coffre-fort de sauvegarde que vous avez créé au cluster de restauration.

   1. Connectez-vous à la console ACK.

   2. Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, choisissez Operations > Application Backup.

   3. Sur la page Application Backup, cliquez sur Restore.

   4. Sélectionnez le Backup Vault utilisé pour la sauvegarde, cliquez sur Initialize Backup Vault et attendez que la sauvegarde soit synchronisée avec ce cluster.

(Facultatif) Étape 5 : Créer manuellement des PVC et des PV dans le cluster de restauration

Dans la plupart des scénarios, il suffit de suivre l'étape 6 pour créer directement une tâche de restauration dans le cluster de restauration. Le composant du centre de sauvegarde génère alors automatiquement les revendications de stockage et les volumes en fonction de la sauvegarde.

Lorsque le centre de sauvegarde exécute une tâche de restauration, il ignore la restauration des PVC et des PV portant les mêmes noms afin de protéger les données existantes. Cela signifie qu'il ne les reconstruit pas et n'écrase pas les données contenues dans les volumes. Par conséquent, dans les scénarios suivants, vous pouvez précréer les PVC et les PV avant la tâche de restauration pour une récupération plus flexible :

• Vous avez sauvegardé des volumes, mais certains d'entre eux contiennent des données qui ne doivent pas être migrées, comme des journaux. Vous pouvez précréer des volumes vides.

• Vous avez sauvegardé des volumes, mais les volumes du cluster de sauvegarde qui ne sont pas utilisés par des Pods en cours d'exécution doivent également être migrés vers le cluster de restauration.

• Vous n'avez pas sauvegardé les volumes et la liste excludedResources inclut persistentvolumeclaims et persistentvolumes, ou la migration implique le déplacement d'une application d'un cluster FlexVolume vers un cluster CSI.

Voici les étapes spécifiques :

1. (Facultatif) Si votre cluster de sauvegarde est un cluster FlexVolume, vous pouvez utiliser un outil en ligne de commande pour convertir par lots les fichiers YAML, car le format YAML des PV et des PVC diffère entre FlexVolume et CSI. Pour plus d'informations, consultez Utiliser l'outil en ligne de commande FlexVolume2CSI pour convertir par lots les fichiers YAML.

2. Exécutez la commande suivante pour déployer le fichier YAML CSI obtenu à partir de FlexVolume2CSI.

   où outputfile.txt correspond à la sortie de la conversion YAML effectuée par l'outil en ligne de commande.

   Développer pour afficher le fichier outputfile.txt

   ---
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     labels:
       alicloud-pvname: d-2ze88915lz1il0**** # The dynamically created disk.
     name: d-2ze88915lz1il0****
   spec:
     accessModes:
     - ReadWriteOnce
     capacity:
       storage: 20Gi
     csi:
       driver: diskplugin.csi.alibabacloud.com
       fsType: ext4
       volumeHandle: d-2ze88915lz1il0****
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: topology.diskplugin.csi.alibabacloud.com/zone
             operator: In
             values:
             - cn-beijing-i
     persistentVolumeReclaimPolicy: Delete
     storageClassName: alicloud-disk-essd
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: disk-essd
     namespace: default
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 20Gi
     selector:
       matchLabels:
         alicloud-pvname: d-2ze88915lz1il0****
     storageClassName: alicloud-disk-essd
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     labels:
       alicloud-pvname: pv-nas
     name: pv-nas
   spec:
     accessModes:
     - ReadWriteMany
     capacity:
       storage: 5Gi
     csi:
       driver: nasplugin.csi.alibabacloud.com
       volumeAttributes:
         server: 1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com
       volumeHandle: pv-nas
     mountOptions:
     - vers=3
     - nolock,tcp,noresvport
     persistentVolumeReclaimPolicy: Retain
     storageClassName: nas
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-nas
     namespace: default
   spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 5Gi
     selector:
       matchLabels:
         alicloud-pvname: pv-nas
     storageClassName: nas
     volumeMode: Filesystem
   

   kubectl apply -f outputfile.txt

3. Exécutez la commande suivante pour confirmer que le PVC dans le cluster de restauration est dans l'état Bound.

   kubectl get pvc 

   Sortie attendue :

   NAME        STATUS   VOLUME                   CAPACITY   ACCESS MODES   STORAGECLASS         AGE
   disk-essd   Bound    d-2ze88915lz1il0xxxxxx   20Gi       RWO            alicloud-disk-essd   29m
   pvc-nas     Bound    pv-nas                   5Gi        RWX            nas                  29m

Étape 6 : Créer une tâche de restauration dans le cluster de restauration

Si vous avez sauvegardé des volumes lors de la création de la sauvegarde, vous utilisez la méthode de modification de la source de données pour la sauvegarde et la restauration. Vous pouvez changer le type de stockage en utilisant la conversion StorageClass (convertedarg). Par exemple, vous pouvez convertir un stockage NAS en stockage sur disque. Sélectionnez la StorageClass cible en fonction de vos besoins.

• Dans cet exemple, étant donné que le cluster de sauvegarde est un cluster FlexVolume v1.16 et que les sauvegardes de volumes sur disque utilisent Cloud Backup, vous pouvez sélectionner alicloud-disk comme StorageClass cible pour la revendication de stockage disk-essd (qui est convertie en une classe de disque CSI et prend par défaut la valeur alicloud-disk-topology-alltype). Si votre cluster de sauvegarde est un cluster CSI v1.18 ou ultérieur, aucune configuration liée aux volumes sur disque n'est nécessaire.

• Cet exemple convertit également le volume NAS FlexVolume en un volume NAS isolé géré par CNFS en sélectionnant la StorageClass cible alibabacloud-cnfs-nas pour le PVC pvc-nas. Si votre cluster ne dispose pas de la StorageClass alibabacloud-cnfs-nas, consultez Gérer les systèmes de fichiers NAS à l'aide de CNFS.

Voici les étapes spécifiques :

1. Exécutez la commande suivante pour créer une tâche de restauration.

   Pour savoir comment configurer une tâche de restauration dans la console ACK, consultez Restaurer les applications et les volumes de données. Cette étape fournit la configuration recommandée pour le scénario d'exemple. Adaptez les paramètres à votre scénario spécifique.

   cat << EOF | kubectl apply -f -
   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationRestore
   metadata:
     annotations:
       csdr.alibabacloud.com/backuplocations: >-
         '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}'
     name: <your-restore-name>
     namespace: csdr
   spec:
     backupName: <your-backup-name>
     excludedNamespaces:
     - arms-prom
     excludedResources:
     - secrets
     appRestoreOnly: false
     convertedarg:
     - convertToStorageClassType: alicloud-disk-topology-alltype
       namespace: default
       persistentVolumeClaim: alicloud-disk
     - convertToStorageClassType: alibabacloud-cnfs-nas
       namespace: default
       persistentVolumeClaim: pvc-nas
     namespaceMapping:
       <backupNamespace>: <restoreNamespace>
   EOF

   Parameter	Description
   excludedNamespaces	Les namespace à exclure. Vous pouvez exclure des namespace indésirables de la liste des ressources de sauvegarde.
   excludedResources	Les resources à exclure. Vous pouvez exclure des types de resource indésirables de la liste des ressources de sauvegarde.
   appRestoreOnly	Pour une sauvegarde incluant des volumes, ce paramètre spécifie si les volumes doivent être restaurés. true : Crée des volumes dynamiques et des storage claims pointant vers une nouvelle source de données lors de la restauration. Les tâches de sauvegarde créées dans la console utilisent true par défaut. false : Aucun volume statique n'est créé. Vous devez déployer manuellement un volume statique au préalable. Remarque En général, définissez ce paramètre sur true en cas de modification de la source de données et sur false si la source de données reste inchangée.
   convertedarg	La liste de conversion StorageClass. Pour les volumes de type FileSystem, tels que OSS, NAS, CPFS et les volumes locaux, vous pouvez configurer ce paramètre pour convertir les StorageClasses de leurs PVC vers le StorageClass spécifié pendant le processus de restauration. Par exemple, vous pouvez convertir des volumes NAS en volumes disk. convertToStorageClassType : le StorageClass souhaité. Assurez-vous que le StorageClass existe dans le cluster actuel. Vous ne pouvez spécifier que le StorageClass disk ou NAS. namespace : le namespace du PVC. persistentVolumeClaim : le nom du PVC. Ce qui précède correspond aux paramètres requis pour la fonctionnalité de conversion StorageClass.

2. Exécutez la commande suivante pour interroger l'état de la tâche de restauration.

   kubectl -ncsdr describe applicationrestore <your-restore-name>

   Dans la sortie attendue, le Phase de Status passe à Completed, ce qui indique que la tâche a été restaurée avec succès.

3. Exécutez les commandes suivantes pour vérifier s'il existe des ressources dont la restauration a échoué et identifier la cause de l'échec.

   kubectl -ncsdr get pod | grep csdr-velero
   kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe restore <your-restore-name> --details

   Sortie attendue :

   Warnings:
     Velero:     <none>
     Cluster:  could not restore, ClusterRoleBinding "kubernetes-proxy" already exists. Warning: the in-cluster version is different than the backed-up version.
     Namespaces:
       demo-ns:  could not restore, ConfigMap "kube-root-ca.crt" already exists. Warning: the in-cluster version is different than the backed-up version.
                  could not restore, Endpoints "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version.
                  could not restore, Service "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version.
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       demo-ns:  error restoring endpoints/xxxxxx/kubernetes: Endpoints "kubernetes" is invalid: subsets[0].addresses[0].ip: Invalid value: "169.254.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10)
                  error restoring endpointslices.discovery.k8s.io/demo-ns/kubernetes: EndpointSlice.discovery.k8s.io "kubernetes" is invalid: endpoints[0].addresses[0]: Invalid value: "169.xxx.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10)
                  error restoring services/xxxxxx/kubernetes-extranet: Service "kubernetes-extranet" is invalid: spec.ports[0].nodePort: Invalid value: 31882: provided port is already allocated

   D'après la sortie précédente, vous pouvez voir si certaines ressources du cluster de restauration n'ont pas été restaurées. Par exemple, les Warnings indiquent qu'une ressource existe déjà et a été ignorée. Les Errors signalent un conflit NodePort, car le port d'origine est conservé lors d'une restauration inter-clusters.

4. Confirmez que l'application restaurée fonctionne correctement.

   1. Une fois l'application restaurée, vérifiez si des ressources se trouvent dans un état anormal en raison de contraintes applicatives, d'exceptions du runtime de conteneur ou d'autres raisons. Le cas échéant, corrigez-les manuellement.

   2. Une fois la récupération vérifiée, l'apiVersion de l'application Nginx est ajustée par défaut sur apps/v1, ce qui est recommandé pour les clusters de version 1.28.