For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/backup-restore-cluster-trilio.md.

Sauvegarder et restaurer un cluster, un namespace et des applications OVHcloud Managed Kubernetes avec TrilioVault for Kubernetes

Voir en Markdown

Sauvegardez et restaurez un cluster, un namespace et des applications avec TVK

Introduction

Ce tutoriel vous explique comment déployer TrilioVault for Kubernetes (ou TVK) sur votre cluster OVHcloud Managed Kubernetes, créer des sauvegardes, et restaurer une sauvegarde en cas de problème.
Vous pouvez sauvegarder l'intégralité de votre cluster en incluant plusieurs namespaces, ou choisir de sauvegarder un seul namespace, des sauvegardes basées sur des labels, des sauvegardes basées sur des Helm Releases ou des sauvegardes basées sur des opérateurs.

Avantages de l'utilisation de Trilio :

  • Réalisez des sauvegardes complètes (ou incrémentielles) de l'ensemble de vos namespaces, d'applications sélectives, et restaurez-les en cas de perte de données.
  • Migrez d'un cluster à un autre.
  • Les sauvegardes de releases Helm sont prises en charge.
  • La sauvegarde des déploiements d'applications basés sur un opérateur est également prise en charge.
  • Exécutez des hooks avant et après les opérations de sauvegarde et de restauration.
  • Une console web de gestion, qui vous permet d'inspecter en détail l'état de vos opérations de sauvegarde/restauration (et bien d'autres fonctionnalités).
  • Définissez des politiques de rétention pour vos sauvegardes.
  • Le cycle de vie de l'application (c'est-à-dire TVK lui-même) peut être géré via un TrilioVault Operator dédié.
  • Intégration avec Velero (Trilio permet de superviser les sauvegardes, restaurations et emplacements de sauvegarde/snapshot Velero via sa console web de gestion).

Fonctionnement de TrilioVault for Kubernetes

TVK suit une architecture cloud native, ce qui signifie qu'il est composé de plusieurs éléments formant ensemble les couches Control Plane et Data Plane. Tout est géré via des CRD, ce qui le rend entièrement natif pour Kubernetes. Ce qui est intéressant avec Trilio, c'est la séparation claire des responsabilités, et l'efficacité avec laquelle il gère les opérations de sauvegarde et de restauration.

Chaque application TrilioVault est constituée d'un ensemble de « contrôleurs » et des CRD associées. Chaque fois qu'une CRD est créée ou mise à jour, le contrôleur responsable en est notifié et effectue une réconciliation du cluster. Le contrôleur en charge déclenche alors des jobs Kubernetes qui exécutent l'opération réelle (comme backup, restore, etc.) en parallèle.

Le Control Plane se compose de :

  • Target Controller : définit le backend de stockage (S31, NFS, etc.) via des CRD spécifiques.
  • BackupPlan Controller : définit les composants à sauvegarder, la planification automatisée des sauvegardes, la stratégie de rétention, etc. via des CRD spécifiques.
  • Restore Controller : définit les opérations de restauration via des CRD spécifiques.

Le Data Plane se compose de :

  • Des pods Datamover, chargés de transférer les données entre les volumes persistants et le support de sauvegarde (ou Target). TrilioVault fonctionne avec les Persistent Volumes (PV) via l'interface CSI. Pour chaque PV à sauvegarder, un pod Datamover éphémère est créé. Une fois l'opération terminée, le pod associé est détruit.
  • Des pods Metamover, chargés de transférer les données des objets de l'API Kubernetes vers le support de sauvegarde (ou Target). Les pods Metamover sont éphémères, tout comme les pods Datamover.

Comprendre la portée d'application de TrilioVault

TrilioVault for Kubernetes fonctionne selon une portée (« scope »), ce qui signifie que vous pouvez opter pour une installation de type Namespaced ou Cluster.

Une installation Namespaced vous permet d'effectuer des opérations backup et restore uniquement au niveau du namespace. En d'autres termes, la sauvegarde vise à protéger un ensemble d'applications rattachées à un namespace que vous possédez. C'est ainsi que fonctionnent un « BackupPlan » et la CRD Backup correspondante. Vous ne pouvez pas modifier ces CRD dans d'autres namespaces : elles doivent être créées dans le même namespace que l'application à sauvegarder.

À l'inverse, une installation de type Cluster n'est ni limitée ni rattachée à un namespace ou à un ensemble d'applications en particulier. Vous définissez les sauvegardes de type cluster via les CRD préfixées par Cluster, telles que : ClusterBackupPlan, ClusterBackup, etc. Les sauvegardes de type Cluster sont un peu plus flexibles, dans le sens où vous n'êtes pas lié à un namespace ou à un ensemble d'applications spécifique à sauvegarder et à restaurer. Vous pouvez effectuer des opérations de sauvegarde/restauration pour plusieurs namespaces et applications à la fois, y compris les PV (vous pouvez également sauvegarder le contenu de la base etcd).

Afin de s'assurer que la portée et les règles d'application de TVK sont bien respectées, TrilioVault utilise un Admission Controller. Il intercepte et valide chaque CRD que vous souhaitez envoyer pour TVK, avant qu'elle ne soit réellement créée. Si la portée d'application de TVK n'est pas respectée, l'Admission Controller rejettera la création de la CRD dans le cluster.

Un autre point important à considérer est qu'une licence TVK est spécifique à une portée d'application donnée. En d'autres termes, vous devez générer un type de licence différent pour une installation Namespaced ou pour une installation Cluster.

Portée d'application TVK Namespaced vs Cluster : quand utiliser l'une ou l'autre ?

Tout dépend du cas d'usage. Par exemple, une portée Namespaced est une option plus appropriée lorsque vous n'avez pas accès à l'ensemble du cluster Kubernetes, mais uniquement à des namespaces et applications spécifiques.

Dans la plupart des cas, vous souhaitez protéger uniquement les applications rattachées à un namespace spécifique que vous possédez.

À l'inverse, une installation à portée cluster fonctionne au niveau global, ce qui signifie qu'elle peut déclencher des opérations de sauvegarde/restauration pour n'importe quel namespace ou ressource d'un cluster Kubernetes (y compris les PV et la base etcd).

Pour résumer :

  • Si vous êtes administrateur de cluster, vous souhaiterez très probablement effectuer des opérations au niveau du cluster via les CRD correspondantes, telles que : ClusterBackupPlan, ClusterBackup, ClusterRestore, etc.
  • Si vous êtes un utilisateur standard, vous effectuerez généralement des opérations limitées au namespace (centrées sur l'application) via les CRD correspondantes, telles que : BackupPlan, Backup, Restore, etc.

L'interface applicative est très similaire, voire uniforme, lorsqu'on compare les deux types : les CRD préfixées Cluster et celles qui ne le sont pas. Ainsi, si vous êtes familier avec l'un des deux types, il est très simple d'utiliser l'autre.

Pour plus d'informations, veuillez consulter la documentation officielle des CRD TVK.

Workflow de sauvegarde et de restauration

Chaque fois que vous souhaitez sauvegarder une application, vous commencez par créer une CRD BackupPlan (ou ClusterBackupPlan), suivie d'un objet Backup (ou ClusterBackup). Le Backup Controller de Trilio est notifié du changement et effectue l'inspection et la validation de l'objet de sauvegarde (c'est-à-dire s'il s'agit d'une sauvegarde cluster, namespace, etc.). Il déclenche ensuite des pods worker (Metamover, Datamover) chargés de déplacer les données réelles (métadonnées Kubernetes, données des PV) vers le stockage backend (ou Target), comme OVHcloud Object Storage.

De même, chaque fois que vous créez un objet Restore, le « Restore Controller » est notifié pour effectuer une restauration à partir d'un objet Backup. Le Restore Controller de Trilio déclenche alors des nœuds worker (Metamover, Datamover), chargés de déplacer les données de sauvegarde depuis OVHcloud Object Storage (métadonnées Kubernetes, données des PV). Enfin, le processus de restauration est lancé à partir de l'objet de sauvegarde concerné.

Trilio est idéal pour les scénarios de reprise après sinistre, ainsi que pour effectuer un « instantané » de l'état de votre application avant de réaliser des opérations système sur votre cluster, comme des mises à niveau. Pour plus de détails sur ce sujet, veuillez consulter les pages officielles Trilio Features et Trilio Use Case.

À la fin de ce tutoriel, vous devriez être en mesure de :

  • Configurer le backend OVHcloud Object Storage pour que Trilio puisse l'utiliser.
  • Effectuer les opérations backup et restore de vos applications.
  • Effectuer les opérations backup et restore de l'intégralité de votre cluster OVHcloud Managed Kubernetes.
  • Créer des sauvegardes planifiées pour vos applications.
  • Créer des politiques de rétention pour vos sauvegardes.

Table des matières

Prérequis

Pour terminer ce tutoriel, vous devez disposer des éléments suivants :

  1. Un conteneur/bucket OVHcloud Object Storage et un utilisateur Object Storage disposant des permissions nécessaires pour accéder au conteneur Object Storage.
  2. Un client Git, pour cloner le dépôt OVHcloud Docs.
  3. Helm, pour gérer les releases et les mises à niveau de TrilioVault Operator.
  4. Kubectl, pour interagir avec Kubernetes.
  5. krew, pour installer le plugin de vérifications préalables (« preflight checks »).
Warning

Informations importantes :

Pour que TrilioVault fonctionne correctement et puisse sauvegarder vos PVC, le cluster OVHcloud Managed Kubernetes doit être configuré pour prendre en charge la Container Storage Interface (ou CSI) et les CustomResourceDefinitions volumesnapshot doivent être déployées.

kubectl get crd | grep volumesnapshot

La sortie doit ressembler à ceci :

volumesnapshotclasses.snapshot.storage.k8s.io    2022-01-20T07:58:05Z
volumesnapshotcontents.snapshot.storage.k8s.io   2022-01-20T07:58:05Z
volumesnapshots.snapshot.storage.k8s.io          2022-01-20T07:58:06Z

Assurez-vous également que la CRD prend en charge les versions d'API v1beta1 et v1. Vous pouvez exécuter la commande ci-dessous pour vérifier la version d'API :

kubectl get crd volumesnapshots.snapshot.storage.k8s.io -o yaml

À la fin du YAML de la CRD, vous devriez obtenir une sortie semblable à celle-ci, montrant storedVersions avec v1beta1 et v1 :

...
- lastTransitionTime: "2022-01-20T07:58:06Z"
    message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
    reason: ApprovedAnnotation
    status: "True"
    type: KubernetesAPIApprovalPolicyConformant
  storedVersions:
  - v1beta1
  - v1

Vous pouvez ensuite installer le pilote CSI Hostpath et créer une storageclass, une volumesnapshotclass. Vous pouvez vérifier la storage class existante avec la commande ci-dessous :

kubectl get storageclass

La sortie doit ressembler à ceci (remarquez que le provisioner est hostpath.csi.k8s.io si vous avez installé le pilote CSI Hostpath) :

NAME                        PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
csi-cinder-classic          cinder.csi.openstack.org   Delete          Immediate           true                   3d
csi-cinder-high-speed       cinder.csi.openstack.org   Delete          Immediate           true                   3d
csi-cinder-high-speed-gen2  cinder.csi.openstack.org   Delete          Immediate           true                   3d
csi-hostpath-sc (default)   hostpath.csi.k8s.io        Retain          Immediate           false                  2d

Il est recommandé d'exécuter une vérification préalable (« preflight check ») pour s'assurer que tous les prérequis de TVK sont bien remplis avant de poursuivre l'installation en toute sécurité. Suivez la page TVK Preflight Checks pour installer et exécuter cette vérification via le plugin krew.

En pratique

Étape 1 - Installer TrilioVault for Kubernetes

Dans cette étape, vous allez apprendre à déployer TrilioVault for Kubernetes pour un cluster OVHcloud Managed Kubernetes, et à gérer les installations TVK via Helm. Les données de sauvegarde seront stockées dans le bucket OVHcloud Object Storage créé précédemment dans la section Prérequis.

TrilioVault for Kubernetes se compose de l'Operator TVK et de l'application TVM.

Le TrilioVault Operator (installable via Helm) installe également la CRD TrilioVaultManager et crée une ressource personnalisée tvm. L'Operator TVK gère l'installation, les étapes de post-configuration, ainsi que les futures mises à niveau des composants applicatifs de Trilio.

Installer TrilioVault Operator et Manager avec Helm

Warning

Ce tutoriel utilise le type d'installation Cluster pour l'application TVK (la valeur Helm applicationScope est définie sur « Cluster »). Tous les exemples de ce tutoriel s'appuient sur ce type d'installation pour fonctionner correctement.

Suivez les étapes ci-dessous pour installer TrilioVault via Helm :

Tout d'abord, clonez le dépôt Git OVHcloud Docs et déplacez-vous dans votre copie locale :

git clone https://github.com/ovh/docs.git
cd docs/pages/public_cloud/containers_orchestration/managed_kubernetes/backup-and-restore-cluster-namespace-and-applications-with-trilio/

Ajoutez ensuite le dépôt Helm de TrilioVault, et listez les charts disponibles :

helm repo add triliovault-operator http://charts.k8strilio.net/trilio-stable/k8s-triliovault-operator
helm repo update
helm search repo triliovault-operator

La sortie ressemble à ceci :

NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
triliovault-operator/k8s-triliovault-operator   2.9.3           2.9.3           K8s-TrilioVault-Operator is an operator designe...

Le chart qui nous intéresse est triliovault-operator/k8s-triliovault-operator, qui installera l'Operator TrilioVault for Kubernetes sur le cluster. Vous pouvez exécuter la commande helm install pour installer l'Operator, ce qui installera également la CRD Triliovault Manager. Installez l'Operator TrilioVault for Kubernetes avec Helm :

TVK permet à l'utilisateur de modifier les valeurs utilisées par l'installation de l'Operator TVK à l'aide de l'option --set. Consultez les instructions détaillées sur la page One-click Installation.

helm install triliovault-operator triliovault-operator/k8s-triliovault-operator --namespace tvk --create-namespace

Vérifiez maintenant votre déploiement TVK :

helm ls -n tvk

La sortie ressemble à ceci (la colonne STATUS doit afficher « deployed ») :

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
triliovault-manager-tvk tvk             1               2022-06-21 07:15:03.681891176 +0000 UTC deployed        k8s-triliovault-2.9.3           2.9.3
triliovault-operator    tvk             1               2022-06-21 07:13:18.731129339 +0000 UTC deployed        k8s-triliovault-operator-2.9.3  2.9.3

Vérifiez ensuite que les applications TrilioVault-Operator et Triliovault-Manager sont bien actives :

kubectl get deployments -n tvk

La sortie ressemble à ceci (les pods du déploiement doivent être à l'état Ready) :

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
k8s-triliovault-admission-webhook               1/1     1            1           45d
k8s-triliovault-control-plane                   1/1     1            1           45d
k8s-triliovault-exporter                        1/1     1            1           45d
k8s-triliovault-ingress-nginx-controller        1/1     1            1           13d
k8s-triliovault-web                             1/1     1            1           45d
k8s-triliovault-web-backend                     1/1     1            1           45d
triliovault-operator-k8s-triliovault-operator   1/1     1            1           45d

Vérifiez maintenant vos CRD triliovaultmanagers, ainsi que la ressource personnalisée tvm :

kubectl get crd | grep trilio

La sortie ressemble à ceci :

backupplans.triliovault.trilio.io                     2022-06-21T07:39:38Z
backups.triliovault.trilio.io                         2022-06-21T07:39:38Z
clusterbackupplans.triliovault.trilio.io              2022-06-21T07:39:39Z
clusterbackups.triliovault.trilio.io                  2022-06-21T07:39:39Z
clusterrestores.triliovault.trilio.io                 2022-06-21T07:39:39Z
hooks.triliovault.trilio.io                           2022-06-21T07:39:39Z
licenses.triliovault.trilio.io                        2022-06-21T07:39:39Z
policies.triliovault.trilio.io                        2022-06-21T07:39:40Z
restores.triliovault.trilio.io                        2022-06-21T07:39:40Z
targets.triliovault.trilio.io                         2022-06-21T07:39:40Z
triliovaultmanagers.triliovault.trilio.io             2022-06-21T07:38:30Z

Vous pouvez également vérifier que la ressource personnalisée TVM a bien été créée.

kubectl get triliovaultmanagers -n tvk

La sortie ressemble à ceci :

NAME                  TRILIOVAULT-VERSION   SCOPE     STATUS     RESTORE-NAMESPACES
triliovault-manager   2.9.3                 Cluster   Deployed

Si la sortie ressemble à ce qui précède, vous avez installé TVK avec succès. Vous allez maintenant apprendre à vérifier le type et la validité de votre licence, ainsi qu'à la renouveler.

Licence de l'application TrilioVault

Par défaut, lors de l'installation de TVK via Helm, aucune licence d'essai gratuite n'est générée. Ce tutoriel vous aide à installer la licence à portée « Cluster », de type « Basic », pour une capacité de cluster de 500 CPU et une durée de validité de 5 ans.
Vous pouvez à tout moment vous rendre sur le site de Trilio et générer une nouvelle licence adaptée aux besoins de votre cluster.

Installer la licence de l'application TVK

Exécutez la commande ci-dessous pour voir quelle licence est disponible pour votre cluster (elle est gérée via la CRD License) :

curl -LO https://raw.githubusercontent.com/ovh/docs/develop/pages/public_cloud/containers_orchestration/managed_kubernetes/backup-and-restore-cluster-namespace-and-applications-with-trilio/manifests/tvk_install_license.yaml
kubectl apply -f tvk_install_license.yaml -n tvk

Exécutez la commande ci-dessous pour vérifier que la licence a bien été créée pour les utilisateurs OVHcloud :

kubectl get license -n tvk

La sortie ressemble à ceci (remarquez le STATUS, qui doit être « Active », ainsi que le type de licence dans la colonne EDITION et l'EXPIRATION TIME) :

NAMESPACE   NAME             STATUS   MESSAGE                                   CURRENT NODE COUNT   GRACE PERIOD END TIME   EDITION   CAPACITY   EXPIRATION TIME        MAX NODES
tvk         trilio-license   Active   Cluster License Activated successfully.   3                                            Basic     500        2027-06-21T00:00:00Z   3

La licence est gérée via une CRD spéciale, à savoir l'objet License. Vous pouvez l'inspecter en exécutant la commande ci-dessous :

kubectl describe license test-license-1 -n tvk

La sortie ressemble à ceci (remarquez les champs Message et Capacity, ainsi que l'Edition) :

Name:         test-license-1
Namespace:    tvk
Labels:       <none>
Annotations:  generation: 1
              triliovault.trilio.io/creator: kubernetes-admin
              triliovault.trilio.io/instance-id: 46188ee1-8ce1-4c45-96fa-c262f2214ced
              triliovault.trilio.io/updater:
                [{"username":"system:serviceaccount:tvk:k8s-triliovault","lastUpdatedTimestamp":"2022-06-21T10:06:59.796280418Z"}]
API Version:  triliovault.trilio.io/v1
Kind:         License
Metadata:
  Creation Timestamp:  2022-06-21T10:56:14Z
...
  Current Node Count:  3
  Max Nodes:           3
  Message:             Cluster License Activated successfully.
  Properties:
    Active:                        true
    Capacity:                      500
    Company:                       OVHCloud License For Users
    Creation Timestamp:            2022-06-21T00:00:00Z
    Edition:                       Basic
    Expiration Timestamp:          2027-06-21T00:00:00Z
    Kube UID:                      46188ee1-8ce1-4c45-96fa-c262f2214ced
    License ID:                    TVAULT-4ddf3f72-d2ab-11ec-9a22-4b4849af53ee
    Maintenance Expiry Timestamp:  2027-06-21T00:00:00Z
    Number Of Users:               -1
    Purchase Timestamp:            2022-06-21T00:00:00Z
    Scope:                         Cluster
...

La sortie ci-dessus vous indique également la date d'expiration de la licence dans le champ Expiration Timestamp, ainsi que la Scope (Cluster dans ce cas). Vous pouvez opter pour un type de licence à l'échelle du cluster, ou pour une licence basée sur un namespace. Vous trouverez plus de détails dans la page de documentation Trilio Licensing.

Renouveler la licence de l'application TVK

Pour renouveler la licence, vous devrez en demander une nouvelle sur le site de Trilio, en accédant à la page licensing. Après avoir rempli le formulaire, vous devriez recevoir le manifeste YAML de licence, qui peut être appliqué à votre cluster à l'aide de kubectl. Les commandes ci-dessous supposent que TVK est installé dans le namespace par défaut tvk (veuillez remplacer les paramètres fictifs <> en conséquence, si nécessaire) :

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Vous pouvez ensuite vérifier le nouveau statut de la licence comme indiqué précédemment :

# List available TVK licenses first from the `tvk` namespace
kubectl get license -n tvk

# Get information about a specific license from the `tvk` namespace
kubectl describe license <YOUR_LICENSE_NAME_HERE> -n tvk

Dans l'étape suivante, vous allez apprendre à définir le backend de stockage que TrilioVault utilisera pour stocker les sauvegardes, appelé target.

Étape 2 - Créer une Target TrilioVault pour stocker les sauvegardes

TrilioVault doit d'abord savoir où stocker vos sauvegardes. TrilioVault désigne le backend de stockage par le terme target, géré via une CRD spéciale nommée Target. Les types de target suivants sont pris en charge : S3 et NFS. Pour OVHcloud et dans le cadre de ce tutoriel, il est pertinent de s'appuyer sur le type de stockage S3, car il est économique et évolutif. Pour bénéficier d'un niveau de protection renforcé, vous pouvez créer plusieurs types de target (à la fois S3 et NFS), afin que vos données soient conservées en sécurité à plusieurs endroits, assurant ainsi une redondance des sauvegardes.

OVHcloud propose deux types de solutions Object Storage compatibles S3 :

  • Pour créer une Target pour OVHcloud Object Storage using S3 Swift API, utilisez ce lien.
  • Pour créer une Target pour S3 compatible Object Storage, utilisez ce lien

Créez un utilisateur Object Storage dans l'onglet situé à côté du conteneur Object Storage. Ensuite, depuis Utilisateurs & Rôles, attribuez les privilèges Administrateur à l'utilisateur S3.

Créez ensuite une Access Key et une Secret Key pour accéder au conteneur Object Storage en suivant le tutoriel Getting Started with the Swift S3 API.

Info

Si vous avez créé un conteneur avec l'option Haute Performance, suivez la documentation Getting started with S3 compatible Object Storage.

Enregistrez l'Access key et la Secret key utilisées dans le fichier ~/.aws/credentails de l'AWS CLI. Cela est nécessaire pour créer un secret de target ultérieurement. Notez l'URL de l'endpoint Object Storage s3.endpoint_url, ainsi que le nom de la région region fourni dans le fichier ~/.aws/config de l'AWS CLI. Ces informations sont nécessaires pour créer une Target ultérieurement.

Pour accéder à l'Object Storage, chaque target doit connaître les identifiants du bucket. Un Secret Kubernetes doit également être créé :

apiVersion: v1
kind: Secret
metadata:
  name: trilio-ovh-s3-target-secret
  namespace: tvk
type: Opaque
stringData:
  accessKey: <YOUR_OVH_OBJECT_STORAGE_BUCKET_ACCESS_KEY_ID_HERE>	# value must be base64 encoded
  secretKey: <YOUR_OVH_OBJECT_STORAGE_BUCKET_SECRET_KEY_HERE>    	# value must be base64 encoded

Remarquez que le nom du secret est trilio-ovh-s3-target-secret.
Il est référencé par le champ spec.objectStoreCredentials.credentialSecret de la CRD Target expliquée ci-dessous. Le secret peut se trouver dans le même namespace que celui où TrilioVault a été installé (par défaut tvk), ou dans un autre namespace de votre choix. Veillez simplement à référencer le namespace correctement. Par ailleurs, veillez à protéger le namespace où sont stockés les secrets TrilioVault via RBAC, pour des raisons de sécurité.

Une définition Target classique ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-ovh-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other								# e.g. `AWS` for AWS S3 Storage and `Other` for OVHcloud Object Storage
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: <YOUR_OVH_OBJECT_STORAGE_BUCKET_NAME_HERE>
    region: <YOUR_OVH_OBJECT_STORAGE_BUCKET_REGION_HERE>    # e.g.: `bhs` region for OVHcloud Object Storage or `us-est-1` etc for AWS S3
    url: "https://s3.<REGION_NAME_HERE>.cloud.ovh.net"  	# e.g.: `https://s3.bhs.cloud.ovh.net` for Object Storage Container in `bhs` region
    credentialSecret:
      name: trilio-ovh-s3-target-secret
      namespace: tvk
  thresholdCapacity: 10Gi

Explications de la configuration ci-dessus :

  • spec.type : type de target pour le stockage des sauvegardes (Object Storage est un stockage objet).
  • spec.vendor : fournisseur de stockage tiers hébergeant la target (pour OVHcloud Object Storage, il faut utiliser « Other » au lieu de « AWS »).
  • spec.enableBrowsing : active la navigation dans la target pour parcourir les sauvegardes qui y sont stockées.
  • spec.objectStoreCredentials : définit les identifiants requis (via credentialSecret) pour accéder à l'Object Storage, ainsi que d'autres paramètres tels que la région et le nom du bucket.
  • spec.thresholdCapacity : capacité seuil maximale pour le stockage des données de sauvegarde.

Étapes pour créer une Target pour TrilioVault :

  1. Tout d'abord, déplacez-vous à l'endroit où le dépôt Git ovh/docs a été cloné sur votre machine locale :
cd docs/pages/public_cloud/containers_orchestration/managed_kubernetes/backup-and-restore-cluster-namespace-and-applications-with-trilio/
  1. Créez ensuite le secret Kubernetes contenant les identifiants de votre bucket Object Storage de target (veuillez remplacer les paramètres fictifs <> en conséquence) :
kubectl create secret generic trilio-ovh-s3-target-secret \
  --namespace=tvk \
  --from-literal=accessKey="<YOUR_OVH_OBJECT_STORAGE_BUCKET_ACCESS_KEY_HERE>" \
  --from-literal=secretKey="<YOUR_OVH_OBJECT_STORAGE_BUCKET_SECRET_KEY_HERE>"
  1. Ouvrez et inspectez ensuite le fichier manifeste Target fourni dans le dépôt docs, à l'aide d'un éditeur de votre choix (de préférence avec la prise en charge du lint YAML). Vous pouvez par exemple utiliser VS Code :
cat manifests/triliovault-ovh-s3-target.yaml
  1. Remplacez maintenant les paramètres fictifs <> par les informations correspondant à votre bucket OVHcloud Object Storage Trilio, comme : bucketName, region, url et credentialSecret.
  2. Enfin, enregistrez le fichier manifeste et créez l'objet Target avec kubectl :
kubectl apply -f manifests/triliovault-ovh-s3-target.yaml

Ce qui se passe ensuite, c'est que TrilioVault déclenche un job worker nommé trilio-ovh-s3-target-validator, chargé de valider votre bucket Object Storage (disponibilité, permissions, etc.). Si le job se termine avec succès, le bucket est considéré comme sain (ou disponible) et la ressource de job trilio-ovh-s3-target-validator est ensuite supprimée. En cas de problème, le job de validation de la target Object Storage reste actif afin que vous puissiez inspecter les logs et identifier le problème éventuel.

Vérifiez à présent si la ressource Target créée précédemment est saine :

kubectl get target trilio-ovh-s3-target -n tvk

La sortie ressemble à ceci (remarquez la valeur de la colonne STATUS, qui doit être « Available », signifiant qu'elle est dans un état sain) :

NAME                   TYPE          THRESHOLD CAPACITY   VENDOR   STATUS      BROWSING ENABLED
trilio-ovh-s3-target   ObjectStore   10Gi                 Other    Available   Enabled

Si la sortie ressemble à ce qui précède, alors vous avez configuré avec succès l'objet target Object Storage.

Astuce : Si l'objet target ne devient pas sain, vous pouvez inspecter les logs du pod trilio-ovh-s3-target-validator pour identifier le problème :

Trouvez d'abord le validateur de target

kubectl get pods -n tvk | grep trilio-ovh-s3-target-validator

La sortie ressemble à ceci :

trilio-ovh-s3-target-validator-tio99a-6lz4q	1/1     Running     0          104s

Récupérez maintenant les données de logs

kubectl logs pod/trilio-ovh-s3-target-validator-tio99a-6lz4q -n tvk

La sortie ressemble à ceci (remarquez l'exception, à titre d'exemple) :

...
INFO:root:2022-06-21 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2022-06-21 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2022-06-21 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
  File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
    utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
    mount_s3_datastore(metadata_list, base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
    wait_until_mount(base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
    base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...

Vous allez maintenant découvrir la console web TVK, qui est un ajout très pratique et utile pour vous aider à gérer facilement les opérations de sauvegarde et de restauration, parmi de nombreuses autres fonctionnalités.

Étape 3 - Découvrir la console web de gestion TVK

Bien que vous puissiez gérer les opérations de sauvegarde et de restauration entièrement en ligne de commande via kubectl et les CRD, TVK propose une console web de gestion pour effectuer les mêmes opérations via une interface graphique. La console de gestion simplifie les tâches courantes grâce à des opérations en quelques clics, offre une meilleure visualisation et inspection des objets du cluster TVK, ainsi que la possibilité de créer des plans de reprise après sinistre (ou DRP).

L'installation via Helm présentée dans Étape 1 - Installer TrilioVault for Kubernetes a déjà pris en charge l'installation des composants nécessaires à la console web de gestion.

Accéder à la console web de gestion TVK

Pour pouvoir accéder à la console et explorer les fonctionnalités qu'elle propose, vous pouvez utiliser un LoadBalancer, un NodePort, ou effectuer un port-forward vers le service ingress-nginx-controller pour TVK.

Tout d'abord, vous devez identifier le service ingress-nginx-controller dans le namespace tvk :

kubectl get svc -n tvk

La sortie ressemble à ceci (recherchez la ligne k8s-triliovault-ingress-nginx-controller, et remarquez qu'elle écoute sur le port 80 dans la colonne PORT(S)) :

NAME                                                            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   10.3.241.124   <none>        443/TCP                      45d
k8s-triliovault-ingress-nginx-controller                        NodePort    10.3.183.125   <none>        80:31879/TCP,443:31921/TCP   13d
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   10.3.20.89     <none>        443/TCP                      13d
k8s-triliovault-web                                             ClusterIP   10.3.56.86     <none>        80/TCP                       45d
k8s-triliovault-web-backend                                     ClusterIP   10.3.236.30    <none>        80/TCP                       45d
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   10.3.8.249     <none>        443/TCP                      45d

Si vous utilisez un LoadBalancer pour ingress-nginx-controller, la sortie ressemblera à ceci :

NAME                                                            TYPE        	CLUSTER-IP     EXTERNAL-IP   	PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   	10.3.241.124   <none>        	443/TCP                      45d
k8s-triliovault-ingress-nginx-controller                        LoadBalancer    10.3.183.125   51.222.45.171	80:31879/TCP,443:31921/TCP   13d
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   	10.3.20.89     <none>        	443/TCP                      13d
k8s-triliovault-web                                             ClusterIP   	10.3.56.86     <none>        	80/TCP                       45d
k8s-triliovault-web-backend                                     ClusterIP   	10.3.236.30    <none>        	80/TCP                       45d
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   	10.3.8.249     <none>        	443/TCP                      45d

TVK utilise un Nginx Ingress Controller pour router le trafic vers les services de la console web de gestion. Le routage est basé sur le nom d'hôte, et celui-ci est ovh-k8s-tvk.demo.trilio.io, comme défini dans le fichier de valeurs Helm du dépôt ovh/docs :

# The host name to use when accessing the web console via the TVK ingress controller service
ingressConfig:
  host: "ovh-k8s-tvk.demo.trilio.io"

Avec ces informations en main, modifiez le fichier /etc/hosts et ajoutez cette entrée :

127.0.0.1 ovh-k8s-tvk.demo.trilio.io

Créez ensuite le port-forward pour le service ingress controller de TVK :

kubectl port-forward svc/k8s-triliovault-ingress-nginx-controller 8080:80 -n tvk

Enfin, téléchargez le fichier kubeconfig de votre cluster OVHcloud Managed Kubernetes, disponible dans l'onglet Service sous le nom « Kubeconfig file ». Cette étape est nécessaire pour que la console web puisse vous authentifier à l'aide du fichier kubeconfig :

Une fois les étapes ci-dessus effectuées, vous pouvez accéder à la console dans votre navigateur web en vous rendant à l'adresse : http://ovh-k8s-tvk.demo.trilio.io. Lorsque le fichier kubeconfig vous est demandé, sélectionnez celui que vous avez créé lors de la dernière commande ci-dessus.

Info

Veuillez conserver le fichier kubeconfig généré en lieu sûr, car il contient des données sensibles.

Explorer l'interface utilisateur de la console web TVK

La page d'accueil ressemble à ceci :

Tableau de bord du cluster d'accueil TVK

Explorez chaque section depuis le menu de gauche :

  • Cluster Management : affiche la liste du cluster principal et des autres clusters disposant d'instances TVK, ajoutés au cluster OVHcloud principal via la fonctionnalité Multi-Cluster Management.
  • Backup & Recovery : il s'agit du tableau de bord principal, qui vous donne une vue d'ensemble générale du cluster entier, comme : les namespaces découverts, les applications, la liste des Backupplans, les Targets, les Hooks, les Policies, etc.
    • Namespaces :
    Namespaces du cluster TVK
    • Applications :
    Applications découvertes automatiquement par TVK
    • Backupplans :
    Backupplans TVK
    • Targets :
    Liste des Targets TVK
    • Scheduling Policy :
    Scheduling Policy par défaut de TVK
    • Retention Policy :
    Retention Policy par défaut de TVK
    • Monitoring : propose deux options, TrilioVault Monitoring et Velero Monitoring, si l'utilisateur a configuré Velero sur son cluster OVHcloud.
      • TrilioVault Monitoring : affiche le récapitulatif des sauvegardes et restaurations du cluster Kubernetes.
    TrilioVault Monitoring des sauvegardes et restaurations TVK
    • Velero Monitoring :
    Velero Monitoring TVK
  • Disaster Recovery : permet de gérer et d'effectuer des opérations de reprise après sinistre. Disaster Recovery TVK

Vous pouvez également retrouver la Target Object Storage créée précédemment, en vous rendant dans Backup & Recovery > Targets > sélectionnez le namespace TVK dans le menu déroulant en haut (dans le cas de ovh/docs, le namespace TVK est tvk) :

Liste des Targets TVK

Pour aller plus loin, vous pouvez parcourir la target et lister les sauvegardes disponibles en cliquant sur le bouton Actions à droite, puis en sélectionnant l'option Launch Browser dans le menu qui s'affiche (pour que cela fonctionne, la target doit avoir le paramètre enableBrowsing défini sur true) :

Navigateur de Target TVK

Pour plus d'informations et de fonctionnalités disponibles, veuillez consulter la documentation officielle TVK Web Management Console User Interface.

Vous allez maintenant apprendre à effectuer des opérations de sauvegarde et de restauration pour des cas d'usage spécifiques, comme :

  • Sauvegarde et restauration d'un ou plusieurs namespaces spécifiques.
  • Sauvegarde et restauration de l'intégralité du cluster.

Étape 4 - Exemple de sauvegarde et de restauration d'une release Helm

Dans cette étape, vous allez apprendre à créer une sauvegarde ponctuelle pour une release Helm entière de votre cluster OVHcloud Managed Kubernetes, puis à la restaurer par la suite, en veillant à ce que toutes les ressources liées à la release Helm soient recréées. Le namespace concerné est demo-backup-ns. TVK dispose d'une fonctionnalité intéressante qui vous permet d'effectuer des sauvegardes à un niveau supérieur aux simples releases Helm, à savoir : des namespaces complets, des applications basées sur des labels, et des applications basées sur un opérateur. Vous allez apprendre à réaliser une telle tâche dans les étapes qui suivent.

Vous allez maintenant effectuer les tâches suivantes :

  • Créer le namespace demo-backup-ns et créer une release Helm mysql-qa pour la base de données MySQL.
  • Effectuer une sauvegarde de namespace, via les CRD BackupPlan et Backup.
  • Supprimer la release Helm mysql-qa.
  • Restaurer la release Helm mysql-qa, via la CRD Restore.
  • Vérifier la restauration des ressources de la release Helm mysql-qa.

Créer la release Helm mysql-qa

helm repo add stable https://charts.helm.sh/stable
helm repo update
helm install mysql-qa --set mysqlRootPassword=triliopass stable/mysql -n demo-backup-ns

Pour vérifier que la release Helm a bien été déployée, exécutez la commande ci-dessous :

helm ls -n demo-backup-ns

La sortie ressemble à ceci :

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
mysql-qa        demo-backup-ns  1               2022-06-21 08:23:01.849247691 +0000 UTC deployed        mysql-1.6.9     5.7.30

Vérifiez ensuite que le déploiement mysql-qa est bien actif :

kubectl get deployments -n demo-backup-ns

La sortie ressemble à ceci :

NAME       READY   UP-TO-DATE   AVAILABLE   AGE
mysql-qa   1/1     1            1           2m5s

Cela montre que la release Helm mysql-qa est prête à être sauvegardée.

Créer une sauvegarde de la release Helm mysql-qa

Pour effectuer des sauvegardes d'une seule application au niveau du namespace (ou release Helm), un BackupPlan suivi d'une CRD Backup est nécessaire. Un BackupPlan vous permet de :

  • Spécifier une target où les sauvegardes doivent être stockées.
  • Définir un ensemble de ressources à sauvegarder (par exemple : un namespace ou des releases Helm).
  • Chiffrer vos sauvegardes sur la target, si vous le souhaitez (une fonctionnalité très intéressante pour sécuriser les données de vos sauvegardes).
  • Définir des schedules (planifications) pour des sauvegardes de type complètes ou incrémentielles.
  • Définir des politiques de retention (rétention) pour vos sauvegardes.
Info

TrilioVault for Kubernetes a créé quelques exemples de politiques de planification et de rétention pour les utilisateurs. Les utilisateurs peuvent créer de nouvelles politiques ou utiliser les politiques d'exemple.

Scheduling Policy par défaut de TVKRetention Policy par défaut de TVK

En d'autres termes, un BackupPlan définit le « quoi », le « où », le « vers » et le « comment » du processus de sauvegarde, mais n'effectue pas la sauvegarde à proprement parler. La CRD Backup est chargée de déclencher le processus de sauvegarde réel, comme défini par la spécification du BackupPlan.

Une CRD BackupPlan classique ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
  name: mysql-qa-helm-release-backup-plan
  namespace: demo-backup-ns
spec:
  backupConfig:
    target:
      name: trilio-ovh-s3-target
      namespace: tvk
  backupPlanComponents:
    helmReleases:
      - mysql-qa

Explications de la configuration ci-dessus :

  • spec.backupConfig.target.name : indique à TVK quel nom de target utiliser pour stocker les sauvegardes.
  • spec.backupConfig.target.namespace : indique à TVK dans quel namespace la target a été créée.
  • spec.backupComponents : définit une liste de ressources à sauvegarder (namespaces ou releases Helm).

Une CRD Backup classique ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: Backup
metadata:
  name: mysql-qa-helm-release-full-backup
  namespace: demo-backup-ns
spec:
  type: Full
  backupPlan:
    name: mysql-qa-helm-release-backup-plan
    namespace: demo-backup-ns

Explications de la configuration ci-dessus :

  • spec.type : spécifie le type de sauvegarde (par exemple Full ou Incremental).
  • spec.backupPlan : spécifie le BackupPlan que ce Backup doit utiliser.

Étapes pour lancer la sauvegarde ponctuelle de la release Helm mysql-qa :

  1. Tout d'abord, assurez-vous que mysql-qa est bien déployé dans votre cluster en suivant ces étapes.
  2. Déplacez-vous ensuite à l'endroit où le dépôt Git docs a été cloné sur votre machine locale :
cd docs/pages/public_cloud/containers_orchestration/managed_kubernetes/backup-and-restore-cluster-namespace-and-applications-with-trilio/
  1. Ouvrez et inspectez ensuite les fichiers manifestes BackupPlan et Backup de la release Helm mysql-qa, fournis dans le dépôt pages/public_cloud/containers_orchestration/managed_kubernetes/backup-and-restore-cluster-namespace-and-applications-with-trilio/guide.en-us.md, à l'aide d'un éditeur de votre choix (de préférence avec la prise en charge du lint YAML). Vous pouvez par exemple utiliser VS Code :
cat manifests/mysql-qa-helm-release-backup-plan.yaml
cat manifests/mysql-qa-helm-release-backup.yaml
  1. Créez la ressource BackupPlan, avec kubectl :
kubectl apply -f manifests/mysql-qa-helm-release-backup-plan.yaml -n demo-backup-ns

Inspectez maintenant le statut du BackupPlan (ciblant la release Helm mysql-qa), avec kubectl :

kubectl get backupplan mysql-qa-helm-release-backup-plan -n demo-backup-ns

La sortie ressemble à ceci (remarquez la valeur de la colonne STATUS, qui doit être « Available ») :

NAME                                  TARGET			...   STATUS
mysql-qa-helm-release-backup-plan   trilio-ovh-s3-target	...   Available
  1. Enfin, créez une ressource Backup, avec kubectl :
kubectl apply -f manifests/mysql-qa-helm-release-backup.yaml -n demo-backup-ns

Inspectez maintenant le statut du Backup (ciblant la release Helm mysql-qa), avec kubectl :

kubect get backup mysql-qa-helm-release-full-backup -n demo-backup-ns

Vérifiez ensuite le statut de l'objet Backup, avec kubectl :

kubectl get backup mysql-qa-helm-release-full-backup -n demo-backup-ns

La sortie ressemble à ceci (remarquez la valeur de la colonne STATUS, qui doit être « InProgress », ainsi que le BACKUP TYPE défini sur « Full ») :

NAME                                BACKUPPLAN                          BACKUP TYPE   STATUS       ...
mysql-qa-helm-release-full-backup   mysql-qa-helm-release-backup-plan   Full          InProgress   ...

Une fois que tous les composants de la release Helm mysql-qa ont fini d'être téléversés vers la target Object Storage, vous devriez obtenir le résultat suivant :

kubectl get backup mysql-qa-helm-release-full-backup -n demo-backup-ns

La sortie ressemble à ceci (remarquez que le STATUS est passé à « Available », et que PERCENTAGE est à « 100 ») :

NAME                                BACKUPPLAN                          BACKUP TYPE   STATUS      ...   PERCENTAGE
mysql-qa-helm-release-full-backup   mysql-qa-helm-release-backup-plan   Full          Available   ...   100

Si la sortie ressemble à ce qui précède, vous avez sauvegardé avec succès la release Helm mysql-qa. Vous pouvez maintenant voir comment TrilioVault stocke les métadonnées Kubernetes, en listant le contenu du bucket S3 TrilioVault.

Enfin, vous pouvez vérifier que la sauvegarde est disponible dans la console web également, en accédant à Backup & Recovery -> Backup Plans et en sélectionnant le namespace demo-ns-backup dans le menu déroulant en haut (remarquez qu'elle est à l'état « Available », et que la release Helm mysql-qa a bien été sauvegardée, dans la sous-vue « Component Details »).

Supprimer la release Helm mysql-qa et ses ressources

Simulez maintenant un sinistre, en supprimant intentionnellement la release Helm mysql-qa :

helm delete mysql-qa -n demo-backup-ns

Vérifiez ensuite que les ressources du namespace ont bien été supprimées (la liste doit être vide) :

kubectl get all -n demo-backup-ns

Restaurer la sauvegarde de la release Helm mysql-qa

Remarques importantes :

  • Si vous restaurez dans le même namespace, assurez-vous que les composants d'origine de l'application ont bien été supprimés. En particulier, les PVC de l'application doivent être supprimés.
  • Si vous restaurez vers un autre cluster (scénario de migration), assurez-vous que TrilioVault for Kubernetes est également en cours d'exécution dans le namespace/cluster distant. Pour restaurer vers un nouveau cluster (où la CR Backup n'existe pas), source.type doit être défini sur location. Veuillez consulter la section Restore des définitions de ressources personnalisées pour voir un exemple de restore par location.
  • Lorsque vous supprimez le namespace demo-backup-ns, la ressource de load balancer associée au service mysql-qa sera également supprimée. Ainsi, lorsque vous restaurerez le service mysq-qa, le Load Balancer sera recréé par OVHcloud. Le problème est que vous obtiendrez une nouvelle adresse IP pour votre Load Balancer, vous devrez donc ajuster les enregistrements A pour rediriger le trafic vers vos domaines hébergés sur le cluster.

Pour restaurer une sauvegarde spécifique, vous devez créer une CRD Restore. Une CRD Restore classique ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: Restore
metadata:
  name: mysql-qa-helm-release-restore
  namespace: demo-restore-ns
spec:
  source:
    type: Backup
    backup:
      name: mysql-qa-helm-release-full-backup
      namespace: demo-backup-ns
  skipIfAlreadyExists: true

Explications de la configuration ci-dessus :

  • spec.source.type : spécifie à partir de quel type de sauvegarde effectuer la restauration.
  • spec.source.backup : contient une référence vers l'objet de sauvegarde à partir duquel restaurer.
  • spec.skipIfAlreadyExists : indique s'il faut ignorer la restauration d'une ressource si elle existe déjà dans le namespace restauré.

Restore vous permet de restaurer la dernière sauvegarde réussie d'une application. Il est utilisé pour restaurer un seul namespace ou une release Helm, protégé par la CRD Backup. La CRD Backup est identifiée par son nom : mysql-qa-helm-release-full-backup.

Commencez par inspecter l'exemple de CRD Restore depuis le dépôt Git ovh/docs :

cat manifests/mysql-qa-helm-release-restore.yaml

Créez ensuite la ressource Restore avec kubectl :

kubectl apply -f manifests/mysql-qa-helm-release-restore.yaml

Enfin, inspectez le statut de l'objet Restore :

kubectl get restore mysql-qa-helm-release-restore -n demo-restore-ns

La sortie ressemble à ceci (remarquez la colonne STATUS définie sur Completed, ainsi que le PERCENTAGE COMPLETED défini sur 100) :

NAME                            STATUS      DATA SIZE   START TIME             END TIME               PERCENTAGE COMPLETED   DURATION
mysql-qa-helm-release-restore   Completed   0           2022-06-21T15:06:52Z   2022-06-21T15:07:35Z   100                    43.524191306s

Si la sortie ressemble à ce qui précède, alors le processus de restauration de la release Helm mysql-qa s'est terminé avec succès.

Vérifier l'intégrité des applications après restauration

Vérifiez que toutes les ressources du namespace demo-restore-ns sont bien en place et actives :

kubectl get all -n demo-restore-ns

La sortie ressemble à ceci :

NAME                                                           READY   STATUS      RESTARTS   AGE
pod/mysql-qa-665f6fb548-m8tnd                                  1/1     Running     0          91m
pod/mysql-qa-helm-release-full-backup-metamover-9w7s0y-x8867   0/1     Completed   0          9m2s

NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/mysql-qa   ClusterIP   10.3.227.118   <none>        3306/TCP   91m

NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mysql-qa   1/1     1            1           91m

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/mysql-qa-665f6fb548   1         1         1       91m

NAME                                                           COMPLETIONS   DURATION   AGE
job.batch/mysql-qa-helm-release-full-backup-metamover-9w7s0y   1/1           28s        9m2s

L'étape suivante traite de la sauvegarde et de la restauration d'un cluster entier, couvrant ainsi un scénario de reprise après sinistre.

Étape 5 - Exemple de sauvegarde et de restauration d'un cluster entier

Dans cette étape, vous allez simuler un scénario de reprise après sinistre. L'intégralité du cluster OVHcloud Managed Kubernetes sera supprimée, puis les applications importantes seront restaurées à partir d'une sauvegarde précédente.

Vous allez maintenant effectuer les tâches suivantes :

  • Créer la sauvegarde multi-namespace, à l'aide d'une CRD ClusterBackupPlan ciblant tous les namespaces importants de votre cluster OVHcloud Managed Kubernetes.
  • Supprimer le cluster OVHcloud Managed Kubernetes, à l'aide de l'.
  • Créer un nouveau cluster OVHcloud Managed Kubernetes, à l'aide de l'.
  • Réinstaller TVK et configurer le bucket OVHcloud Object Storage comme target S3 (vous allez utiliser le même bucket S3 dans lequel vos sauvegardes importantes sont stockées).
  • Restaurer toutes les applications importantes à l'aide de la console web TVK.
  • Vérifier l'intégrité des applications du cluster OVHcloud Managed Kubernetes.

Créer la sauvegarde du cluster OVHcloud Managed Kubernetes avec la fonctionnalité de sauvegarde multi-namespace de TVK

L'idée principale ici est d'effectuer une sauvegarde du cluster OVHcloud Managed Kubernetes en incluant tous les namespaces importants, qui contiennent vos applications et configurations essentielles. En réalité, on ne peut pas véritablement parler de sauvegarde et de restauration complète du cluster, mais plutôt d'une opération de sauvegarde et de restauration multi-namespace. En pratique, c'est tout ce dont vous avez besoin, car tout est « namespacé » dans Kubernetes. Vous allez également apprendre à effectuer une opération de restauration de cluster via l'emplacement (« location ») depuis la target. Le même principe s'applique lorsque vous devez effectuer une migration de cluster.

Un manifeste ClusterBackupPlan classique ciblant plusieurs namespaces ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: ovh-multi-ns-backup-plan
  namespace: default
spec:
  backupConfig:
    target:
      name: trilio-ovh-s3-target
      namespace: default
  backupComponents:
    - namespace: default
    - namespace: demo-backup-ns
    - namespace: backend
    - namespace: monitoring

Remarquez que kube-system (ou d'autres namespaces liés au cluster OVHcloud Managed Kubernetes) n'est pas inclus dans la liste. Généralement, ceux-ci ne sont pas nécessaires, sauf cas particulier exigeant que certains paramètres soient conservés à ce niveau.

Un manifeste ClusterBackup classique ciblant plusieurs namespaces ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackup
metadata:
  name: multi-ns-backup
  namespace: default
spec:
  type: Full
  clusterBackupPlan:
    name: ovh-multi-ns-backup-plan
    namespace: default

Étapes pour lancer une sauvegarde de tous les namespaces importants de votre cluster OVHcloud Managed Kubernetes :

  1. Tout d'abord, déplacez-vous à l'endroit où le dépôt Git ovh/docs a été cloné sur votre machine locale :
cd docs
  1. Ouvrez et inspectez ensuite les fichiers manifestes ClusterBackupPlan et ClusterBackup fournis dans le dépôt docs.
cat manifests/multi-ns-backup-plan.yaml
cat manifests/multi-ns-backup.yaml
  1. Créez la ressource ClusterBackupPlan, avec kubectl :
kubectl apply -f manifests/multi-ns-backup-plan.yaml

Inspectez maintenant le statut du ClusterBackupPlan, avec kubectl :

kubectl get clusterbackupplan multi-ns-backup-plan -n default

La sortie ressemble à ceci (remarquez la valeur de la colonne STATUS, qui doit être « Available ») :

NAME                            TARGET                 ...		STATUS
ovh-multi-ns-backup-plan		trilio-ovh-s3-target   ...		Available
  1. Enfin, créez la ressource ClusterBackup, avec kubectl :
kubectl apply -f manifests/multi-ns-cluster-backup.yaml

Vérifiez ensuite le statut du ClusterBackup, avec kubectl :

kubectl get clusterbackup multi-ns-cluster-backup -n default

La sortie ressemble à ceci (remarquez la valeur de la colonne STATUS, qui doit être « Available », ainsi que le PERCENTAGE COMPLETE défini sur « 100 ») :

NAME           		BACKUPPLAN             		BACKUP TYPE   STATUS		...		COMPLETE
multi-ns-backup   	ovh-multi-ns-backup-plan	Full          Avilable		...		100

Si la sortie ressemble à ce qui précède, alors tous les namespaces d'applications importants ont bien été sauvegardés avec succès.

Info

Veuillez noter que la sauvegarde complète du cluster peut prendre un certain temps, selon le nombre de namespaces et de ressources associées impliqués dans le processus.

Vous pouvez également ouvrir le tableau de bord principal de la console web et inspecter la sauvegarde multi-namespace (remarquez que tous les namespaces importants sauvegardés sont mis en évidence en vert, dans une structure en nid d'abeille).

Recréer le cluster OVHcloud Managed Kubernetes et restaurer les applications

Un point important à garder en tête est que chaque fois que vous détruisez un cluster OVHcloud Managed Kubernetes puis le restaurez, un nouveau Load Balancer avec une nouvelle IP externe est également créé lorsque TVK restaure votre ingress controller. Veillez donc à mettre à jour vos enregistrements A du DNS Managed OVHcloud en conséquence.

Supprimez maintenant l'intégralité du cluster OVHcloud Managed Kubernetes à l'aide de l'.

Recréez ensuite le cluster comme décrit dans Créer un cluster OVHcloud Managed Kubernetes.

Pour effectuer l'opération de restauration, vous devez installer l'application TVK comme décrit dans Étape 1 - Installer TrilioVault for Kubernetes. Veillez à utiliser la même version de Helm Chart : c'est important !

Une fois l'installation terminée avec succès, configurez la target TVK comme décrit dans Étape 2 - Créer une Target TrilioVault pour stocker les sauvegardes, et faites-la pointer vers le même bucket OVHcloud Object Storage où sont stockées vos données de sauvegarde. Veillez également à ce que target browsing soit activé.

Vérifiez et activez ensuite une nouvelle licence, comme décrit dans la section Licence de l'application TrilioVault.

Pour accéder à l'interface utilisateur de la console web, veuillez consulter la section Accéder à la console web de gestion TVK.

Accédez ensuite à Resource Management > TVK Namespace > Targets (dans le cas de ovh/docs, le namespace TVK est tvk).

Liste des Targets TVK

Pour aller plus loin, parcourez la target et listez les sauvegardes disponibles en cliquant sur le bouton Actions à droite. Sélectionnez ensuite l'option Launch Browser dans le menu qui s'affiche (pour que cela fonctionne, la target doit avoir le paramètre enableBrowsing défini sur « true »).

Navigateur de Target TVK

Cliquez maintenant sur l'élément multi-ns-backup-plan dans la liste, puis cliquez sur l'élément multi-ns-backup pour le déployer dans la sous-fenêtre de droite, comme ceci :

Restauration multi-namespace - Phase 1

Pour démarrer le processus de restauration, cliquez sur le bouton Restore. Une fenêtre de progression s'affiche, semblable à celle-ci :

Restauration multi-namespace - Phase 2

Après un certain temps, si la fenêtre de progression ressemble à ceci, alors l'opération de restauration multi-namespace s'est terminée avec succès.

Restauration multi-namespace - Phase 3

Vérifier l'état des applications du cluster OVHcloud Managed Kubernetes

Vérifiez d'abord toutes les ressources Kubernetes du cluster (tout devrait être en place) :

kubectl get all --all-namespaces

Dans l'étape suivante, vous allez apprendre à effectuer des sauvegardes planifiées (ou automatiques) pour les applications de votre cluster OVHcloud Managed Kubernetes.

Étape 6 - Sauvegardes planifiées

Réaliser des sauvegardes automatiquement selon une planification est une fonctionnalité très utile. Elle vous permet de revenir en arrière dans le temps et de restaurer le système à un état de fonctionnement antérieur en cas de problème. Cette section propose un exemple de sauvegarde automatique selon une planification toutes les 15 minutes (le namespace kube-system a été choisi).

Info

Par défaut, TrilioVault for Kubernetes crée des exemples de politiques de planification quotidienne, hebdomadaire et mensuelle après l'installation. Les utilisateurs peuvent utiliser ces mêmes politiques de planification si aucune modification n'est nécessaire. Consultez les valeurs par défaut des politiques dans la Scheduling Policy de l'interface TVK :

Scheduling Policy par défaut de TVK

Vous devez d'abord créer une CRD Policy de type Schedule, qui définit la planification de sauvegarde au format cron (identique au cron Linux). Les politiques de planification peuvent être utilisées à la fois pour les CRD BackupPlan et ClusterBackupPlan. Une CRD de politique de planification classique ressemble à ceci (définit une planification toutes les 15 minutes) :

kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-15min
  namespace: default
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/15 * * * *" # trigger every 15 minutes

Vous pouvez ensuite appliquer la politique de planification à une CRD ClusterBackupPlan, par exemple comme ceci :

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: multi-ns-backup-plan-5min-schedule
  namespace: default
spec:
  backupConfig:
    target:
      name: trilio-ovh-s3-target
      namespace: default
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-15min
        namespace: default
  backupComponents:
    - namespace: default
    - namespace: demo-backup-ns
    - namespace: backend

Comme vous pouvez le constater, il s'agit d'une CRD ClusterBackupPlan classique, référençant la CRD Policy définie précédemment via le champ spec.backupConfig.schedulePolicy. Vous pouvez avoir des politiques distinctes créées pour les sauvegardes complètes ou incrémentielles, d'où les champs fullBackupPolicy ou incrementalBackupPolicy que vous pouvez spécifier dans le spec.

Créez maintenant la Policy de planification, à l'aide du manifeste d'exemple fourni par le tutoriel ovh/docs (assurez-vous de vous déplacer d'abord à l'endroit où le dépôt Git ovh/docs a été cloné sur votre machine locale) :

kubectl apply -f manifests/triliovault-scheduling-policy-every-15min.yaml

Vérifiez que la ressource de politique a bien été créée :

kubectl get policies -n default

La sortie ressemble à ceci (remarquez le type POLICY défini sur Schedule) :

NAMESPACE   NAME                           POLICY     DEFAULT
default     scheduled-backup-every-15min   Schedule   false

Enfin, créez la ressource backupplan pour les sauvegardes planifiées du namespace default :

Créez d'abord le backup plan pour le namespace default.

kubectl apply -f manifests/triliovault-multi-ns-backup-plan-every-15min.yaml

Vérifiez le statut du backup plan planifié pour default :

kubectl get clusterbackupplan triliovault-multi-ns-backup-plan-every-15min.yaml -n default

La sortie ressemble à ceci (remarquez la valeur FULL BACKUP POLICY, définie sur la ressource de politique scheduled-backup-every-5min créée précédemment, ainsi que le STATUS, qui doit être « Available ») :

NAME                                  TARGET                 ...   FULL BACKUP POLICY             STATUS
multi-ns-backup-plan-15min-schedule   trilio-ovh-s3-target   ...   scheduled-backup-every-15min   Available

Créez une ressource clusterbackup utilisant la politique planifiée toutes les 15 min :

Créez et déclenchez la sauvegarde planifiée pour le namespace default :

kubectl apply -f manifests/triliovault-multi-ns-backup-every-15min.yaml.yaml

Vérifiez le statut de la sauvegarde planifiée pour default :

kubectl get clusterbackup multi-ns-backup-15min-schedule -n default

La sortie ressemble à ceci (remarquez la valeur BACKUPPLAN, définie sur la ressource de backup plan créée précédemment, ainsi que le STATUS, qui doit être « Available ») :

NAME                             BACKUPPLAN                            BACKUP TYPE   STATUS      ...
multi-ns-backup-15min-schedule   multi-ns-backup-plan-15min-schedule   Full          Available   ...

Vous pouvez maintenant vérifier que les sauvegardes sont bien effectuées à intervalle régulier (15 minutes), en interrogeant la ressource de cluster backup et en inspectant la colonne START TIME (kubectl get clusterbackup -n default). Elle devrait refléter un écart de 15 minutes.

Dans l'étape suivante, vous allez apprendre à configurer une politique de rétention pour vos sauvegardes.

Étape 7 - Politique de rétention des sauvegardes

La politique de rétention vous permet de définir le nombre de sauvegardes à conserver et la fréquence de suppression des sauvegardes selon les exigences de conformité. La CRD de politique de rétention propose une spécification YAML simple pour définir le nombre de sauvegardes à conserver en termes de jours, semaines, mois, années, dernières sauvegardes, etc.

Info

Par défaut, TrilioVault for Kubernetes crée l'exemple de politique de rétention sample-ret-policy après l'installation. Les utilisateurs peuvent utiliser cette même politique de rétention si aucune modification n'est nécessaire. Consultez les valeurs par défaut de la politique dans la Retention Policy de l'interface TVK :

Retention Policy par défaut de TVK

Utiliser les politiques de rétention

Les politiques de rétention peuvent être utilisées à la fois pour les CRD BackupPlan et ClusterBackupPlan. Un manifeste Policy classique pour le type Retention ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-ret-policy
spec:
  type: Retention
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

Explications de la configuration ci-dessus :

  • spec.type : définit le type de politique. Peut être : Retention ou Schedule.
  • spec.retentionConfig : décrit la configuration de rétention, comme l'intervalle à utiliser pour la rétention des sauvegardes et leur nombre.
  • spec.retentionConfig.latest : nombre maximal des dernières sauvegardes à conserver.
  • spec.retentionConfig.weekly : nombre maximal de sauvegardes à conserver sur une semaine.
  • spec.retentionConfig.dayOfWeek : jour de la semaine pour conserver les sauvegardes hebdomadaires.
  • spec.retentionConfig.monthly : nombre maximal de sauvegardes à conserver sur un mois.
  • spec.retentionConfig.dateOfMonth : date du mois pour conserver les sauvegardes mensuelles.
  • spec.retentionConfig.monthOfYear : mois de la sauvegarde à conserver pour les sauvegardes annuelles.
  • spec.retentionConfig.yearly : nombre maximal de sauvegardes à conserver sur une année.

La politique de rétention ci-dessus se traduit par :

  • Sur une base hebdomadaire, conserver une sauvegarde chaque mercredi.
  • Sur une base mensuelle, conserver une sauvegarde le 15e jour.
  • Sur une base annuelle, conserver une sauvegarde chaque mars.
  • Globalement, toujours disposer des 2 sauvegardes les plus récentes disponibles.

Le déroulement de base pour créer une ressource de politique de rétention est identique à celui des sauvegardes planifiées. Vous avez besoin d'une CRD BackupPlan ou ClusterBackupPlan définie pour référencer la politique de rétention, puis d'un objet Backup ou ClusterBackup pour déclencher le processus.

Un exemple de configuration ClusterBackupPlan classique avec rétention définie ressemble à ceci :

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: multi-ns-backup-plan-15min-schedule-retention
  namespace: default
spec:
  backupConfig:
    target:
      name: trilio-ovh-s3-target
      namespace: default
    retentionPolicy:
        name: sample-ret-policy
        namespace: default
  backupComponents:
    - namespace: default
    - namespace: backend

Une fois le ClusterBackupplan appliqué, vous pouvez le vérifier avec :

kubect get clusterbackupplan -n default

La sortie ressemble à ceci :

NAME                                            TARGET                 RETENTION POLICY    ...		STATUS
multi-ns-backup-plan-15min-schedule-retention   trilio-ovh-s3-target   sample-ret-policy   ...		Available

Remarquez qu'il utilise un champ retentionPolicy pour référencer la politique en question. Bien entendu, vous pouvez avoir un backup plan combinant les deux types de politiques, afin qu'il puisse à la fois effectuer des sauvegardes planifiées et gérer des stratégies de rétention.

Utiliser les politiques de nettoyage

Avec un si grand nombre de ressources TVK (chacune responsable de diverses opérations telles que : les sauvegardes planifiées, la rétention, etc.), il est très probable que des problèmes surviennent à un moment ou à un autre. Cela signifie que certaines des opérations énumérées précédemment peuvent échouer pour diverses raisons, comme : un stockage inaccessible, des problèmes réseau pour NFS, etc.
Ainsi, votre cluster OVHcloud Managed Kubernetes risque de se retrouver encombré de nombreux objets Kubernetes en état d'échec.

Vous avez besoin d'un moyen de collecter (« garbage collect ») tous ces objets et de libérer les ressources associées, pour éviter tout problème à l'avenir. Voici la CRD Cleanup Policy :

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: garbage-collect-policy
  namespace: tvk
spec:
  type: Cleanup
  cleanupConfig:
    backupDays: 5

La politique de nettoyage ci-dessus doit être définie dans le namespace d'installation de TVK. Un cron job est ensuite automatiquement créé, qui s'exécute toutes les 30 minutes et supprime les sauvegardes en échec en fonction de la valeur spécifiée pour backupdays dans le champ spec.

Il s'agit d'une fonctionnalité très pratique que TVK propose pour vous aider à gérer ce type de situation.

Conclusion

Dans ce tutoriel, vous avez appris à effectuer des sauvegardes ponctuelles, ainsi que des sauvegardes planifiées, et à tout restaurer par la suite. Disposer de sauvegardes planifiées est très important, car cela vous permet de revenir à un instantané précédent en cas de problème. Vous avez également parcouru un scénario de reprise après sinistre. Enfin, la rétention des sauvegardes joue également un rôle important, car le stockage est limité et peut parfois devenir coûteux si trop d'objets sont concernés.

Toutes les tâches et opérations de base expliquées dans ce tutoriel visent à vous donner une introduction et une compréhension de base de ce dont TrilioVault for Kubernetes est capable. Vous pouvez en apprendre davantage sur TrilioVault for Kubernetes et d'autres sujets intéressants (ou utiles), en suivant les liens ci-dessous :

Aller plus loin

  • Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

  • Échangez avec notre communauté d'utilisateurs.

1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit.

Cette page vous a-t-elle aidé ?