La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Gérez les modèles de hooks d'exécution Kubernetes dans NetApp Backup and Recovery

08/21/2026 Contributeurs

Créez des modèles de hooks d'exécution pour exécuter des scripts personnalisés avant ou après les opérations de protection des applications Kubernetes gérées.

NetApp Backup and Recovery gèle et dégèle les systèmes de fichiers pour des applications comme KubeVirt lors de la protection des données. Vous pouvez désactiver ce comportement globalement ou pour des applications spécifiques en utilisant la documentation Trident Protect :

Pour désactiver ce comportement pour toutes les applications, reportez-vous à "Protection des données avec les machines virtuelles KubeVirt" .
Pour désactiver ce comportement pour une application spécifique, reportez-vous à "Définir une application" .

Rôle de NetApp Console requis

Super administrateur de Backup and Recovery, administrateur de sauvegarde Backup and Recovery ou administrateur de restauration Backup and Recovery. "En savoir plus sur les rôles d'accès à NetApp Backup and Recovery". "En savoir plus sur les rôles d'accès à la NetApp Console pour tous les services".

Types de hooks d'exécution

NetApp Backup and Recovery prend en charge les types de hooks d'exécution suivants en fonction de leur moment d'exécution :

Pré-instantané
Post-instantané
Pré-sauvegarde
Post-sauvegarde
Post-restauration

Ordre d'exécution

Lorsqu'une opération de protection des données s'exécute, les événements du hook d'exécution se produisent dans l'ordre suivant :

Tous les hooks d’exécution de pré-opération personnalisés applicables sont exécutés sur les conteneurs appropriés. Vous pouvez créer plusieurs hooks de pré-opération personnalisés, mais leur ordre d'exécution n'est ni garanti ni configurable.
Des blocages du système de fichiers se produisent, le cas échéant.
L'opération de protection des données est effectuée.
Les systèmes de fichiers gelés sont dégelés, le cas échéant.
NetApp Backup and Recovery exécute tous les hooks personnalisés post-opération applicables sur les conteneurs appropriés. Vous pouvez créer plusieurs hooks personnalisés post-opération, mais leur ordre d'exécution n'est ni garanti ni configurable.

Si vous créez plusieurs hooks du même type, leur ordre d'exécution n'est pas garanti. Les hooks de types différents s'exécutent toujours dans l'ordre spécifié. Par exemple, les hooks s'exécutent dans cet ordre lorsqu'une configuration inclut tous les types de hooks pris en charge :

Exécution des hooks de pré-snapshot
Exécution des hooks post-snapshot
Exécution des hooks de pré-sauvegarde
Exécution des hooks post-sauvegarde

Testez les scripts d'exécution avant de les activer en production. Utilisez « kubectl exec » pour tester les scripts, puis vérifiez les instantanés et les sauvegardes en clonant l'application dans un espace de noms temporaire et en la restaurant.

Si un hook d’exécution pré-snapshot ajoute, modifie ou supprime des ressources Kubernetes, ces modifications sont incluses dans le snapshot ou la sauvegarde et dans toute opération de restauration ultérieure.

Remarques importantes sur les hooks d'exécution personnalisés

Tenez compte des éléments suivants lors de la planification des hooks d'exécution pour vos applications.

Un hook d'exécution doit utiliser un script pour effectuer des actions. De nombreux hooks d’exécution peuvent référencer le même script.
Les hooks d'exécution doivent être des scripts shell exécutables.
La taille du script est limitée à 96 Ko.
Les paramètres de hook d'exécution et tous les critères de correspondance sont utilisés pour déterminer quels hooks sont applicables à une opération de snapshot, de sauvegarde ou de restauration.

Les hooks d'exécution peuvent réduire ou désactiver la fonctionnalité de l'application. Faites en sorte que vos hooks personnalisés s'exécutent le plus rapidement possible. Si vous annulez une opération de sauvegarde ou de snapshot qui a des hooks d'exécution associés, ces hooks s'exécutent quand même si l'opération a déjà commencé. La logique d'un hook d'exécution post-sauvegarde ne peut pas supposer que la sauvegarde est terminée.

Filtres de crochet d'exécution

Lorsque vous ajoutez ou modifiez un hook d'exécution pour une application, vous pouvez ajouter des filtres au hook d'exécution afin de contrôler les conteneurs auxquels le hook correspond. Les filtres sont utiles pour les applications qui utilisent la même image de conteneur sur tous les conteneurs, mais peuvent utiliser chaque image à des fins différentes (comme Elasticsearch). Les filtres vous permettent de créer des scénarios où les hooks d'exécution s'exécutent sur certains, mais pas nécessairement sur tous les conteneurs identiques. Si vous créez plusieurs filtres pour un même hook d'exécution, ils sont combinés à l'aide de l'opérateur logique AND. Vous pouvez avoir jusqu'à 10 filtres actifs par hook d'exécution.

Chaque filtre que vous ajoutez à un hook d'exécution utilise une expression régulière pour faire correspondre les conteneurs de votre cluster. Lorsqu'un hook correspond à un conteneur, il exécute son script associé sur ce conteneur. Les expressions régulières pour les filtres utilisent la syntaxe Regular Expression 2 (RE2), qui ne permet pas de créer un filtre excluant des conteneurs de la liste des correspondances. Pour obtenir des informations sur la syntaxe que NetApp Backup and Recovery prend en charge pour les expressions régulières dans les filtres des hooks d'exécution, consultez "Prise en charge de la syntaxe des expressions régulières 2 (RE2)".

Si vous ajoutez un filtre d'espace de noms à un hook d'exécution qui s'exécute après une opération de restauration ou de clonage et que la source et la destination de restauration ou de clonage se trouvent dans des espaces de noms différents, le filtre d'espace de noms est appliqué uniquement à l'espace de noms de destination.

Exemples de crochets d'exécution

Visitez le "Projet GitHub NetApp Verda" pour télécharger de véritables hooks d'exécution pour des applications populaires telles qu'Apache Cassandra et Elasticsearch. Vous pouvez également voir des exemples et obtenir des idées pour structurer vos propres hooks d'exécution personnalisés.

Les scripts du dépôt Verda GitHub sont fournis tels quels et ne sont pas officiellement pris en charge par NetApp. Seul le framework d'exécution des hooks dans Trident Protect et Backup and Recovery est officiellement pris en charge par NetApp.

Créer un modèle de hook d'exécution

Vous pouvez créer un modèle de hook d’exécution personnalisé que vous pouvez utiliser pour effectuer des actions avant ou après une opération de protection des données sur une application.

Les modèles que vous créez ici ne sont utilisables que lors de la protection des charges de travail Kubernetes.

Étapes

Dans la console, accédez à Protection > Sauvegarde et récupération.
Sélectionnez l'onglet Paramètres.
Développez la section Modèle de hook d'exécution.
Sélectionnez Créer un modèle de hook d'exécution.
Entrez un nom pour le hook d’exécution.
Vous pouvez également choisir un type de hook. Par exemple, un hook post-restauration est exécuté une fois l'opération de restauration terminée.
Dans la zone de texte Script, saisissez le script shell exécutable que vous souhaitez exécuter dans le cadre du modèle de hook d'exécution. Vous pouvez également sélectionner Télécharger le script pour télécharger un fichier de script à la place.
Sélectionnez Créer.

Une fois le modèle créé, il apparaît dans la liste des modèles dans la section Modèle de hook d'exécution.