Gérer les conflits sur des ressources lors d'une restauration

Cette page explique comment configurer des stratégies de gestion des conflits dans un plan de restauration, pour les ressources d'espace de noms et à l'échelle d'un cluster.

Lors de la restauration sur un cluster, vous risquez de rencontrer des conflits de ressources dans les scénarios suivants :

  • Effectuer une restauration sur un cluster existant sur lequel des ressources sont déjà provisionnées.
  • Lorsqu'une ressource Kubernetes est gérée par des outils tels que GitOps ou un opérateur.

Le service Sauvegarde pour GKE fournit diverses options permettant de définir la gestion des conflits pour les ressources d'espace de noms et à l'échelle d'un cluster, que vous pouvez spécifier dans un plan de restauration.

Gestion des conflits de restauration concernant les ressources à l'échelle du cluster

Vous pouvez configurer les options suivantes dans le plan de restauration, afin de gérer les conflits concernant les ressources à l'échelle du cluster :

  • Conserver les ressources dans le cluster cible (non destructif) : si une ressource portant le même nom existe dans le cluster cible, elle sera conservée telle quelle.

  • Remplacer les ressources dans le cluster cible (destructif) : si une ressource existe déjà dans le cluster cible, elle sera supprimée et une copie sera restaurée à partir de la sauvegarde.

gcloud

Mettez à jour un plan de restauration existant afin de gérer les conflits concernant une ressource à l'échelle du cluster :

gcloud beta container backup-restore restore-plans update RESTORE_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION \
    --cluster-resource-conflict-policy=CLUSTER_RESOURCE_CONFLICT_POLICY

Remplacez les éléments suivants :

  • RESTORE_PLAN : nom du plan de restauration que vous souhaitez mettre à jour.
  • PROJECT_ID : ID de votre projet Google Cloud
  • LOCATION : région de calcul de la ressource, par exemple us-central1.

  • CLUSTER_RESOURCE_CONFLICT_POLICY : définit la gestion des conflits de délai de restauration pour les ressources de cluster sélectionnées. Utilisez l'une des options suivantes :

    • use-existing-version : si les ressources en cours de restauration existent déjà dans le cluster cible, Sauvegarde pour GKE conserve les ressources existantes.
    • use-backup-version : si les ressources en cours de restauration existent déjà dans le cluster cible, Sauvegarde pour GKE remplace les ressources existantes par les nouvelles ressources de la sauvegarde.

Console

Suivez les instructions ci-dessous pour mettre à jour la règle de conflit sur les ressources à l'échelle du cluster dans la console Google Cloud :

  1. Dans Google Cloud Console, accédez à la page Google Kubernetes Engine.

    Accéder à Google Kubernetes Engine

  2. Dans le menu de navigation, cliquez sur Sauvegarde pour GKE.

  3. Cliquez sur l'onglet Plans de restauration.

  4. Cliquez sur le nom du plan de restauration.

  5. Cliquez sur l'onglet Détails.

  6. Dans la section Configuration de restauration, accédez à la section Ressources à l'échelle du cluster, puis cliquez sur Modifier.

  7. Dans la section Définir la gestion des conflits, sélectionnez une option de gestion des conflits.

  8. Cliquez sur Enregistrer les modifications.

Gestion des conflits de restauration concernant les ressources d'espace de noms

Dans le plan de restauration, vous pouvez configurer les options suivantes pour gérer les conflits concernant une ressource d'espace de noms. Vous pouvez spécifier la gestion des conflits concernant les ressources d'espace de noms aux niveaux suivants :

  • Ressource individuelle
  • Espace de noms et application protégée

Vous trouverez ci-dessous les options disponibles pour gérer les conflits au niveau des ressources individuelles :

  • Ignorer la fusion (non destructif) : si une ressource spécifique existe déjà, sa restauration à partir de la sauvegarde va être ignorée.
  • Fusionner en remplaçant le volume (destructeur) : si une ressource spécifique existe déjà, sa restauration va être ignorée mais le volume persistant sous-jacent va être remplacé à l'aide de la règle de restauration des données de volume. La fusion en remplaçant le volume permet d'effectuer la une restauration ne contenant que des données.
  • Fusionner en remplaçant (destructeur) : si une ressource spécifique existe déjà, elle va être remplacée par celle de la sauvegarde et les données de volume associées, en appliquant la règle de restauration des données de volume.

Vous trouverez ci-dessous les options disponibles pour gérer les conflits au niveau de toutes les ressources appartenant à un Namespace et à une ProtectedApplication :

  • Échec en cas de conflit (non destructeur) : si l'espace de noms ou la ProtectedApplication ciblés pour la restauration à partir d'une sauvegarde existent déjà dans le cluster cible, la restauration va échouer.

  • Rollback (destructeur) : si le cluster cible contient l'espace de noms ou la ProtectedApplication qui sont ciblés pour la restauration dans le cluster, le groupe de ressources existant va être supprimé avant la restauration des nouvelles ressources.

gcloud

Mettez à jour un plan de restauration existant afin de gérer les conflits concernant une ressource d'espace de noms :

gcloud beta container backup-restore restore-plans update RESTORE_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION \
    --namespaced-resource-restore-mode=NAMESPACED_RESOURCE_RESTORE_MODE

Remplacez les éléments suivants :

  • RESTORE_PLAN : nom du plan de restauration que vous souhaitez mettre à jour.
  • PROJECT_ID : ID de votre projet Google Cloud
  • LOCATION : région de calcul de la ressource, par exemple us-central1.

  • NAMESPACED_RESOURCE_RESTORE_MODE : définit la gestion des conflits de délai de restauration pour les ressources d'espace de noms. Utilisez l'une des options suivantes :

    • merge-skip-on-conflict : ignore les ressources en conflit individuelles.
    • merge-replace-volume-on-conflict : ignore les ressources en conflit individuelles, mais remplace les données de volume persistant sous-jacentes.
    • merge-replace-on-conflict : remplace les ressources individuelles en conflit et les données de volume persistantes sous-jacentes.
    • fail-on-conflict : renvoie un échec sur l'espace de noms ou la ProtectedApplication en conflit.
    • delete-and-restore : effectue un rollback sur l'espace de noms ou la ProtectedApplication en conflit.

Console

Suivez les instructions ci-dessous pour mettre à jour la règle relative aux conflits sur des ressources d'espaces de noms dans la console Google Cloud :

  1. Dans Google Cloud Console, accédez à la page Google Kubernetes Engine.

    Accéder à Google Kubernetes Engine

  2. Dans le menu de navigation, cliquez sur Sauvegarde pour GKE.

  3. Cliquez sur l'onglet Plans de restauration.

  4. Cliquez sur le nom du plan de restauration.

  5. Cliquez sur l'onglet Détails.

  6. Dans la section Configurations de restauration, accédez à la section Ressources d'espace de noms, puis cliquez sur Modifier.

  7. Dans la section Définir la gestion des conflits, sélectionnez une option de gestion des conflits.

  8. Cliquez sur Enregistrer les modifications.

Le tableau suivant présente les stratégies de gestion des conflits recommandées pour certains scénarios courants :

Scénarios Stratégie de gestion des conflits recommandée pour une ressource d'espace de noms Stratégie de gestion des conflits recommandée pour une ressource à l'échelle d'un cluster
Effectuer une restauration sur un tout nouveau cluster Échec en cas de conflit Conserver les ressources dans le cluster cible
Effectuer un rollback de l'intégralité de l'espace de noms ou de la ProtectedApplication Supprimer et restaurer Non applicable
Effectuer une restauration sur un cluster géré basé sur GitOps, sans volumes Ne pas fusionner Conserver les ressources dans le cluster cible
Restauration des données uniquement pour un cluster géré basé sur GitOps Fusionner en remplaçant le volume Conserver les ressources dans le cluster cible
Effectuer un rollback des charges de travail et données de volume sélectionnées Fusionner en remplaçant Remplacer les ressources dans le cluster cible

Étapes suivantes