Container Service for Kubernetes:FAQ Backup Center

Index

Opérations générales

Si le statut d'une tâche de sauvegarde, de conversion de classe de stockage ou de restauration est Failed ou Partially Failed, utilisez les méthodes suivantes pour récupérer les messages d'erreur.

• Survolez le statut Failed ou Partially Failed dans la colonne Task Status pour afficher un résumé de l'erreur, par exemple RestoreError: snapshot cross region request failed.

• Pour obtenir des informations d'erreur plus détaillées, exécutez l'une des commandes suivantes afin d'interroger les enregistrements d'événements de la ressource associée. Un enregistrement d'événement fournit un message d'erreur détaillé, tel que RestoreError: process advancedvolumesnapshot failed avs: snapshot-hz, err: transition canceled with error: the ECS-snapshot related ram policy is missing.

  • Tâche de sauvegarde

    kubectl -n csdr describe applicationbackup <backup-name> 

  • Tâche de conversion de classe de stockage

    kubectl -n csdr describe converttosnapshot <backup-name>

  • Tâche de restauration

    kubectl -n csdr describe applicationrestore <restore-name>

La console affiche « Component error » ou « Failed to pull data »

Symptômes

La console affiche Component error ou Failed to pull data.

Cause

Le composant Backup Center n'est pas installé correctement.

Solution

• Vérifiez si des nœuds existent dans le cluster. En l'absence de nœuds, le déploiement de Backup Center est impossible.

• Si votre cluster utilise le plugin de stockage FlexVolume, migrez-le vers un plugin CSI. Pour plus d'informations, reportez-vous à Le composant migrate-controller d'un cluster FlexVolume ne parvient pas à démarrer.

• Si vous utilisez l'outil en ligne de commande kubectl pour gérer Backup Center, vérifiez l'absence d'erreurs dans vos configurations YAML. Pour plus d'informations, reportez-vous à Sauvegarder et restaurer des applications de cluster à l'aide de kubectl.

• Si votre cluster est un ACK Dedicated Cluster ou un Registered Cluster, assurez-vous que les permissions requises sont configurées. Pour plus d'informations, reportez-vous à ACK Dedicated Clusters et Registered Clusters.

• Vérifiez que les applications stateless csdr-controller et csdr-velero s'exécutent dans le namespace csdr. Dans le cas contraire, résolvez l'échec de déploiement, qui peut provenir de limites de ressources ou de contraintes de planification.

Erreur de la console : Une ressource portant le même nom existe déjà

Symptômes

Lorsque vous créez ou supprimez une tâche de sauvegarde, de conversion de classe de stockage ou de restauration, la console affiche le message The name has been used. Change the name and try again..

Cause

La suppression d'une tâche depuis la console crée une ressource deleterequest dans le cluster. Le composant worker effectue ensuite une série d'opérations de suppression qui ne se limitent pas au retrait de la ressource de sauvegarde correspondante. Un processus similaire se produit pour les opérations réalisées avec un outil en ligne de commande. Pour plus d'informations, reportez-vous à Sauvegarder et restaurer des ressources à l'aide d'un outil en ligne de commande.

Si l'opération de suppression échoue ou si une erreur survient lors du traitement de la ressource deleterequest, certaines ressources peuvent subsister dans le cluster. Ces ressources résiduelles provoquent l'erreur « A resource with the same name already exists ».

Solution

• Supprimez la ressource conflictuelle indiquée dans le message d'erreur. Par exemple, si l'erreur est deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists, exécutez la commande suivante pour la supprimer :

  kubectl -n csdr delete deleterequests xxxxx-dbr

• Créez la tâche correspondante avec un nouveau nom.

Impossible de sélectionner une sauvegarde pour une restauration inter-clusters

Symptômes

Lors d'une tentative de restauration d'une application entre clusters, aucune sauvegarde n'est disponible pour la sélection.

Cause

• Cause 1 : Le référentiel de sauvegarde n'est pas associé au cluster actuel car il n'a pas été initialisé.

  Le processus d'initialisation du référentiel envoie la configuration du référentiel de sauvegarde, telle que l'OSS Bucket associé, au cluster actuel. Le cluster enregistre alors les sauvegardes terminées du référentiel. Vous devez initialiser le référentiel dans le cluster cible avant de pouvoir sélectionner ses sauvegardes pour une tâche de restauration.

• Cause 2 : Si l'initialisation du référentiel échoue, le statut de la ressource backuplocation dans le cluster actuel passe à Unavailable.

• Cause 3 : La tâche de sauvegarde ne s'est pas terminée ou a échoué.

Solution

• Solution 1 :

Sur la page Create Restoration Task, cliquez sur Backup Vaults à côté de Initialize Backup Vault. Une fois le référentiel de sauvegarde initialisé, sélectionnez la sauvegarde souhaitée.

• Solution 2 :

Exécutez la commande suivante pour vérifier le statut de la ressource backuplocation :

kubectl get -n csdr backuplocation <backuplocation-name> 

Sortie attendue :

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

Si le statut est Unavailable, reportez-vous à la solution décrite dans Le statut de la tâche est Failed et le message d'erreur contient « VaultError: xxx ».

Solution 3 :

Dans la console du cluster source, confirmez que la tâche de sauvegarde présente le statut Completed. Si le statut de la sauvegarde est anormal, identifiez et résolvez la cause. Pour plus d'informations, reportez-vous à l'Index.

Erreur de la console : Rôle de service non autorisé

Symptômes

Lorsque vous accédez à la console de sauvegarde d'applications, un message d'erreur indique que le rôle de service requis n'est pas autorisé. Le code d'erreur est AddonRoleNotAuthorized.

Cause

Ce problème survient car la version 1.8.0 du composant migrate-controller de Backup Center a introduit une nouvelle logique d'authentification pour les ressources cloud dans les clusters gérés ACK. Lors de la première installation ou mise à niveau d'un cluster vers cette version au sein d'un compte Alibaba Cloud, le compte doit accorder les permissions nécessaires.

Solution

• Si vous êtes connecté avec un compte Alibaba Cloud, cliquez sur Go to Authorize pour accorder les permissions requises.

• Si vous êtes connecté en tant qu'utilisateur RAM, cliquez sur Copy Authorization Link et envoyez le lien au propriétaire du compte Alibaba Cloud pour autorisation.

Permissions RBAC de cluster manquantes dans la console

Symptômes

Lorsque vous accédez à la console de sauvegarde d'applications, une erreur APISERVER.403 s'affiche. Le message indique que votre compte ne dispose pas des permissions RBAC de cluster requises et nécessite une autorisation de votre compte principal ou d'un administrateur des permissions.

Cause

La console interagit avec le serveur API pour créer et gérer les tâches de sauvegarde et de restauration, ainsi que pour récupérer leur statut. Les permissions RBAC par défaut attribuées aux opérateurs et développeurs de cluster n'incluent pas certaines permissions requises par les composants de Backup Center. Un compte principal ou un administrateur des permissions doit accorder ces autorisations.

Solution

Accordez les permissions ClusterRole suivantes aux opérateurs de Backup Center. Pour obtenir des instructions, reportez-vous à Utiliser un RBAC personnalisé pour restreindre les opérations sur les ressources dans un cluster.

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

Échec de la mise à niveau ou de la désinstallation du composant Backup Center

Symptômes

La mise à niveau ou la désinstallation du composant Backup Center échoue, et le namespace csdr reste bloqué à l'état Terminating.

Cause

Lorsque le composant Backup Center s'arrête de manière inattendue, il peut laisser des tâches à l'état InProgress dans le namespace csdr. Les finalizers présents sur les ressources de cluster de ces tâches peuvent bloquer leur suppression. Par conséquent, le namespace csdr reste figé à l'état Terminating.

Solution

• Exécutez la commande suivante pour déterminer pourquoi le namespace csdr est à l'état Terminating :

  kubectl describe ns csdr

  Confirmez que la tâche bloquée n'est plus nécessaire, puis supprimez ses finalizers.

• Une fois le namespace csdr supprimé :

  • Pour une mise à niveau de composant, réinstallez le composant migrate-controller.

  • Pour une désinstallation de composant, la désinstallation est terminée.

Échec de la tâche avec une « internal error »

Symptômes

Le statut de la tâche est Failed et le message d'erreur contient « internal error ».

Cause

La cause est une erreur inattendue dans un composant ou un produit cloud dépendant. Par exemple, un produit cloud peut ne pas être activé dans la région actuelle.

Solution

Si le message d'erreur est « HBR backup/restore internal error », ouvrez la console Cloud Backup pour vérifier si la sauvegarde de conteneurs est activée.

Échec de la tâche avec l'erreur « create cluster resources timeout »

Symptômes

Le statut de la tâche est Failed, avec le message d'erreur « create cluster resources timeout ».

Cause

Les tâches de conversion de StorageClass ou de restauration créent des ressources temporaires, telles que des Pods, des PersistentVolumeClaims et des PersistentVolumes. Si ces ressources ne deviennent pas disponibles à temps, la tâche échoue avec l'erreur « create cluster resources timeout ».

Solution

1. Exécutez la commande suivante pour consulter les événements (Events) de la ressource et déterminer la cause de l'échec.

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

   Sortie attendue :

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

   La sortie indique que le PersistentVolumeClaim utilisé pour la conversion de StorageClass, demo-pvc-for-convert202311151045 dans le namespace default, n'a pas atteint l'état Bound dans le délai imparti.

2. Exécutez la commande suivante pour vérifier le statut du PersistentVolumeClaim et identifier la cause du problème.

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

   Voici les causes courantes de ce problème dans Backup Center. Pour plus d'informations, reportez-vous à Dépanner les problèmes de stockage.

   • Ressources insuffisantes ou statut anormal du cluster ou des nœuds.

   • La StorageClass requise manque dans le cluster de restauration. Utilisez la fonctionnalité de conversion de StorageClass pour sélectionner une StorageClass existante dans le cluster de restauration, puis réessayez l'opération de restauration.

   • Le stockage sous-jacent associé à la StorageClass est indisponible. Par exemple, le type de disque cloud spécifié n'est pas pris en charge dans la zone de disponibilité actuelle.

   • Le CNFS associé à alibabacloud-cnfs-nas n'est pas sain. Consultez Gérer les systèmes de fichiers NAS à l'aide de CNFS.

   • Sélection d'une StorageClass avec volumeBindingMode défini sur Immediate lors de la restauration vers un cluster multi-AZ.

Échec de la tâche avec l'erreur « addon status is abnormal »

Symptômes

Le statut de la tâche est Failed, avec le message d'erreur « addon status is abnormal ».

Cause

Un composant du namespace csdr ne fonctionne pas correctement.

Solution

Reportez-vous à Cause 1 et solution : Un composant du namespace csdr ne fonctionne pas correctement.

Échec de la tâche avec le message « VaultError: xxx »

Symptômes

Une tâche de sauvegarde, de restauration ou de conversion de StorageClass échoue avec le message d'erreur VaultError: backup vault is unavailable: xxx.

Causes

• L'OSS Bucket n'existe pas.

• Les permissions OSS ne sont pas configurées pour le cluster.

• Le cluster ne peut pas atteindre l'OSS Bucket via le réseau.

Solution

1. Connectez-vous à la Console de gestion OSS et vérifiez que l'OSS Bucket associé au coffre-fort de sauvegarde existe.

   Si l'OSS Bucket est manquant, créez un bucket et associez-le à nouveau. Pour plus d'informations, reportez-vous à Créer un bucket.

2. Vérifiez que les permissions OSS pour le cluster sont configurées.

   • Cluster ACK Pro : Il n'est pas nécessaire de configurer les permissions OSS. Assurez-vous simplement que l'OSS Bucket associé au coffre-fort de sauvegarde utilise le préfixe cnfs-oss-**.

   • Cluster ACK Dedicated et Registered Cluster : Vous devez configurer les permissions OSS. Pour obtenir des instructions, reportez-vous à Installer les composants du service de sauvegarde et configurer les permissions.

   Si vous avez installé ou mis à niveau le composant vers la version 1.8.0 ou ultérieure sur un cluster géré ACK sans utiliser la console, il se peut que les permissions OSS requises manquent au cluster. Vous pouvez exécuter la commande suivante pour vérifier :

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

   Sortie attendue :

   addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

   Si la commande renvoie cette sortie, le cluster a seulement besoin d'utiliser un OSS Bucket avec le préfixe cnfs-oss-*, et aucune permission OSS supplémentaire n'est requise.

   Si la commande ne renvoie pas cette sortie, accordez les permissions requises en utilisant l'une des méthodes suivantes :

   • Configurez les permissions OSS comme pour un cluster ACK Dedicated ou un Registered Cluster. Pour obtenir des instructions, reportez-vous à Installer les composants du service de sauvegarde et configurer les permissions.

   • Utilisez votre compte Alibaba Cloud pour cliquer sur Go to Authorize et terminez le processus d'autorisation. Cette autorisation n'est nécessaire qu'une seule fois par compte Alibaba Cloud.

   Remarque

   Un coffre-fort de sauvegarde ne peut pas être recréé avec le même nom, ni associé à un OSS Bucket dont le nom ne respecte pas la convention de nommage cnfs-oss-**. Si vous avez précédemment associé un bucket ne respectant pas cette convention, vous devez créer un nouveau coffre-fort de sauvegarde avec un nom différent et l'associer à un bucket conforme à l'exigence de nommage.

3. Exécutez la commande suivante pour vérifier la configuration réseau du cluster.

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

   La sortie doit ressembler à ce qui suit :

   network: internal

   • Si la valeur network est internal, le coffre-fort de sauvegarde accède à l'OSS Bucket via le réseau interne.

   • Si la valeur network est public, le coffre-fort de sauvegarde accède à l'OSS Bucket via le réseau public. Si vous utilisez le réseau public et que l'erreur spécifique est un délai d'attente (timeout), vérifiez si l'accès au réseau public est activé pour le cluster. Pour plus d'informations, reportez-vous à Activer l'accès au réseau public pour un cluster.

   Dans les trois scénarios suivants, le coffre-fort de sauvegarde doit accéder à l'OSS Bucket via le réseau public :

   • Le cluster et l'OSS Bucket se trouvent dans des régions différentes.

   • Le cluster est un cluster ACK Edge.

   • Le cluster est un Registered Cluster non connecté à un VPC cloud via des méthodes telles que Cloud Enterprise Network (CEN), Express Connect ou VPN. Ce scénario inclut également les Registered Clusters connectés à un VPC cloud mais ne disposant pas de route vers le réseau interne OSS de cette région ; dans ce cas, vous devez en configurer une.

     • Pour plus d'informations sur la connexion d'un centre de données local à un VPC cloud, reportez-vous à Méthodes de connexion.

     • Pour les correspondances entre les noms de domaine internes OSS et les blocs CIDR VIP, reportez-vous à Accéder à OSS via des endpoints et des noms de domaine de bucket.

   Si vous devez utiliser le réseau public pour accéder à l'OSS Bucket, exécutez les commandes suivantes pour changer le mode d'accès. Dans ces commandes, remplacez <backuplocation-name> par le nom de votre coffre-fort de sauvegarde et <region-id> par l'ID de la région où se trouve l'OSS Bucket, par exemple 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>"}}]'

Échec de la tâche avec « HBRError: check HBR vault error »

Symptômes

Une tâche de sauvegarde, de restauration ou de conversion de classe de stockage échoue, et le message d'erreur contient «HBRError: check HBR vault error ».

Cause

Le service HBR n'est pas activé ou les permissions requises ne sont pas configurées correctement.

Solution

1. Vérifiez que le service HBR est activé. Pour obtenir des instructions, reportez-vous à Activer HBR.

2. Si votre cluster se trouve dans une région telle que China (Ulanqab), China (Heyuan) ou China (Guangzhou), vous devez également accorder les permissions API Gateway au service HBR après l'activation. Pour obtenir des instructions, reportez-vous à (Facultatif) Étape 3 : Accorder les permissions API Gateway au service HBR.

3. Si votre cluster est un ACK Dedicated Cluster ou un Registered Cluster, vérifiez que les permissions RAM HBR requises sont accordées. Pour plus de détails sur ces permissions et la manière de les accorder, reportez-vous à Installer le composant de service de sauvegarde migrate-controller et configurer les permissions.

Échec de la tâche avec « HBRError: ... code: 400, Illegal request »

Symptômes

Une tâche de sauvegarde, de restauration ou de conversion de classe de stockage échoue avec l'erreur «HBRError: ... code: 400, Illegal request. Please modify the parameters ».

Cause

Le coffre-fort de sauvegarde ack-backup-data de Cloud Backup a été supprimé de la région du cluster.

Lors de votre première utilisation de Backup Center dans une région, le composante provisionne automatiquement un coffre-fort de sauvegarde nommé ack-backup-data pour stocker les sauvegardes créées par Backup Center. Ces sauvegardes sont automatiquement supprimées en fonction de leur durée de rétention spécifiée.

Solution

1. Exécutez les commandes suivantes sur tous les clusters de la région actuelle utilisant Backup Center pour effacer les enregistrements du référentiel de sauvegarde.

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

2. Sur le cluster où vous souhaitez créer des sauvegardes, lancez une nouvelle tâche de sauvegarde. Le composant recrée automatiquement le coffre-fort de sauvegarde ack-backup-data et l'associe à votre référentiel de sauvegarde.

Échec d'une tâche avec l'erreur « hbr task finished with unexpected status: FAILED, errMsg ClientNotExist »

Symptômes

Une tâche de sauvegarde, de restauration ou de conversion de classe de stockage échoue et renvoie un message d'erreur contenant hbr task finished with unexpected status: FAILED, errMsg ClientNotExist.

Cause

Le déploiement du client Cloud Backup a échoué sur le nœud cible. Cela indique que le Pod du DaemonSet hbr-client dans le namespace csdr ne fonctionne pas correctement sur ce nœud.

Solution

1. Exécutez la commande suivante pour vérifier si des Pods hbr-client présentent des dysfonctionnements :

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

2. Si des Pods se trouvent dans un état anormal, vérifiez d'abord si le problème provient d'un manque de ressources (adresses IP de Pod, mémoire ou CPU). Lorsqu'un Pod affiche le statut CrashLoopBackOff, exécutez la commande suivante pour consulter ses journaux.

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

   Si la sortie contient "SDKError:\n StatusCode: 403\n Code: MagpieBridgeSlrNotExist\n Message: code: 403, AliyunServiceRoleForHbrMagpieBridge doesn't exist, please create this role. ", accordez les permissions requises au service Cloud Backup. Pour plus d'informations, consultez (Facultatif) Étape 3 : Accorder des permissions API Gateway au service Cloud Backup.

3. Lorsque la sortie des journaux contient d'autres types d'erreurs SDK, utilisez le code d'erreur EC présent dans la réponse pour résoudre le problème.

   Pour plus d'informations, consultez Résolution des problèmes à l'aide des codes d'erreur EC.

Tâche bloquée à l'état InProgress

Cause 1 et solution : Composants anormaux dans le namespace csdr

Vérifiez l'état des composants afin d'identifier l'origine du problème.

1. Exécutez la commande suivante pour déterminer si des composants du namespace csdr redémarrent ou n'ont pas réussi à démarrer.

   kubectl get pod -n csdr

2. Exécutez la commande suivante pour identifier la cause du redémarrage ou de l'échec de démarrage.

   kubectl describe pod <pod-name> -n csdr

Cause 2 et solution : Permissions de snapshot non configurées pour les sauvegardes de disques cloud

Si une tâche de sauvegarde de données pour une application utilisant un volume Cloud Disk reste bloquée à l'état InProgress, exécutez la commande suivante pour vérifier la présence de nouvelles ressources volumesnapshot dans le cluster.

kubectl get volumesnapshot -n <backup-namespace>

Voici un exemple de sortie attendue :

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

Si le statut READYTOUSE de toutes les ressources volumesnapshot reste à false pendant une période prolongée, suivez les étapes ci-dessous.

1. Connectez-vous à la console ECS et vérifiez si le service de snapshot de disque cloud est activé.

   • S'il n'est pas activé, activez les snapshots de disque cloud dans la région correspondante. Pour plus d'informations, consultez Activer les snapshots.

   • S'il est déjà activé, passez à l'étape suivante.

2. Assurez-vous que les composants CSI du cluster fonctionnent normalement.

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

3. Vérifiez que les permissions nécessaires à l'utilisation des snapshots de disque cloud sont bien configurées.

   Cluster géré

   1. Connectez-vous à la console RAM en tant qu'administrateur RAM.

   2. Dans le volet de navigation de gauche, choisissez Identities > Roles. Vous pouvez filtrer les rôles par type ou rechercher un rôle spécifique. Les rôles liés au service créés automatiquement figurent également sur cette page et peuvent être récupérés via l'opération d'API ListRoles ou la commande CLI correspondante.

   3. Sur la page Role, recherchez AliyunCSManagedBackupRestoreRole et vérifiez que sa politique de permissions contient les éléments suivants.

      {
        "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"
      }

      • Si le rôle AliyunCSManagedBackupRestoreRole est absent, accédez à la page Autorisation rapide pour Resource Access Management (RAM) pour autoriser ce rôle.

      • Si le rôle AliyunCSManagedBackupRestoreRole existe mais que sa politique est incomplète, accordez-lui les permissions requises. Pour plus d'informations, consultez Créer une politique de permissions personnalisée et Gérer les permissions d'un rôle RAM.

   Cluster dédié

   1. Connectez-vous à la console Container Service, puis dans le volet de navigation de gauche, cliquez sur Clusters.

   2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Cluster Information.

   3. Sur la page Cluster Information, localisez le paramètre master RAM role et cliquez sur le lien situé à côté.

   4. Dans l'onglet Permission Management, vérifiez les permissions relatives aux snapshots de disque cloud.

      Si la politique de permissions k8sMasterRolePolicy-Csi-*** est absente ou ne comprend pas les permissions requises, attribuez la politique de permissions suivante pour les snapshots de disque cloud au rôle RAM master. Pour plus d'informations, consultez Créer une politique de permissions personnalisée et Gérer les permissions d'un rôle 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"
      }

   Cluster enregistré

   La fonctionnalité de snapshot de disque cloud est disponible uniquement pour les clusters enregistrés dont tous les nœuds sont des instances ECS Alibaba Cloud. Vérifiez que les permissions requises ont bien été accordées lors de l'installation du plugin de stockage CSI. Pour plus d'informations, consultez Configurer les permissions RAM pour les composants CSI.

Cause 3 et solution : Types de volumes non pris en charge

À partir de la version 1.7.7, le composant migrate-controller du Centre de sauvegarde prend en charge la restauration interrégionale pour les sauvegardes de données Cloud Disk. La restauration interrégionale n'est pas encore disponible pour les autres types de données. Si vous utilisez un produit de stockage accessible via le réseau public, tel qu'Alibaba Cloud OSS, vous pouvez créer statiquement une Persistent Volume Claim et un Persistent Volume avant de restaurer l'application. Pour plus d'informations, consultez Utiliser un volume statique avec ossfs 1.0.

Erreur « backup already exists in OSS bucket »

Symptômes

La sauvegarde échoue avec le statut Failed et un message d'erreur indiquant « backup already exists in OSS bucket ».

Cause

Une sauvegarde portant le même nom existe déjà dans le bucket OSS associé au référentiel de sauvegarde.

Cette sauvegarde existante peut ne pas être visible dans le cluster actuel pour les raisons suivantes :

• Le système ne synchronise pas les sauvegardes en cours ou ayant échoué vers d'autres clusters.

• Lorsque vous supprimez une sauvegarde depuis un cluster différent de celui où elle a été créée, le système la marque simplement pour suppression au lieu de la retirer effectivement du bucket OSS. Ces sauvegardes marquées ne sont pas synchronisées vers les clusters nouvellement associés.

• Le cluster actuel n'est pas associé au référentiel de sauvegarde contenant la sauvegarde existante. Autrement dit, l'initialisation du référentiel n'est pas terminée.

Solution

Créez un référentiel de sauvegarde avec un nouveau nom.

Échec de la sauvegarde avec l'erreur « get target namespace failed »

Symptômes

La sauvegarde échoue avec le statut Failed et le message d'erreur « get target namespace failed ».

Cause

Ce problème survient généralement avec les tâches de sauvegarde planifiées. La cause de l'échec dépend de la méthode de sélection des namespaces.

• Avec la méthode Include, tous les namespaces sélectionnés ont été supprimés.

• Avec la méthode Exclude, seuls les namespaces exclus subsistent dans le cluster.

Solution

Modifiez le plan de sauvegarde pour corriger la sélection des namespaces.

Échec de la sauvegarde avec l'erreur « velero backup process timeout »

Symptômes

Le statut de la sauvegarde est Failed et le message d'erreur contient « velero backup process timeout ».

Causes

• Cause 1 : Une sous-tâche de sauvegarde d'application a expiré. La durée de cette sous-tâche dépend de facteurs tels que la disponibilité des ressources du cluster et la latence de l'API Server. Depuis la version 1.7.7, le composant migrate-controller du centre de sauvegarde applique par défaut un délai d'expiration de 60 minutes.

• Cause 2 : La classe de stockage du bucket utilisé par le référentiel de sauvegarde est Archive, Cold Archive ou Deep Cold Archive. Pour garantir un processus de sauvegarde cohérent, le composant doit mettre à jour les fichiers de métadonnées sur le serveur OSS. Cette opération n'est pas prise en charge pour les objets non restaurés.

Solution

• Solution 1 : Modifiez le paramètre global de délai d'expiration des sous-tâches de sauvegarde dans le cluster de sauvegarde.

  Exécutez la commande suivante pour ajouter l'élément de configuration velero_timeout_minutes (en minutes) à applicationBackup.

  kubectl edit -n csdr cm csdr-config

  Par exemple, pour définir le délai d'expiration à 100 minutes, effectuez la modification suivante :

  apiVersion: v1
  data:
    applicationBackup: |
      ... # Omitted for brevity
      velero_timeout_minutes: 100

  Après avoir modifié la configuration, exécutez la commande suivante pour redémarrer le csdr-controller et appliquer les changements.

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

• Solution 2 : Changez la classe de stockage du bucket utilisé par le référentiel de sauvegarde pour utiliser la classe Standard.

  Pour stocker des données de sauvegarde dans une classe de stockage d'archivage, configurez une règle de cycle de vie afin de transitionner automatiquement la classe de stockage. Vous devrez ensuite restaurer les données avant la récupération. Pour plus d'informations, consultez Modifier la classe de stockage.

Échec de la tâche de sauvegarde : « HBR backup request failed »

Symptômes

Le statut de la tâche de sauvegarde est Failed et le message d'erreur contient « HBR backup request failed ».

Causes

• Cause 1 : Le plugin de stockage utilisé par le cluster est incompatible.

• Cause 2 : Cloud Backup ne prend pas en charge la sauvegarde des volumes dont le paramètre volumeMode est défini sur Block. Pour plus d'informations, consultez volumeMode.

• Cause 3 : Un problème lié au client Cloud Backup entraîne un délai d'expiration ou un échec lors de la sauvegarde ou de la restauration de données de système de fichiers (OSS, NAS, CPFS ou volumes locaux).

Solution

• Solution 1 : Des problèmes de compatibilité peuvent survenir si votre cluster utilise un plugin de stockage CSI non-Alibaba Cloud ou des volumes qui ne correspondent pas aux types Kubernetes standard, comme NFS ou LocalVolume. Dans ce cas, ouvrez un ticket pour obtenir de l'aide.

• Solution 2 : Le mode Block est généralement requis uniquement pour les volumes de disque cloud. Lorsqu'un cluster utilise le plugin de stockage CSI, Cloud Backup recourt par défaut aux snapshots de disque cloud pour la sauvegarde des données, méthode qui prend en charge les volumes en mode Block. Si vous utilisez un plugin de stockage incompatible, passez à CSI, réinstallez le composant de sauvegarde, puis réessayez la sauvegarde.

• Solution 3 : Suivez ces étapes :

  1. Connectez-vous à la console Cloud Backup.

  2. Dans le volet de navigation de gauche, choisissez Backup > Container Backup, puis cliquez sur l'onglet Backup Jobs.

  3. Dans la barre de navigation supérieure, sélectionnez une région.

  4. Dans l'onglet Backup Jobs, cliquez sur la liste déroulante à côté du champ de recherche, sélectionnez Job Name, puis recherchez <backup-name>-hbr pour vérifier le statut et la cause de l'échec de la tâche de sauvegarde. Pour plus d'informations, consultez Sauvegarde de Container Service for Kubernetes (ACK).

     Remarque

     Pour interroger une tâche de transition de classe de stockage ou une tâche de sauvegarde, effectuez une recherche par nom de sauvegarde correspondant.

Erreur de sauvegarde : « hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST »

Symptômes

Le statut de la sauvegarde est Failed et le message d'erreur contient « hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST ».

Causes

• Pour les pilotes CSI d'autres fournisseurs cloud ou les types de stockage auto-gérés tels que NFS ou Ceph :

  Dans un scénario de cloud hybride, le centre de sauvegarde utilise par défaut le chemin de montage de volume Kubernetes standard. Pour un pilote de stockage CSI standard, le chemin de montage par défaut est /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. La même logique s'applique aux autres pilotes de stockage Kubernetes officiellement pris en charge, tels que NFS et FlexVolume.

  /var/lib/kubelet correspond au répertoire racine par défaut de kubelet. Si vous modifiez ce chemin dans votre cluster Kubernetes, le service de sauvegarde cloud pourrait ne pas accéder aux données.

• Pour le stockage HostPath :

  Les volumes HostPath ne créent pas de chemin de montage sous le répertoire racine de kubelet. Au lieu de cela, un pod monte directement un chemin spécifié sur le nœud. Par défaut, le composant de sauvegarde ne peut pas lire les données depuis le chemin du nœud, ce qui provoque l'échec de la sauvegarde.

Solution

• Pour les pilotes CSI d'autres fournisseurs cloud ou les types de stockage auto-gérés tels que NFS ou Ceph :

  Connectez-vous au nœud où le volume est monté pour effectuer le dépannage :

  1. Vérifiez si le répertoire racine de kubelet sur le nœud a été modifié.

     1. Exécutez la commande suivante pour vérifier la commande de démarrage de kubelet :

        ps -elf | grep kubelet

        Si la commande de démarrage inclut le paramètre --root-dir, sa valeur correspond au répertoire racine de kubelet.

        Si la commande inclut le paramètre --config, sa valeur correspond au chemin du fichier de configuration de kubelet. Dans ce fichier, la valeur du champ root-dir spécifie le répertoire racine de kubelet.

     2. Si la commande de démarrage ne contient pas d'information sur le répertoire racine, vérifiez le fichier d'unité de service kubelet situé à /etc/systemd/system/kubelet.service. S'il contient un champ EnvironmentFile, par exemple :

        EnvironmentFile=-/etc/kubernetes/kubelet

        Cela signifie que le fichier de configuration des variables d'environnement est /etc/kubernetes/kubelet. Recherchez le contenu suivant dans ce fichier :

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

        Ici, /xxx représente le répertoire racine de kubelet.

     3. Si aucune modification associée n'est trouvée, le répertoire racine de kubelet correspond à la valeur par défaut /var/lib/kubelet.

  2. Exécutez la commande suivante pour vérifier si le répertoire racine de kubelet est un lien symbolique vers un autre chemin :

     ls -al <root-dir>

     Si la sortie ressemble à ce qui suit :

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

     Le répertoire racine réel est /var/lib/container/kubelet.

  3. Vérifiez que les données du volume cible existent bien dans le répertoire racine.

     Assurez-vous que le chemin de montage du volume <root-dir>/pods/<pod-uid>/volumes existe et contient des sous-répertoires pour les types de stockage cibles, tels que kubernetes.io~csi ou kubernetes.io~nfs.

  4. Ajoutez la variable d'environnement KUBELET_ROOT_PATH = /var/lib/container/kubelet/pods à l'application stateless csdr/csdr-controller, en remplaçant /var/lib/container/kubelet dans la valeur par le répertoire racine réel de kubelet identifié à partir de la configuration et des liens symboliques.

• Pour le stockage HostPath :

  Ouvrez un ticket.

Échec de la sauvegarde : Erreur d'accès aux fichiers OSS

Symptômes

Le statut de la sauvegarde est Failed et le message d'erreur contient « upload backup files to OSS bucket failed ».

Causes

Ce problème survient lorsque le composant reçoit une erreur du serveur OSS lors de la vérification, du téléchargement ou de l'envoi de fichiers vers le bucket OSS du coffre-fort de sauvegarde. Causes possibles :

• Cause 1 : Le chiffrement des données est activé pour le bucket OSS, mais les permissions KMS requises n'ont pas été accordées.

• Cause 2 : Les permissions de lecture et d'écriture requises pour les clusters dédiés ACK et les clusters enregistrés n'ont pas été accordées lors de l'installation du composant.

• Cause 3 : Les identifiants d'accès de l'utilisateur RAM utilisé pour configurer les permissions d'un cluster dédié ou enregistré ACK ont été révoqués.

Solution

• Solution 1 : Consultez Accorder les permissions KMS requises pour les buckets OSS chiffrés.

• Solution 2 : Vérifiez la politique de permissions de l'utilisateur RAM utilisé pour configurer les permissions. Pour les politiques de permissions requises par le composant, consultez Étape 1 : Configurer les permissions.

• Solution 3 : Vérifiez que les identifiants d'accès de l'utilisateur RAM utilisé pour configurer les permissions sont actifs. Si les identifiants ont été révoqués, obtenez de nouveaux identifiants, mettez à jour le Secret alibaba-addon-secret dans le namespace csdr, puis redémarrez le composant en exécutant la commande suivante :

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

Sauvegarde PartiallyFailed avec un message Velero

Symptômes

Le statut de la sauvegarde est PartiallyFailed et le message contient « PROCESS velero partially completed ».

Cause

Cela se produit lorsque le composant velero ne parvient pas à sauvegarder certaines ressources intra-cluster d'une application.

Solution

Exécutez la commande suivante pour identifier les ressources ayant échoué et la cause associée.

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

Utilisez les informations des champs Errors et Warnings de la sortie pour résoudre le problème.

Si la sortie n'identifie pas la cause, exécutez la commande suivante pour obtenir les journaux de sauvegarde.

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

Tâche de sauvegarde PartiallyFailed avec l'erreur « PROCESS hbr partially completed »

Symptômes

Le statut de la tâche de sauvegarde est PartiallyFailed avec l'erreur « PROCESS hbr partially completed ».

Cause

Ce problème survient lorsque Cloud Backup ne parvient pas à sauvegarder certaines ressources provenant de systèmes de fichiers tels que OSS, NAS, CPFS ou des volumes de stockage locaux.

• Cause 1 : Certains volumes de données utilisent un plugin de stockage non pris en charge.

• Cause 2 : Cloud Backup ne garantit pas la cohérence des données. Si un fichier est supprimé pendant le processus de sauvegarde, celle-ci peut échouer.

Solution

1. Connectez-vous à la console Cloud Backup.

2. Dans le volet de navigation de gauche, choisissez Backup > Container Backup, puis cliquez sur l'onglet Backup Jobs.

3. Dans la barre de navigation supérieure, sélectionnez une région.

4. Dans l'onglet Backup Jobs, sélectionnez Job Name dans le filtre de recherche, puis recherchez <backup-name>-hbr pour déterminer pourquoi la sauvegarde du volume de stockage a échoué. Pour plus d'informations, consultez Sauvegarder des clusters Container Service for Kubernetes (ACK).

Échec de la conversion de classe de stockage : « storageclass xxx not exists »

Symptômes

Le statut de la conversion de classe de stockage est Failed, avec le message d'erreur « storageclass xxx not exists ».

Cause

La classe de stockage cible sélectionnée pour la conversion n'existe pas dans le cluster actuel.

Solution

1. Exécutez la commande suivante pour réinitialiser la tâche de conversion de classe de stockage.

   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. Créez la classe de stockage manquante dans le cluster actuel.

3. Relancez la tâche de restauration et configurez la conversion de classe de stockage.

Échec de la conversion de classe de stockage avec un provisionneur non pris en charge

Symptômes

Le statut de la conversion de classe de stockage est Failed et le message d'erreur contient « only support convert to storageclass with CSI diskplugin or nasplugin provisioner ».

Cause

Ce problème survient car la classe de stockage cible sélectionnée n'utilise pas le provisionneur CSI Alibaba Cloud pour un disque cloud ou un volume NAS.

Solution

• La version actuelle prend en charge la création et la restauration de snapshots uniquement pour les volumes de type disque cloud, NAS et OSS. Pour restaurer d'autres types de volumes, ouvrez un ticket.

• Alternativement, pour un produit de stockage accessible publiquement tel qu'Alibaba Cloud OSS, vous pouvez utiliser un montage statique pour créer un PersistentVolume et une PersistentVolumeClaim. Cette méthode permet de restaurer l'application directement sans passer par l'étape de conversion de classe de stockage. Pour plus d'informations, consultez Utiliser un volume statique avec ossfs 1.0.

Échec de la conversion de classe de stockage avec l'erreur « multi-zoned »

Symptômes

L'état de la conversion de classe de stockage est Failed et le message d'erreur contient « current cluster is multi-zoned ».

Cause

Ce problème survient lors de la conversion vers une classe de stockage de disque cloud dans un cluster multi-AZ, lorsque le paramètre volumeBindingMode de la classe cible est défini sur Immediate. Dans un cluster multi-AZ, cette configuration peut entraîner la création du volume de stockage dans une zone de disponibilité différente de celle où le pod est planifié. Cette incompatibilité empêche la planification du pod sur le nœud cible et le maintient dans l'état Pending. Pour plus d'informations sur le champ volumeBindingMode, consultez la rubrique Classes de stockage.

Solution

1. Exécutez la commande suivante pour réinitialiser la tâche de conversion de classe de stockage.

   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. Si vous devez convertir vers une classe de stockage de disque cloud :

   • Dans la console, sélectionnez alicloud-disk. La classe alicloud-disk utilise par défaut la classe de stockage alicloud-disk-topology-alltype.

   • En ligne de commande, sélectionnez alicloud-disk-topology-alltype. Il s'agit de la classe de stockage par défaut fournie par le plugin de stockage CSI. Vous pouvez également créer une classe de stockage personnalisée dont le paramètre volumeBindingMode est défini sur WaitForFirstConsumer.

3. Réessayez la conversion de classe de stockage.

Échec de la tâche de restauration avec l'erreur « multi-node writing »

Symptômes

Une tâche de restauration ou de conversion de classe de stockage échoue avec le message d'erreur suivant : « multi-node writing is only supported for block volume. For Kubernetes users, if unsure, use ReadWriteOnce access mode in PersistentVolumeClaim for disk volume ».

Cause

Le pilote CSI valide les accessModes d'un volume de disque cloud lors du montage afin d'éviter un détachement forcé. Un tel détachement peut se produire si un nœud tente de monter un disque déjà utilisé. Le pilote interdit l'utilisation des modes ReadWriteMany ou ReadOnlyMany pour ce type de volume.

Le pilote CSI peut déclencher cette erreur lors de la restauration d'une application sur un disque cloud Alibaba Cloud, car ces disques ne prennent pas en charge l'attachement multi-nœuds par défaut. Cela se produit si le volume de l'application sauvegardée utilisait un paramètre accessModes défini sur ReadWriteMany ou ReadOnlyMany. Ces paramètres sont courants pour le stockage réseau multi-attachement, tel que OSS ou NAS.

Plus précisément, cette erreur peut survenir dans les trois scénarios suivants :

Scénario 1 : Le cluster source utilise une version ancienne du pilote CSI ou le plugin de stockage FlexVolume. Les versions antérieures du pilote CSI ne validaient pas le champ accessModes des volumes de disque cloud lors du montage. Par conséquent, une erreur survient lors de la restauration du volume original vers un cluster exécutant une version plus récente du CSI.

Scénario 2 : La classe de stockage personnalisée utilisée par le volume sauvegardé n'existe pas dans le cluster de destination. Le volume est alors restauré par défaut en tant que volume de disque cloud Alibaba Cloud.

Scénario 3 : Lors d'une restauration, vous utilisez la fonctionnalité de conversion de classe de stockage pour restaurer le volume sauvegardé en tant que volume de disque cloud Alibaba Cloud.

Solution

Scénario 1 : À partir de la version v1.8.4, le composant de sauvegarde convertit automatiquement le champ accessModes d'un volume de disque cloud en ReadWriteOnce. Mettez à niveau le composant Backup Center, puis réessayez la restauration.

Scénario 2 : La restauration automatique d'une classe de stockage dans le cluster de destination peut rendre les données inaccessibles ou provoquer leur écrasement. Pour éviter cela, créez une classe de stockage portant le même nom dans le cluster de destination avant la restauration, ou utilisez la fonctionnalité de conversion de classe de stockage pour spécifier la classe cible.

Scénario 3 : Lors de la restauration d'un volume de stockage réseau en tant que volume de disque cloud, utilisez le paramètre convertToAccessModes pour définir les accessModes sur ReadWriteOnce. Pour plus d'informations, consultez la rubrique convertToAccessModes : Liste des accessModes cibles.

Échec de la tâche de restauration avec une erreur inter-région

Symptômes

L'état de la tâche de restauration est Failed et le message d'erreur est « only disk type PVs support cross-region restore in current version ».

Cause

Depuis la version v1.7.7, le composant migrate-controller de Backup Center prend en charge la restauration inter-région pour les sauvegardes de disques cloud. La restauration inter-région pour les autres types de données n'est pas encore prise en charge.

Solution

• Pour les produits de stockage accessibles via le réseau public, tels qu'Alibaba Cloud OSS, créez une demande de volume persistant (PVC) et un volume persistant (PV) via un montage statique avant de restaurer l'application. Pour plus d'informations, consultez la rubrique Utilisation de volumes statiques ossfs 1.0.

Échec de la tâche de restauration : « ECS snapshot cross region request failed »

Symptômes

La tâche de restauration présente l'état Failed et le message d'erreur inclut « ECS snapshot cross region request failed ».

Cause

Depuis la version 1.7.7, le composant migrate-controller de Backup Center prend en charge les restaurations inter-régions des sauvegardes de disques cloud. Cette erreur indique que les permissions requises pour les snapshots de disques cloud ECS sont manquantes.

Solution

Pour les clusters dédiés ACK ou les clusters enregistrés exécutant Kubernetes auto-géré sur des instances ECS, vous devez attacher la politique de permissions requise pour les snapshots de disques cloud ECS. Pour plus d'informations, consultez la rubrique Clusters enregistrés.

Échec de la tâche de récupération avec une erreur accessMode PVC

Symptômes

Une tâche de récupération échoue avec un message d'erreur contenant « accessMode of PVC xxx is xxx ».

Cause

Pour restaurer un volume de disque cloud, son AccessMode doit être défini sur ReadOnlyMany ou ReadWriteMany.

Lors de la restauration d'un volume de stockage de disque cloud, le plugin de stockage CSI doit le monter. La version actuelle du CSI présente les limitations suivantes :

• Seuls les volumes de stockage avec la fonctionnalité multiAttach activée peuvent être montés sur plusieurs instances.

• Les volumes de stockage dont le VolumeMode est Filesystem (c'est-à-dire montés via un système de fichiers comme ext4 ou xfs) ne prennent en charge que le montage en lecture seule sur plusieurs nœuds.

Pour plus d'informations sur le stockage sur disque cloud, consultez la rubrique Utilisation de volumes de disque cloud dynamiques.

Solution

• Si vous utilisez la fonctionnalité de transition de classe de stockage pour convertir un volume prenant en charge plusieurs types de montage (comme un volume OSS ou NAS) vers un disque cloud, nous vous recommandons de créer une nouvelle tâche de restauration afin de maintenir le partage des données entre les réplicas. Dans cette tâche, sélectionnez alibabacloud-cnfs-nas comme type cible pour la transition de classe de stockage afin d'utiliser un volume de stockage NAS géré par CNFS. Pour plus d'informations, consultez la rubrique Gestion des systèmes de fichiers NAS via CNFS.

• Si la sauvegarde de votre volume de disque cloud a été créée avec une version antérieure du CSI qui ne vérifie pas l'AccessMode, et que le volume sauvegardé lui-même ne répond pas aux exigences de création du CSI actuel, nous vous conseillons de prioriser le refactoring de votre service original pour utiliser des volumes de stockage de disque cloud dynamiques. Cela permet d'éviter le risque de détachement forcé lorsque le volume est planifié sur d'autres nœuds.

Ressources manquantes après la restauration

Symptômes

L'état de la tâche de restauration est Completed, mais certaines ressources sont absentes du cluster restauré.

Causes

• Cause 1 : La ressource n'a pas été sauvegardée.

• Cause 2 : La ressource a été exclue de la restauration en raison de la configuration.

• Cause 3 : La sous-tâche de restauration de l'application a partiellement échoué.

• Cause 4 : La ressource a été restaurée avec succès, mais a ensuite été supprimée par le ramasse-miettes en raison de la configuration ownerReferences ou de la logique métier.

Solution

Solution 1 :

Exécutez la commande suivante pour afficher les détails de la sauvegarde.

 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

Vérifiez si la ressource cible a bien été sauvegardée. Si ce n'est pas le cas, vérifiez si elle a été exclue par la configuration de sauvegarde (par exemple, les paramètres d'inclusion ou d'exclusion de namespaces et de ressources), puis créez une nouvelle sauvegarde. Par défaut, les ressources de niveau cluster pour les applications (Pods) situées dans des namespaces non sélectionnés ne sont pas sauvegardées. Pour sauvegarder toutes les ressources de niveau cluster, consultez la rubrique Sauvegarde de niveau cluster.

Solution 2 :

Si la ressource cible n'a pas été restaurée, vérifiez si elle a été exclue par la configuration de restauration (par exemple, les paramètres d'inclusion ou d'exclusion de namespaces et de ressources), puis lancez une nouvelle tâche de restauration.

Solution 3 :

Exécutez la commande suivante pour identifier les ressources ayant échoué ainsi que la raison de l'échec.

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

Examinez les messages dans les champs Errors et Warnings de la sortie pour résoudre le problème.

Solution 4 :

Consultez les journaux d'audit de la ressource pour déterminer si elle a été supprimée de manière inattendue après sa création.

Échec du démarrage de migrate-controller dans les clusters Flexvolume

Le composant migrate-controller de Backup Center est incompatible avec les clusters Flexvolume. Pour utiliser Backup Center, migrez le plugin Flexvolume vers CSI en utilisant l'une des méthodes suivantes.

• Migrer Flexvolume vers CSI à l'aide du composant csi-compatible-controller

• Migrer Flexvolume vers CSI pour un cluster sans stockage persistant

• Migrer un volume de stockage statique NAS basé sur Flexvolume vers CSI

• Migrer un volume de stockage statique OSS basé sur Flexvolume vers CSI

• Pour les scénarios non couverts ici, rejoignez notre groupe d'utilisateurs DingTalk (ID du groupe : 35532895).

Pour sauvegarder des charges de travail depuis un cluster Flexvolume et les restaurer vers un cluster CSI pendant la migration Flexvolume-vers-CSI, consultez la rubrique Migrer des applications depuis une version antérieure de Kubernetes à l'aide de Backup Center.

Modification d'un coffre de sauvegarde

Backup Center ne prend pas en charge la modification d'un coffre de sauvegarde. Pour changer la configuration d'un coffre, vous devez supprimer le coffre existant et en créer un nouveau avec un nom différent.

Un coffre de sauvegarde est une ressource partagée qui peut effectuer une opération de Backup ou de Restore à tout moment. La modification de ses paramètres pendant son utilisation peut faire échouer ces opérations, car le système pourrait ne pas localiser les données. Afin de garantir l'intégrité des données et de prévenir les échecs opérationnels, un coffre de sauvegarde ne peut être ni modifié ni recréé avec le même nom.

Emplacements de sauvegarde et buckets non nommés « cnfs-oss-* »

Pour les types de clusters autres que les clusters dédiés ACK et les clusters enregistrés, le composant Backup Center dispose de permissions de lecture et d'écriture par défaut sur les buckets OSS dont le nom commence par le préfixe cnfs-oss-*. Pour éviter l'écrasement des données, nous recommandons de créer un bucket OSS dédié à Backup Center respectant la convention de nommage cnfs-oss-*.

1. Pour associer un emplacement de sauvegarde à un bucket OSS qui ne respecte pas le format de nommage « cnfs-oss-* », vous devez configurer les permissions pour le composant. Pour plus d'informations, consultez la rubrique Clusters dédiés ACK.

2. Après avoir configuré les permissions, exécutez les commandes suivantes pour redémarrer le composant du service de sauvegarde.

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

   Si vous avez déjà créé un emplacement de sauvegarde associé à un bucket OSS qui ne respecte pas le format de nommage « cnfs-oss-* », attendez que la vérification de connectivité soit terminée et que l'état passe à Available avant d'effectuer une sauvegarde ou une restauration. La vérification de connectivité s'exécute environ toutes les cinq minutes. Pour interroger l'état de l'emplacement de sauvegarde, exécutez la commande suivante.

   kubectl -n csdr get backuplocation

   Sortie attendue :

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

Planification des sauvegardes

Une planification de sauvegarde peut être une expression cron (par exemple, 1 4 * * *) ou une planification basée sur un intervalle (par exemple, 6h30m crée une sauvegarde toutes les 6 heures et 30 minutes).

Une expression cron définit une planification à l'aide de cinq champs. L'astérisque (*) agit comme un caractère générique, représentant toute valeur valide pour un champ donné.

• 1 4 * * * : Crée une sauvegarde tous les jours à 4 h 01.

• 0 2 15 * 1 : Crée une sauvegarde à 2 h 00 le 15 de chaque mois ainsi que chaque lundi.

 *  *  *  *  * 
 |  |  |  |  |
 |  |  |  |  ·----- day of week (0 - 6) (Sun to Sat)
 |  |  |  ·-------- month (1 - 12) 
 |  |  .----------- day of month (1 - 31)
 |  ·-------------- hour (0 - 23) 
 ·----------------- minute (0 - 59)  
 

Ajustements par défaut pour les ressources YAML

Lors d'une tâche de récupération, le système applique les ajustements par défaut suivants aux ressources YAML :

Ajustement 1 :

Si un volume de stockage de disque cloud est inférieur à 20 GiB, la tâche de récupération augmente sa capacité à 20 GiB.

Ajustement 2 :

Consultation des ressources sauvegardées

Ressources de sauvegarde d'applications

Les fichiers YAML des ressources du cluster sont stockés dans le bucket OSS associé au référentiel de sauvegarde. Vous pouvez consulter les ressources sauvegardées de l'une des manières suivantes.

• Dans n'importe quel cluster synchronisant la sauvegarde, exécutez les commandes suivantes pour afficher les ressources.

  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

• Consultez les ressources dans la console Container Service for Kubernetes (ACK).

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

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

  3. Sur la page Application Backup, cliquez sur l'onglet Backup Records. Dans la colonne Backup Records, cliquez sur l'enregistrement de sauvegarde que vous souhaitez consulter.

Ressources de sauvegarde de volumes de disque cloud

1. Connectez-vous à la console ECS.

2. Dans le volet de navigation de gauche, choisissez Storage & Snapshots > Snapshot.

3. Dans le coin supérieur gauche de la page, sélectionnez une région et un groupe de ressources.

4. Sur la page Snapshots, recherchez des snapshots par ID de disque cloud.

Ressources de sauvegarde de volumes hors disque cloud

1. Connectez-vous à la console Cloud Backup.

2. Dans le volet de navigation de gauche, choisissez Backup > Container Backup.

3. Dans la barre de navigation supérieure, sélectionnez une région.

4. Consultez les sauvegardes de conteneurs.

   • L'onglet Clusters liste vos clusters protégés. Cliquez sur un ACK Cluster ID pour voir les demandes de volume persistant (PVC) protégées. Pour plus d'informations, consultez la rubrique Demande de volume persistant (PVC).

     Si l'Client Status est anormal, cela indique que le service Cloud Backup ne fonctionne pas correctement dans le cluster ACK. Pour résoudre ce problème, accédez à la page DaemonSets dans la console ACK. La liste comprend des colonnes telles que ACK Cluster ID, ACK Cluster, Network Type, Client Status, Remarks et Actions. Un Client Status à Ready indique que le client du cluster est enregistré avec succès. Dans la colonne Actions, vous pouvez cliquer sur View Protected Storage Claims pour plus de détails.

   • L'onglet Backup Jobs affiche l'état d'exécution des tâches de sauvegarde.

     Vous pouvez filtrer les tâches de cet onglet par ACK Cluster ID. La liste des tâches comprend des colonnes telles que Backup Job/ID, ACK Cluster ID, Vault Name/ID, Persistent Volume Claim/ID, Source Data Size, Vault Usage, Backup Speed, Time Period, Status et Actions. Cet onglet fournit des détails pour chaque tâche de sauvegarde, tels que la taille des données sources, l'utilisation du coffre après déduplication, la vitesse de transfert, le temps d'exécution et la progression.

Sauvegarde et restauration inter-versions

Oui.

Lors d'une sauvegarde, toutes les apiVersions prises en charge pour chaque ressource sont capturées par défaut. Par exemple, une ressource Deployment dans un cluster Kubernetes 1.16 prend en charge les versions d'API extensions/v1beta1, apps/v1beta1, apps/v1beta2 et apps/v1. Le coffre de sauvegarde stocke les quatre représentations de la ressource Deployment, quelle que soit la version utilisée initialement pour le déploiement. La fonctionnalité Kubernetes Convert sous-jacente gère ce processus.

Lors d'une restauration, les ressources sont restaurées en utilisant l'apiVersion préférée du cluster cible. Par exemple, puisque l'apiVersion préférée pour un Deployment dans un cluster Kubernetes 1.28 est apps/v1, le processus restaure la sauvegarde en tant que Deployment apps/v1.

Trafic de l'équilibreur de charge pendant la récupération

Non.

Par défaut, ni la désactivation de l'écoute forcée ni la création d'une nouvelle instance SLB ne basculent automatiquement le trafic vers le cluster de sauvegarde. Si vous utilisez d'autres produits cloud ou une découverte de services tierce et souhaitez empêcher le basculement automatique du trafic, envisagez d'exclure les ressources Service de la sauvegarde. Cela vous permet d'effectuer un déploiement manuel pour basculer le trafic lorsque vous êtes prêt.

Exclusions de sauvegarde par défaut

• Le namespace csdr est le namespace de travail de Backup Center. Sauvegarder et restaurer directement ce namespace peut entraîner un dysfonctionnement des composants de Backup Center dans le cluster de récupération. De plus, Backup Center synchronise automatiquement les sauvegardes, il est donc inutile de migrer manuellement les sauvegardes vers un nouveau cluster.

• Le namespace ack-csi-fuse est le namespace de travail du composant de stockage CSI et exécute des Pods clients FUSE gérés par CSI. Lorsque vous restaurez le stockage dans un nouveau cluster, le CSI de ce cluster provisionne automatiquement les Pods clients requis. Par conséquent, une sauvegarde et une restauration manuelles sont inutiles.

• Les namespaces kube-system, kube-public et kube-node-lease sont des namespaces système par défaut dans un cluster Kubernetes. Étant donné que les paramètres et configurations du cluster varient selon les environnements, ces namespaces ne peuvent pas être simplement restaurés d'un cluster à un autre. Backup Center est conçu pour sauvegarder et restaurer des applications métier, et non l'infrastructure sous-jacente du cluster. Avant de lancer une tâche de restauration, vous devez préinstaller et configurer les composants système requis dans le cluster de récupération. Par exemple :

  • Composant sans identifiant ACR : Réautorisez et configurez acr-configuration pour le cluster de récupération.

  • Composant ALB Ingress : Préconfigurez ALBConfig et d'autres paramètres.

  La sauvegarde directe de composants système du namespace kube-system vers un nouveau cluster peut provoquer leur échec.

Sauvegarde avec snapshots de disque cloud ECS

Dans les scénarios suivants, Backup Center utilise par défaut les snapshots de disque cloud ECS pour sauvegarder les disques cloud :

1. Le cluster est un cluster géré ACK ou un cluster dédié ACK.

2. Le cluster exécute la version 1.18 ou ultérieure et utilise un plugin de stockage CSI version 1.18 ou ultérieure.

Dans les autres scénarios, Backup Center utilise par défaut Cloud Backup pour sauvegarder les disques cloud.

Par défaut, les snapshots de disque cloud créés par Backup Center ont la fonctionnalité de disponibilité rapide des snapshots activée. Leur période de rétention correspond à celle spécifiée dans la configuration de sauvegarde. Depuis le 12 octobre 2023 à 11 h 00, Alibaba Cloud ne facture plus de frais de stockage ou de requête pour la fonctionnalité de disponibilité rapide des snapshots dans toutes les régions. Pour plus d'informations, consultez la rubrique Disponibilité rapide des snapshots.

Incohérence de la période de rétention des snapshots ECS

La création de snapshots de disque cloud dépend du composant csi-provisioner (ou managed-csiprovisioner) du cluster. Si la version du composant csi-provisioner est antérieure à la 1.20.6, il ne prend pas en charge la spécification d'une période de rétention ou l'activation de la fonctionnalité de disponibilité rapide des snapshots lors de la création de la ressource de snapshot associée (VolumeSnapshot). Par conséquent, la période de rétention spécifiée dans la configuration de sauvegarde ne s'applique pas aux snapshots de disque cloud ECS.

**Par conséquent, pour utiliser la fonctionnalité de sauvegarde de données pour les volumes de disque cloud, mettez à niveau le composant csi-provisioner vers la version 1.20.6 ou ultérieure.**

Si vous ne pouvez pas mettre à niveau le composant csi-provisioner sur votre cluster, vous pouvez configurer une période de rétention de snapshot par défaut en suivant ces étapes :

1. Mettez à niveau le composant migrate-controller du centre de sauvegarde vers la version 1.7.10 ou ultérieure.

2. Exécutez la commande suivante pour vérifier s'il existe une classe de snapshot avec une période de rétention par défaut de 30 jours dans le cluster.

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

   • Si la classe de snapshot n'existe pas, créez la classe de snapshot csdr-disk-snapshot-with-default-ttl en utilisant le manifeste YAML suivant.

   • Si elle existe déjà, définissez simplement retentionDays sur « 30 » dans la classe de snapshot par défaut csdr-disk-snapshot-with-default-ttl.

     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. Après l'application de cette configuration, les sauvegardes de volumes de disque cloud dans ce cluster créeront des snapshots avec une période de rétention correspondant à la valeur retentionDays.

   Important

   Pour garantir que la période de rétention des snapshots de disque cloud ECS issus des sauvegardes corresponde toujours à la configuration de sauvegarde, mettez à niveau le composant csi-provisioner vers la version 1.20.6 ou ultérieure.

Quand sauvegarder les données de volume de stockage

Qu'est-ce que la sauvegarde de volume de stockage ?

Sauvegarder les données d'un volume de stockage consiste à enregistrer son contenu sur un stockage cloud à l'aide de services tels que les snapshots de disque cloud ECS ou HBR. Lors d'une restauration, ces données sont ensuite chargées dans un nouveau disque cloud ou volume NAS pour être utilisées par l'application restaurée. Ce processus garantit que l'application restaurée et l'application originale ne partagent pas la même source de données, ce qui leur permet de fonctionner indépendamment.

Si vous n'avez pas besoin de copier les données ou si vous nécessitez une source de données partagée, vous pouvez choisir de ne pas sauvegarder les données du volume de stockage. Dans ce cas, assurez-vous que les ressources PVC et PV ne figurent pas sur la liste d'exclusion de votre configuration de sauvegarde. Lors d'une restauration, le processus déploie le volume de stockage directement dans le nouveau cluster en fonction de sa configuration YAML originale.

Cas d'utilisation

• Pour la reprise après sinistre (DR) et le versionning des données.

• Lors de l'utilisation de disques cloud, car ils ne peuvent être attachés qu'à un seul nœud.

• Pour la sauvegarde et la restauration inter-régions, car la plupart des types de stockage (sauf OSS) ne permettent pas l'accès inter-régions.

• Lorsqu'une isolation des données est requise entre les applications source et restaurée.

• Lorsque des différences significatives dans les plugins de stockage ou leurs versions entre les clusters source et de restauration empêchent une restauration directe depuis le YAML original.

Risques liés à l'absence de sauvegarde des données

Si vous ne sauvegardez pas les données du volume de stockage et que la sauvegarde inclut une application avec état, la restauration se comporte comme suit :

• **Pour les volumes de stockage avec une politique de récupération Delete :**

  Ce processus est similaire à un déploiement initial de PVC. Si une classe de stockage correspondante existe dans le cluster de restauration, le pilote CSI provisionne automatiquement un nouveau PV. Par exemple, avec un stockage sur disque cloud, le système attache un nouveau disque cloud vide à l'application restaurée. Pour un PV provisionné statiquement sans classe de stockage spécifiée, ou si le cluster de restauration ne possède pas de classe de stockage correspondante, le PVC restauré et le pod resteront dans l'état Pending jusqu'à ce que vous créiez manuellement le PV ou la classe de stockage requis.

• **Pour les volumes de stockage avec une politique de récupération Retain :**

  Lors d'une restauration, le processus restaure le PV puis le PVC séquentiellement en fonction de leurs configurations YAML originales. Pour le stockage multi-attachement comme NAS ou OSS, cela permet à l'application restaurée de réutiliser le système de fichiers ou le bucket original. Cependant, pour un disque cloud, cela risque de provoquer un détachement forcé.

Vous pouvez exécuter la commande suivante pour interroger la politique de récupération d'un volume de stockage :

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

Sortie attendue :

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

Sélectionner des nœuds pour les sauvegardes de système de fichiers

Cloud Backup sauvegarde et restaure les volumes (à l'exclusion des disques cloud) en exécutant des tâches sur un nœud. La politique de planification par défaut de ACK Scheduler correspond à celle du planificateur Kubernetes communautaire. Vous pouvez également configurer des politiques pour restreindre les tâches à des nœuds spécifiques.

Politiques de planification des nœuds

• Politique d'exclusion (par défaut) : Par défaut, tous les nœuds peuvent être utilisés pour la sauvegarde et la restauration. Si vous ne souhaitez pas que les tâches de sauvegarde cloud soient planifiées sur certains nœuds, vous devez ajouter le libellé csdr.alibabacloud.com/agent-excluded="true" à ces nœuds.

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

• Politique d'inclusion : Par défaut, les nœuds non étiquetés ne peuvent pas être utilisés pour la sauvegarde et la récupération. Vous devez ajouter le tag csdr.alibabacloud.com/agent-included="true" aux nœuds autorisés à exécuter des tâches de sauvegarde cloud.

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

• Préféré : Par défaut, n'importe quel nœud peut exécuter des tâches de sauvegarde et de restauration. La priorité de planification est la suivante :

  1. Priorité la plus élevée : les nœuds portant le libellé csdr.alibabacloud.com/agent-included="true".

  2. Priorité intermédiaire : les nœuds sans libellé spécifique.

  3. Priorité la plus basse : les nœuds portant le libellé csdr.alibabacloud.com/agent-excluded="true".

Modifier la politique de planification des nœuds

1. Exécutez la commande suivante pour modifier le ConfigMap csdr-config.

   kubectl -n csdr edit cm csdr-config

   Dans la section applicationBackup, ajoutez le paramètre node_schedule_policy comme illustré dans l'exemple suivant :

   Exemple

   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  # Add this configuration. Valid values: include, exclude, prefer.
     pvBackup: |
       batch_snapshot_max_num: 20
       enable_ecs_snapshot: "true"

2. Exécutez la commande suivante afin de redémarrer le Deployment csdr-controller et appliquer les modifications.

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

Sauvegarde d'applications et protection des données

Sauvegarde d'applications :

• Cette méthode cible les charges de travail de votre cluster. Elle sauvegarde les ressources du cluster, y compris les applications, les services et les fichiers de configuration.

• Elle permet également de sauvegarder les données des volumes de stockage montés par vos applications.

  Remarque

  Une sauvegarde d'application n'inclut pas les données des volumes de stockage qui ne sont pas montés par un Pod.

  Pour sauvegarder une application avec l'intégralité des données de ses volumes de stockage, créez également une sauvegarde de protection des données.

• Cette fonctionnalité est idéale pour la migration de clusters et permet une récupération rapide des applications en cas de reprise après sinistre.

Protection des données :

• Cette approche cible spécifiquement les données des volumes de stockage. La sauvegarde inclut uniquement les persistent volume claims et les persistent volumes.

• La restauration de la sauvegarde crée un nouveau persistent volume claim que votre application peut monter directement. Ce volume restauré contient une copie distincte des données, indépendante de l'original. Si un persistent volume claim est supprimé accidentellement, une restauration depuis le centre de sauvegarde provisionne un nouveau disque cloud contenant des données identiques à celles présentes au moment de la sauvegarde. Le persistent volume claim restauré conserve tous les paramètres de montage d'origine, à l'exception de l'instance de disque cloud sous-jacente, ce qui permet à votre application de le monter sans aucune modification.

• Conçue pour la réplication des données et la reprise après sinistre, cette fonctionnalité répond aux besoins de continuité d'activité.

Ignorer la sauvegarde et la restauration de volumes spécifiques

Dans les environnements de production, les données de certains volumes de stockage, telles que les journaux, sont considérées comme jetables lors d'une migration ou d'une reprise après sinistre.

Il est possible d'ignorer la sauvegarde et la restauration des données pour les services à faible priorité utilisant des sources de stockage résilientes. Par exemple, des services de stockage comme OSS offrent une évolutivité massive, un accès inter-zones de disponibilité ou interrégions, ainsi que des capacités intégrées de reprise après sinistre avec plusieurs réplicas.

Prenons l'exemple d'un namespace contenant deux volumes : le volume de stockage A, qui ne nécessite pas de sauvegarde, et le volume de stockage B, qui en nécessite une.

Processus de sauvegarde

1. Utilisez la fonctionnalité de protection des données pour sélectionner le volume de stockage B, ce qui sauvegarde à la fois la configuration YAML et les données correspondantes de ce volume. Pour plus d'informations, consultez Sauvegarder et restaurer des applications au sein d'un cluster.

   Remarque

   Lors de la sauvegarde des données, le système utilise un snapshot ou un service de sauvegarde cloud pour créer une sauvegarde indépendante. Un volume de stockage restauré à partir de cette sauvegarde constitue une copie séparée contenant les mêmes données que l'original. Les modifications apportées à l'un n'affectent pas l'autre.

2. Recourez à la fonctionnalité de sauvegarde d'applications pour sélectionner le namespace contenant votre application. Pour l'option Volume Backup, sélectionnez Disable. Cette action sauvegarde par défaut les configurations YAML du volume de stockage A et du volume de stockage B. Pour plus d'informations, consultez Sauvegarder et restaurer des applications au sein d'un cluster.

   Remarque

   Si vous n'avez pas besoin de déployer le volume de stockage A dans le nouveau cluster, spécifiez pvc, pv dans le champ Excluded Resources des paramètres avancés afin d'éviter la restauration de sa configuration YAML.

Processus de restauration

Le processus de restauration s'apparente au déploiement d'une nouvelle application. Vous devez restaurer les volumes de stockage et les données avant de restaurer les charges de travail qui les utilisent.

1. Dans le cluster de destination, restaurez la sauvegarde de protection des données. Cela restaure la configuration YAML et les données du volume de stockage B. Pour plus d'informations, consultez Sauvegarder et restaurer des applications au sein d'un cluster.

2. Toujours dans le cluster de destination, restaurez la sauvegarde d'applications. Cette opération restaure le YAML du volume de stockage A ainsi que les autres ressources de l'application. Selon la politique de récupération du PV d'origine pour le volume de stockage A, le pilote CSI provisionne une nouvelle source de stockage ou réutilise celle existante. Pour plus d'informations, reportez-vous à la section « Quels sont les risques liés à l'absence de sauvegarde des données de volumes de stockage pour une application avec état ? » de la rubrique Dans quels scénarios dois-je sauvegarder les données des volumes de stockage lors d'une sauvegarde d'application ?.

Vous avez désormais restauré l'application, le volume de stockage A et le volume de stockage B (y compris ses données).

Chiffrement des buckets OSS et permissions KMS

Le chiffrement d'un bucket OSS peut être effectué côté serveur ou côté client. Actuellement, Backup Center prend uniquement en charge le chiffrement côté serveur pour les buckets OSS. Vous pouvez activer et configurer manuellement ce chiffrement côté serveur pour votre bucket associé dans la console OSS. Pour plus de détails sur le chiffrement côté serveur des buckets OSS et sa configuration, consultez Chiffrement côté serveur.

• Si vous utilisez une clé hébergée par KMS pour le chiffrement et le déchiffrement, et recourez à l'option Bring Your Own Key (BYOK) en spécifiant un ID CMK, vous devez accorder des permissions KMS supplémentaires à Backup Center. Procédez comme suit :

  • Créez une politique personnalisée avec le contenu suivant. Consultez Créer une politique personnalisée pour obtenir les instructions détaillées.

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

    Cette politique autorise l'utilisation de toutes les clés KMS associées à l'ID de compte Alibaba Cloud spécifié. Pour un contrôle plus granulaire des ressources, consultez Informations d'autorisation.

  • Pour un cluster dédié ACK ou un cluster enregistré, attribuez cette politique à l'utilisateur RAM utilisé lors de l'installation (consultez Gérer les permissions des utilisateurs RAM). Pour les autres types de clusters, attribuez la politique au rôle RAM AliyunCSManagedBackupRestoreRole (consultez Gérer les permissions des rôles RAM).

• Si vous utilisez la clé KMS par défaut gérée par OSS ou une clé gérée par OSS pour le chiffrement et le déchiffrement, aucune permission supplémentaire n'est requise.

Modifier les images lors de la restauration

Supposons que l'application incluse dans votre sauvegarde utilise l'image suivante : docker.io/library/app1:v1

• Modification du registre d'images

  Dans les scénarios de cloud hybride, lors du déploiement d'applications sur plusieurs fournisseurs cloud ou de la migration d'applications d'un IDC vers le cloud, vous devez d'abord transférer les images requises vers un référentiel cloud, tel qu'Alibaba Cloud Container Registry (ACR).

  Utilisez le champ imageRegistryMapping pour configurer un mappage de registres. Par exemple, la configuration suivante remplace le chemin de l'image par registry.cn-beijing.aliyuncs.com/my-registry/app1:v1.

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

• Modification du référentiel d'images, du tag ou d'autres attributs

  Il s'agit d'une configuration avancée. Vous devez définir une règle de transformation dans un ConfigMap avant de lancer la restauration.

  Par exemple, pour remplacer l'image par app2:v2, créez la configuration suivante :

  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"
    # To change only the repository:
    # "case1": "app1,app2"
    # To change only the tag:
    # "case1": "v1:v2"
    # To change an image from a specific registry:
    # "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

  Si vous devez effectuer plusieurs ajustements, continuez à configurer case2, case3, etc. dans la section data.

  Après avoir créé le ConfigMap, créez la tâche de restauration normalement, mais laissez le champ imageRegistryMapping vide.

  Remarque

  Cette configuration s'applique à toutes les tâches de restauration du cluster. Pour éviter toute modification involontaire, utilisez des règles de transformation spécifiques. Les commentaires fournissent des exemples, tels que la limitation de la portée à un registre spécifique. Supprimez le ConfigMap lorsqu'il n'est plus nécessaire.