Activer le mode permissif sur un plan de sauvegarde

Autopilot Standard

Cette page explique comment activer le mode Permissive sur un plan de sauvegarde.

Lors de l'exécution d'une sauvegarde, si Sauvegarde pour GKE détecte des conditions susceptibles de provoquer l'échec de la restauration, la sauvegarde elle-même échoue. Le motif de l'échec est fourni dans le champ state_reason de la sauvegarde. Dans la console Google Cloud, ce champ est intitulé Motif de l'état.

Si vous activez le mode permissif, la description du problème est toujours fournie dans le champ Motif de l'état, mais la sauvegarde n'échoue pas. Vous pouvez activer ce comportement si vous êtes au courant du problème et que vous êtes prêt à utiliser une solution de contournement au moment de la restauration.

Voici un exemple de message d'erreur susceptible de s'afficher dans le champ Motif de l'état de la sauvegarde, qui suggère l'activation du mode d'autorisation : If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Activer le mode permissif :

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Remplacez les éléments suivants :

BACKUP_PLAN : nom du plan de sauvegarde 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. Consultez la page À propos des emplacements des ressources.

Pour obtenir la liste complète des options, consultez la documentation gcloud beta container backup-restore backup-plans update.

Console

Suivez les instructions ci-dessous pour activer le mode Permissif dans la console Google Cloud :

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

Accéder à Google Kubernetes Engine
Dans le menu de navigation, cliquez sur Sauvegarde pour GKE.
Cliquez sur l'onglet Plans de sauvegarde.
Développez le cluster, puis cliquez sur le nom du plan.
Cliquez sur l'onglet Détails pour modifier les informations relatives au plan.
Cliquez sur Modifier pour modifier la section comportant le mode de sauvegarde.
Cochez la case Mode permissif, puis cliquez sur Enregistrer les modifications.

Terraform

Mettez à jour la ressource google_gke_backup_backup_plan existante.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Remplacez les éléments suivants :

NAME : nom du google_gke_backup_backup_plan que vous souhaitez mettre à jour.

Pour en savoir plus, consultez la section gke_backup_backup_plan.

Résoudre les échecs de sauvegarde

Le tableau suivant fournit des explications et les actions recommandées pour divers messages d'échec de sauvegarde affichés dans le champ Motif de l'état de la sauvegarde.

Message d'échec de la sauvegarde	Description du message et motif de l'échec	Action recommandée
`CustomResourceDefinitions "..." have invalid schemas`	Description : Une définition de ressource personnalisée (CRD) dans le cluster a été appliquée à l'origine en tant que `apiextensions.k8s.io/v1beta1` et ne dispose pas d'un schéma structurel requis dans `apiextensions.k8s.io/v1`. Motif : Sauvegarde pour GKE ne peut pas définir automatiquement le schéma structurel. La restauration de l'objet CRD dans les clusters Kubernetes v1.22 et versions ultérieures, où `apiextensions.k8s.io/v1beta1` n'est pas disponible, entraîne l'échec de la restauration. Cette défaillance se produit lors de la restauration de ressources personnalisées définies par l'objet CRD.	Nous vous recommandons d'utiliser les options suivantes : Si vous gérez la CRD, suivez la procédure décrite dans la documentation Kubernetes pour spécifier un schéma structurel pour votre CRD. S'il s'agit d'une CRD gérée par GKE, vous pouvez appeler `kubectl delete crd` si aucune ressource existante n'est diffusée par l'objet CRD. Si des ressources existantes sont diffusées par la CRD, vous pouvez activer le mode permissif en comprenant le comportement de restauration. Pour obtenir des recommandations sur les CRD courantes, consultez la documentation. S'il s'agit d'une CRD tierce, consultez la documentation appropriée pour migrer vers `apiextensions.k8s.io/v1`. Lorsque le mode Permissif est activé, l'objet CRD sans schéma de structure n'est pas sauvegardé dans un cluster Kubernetes version 1.22 ou ultérieure. Pour réussir à restaurer une telle sauvegarde, vous devez exclure les ressources servies par la CRD de la restauration ou créer la CRD dans le cluster cible avant de commencer la restauration.
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	Description : dans le cluster source, un PVC est lié à un PV qui n'est pas un volume Persistent Disk. Motif : Sauvegarde pour GKE ne permet de sauvegarder que les données de volume Persistent Disk. Aucune donnée de volume ne sera restaurée pour les PVC de disque non persistant restaurés à l'aide de la règle Provisionner de nouveaux volumes et restaurer les données de volume à partir de la sauvegarde. Toutefois, la règle Réutiliser les volumes existants contenant vos données permet de reconnecter les PVC au descripteur de volume d'origine. Cela est utile pour les types de volumes qui sont gérés par un serveur externe, comme NFS.	Activez le mode Permissif grâce à une compréhension des options de restauration disponibles pour les volumes non persistants de disques persistants dans le cluster source. Pour sauvegarder des volumes Filestore, consultez la section Gérer les volumes Filestore avec la sauvegarde pour GKE. Lorsque le mode Permissif est activé, la configuration du PVC est sauvegardée, mais pas les données de volume.
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	Description : un PVC du cluster n'est pas lié à un PV. Motif : Sauvegarde pour GKE peut sauvegarder le PVC, mais il n'y a pas de données de volume à sauvegarder. Cette situation peut indiquer une mauvaise configuration ou une incohérence entre l'espace de stockage demandé et disponible.	Vérifiez si le PVC non lié est dans un état acceptable. Si c'est le cas, activez le mode Permissif. Tenez compte des conséquences sur le comportement des sauvegardes. Lorsque le mode permissif est activé, la configuration du PVC est sauvegardée, mais aucune donnée de volume ne doit être sauvegardée.
`Failed to query API resources ...`	Description : Un service d'API du cluster est mal configuré. Les requêtes adressées au chemin d'accès de l'API renvoient ainsi "Échec de l'interrogation des ressources d'API". Il est possible que le service sous-jacent n'existe pas ou qu'il ne soit pas encore prêt. Motif : Sauvegarde pour GKE ne peut pas sauvegarder les ressources gérées par l'API indisponible.	Vérifiez le service sous-jacent dans le fichier `spec.service` du service d'API pour vous assurer qu'il est prêt. Lorsque le mode Permissif est activé, les ressources des groupes d'API dont le chargement a échoué ne sont pas sauvegardées.
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	Description : dans Kubernetes v1.23 et versions antérieures, les comptes de service génèrent automatiquement un jeton sauvegardé par un secret. Toutefois, dans les versions ultérieures, Kubernetes a supprimé cette fonctionnalité de jeton généré automatiquement. Un pod du cluster peut avoir installé le volume secret sur le système de fichiers de ses conteneurs. Motif : si Sauvegarde pour GKE tente de restaurer un compte de service avec son secret généré automatiquement et un pod qui installe le volume secret, la restauration semble réussie. Cependant, Kubernetes supprime le secret, ce qui entraîne le blocage du pod lors de la création du conteneur et l'échec du démarrage.	Définissez le champ `spec.serviceAccountName` dans le pod. Cette action garantit que le jeton est automatiquement installé sur `/var/run/secrets/kubernetes.io/serviceaccount` dans les conteneurs. Pour en savoir plus, consultez la documentation Configurer des comptes de service pour les pods. Lorsque le mode Permissif est activé, le secret est sauvegardé, mais ne peut pas être installé dans les pods des clusters Kubernetes v1.24 et versions ultérieures.

CRD courantes avec problèmes et actions recommandées

Voici quelques CRD courantes qui présentent des problèmes de sauvegarde, ainsi que les actions que nous vous recommandons pour les résoudre :

capacityrequests.internal.autoscaling.k8s.io : cette CRD a été utilisée temporairement dans les clusters v1.21. Exécutez kubectl delete crd capacityrequests.internal.autoscaling.k8s.io pour supprimer la CRD.
scalingpolicies.scalingpolicy.kope.io : cette CRD a été utilisée pour contrôler les ressources fluentd, mais GKE a migré vers fluentbit. Exécutez kubectl delete crd scalingpolicies.scalingpolicy.kope.io pour supprimer la CRD.
memberships.hub.gke.io : exécutez kubectl delete crd memberships.hub.gke.io pour supprimer la CRD s'il n'y a pas de ressources d'appartenance. Active le mode Permissif s'il existe des ressources d'appartenance.
applications.app.k8s.io : active le mode Permissif grâce à une compréhension du comportement de restauration.