Sauvegarder un cluster OVHcloud Managed Kubernetes avec CloudCasa

Découvrez comment sauvegarder un cluster OVHcloud Managed Kubernetes avec CloudCasa

Objectif

Ce guide de démarrage rapide vous explique comment déployer CloudCasa sur votre cluster OVHcloud Managed Kubernetes, créer des politiques de sauvegarde, définir des planifications, exécuter des sauvegardes et effectuer des restaurations.

CloudCasa™ by Catalogic est un service de sauvegarde puissant et facile à utiliser pour Kubernetes et les bases de données cloud, destiné aux équipes DevOps et IT Ops. Avec CloudCasa, vous n'avez pas besoin d'être un expert du stockage ou de la protection des données pour sauvegarder et restaurer vos clusters Kubernetes. CloudCasa vous accompagne dans la tâche ardue de protéger les ressources de votre cluster et vos données persistantes contre les erreurs humaines, les failles de sécurité et les pannes de service, afin d'assurer la continuité d'activité et la conformité dont votre entreprise a besoin.

La mise en place et la configuration de CloudCasa pour votre cluster OVHcloud Managed Kubernetes se déroulent en une procédure simple de 6 étapes :

Créer un compte CloudCasa et déployer l'agent CloudCasa
Créer une application fictive
Configurer la classe de snapshot de volume
Configurer une politique de sauvegarde
Définir et exécuter une sauvegarde
Exécuter une opération de restauration pour l'application fictive

Avant de commencer

Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes opérationnel, ainsi que de connaissances de base sur son fonctionnement. Pour en savoir plus sur ces sujets, veuillez consulter la documentation Déployer une application Hello World.

L'outil kubectl doit être installé et configuré. Vous aurez besoin d'un accès administrateur au cluster pour installer l'agent CloudCasa sur votre cluster. Lors de l'enregistrement de votre cluster dans l'interface utilisateur (UI), chaque cluster recevra un fichier YAML unique à appliquer sur celui-ci. Vous devez autoriser l'accès réseau sortant depuis votre cluster vers le service CloudCasa (agent.cloudcasa.io) sur le port 443 (ce port est ouvert par défaut).

En pratique

Étape 1 – Créer un compte CloudCasa et déployer l'agent CloudCasa

Rendez-vous sur cloudcasa.io/signup pour créer un compte gratuit en fournissant les informations habituelles. Connectez-vous ensuite à votre compte après avoir vérifié l'adresse e-mail enregistrée, ce qui vous amènera au tableau de bord CloudCasa.

Ce guide s'appuie sur la version de CloudCasa datée du 11 octobre 2022.

Après vous être connecté à CloudCasa, accédez à l'onglet Protection > Clusters > Overview, puis cliquez sur le bouton Add cluster en haut à droite.

Indiquez le nom et la description du cluster, puis cliquez sur le bouton Save.

Cela affiche une commande kubectl à exécuter pour installer l'agent CloudCasa.

Exécutez la commande kubectl sur votre cluster et vérifiez que le cluster Kubernetes enregistré passe à l'état actif dans l'UI CloudCasa. Cela ne devrait pas prendre plus de quelques minutes. Votre agent CloudCasa a maintenant été déployé avec succès.

Étape 2 – Créer une application fictive

Commencez par créer un exemple de déploiement dans un nouveau namespace ovhcloud-and-cloudcasa-test :

kubectl create namespace ovhcloud-and-cloudcasa-test

Appliquez ensuite la configuration suivante à l'aide de :

kubectl create -f <path to .yaml>

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: mypvc 
  namespace: ovhcloud-and-cloudcasa-test 
spec: 
  storageClassName: csi-cinder-classic 
  accessModes: 
    - ReadWriteOnce 
  resources: 
    requests: 
      storage: 2Gi 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: myapp-deployment 
  namespace: ovhcloud-and-cloudcasa-test 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      app: myapp 
  template: 
    metadata: 
      labels: 
        app: myapp 
    spec: 
      containers: 
      - name: date 
        image: debian:9-slim 
        command: ["/bin/sh","-c"] 
        args: ["while true; do /bin/date | /usr/bin/tee -a /mnt/date ; /bin/sleep 5; done"] 
        volumeMounts: 
          - mountPath: /mnt 
            name: data-mount 
      - name: sidecar 
        image: debian:9-slim 
        command: ["/bin/sh","-c"] 
        args: ["/bin/sleep 3600"] 
        securityContext: 
          privileged: true 
        volumeMounts: 
          - mountPath: /mnt 
            name: data-mount 
      volumes: 
      - name: data-mount 
        persistentVolumeClaim: 
          claimName: mypvc

Ce déploiement crée un pod contenant 2 conteneurs. Le conteneur date se contente d'ajouter la date sur la sortie standard et dans /mnt/date toutes les 5 secondes :

kubectl -n ovhcloud-and-cloudcasa-test exec myapp-deployment-<pod-name> -c date -- cat /mnt/date

Le conteneur sidecar se contente de monter le PVC sous /mnt puis reste inactif. Ce conteneur est utilisé pendant le processus de snapshot pour figer (« quiesce ») le système de fichiers afin qu'un snapshot cohérent puisse être réalisé. Il ne remplit aucune autre fonction. Remarquez que ce conteneur doit avoir le flag privileged défini sur true. Cela est nécessaire pour exécuter la commande fsfreeze.

Étape 3 – Configurer la classe de snapshot de volume

Supprimez la classe de snapshot de volume CloudCasa :

kubectl delete volumesnapshotclass cloudcasa-cinder-csi-openstack-org

Modifiez la volumesnapshotclass :

kubectl edit volumesnapshotclass csi-cinder-snapclass-in-use-v1

Modifiez cette VSC pour effectuer les changements suivants : Ajoutez le label suivant :

velero.io/csi-volumesnapshot-class: "true" 
Ensure that DeletionPolicy is set to Retain.

Voici un exemple de volumesnapshotclass :

# Please edit the object below. Lines beginning with a '#' will be ignored, 
# and an empty file will abort the edit. If an error occurs while saving this file will be 
# reopened with the relevant failures. 
# 
apiVersion: snapshot.storage.k8s.io/v1 
deletionPolicy: Retain 
driver: cinder.csi.openstack.org 
kind: VolumeSnapshotClass 
metadata: 
  creationTimestamp: "2022-09-29T13:41:28Z" 
  generation: 2 
  labels: 
    velero.io/csi-volumesnapshot-class: "true" 
  name: csi-cinder-snapclass-in-use-v1 
  resourceVersion: "3694783821" 
  uid: 2040b84b-b10a-46fe-8d30-2507a12edd58 
parameters: 
  force-create: "true"

Étape 4 – Configurer une politique de sauvegarde

Une politique de sauvegarde vous permet de définir quand les sauvegardes qui l'utilisent seront exécutées et pendant combien de temps elles seront conservées. Vous pouvez avoir plusieurs planifications avec des durées de rétention différentes au sein d'une même politique. Par exemple, une politique peut prévoir la création de sauvegardes horaires conservées pendant 7 jours, et de sauvegardes quotidiennes conservées pendant 30 jours.

Accédez à l'onglet Policies via Configuration > Protection > Policies. Créez une politique en cliquant sur le bouton Add policy. Renseignez les informations requises, puis cliquez sur le bouton Create policy.

Étape 5 – Définir et exécuter une sauvegarde

Accédez à l'onglet Dashboard. Cliquez sur Define backup. Indiquez le nom de la sauvegarde et sélectionnez le cluster pour lequel vous définissez une sauvegarde.

Choisissez entre l'ensemble du cluster, un namespace spécifique, ou indiquez un sélecteur de label (facultatif). Si vous sauvegardez un namespace spécifique, saisissez le nom du namespace que vous souhaitez protéger.

Pour l'opération de sauvegarde, choisissez si vous souhaitez réaliser un snapshot de vos PV. Sélectionnez ensuite l'une des deux options disponibles :

Snapshot uniquement
Snapshot et copie

L'option « Snapshot et copie » n'est disponible qu'avec un abonnement payant.

Si vous souhaitez exécuter des commandes avant et après la sauvegarde pour permettre des sauvegardes cohérentes au niveau applicatif, sélectionnez Enable App Hooks et saisissez les définitions de hooks d'application appropriées, avant et après la sauvegarde. Vous devrez avoir défini des hooks personnalisés dans Configuration/App Hooks pour figer l'application et le système de fichiers. Cela n'est pas nécessaire pour toutes les applications. Si vous avez besoin d'aide à ce sujet, utilisez le chat intégré au produit ou contactez casa@cloudcasa.io.

Sur la page suivante, activez Run now pour exécuter immédiatement l'opération de sauvegarde et indiquez le nombre de jours de rétention (cette période de rétention ne s'applique qu'à cette exécution ponctuelle). Cliquez sur le bouton Create. Cela crée une définition de sauvegarde.

Accédez à l'onglet Dashboard et repérez, dans Clusters > Backups, la sauvegarde que vous souhaitez exécuter. Cliquez sur le bouton Run now sur sa ligne. Vous verrez le job s'exécuter dans l'onglet Activity du tableau de bord. Vérifiez qu'il se termine avec succès.

Étape 6 – Exécuter une opération de restauration pour l'application fictive

Mettons en place un scénario de reprise après sinistre, en supprimant notre application fictive et le namespace associé :

kubectl delete -n ovhcloud-and-cloudcasa-test deployments.apps myapp-deployment 

kubectl delete namespaces ovhcloud-and-cloudcasa-test

Restaurons maintenant notre application fictive. Retournez dans Clusters > Backups sur le Dashboard et cliquez sur l'icône Restore à côté de votre définition de sauvegarde dans la liste.

Lorsque la page de restauration s'ouvre, sélectionnez un point de récupération spécifique dans la liste des points de récupération disponibles. Cliquez ensuite sur le bouton Next.

Sur la page suivante, vous pouvez choisir de restaurer tous les namespaces de la sauvegarde, ou uniquement certains namespaces sélectionnés. Si vous choisissez cette dernière option, une liste de namespaces s'affiche, dans laquelle vous pouvez sélectionner le ou les namespaces pour lesquels l'opération de restauration sera effectuée. Notez que seuls les namespaces inclus dans la sauvegarde seront affichés.

Pour cette démonstration, nous allons restaurer l'intégralité du namespace ovhcloud-and-cloudcasa-test. Nous prenons également en charge la restauration de types de ressources spécifiques, ainsi que l'utilisation de scripts post-restauration via l'activation des hooks d'application.

Notez que les namespaces existants ne peuvent pas être écrasés. Si vous souhaitez restaurer un namespace existant sur un cluster, vous devez d'abord supprimer l'ancien. Vous pouvez également renommer les namespaces lors de la restauration (plus tard).

Vous pouvez également ajouter des labels pour sélectionner les ressources à restaurer. Il s'agit de paires clé/valeur, qui ne seront pas validées par l'UI. Vous pouvez les ajouter une par une, ou plusieurs paires à la fois, séparées par des espaces.

Enfin, vous devez choisir de restaurer ou non les snapshots de PV. Si vous désactivez l'option « Exclude persistent volumes », les PV seront restaurés à l'aide des snapshots ou copies associés au point de récupération que vous avez sélectionné.

Notez que si vous avez sélectionné des namespaces ou des labels spécifiques pour la restauration, seuls les PV présents dans ces namespaces ou portant ces labels seront restaurés.

Sur la page suivante, les options de destination vous seront présentées.

Le système enregistre également le job sous son nom, afin que vous puissiez le modifier et le relancer ultérieurement.

À l'étape suivante, vous pouvez choisir un cluster alternatif vers lequel restaurer. Par défaut, la restauration s'effectue vers le cluster d'origine. Vous pouvez choisir de renommer les namespaces restaurés en ajoutant un préfixe et/ou un suffixe, et modifier les storage classes si vous le souhaitez.

Notez que tous les namespaces restaurés recevront ces préfixes ou suffixes. Si vous souhaitez renommer uniquement certains namespaces spécifiques, vous devez effectuer plusieurs restaurations et sélectionner explicitement ces namespaces.

Enfin, donnez un nom au job de restauration. Cliquez sur le bouton Restore et CloudCasa se charge du reste ! Vous pouvez suivre la progression du job de restauration dans le panneau de progression. Vous pouvez également le modifier et le relancer, si vous le souhaitez, depuis l'onglet Restore du cluster.

Vérifiez que l'application est de nouveau active.

Enfin, consultons le contenu du fichier /mnt/date dans le pod de l'application. Vous pouvez voir ici un écart de 14 minutes, ce qui correspond à l'heure du snapshot (12:40) et à l'heure de la restauration (12:54).

Récapitulatif

Félicitations, vous avez terminé ! C'est aussi simple que cela. Vous savez désormais réaliser des sauvegardes ponctuelles ou planifiées, et effectuer des restaurations de vos clusters, namespaces et applications OVHcloud Managed Kubernetes avec CloudCasa.

Aller plus loin

Si vous avez des questions, vous pouvez consulter la page FAQ et accéder au forum dédié.

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?