Comment effectuer une sauvegarde et une restauration en utilisant TrilioVault dans DOKS

Introduction

Dans ce tutoriel, vous apprendrez comment déployer TrilioVault pour Kubernetes (ou TVK) sur votre cluster DOKS, créer des sauvegardes et récupérer une sauvegarde en cas de problème. Vous pouvez sauvegarder l’ensemble de votre cluster, ou choisir facultativement des sauvegardes basées sur un espace de noms ou des libellés.

Avantages de l’utilisation de Trilio :

• Réalisez des sauvegardes complètes (ou incrémentielles) de votre cluster et restaurez en cas de perte de données.
• Migrez d’un cluster à un autre.
• Les sauvegardes de versions Helm sont prises en charge.
• Exécutez des pré et post-hooks pour les opérations de sauvegarde et de restauration.
• Console de gestion Web vous permettant d’inspecter en détail l’état de vos opérations de sauvegarde/restauration.
• 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 opérateur TrilioVault dédié.
• Intégration avec Velero.
• Vous pouvez sauvegarder et restaurer des applications basées sur des opérateurs.

Pour plus d’informations, veuillez consulter la documentation officielle sur les TVK CRDs.

Table des matières

• Prérequis
• Étape 1 – Installation de TrilioVault pour Kubernetes
• Étape 2 – Création d’une cible TrilioVault pour stocker les sauvegardes
• Étape 3 – Découverte de la console de gestion Web TVK
• Étape 4 – Exemple de sauvegarde et restauration avec espaces de noms
• Étape 5 – Exemple de sauvegarde et restauration de tout le cluster
• Étape 6 – Sauvegardes planifiées
• Étape 7 – Politique de rétention des sauvegardes
• Conclusion

Prérequis

Pour terminer ce tutoriel, vous avez besoin des éléments suivants :

1. A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
2. A Git client to clone the Starter Kit repository.
3. Helm, pour la gestion des déploiements et mises à jour de TrilioVault Operator.
4. Doctl pour l’interaction avec l’API DigitalOcean.
5. Kubectl pour l’interaction avec Kubernetes.

Pour que TrilioVault fonctionne correctement et sauvegarde vos PVC, DOKS doit être configuré pour prendre en charge l’interface de stockage de conteneurs (CSI pour faire court). Par défaut, il est livré avec le pilote déjà installé et configuré. Vous pouvez vérifier en utilisant la commande suivante :

kubectl get storageclass

La sortie devrait ressembler à l’extrait suivant. Remarquez que le provisionneur est dobs.csi.digitalocean.com.

NAME                         PROVISIONER                 RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
do-block-storage (default)   dobs.csi.digitalocean.com   Delete          Immediate           true                   10d

L’installation de TrilioVault nécessite également la définition de ressource personnalisée (CRD) volumeSnapshot pour une installation réussie. Vous pouvez vérifier en utilisant la commande suivante :

kubectl get crd | grep volumesnapshot

La sortie devrait ressembler à l’extrait suivant. Si la CRD VolumeSnapshot n’est pas installée, référez-vous à Installation des CRD VolumeSnapshot.

volumesnapshotclasses.snapshot.storage.k8s.io         2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io        2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io               2022-02-01T06:01:15Z

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

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

À la fin du fichier YAML de la CRD, vous devriez voir une liste storedVersions, contenant à la fois les valeurs v1beta1 et v1 (si non installé, référez-vous à Installation des CRD VolumeSnapshot) :

...
- 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

Étape 1 – Installation de TrilioVault pour Kubernetes

À cette étape, vous apprendrez comment déployer TrilioVault pour DOKS et gérer les installations TVK via Helm. Les données de sauvegarde seront stockées dans le compartiment DO Spaces créé précédemment dans la section Prérequis.

L’application TrilioVault peut être installée de plusieurs manières :

• Par le biais de l’opérateur TrilioVault. Vous définissez un CRD TrilioVaultManager qui indique à l’opérateur TrilioVault comment gérer l’installation, les étapes de post-configuration et les futures mises à niveau des composants de l’application Trilio.
• Par le biais du graphique triliovault-operator entièrement géré par Helm (couvert dans ce tutoriel).

Installation de TrilioVault à l’aide de Helm

Tout d’abord, clonez le dépôt Git du Starter Kit et changez de répertoire vers votre copie locale :

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git
cd Kubernetes-Starter-Kit-Developers

Ensuite, ajoutez le dépôt Helm TrilioVault et répertoriez les graphiques disponibles :

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

La sortie ressemble à ce qui suit :

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

Ensuite, ouvrez et inspectez le fichier de valeurs Helm TrilioVault fourni dans le référentiel du kit de démarrage à l’aide d’un éditeur de votre choix (de préférence avec le support de lint YAML).

code 05-setup-backup-restore/assets/manifests/triliovault-values-v2.9.2.yaml

Enfin, installez TrilioVault pour Kubernetes à l’aide de Helm:

helm install triliovault-operator triliovault-operator/k8s-triliovault-operator \
  --namespace tvk \
  --create-namespace \
  -f 05-setup-backup-restore/assets/manifests/triliovault-values.yaml

installTVK.ComponentConfiguration.ingressController.service.type pour le type de service permettant d’accéder à l’interface utilisateur de TVK, par exemple NodePort ou LoadBalancer

helm ls -n tvk

Maintenant, vérifiez le déploiement de votre TVK :

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
triliovault-manager-tvk tvk             1               2022-06-08 08:30:08.490304959 +0000 UTC deployed        k8s-triliovault-2.9.2           2.9.2
triliovault-operator    tvk             1               2022-06-08 11:32:55.755395 +0300 EEST   deployed        k8s-triliovault-operator-2.9.2  2.9.2

La sortie ressemble à l’extrait suivant (la colonne STATUS doit afficher déployé) :

kubectl get deployments -n tvk

Ensuite, vérifiez que TrilioVault est opérationnel :

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
k8s-triliovault-admission-webhook               1/1     1            1           83s
k8s-triliovault-control-plane                   1/1     1            1           83s
k8s-triliovault-exporter                        1/1     1            1           83s
k8s-triliovault-ingress-nginx-controller        1/1     1            1           83s
k8s-triliovault-web                             1/1     1            1           83s
k8s-triliovault-web-backend                     1/1     1            1           83s
triliovault-operator-k8s-triliovault-operator   1/1     1            1           4m22s

La sortie ressemble à l’extrait suivant. Tous les pods déployés doivent être dans l’état Prêt.

Si la sortie ressemble à ceci, vous avez installé TVK avec succès. Ensuite, vous apprendrez comment vérifier le type et la validité de la licence, ainsi que comment la renouveler.

Licence d’application TrilioVault

Les exemples de kits de démarrage reposent sur un type de licence Cluster pour fonctionner correctement.

Création et vérification de la licence de l’application TVK

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/tvk_install_license.yaml

Exécutez la commande suivante pour créer une nouvelle licence pour votre cluster (elle est gérée via le CRD de licence) :

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

Si vous téléchargez une licence gratuite depuis le site web de Trilio, appliquez-la en utilisant cette commande :

kubectl get license -n tvk

Veuillez exécuter la commande suivante pour voir si la licence est installée et dans l’état Actif sur votre cluster.

NAME             STATUS   MESSAGE                                   CURRENT NODE COUNT   GRACE PERIOD END TIME   EDITION     CAPACITY   EXPIRATION TIME        MAX NODES
test-license-1   Active   Cluster License Activated successfully.   1                                            FreeTrial   100000     2023-02-25T00:00:00Z   1

La sortie ressemble à ce qui suit. Remarquez le STATUT qui devrait être Actif, ainsi que le type de licence dans la colonne EDITION et TEMPS D'EXPIRATION.

kubectl describe license test-license-1 -n tvk

La licence est gérée via un CRD spécial appelé objet Licence. Vous pouvez l’inspecter en exécutant la commande suivante :

Name:         test-license-1
Namespace:    tvk
Labels:       <none>
Annotations:
              generation: 1
              triliovault.trilio.io/creator: system:serviceaccount:tvk:k8s-triliovault
              triliovault.trilio.io/instance-id: b060660d-4851-482b-8e60-4addd260e1d3
              triliovault.trilio.io/updater:
                [{"username":"system:serviceaccount:tvk:k8s-triliovault","lastUpdatedTimestamp":"2022-02-24T06:38:21.418828262Z"}]
API Version:  triliovault.trilio.io/v1
Kind:         License
Metadata:
  Creation Timestamp:  2022-02-24T06:38:21Z
...
Status:
  Condition:
    Message:           License Key changed
    Timestamp:         2022-02-24T06:38:21Z
    Message:           Cluster License Activated successfully.
    Status:            Active
    Timestamp:         2022-02-24T06:38:21Z
  Current Node Count:  1
  Max Nodes:           1
  Message:             Cluster License Activated successfully.
  Properties:
    Active:                        true
    Capacity:                      100000
    Company:                       TRILIO-KUBERNETES-LICENSE-GEN-DIGITALOCEAN-BASIC
    Creation Timestamp:            2022-02-24T00:00:00Z
    Edition:                       FreeTrial
    Expiration Timestamp:          2023-02-25T00:00:00Z
    Kube UID:                      b060660d-4851-482b-8e60-4addd260e1d3
    License ID:                    TVAULT-5a4b42c6-953c-11ec-8116-0cc47a9fd48e
    Maintenance Expiry Timestamp:  2023-02-25T00:00:00Z
    Number Of Users:               -1
    Purchase Timestamp:            2022-02-24T00:00:00Z
    Scope:                         Cluster
...

La sortie ressemble à ce qui suit. Remarquez les champs Message et Capacité, ainsi que l’Edition.

La sortie ci-dessus vous indiquera également quand la licence va expirer dans le champ Expiration Timestamp, et la Portée (Cluster dans ce cas). Vous pouvez opter pour un type de licence à l’échelle du cluster ou basé sur l’espace de noms.

Renouvellement de la Licence de l’Application TVK

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

Pour renouveler la licence, vous devrez en demander une nouvelle sur le site web de Trilio en accédant à la page de licence pour remplacer l’ancienne. Après avoir rempli le formulaire, vous devriez recevoir le manifeste YAML de la licence, qui peut être appliqué à votre cluster en utilisant kubectl. Les commandes suivantes supposent que TVK est installé dans l’espace de noms par défaut tvk (veuillez remplacer les espaces réservés <> selon les besoins) :

Ensuite, vous pouvez vérifier le nouveau statut de la licence comme vous l'avez déjà appris via :
kubectl get license -n tvk

# Liste d'abord les licences TVK disponibles depuis l'espace de noms `tvk`
kubectl describe license <YOUR_LICENSE_NAME_HERE> -n tvk

# Obtenir des informations sur une licence spécifique depuis l’espace de noms `tvk`

Dans l’étape suivante, vous apprendrez comment définir le stockage de sauvegarde pour TrilioVault pour stocker les sauvegardes appelé une cible.

Étape 2 – Création d’une cible TrilioVault pour stocker les sauvegardes

A typical Target definition looks like:

apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: <YOUR_DO_SPACES_BUCKET_NAME_HERE>
    region: <YOUR_DO_SPACES_BUCKET_REGION_HERE>
    url: 'https://<YOUR_DO_SPACES_BUCKET_ENDPOINT_HERE>'
    credentialSecret:
      name: trilio-s3-target
      namespace: tvk
  thresholdCapacity: 10Gi

TrilioVault doit d’abord savoir où stocker vos sauvegardes. TrilioVault fait référence au backend de stockage en utilisant le terme cible, et il est géré via un CRD spécial nommé Cible. Les types de cibles suivants sont pris en charge : S3 et NFS. Pour DigitalOcean et dans le cadre du Starter Kit, il est logique de s’appuyer sur le type de stockage S3 car il est bon marché et évolutif. Pour bénéficier d’un niveau de protection accru, vous pouvez créer plusieurs types de cibles (à la fois S3 et NFS), afin que vos données soient stockées en toute sécurité à plusieurs endroits, ce qui permet d’obtenir une redondance des sauvegardes.

• Dans cette configuration,
• spec.type : Type de cible pour le stockage de sauvegarde (S3 est un magasin d’objets).
• spec.vendor : Vendeur de stockage tiers hébergeant la cible (pour DigitalOcean Spaces, vous devez utiliser Autre au lieu de AWS).
• spec.enableBrowsing : Activer la navigation pour la cible.
• spec.objectStoreCredentials : Définit les informations d’identification requises (via credentialSecret) pour accéder au stockage S3, ainsi que d’autres paramètres tels que la région et le nom du compartiment.

spec.thresholdCapacity : Capacité maximale de seuil pour stocker les données de sauvegarde.

apiVersion: v1
kind: Secret
metadata:
  name: trilio-s3-target
  namespace: tvk
type: Opaque
stringData:
  accessKey: <YOUR_DO_SPACES_ACCESS_KEY_ID_HERE> Pour accéder au stockage S3, chaque cible doit connaître les informations d'identification du compartiment. Un secret Kubernetes doit également être créé :
  secretKey: <YOUR_DO_SPACES_SECRET_KEY_HERE>    # la valeur doit être encodée en base64

# la valeur doit être encodée en base64

Remarquez que le nom du secret est trilio-s3-target et il est référencé par le champ spec.objectStoreCredentials.credentialSecret du CRD de la Cible expliqué précédemment. Le secret peut être dans le même namespace où TrilioVault a été installé (par défaut tvk), ou dans un autre namespace de votre choix. Assurez-vous simplement de référencer le namespace correctement. D’autre part, veuillez vous assurer de protéger le namespace où vous stockez les secrets de TrilioVault via RBAC pour des raisons de sécurité.

Étapes pour créer une cible pour TrilioVault:

cd Kubernetes-Starter-Kit-Developers

Tout d’abord, changez le répertoire où le dépôt Git du Starter Kit a été cloné sur votre machine locale :

kubectl create secret generic trilio-s3-target \
  --namespace=tvk \
  --from-literal=accessKey="<YOUR_DO_SPACES_ACCESS_KEY_HERE>" \
  --from-literal=secretKey="<YOUR_DO_SPACES_SECRET_KEY_HERE>"

Ensuite, créez le secret Kubernetes contenant les informations d’identification de votre compartiment S3 cible (veuillez remplacer les espaces réservés <> en conséquence) :

code 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

–from-literal=accessKey=« <VOTRE_CLÉ_D’ACCÈS_DO_SPACES_ICI> » \

–from-literal=secretKey=« <VOTRE_CLÉ_SECRÈTE_DO_SPACES_ICI> »

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

Ensuite, ouvrez et inspectez le fichier manifeste cible fourni dans le dépôt du kit de démarrage à l’aide d’un éditeur de votre choix (de préférence avec une prise en charge de la validation YAML).

Maintenant, veuillez remplacer les espaces réservés <> en conséquence pour votre compartiment DO Spaces Trilio, comme bucketName, region, url et credentialSecret.

kubectl get target trilio-s3-target  -n tvk

Enfin, enregistrez le fichier manifeste et créez l’objet Target en utilisant kubectl :

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

Ensuite, TrilioVault lancera un travail ouvrier nommé trilio-s3-target-validator chargé de valider votre compartiment S3 (comme la disponibilité, les autorisations, etc.). Si le travail se termine avec succès, le compartiment est considéré comme étant en bonne santé ou disponible et la ressource de travail trilio-s3-target-validator est supprimée par la suite. Si quelque chose de mauvais se produit, le travail de validation de la cible S3 reste en cours d’exécution afin que vous puissiez inspecter les journaux et trouver le problème éventuel.

 La sortie ressemble à ce qui suit. Remarquez la valeur de la colonne STATUS - devrait être Available, ce qui signifie qu'il est en bon état de fonctionnement. 
kubectl get pods -n tvk | grep trilio-s3-target-validator

 Si la sortie ressemble à ceci, alors vous avez configuré avec succès l'objet cible S3. 
 Dans le cas où l'objet cible ne devient pas en bonne santé, vous pouvez inspecter les journaux du Pod trilio-s3-target-validator pour trouver le problème :

# Tout d'abord, vous devez trouver le validateur cible
kubectl logs pod/trilio-s3-target-validator-tio99a-6lz4q -n tvk

...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 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.
...

#trilio-s3-target-validator-tio99a-6lz4q 1/1 En cours 0 104s

# Maintenant, récupérez les données des journaux

La sortie sera cette exception :

Ensuite, vous découvrirez la console Web TVK qui est un ajout utile pour vous aider à gérer facilement les opérations de sauvegarde et de restauration, entre autres.

Étape 3 – Faire connaissance avec la console de gestion Web TVK

Alors que vous pouvez gérer les opérations de sauvegarde et de restauration entièrement depuis la CLI via kubectl et CRDs, TVK fournit une Console de gestion Web pour accomplir les mêmes opérations via l’interface graphique utilisateur. La console de gestion simplifie les tâches courantes via des opérations de point-and-click, offre une meilleure visualisation et inspection des objets de cluster TVK, ainsi que pour créer des plans de reprise après sinistre (ou DRPs).

L’installation basée sur Helm couverte dans Étape 1 – Installation de TrilioVault pour Kubernetes a déjà pris en charge l’installation des composants requis pour la console de gestion Web.

kubectl get svc -n tvk

Obtention de l’accès à la console de gestion Web de TVK

NAME                                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   10.245.202.17    <none>        443/TCP                      13m
k8s-triliovault-ingress-nginx-controller                        NodePort    10.245.192.140   <none>        80:32448/TCP,443:32588/TCP   13m
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   10.3.20.89       <none>        443/TCP                      13m
k8s-triliovault-web                                             ClusterIP   10.245.214.13    <none>        80/TCP                       13m
k8s-triliovault-web-backend                                     ClusterIP   10.245.10.221    <none>        80/TCP                       13m
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   10.245.186.59    <none>        443/TCP                      16m

Pour pouvoir accéder à la console et explorer les fonctionnalités qu’elle offre, vous devez rediriger le service du contrôleur d’entrée pour TVK.

Tout d'abord, vous devez identifier le service ingress-nginx-controller de l'espace de noms tvk:
installTVK:
  ingressConfig:
    host: "tvk-doks.com"

La sortie ressemble à ce qui suit. Recherchez la ligne k8s-triliovault-ingress-nginx-controller et remarquez qu’elle écoute sur le port 80 dans la colonne PORT(S).

127.0.0.1 tvk-doks.com

TVK utilise un contrôleur d’entrée Nginx pour router le trafic vers les services de la console de gestion Web. Le routage est basé sur l’hôte, et le nom d’hôte est tvk-doks.com tel que défini dans le fichier des valeurs Helm du Starter Kit:

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

# Le nom d’hôte à utiliser lors de l’accès à la console Web via le contrôleur d’entrée TVK nginx

Ayant les informations ci-dessus à portée de main, veuillez procéder à l'édition du fichier /etc/hosts et ajoutez cette entrée:
doctl k8s cluster list

Ensuite, créez la redirection de port pour le service du contrôleur d'entrée TVK:
doctl kubernetes cluster kubeconfig show <YOUR_CLUSTER_NAME_HERE> > config_<YOUR_CLUSTER_NAME_HERE>.yaml

DOKS_CLUSTER_NAME="$(doctl k8s cluster list --no-header --format Name)"
doctl kubernetes cluster kubeconfig show $DOKS_CLUSTER_NAME > config_${DOKS_CLUSTER_NAME}.yaml

# Liste des clusters disponibles

Si vous n’avez qu’un seul cluster, exécutez la commande suivante:

Après avoir suivi ces étapes, vous pouvez accéder à la console dans votre navigateur Web en naviguant sur : http://tvk-doks.com:8080. Lorsqu’on vous demande le fichier kubeconfig, veuillez sélectionner celui que vous avez créé dans la dernière commande ci-dessus.

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

• Explorer l’interface utilisateur de la console Web TVK
• Explorez chaque section sur la gauche, comme :
• Gestion du cluster: Cela montre la liste des clusters principaux et autres ayant des instances TVK, ajoutés au cluster OVH principal à l’aide de la fonctionnalité de gestion multi-clusters.
• Sauvegarde & Récupération : Ceci est le tableau de bord principal qui vous donne un aperçu général de l’ensemble du cluster, comme les espaces de noms découverts, les applications, la liste des plans de sauvegarde, les cibles, les hooks, les politiques, etc.

Surveillance : Il y a deux options – Surveillance TrilioVault et Surveillance Velero si l’utilisateur a configuré Velero sur son cluster OVH.

Récupération de catastrophe : Vous permet de gérer et d’effectuer des opérations de récupération après sinistre.

Récupération de catastrophe : Vous permet de gérer et d’effectuer des opérations de récupération après sinistre.

Vous pouvez également voir la cible S3 créée précédemment, en naviguant vers Sauvegarde & Récupération -> Cibles -> <Espace de noms> tvk dans le menu déroulant en haut.

En outre, vous pouvez parcourir la cible et lister les sauvegardes disponibles en cliquant sur le bouton Actions à droite, puis en sélectionnant l’option Lancer le navigateur dans le menu contextuel. Pour que cela fonctionne, la cible doit avoir le drapeau enableBrowsing défini sur true.

Pour plus d’informations et de fonctionnalités disponibles, veuillez consulter la documentation officielle de l’interface utilisateur de la Console de gestion Web TVK.

Ensuite, vous apprendrez comment effectuer des opérations de sauvegarde et de restauration pour des cas d’utilisation spécifiques.

Étape 4 – Exemple de sauvegarde et de restauration avec espace de noms

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

Dans cette étape, vous apprendrez comment créer une sauvegarde ponctuelle pour un espace de noms entier (ambassador dans ce cas) à partir de votre cluster DOKS et le restaurer par la suite, en vous assurant que toutes les ressources sont recréées. TVK dispose d’une fonctionnalité qui vous permet d’effectuer des sauvegardes à un niveau plus élevé que simplement les espaces de noms.

• Création de la sauvegarde de la version Helm de l’Ambassadeur
• Pour effectuer des sauvegardes pour une seule application au niveau de l’espace de noms (ou de la version Helm), un Plan de Sauvegarde suivi d’une CRD de Sauvegarde sont requis. Le Plan de Sauvegarde est une définition du ‘quoi’, ‘où’, ‘vers’, et ‘comment’ du processus de sauvegarde, mais il n’effectue pas la sauvegarde réelle. La CRD de Sauvegarde est responsable de déclencher le processus de sauvegarde réelle, tel que dicté par la spécification du Plan de Sauvegarde.
• Dans cette configuration,

A typical Backup CRD looks like below:

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

spec.backupConfig.target.name: Indique à TVK quel nom de cible utiliser pour stocker les sauvegardes.

• spec.backupConfig.target.namespace: Indique à TVK dans quel espace de noms la cible a été créée.
• spec.backupComponents: Définit une liste de ressources à sauvegarder.

Dans cette configuration,

spec.type: Spécifie le type de sauvegarde.

spec.backupPlan: Spécifie le plan de sauvegarde que cette sauvegarde doit utiliser.

cd Kubernetes-Starter-Kit-Developers

Étapes pour initier la sauvegarde ponctuelle d’une version d’Ambassador Helm :

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Tout d’abord, assurez-vous que Ambassador Edge Stack est déployé dans votre cluster en suivant les étapes du tutoriel Ambassador Ingress.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Ensuite, changez de répertoire vers l’endroit où le dépôt Git du Starter Kit a été cloné sur votre machine locale:

kubectl get backupplan ambassador-helm-release-backup-plan -n ambassador

Ensuite, ouvrez et inspectez les fichiers de manifeste Ambassador BackupPlan et Backup fournis dans le dépôt Starter Kit à l’aide d’un éditeur de votre choix (de préférence avec le support de lint YAML).

NAME                                  TARGET             ...   STATUS
ambassador-helm-release-backup-plan   trilio-s3-target   ...   Available

Enfin, créez les ressources BackupPlan et Backup à l’aide de kubectl.

kubectl get backup ambassador-helm-release-full-backup -n ambassador

Maintenant, inspectez le statut du BackupPlan (ciblant la version Helm ambassador) en utilisant kubectl:

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

La sortie ressemble à ce qui suit. Remarquez la valeur de la colonne STATUS qui doit être définie sur Available.

Ensuite, vérifiez le statut de l'objet Backup en utilisant kubectl:
NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS      ...   PERCENTAGE
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          Available   ...   100

La sortie ressemble à ce qui suit. Remarquez la valeur de la colonne STATUS qui doit être définie sur InProgress, ainsi que le TYPE DE SAUVEGARDE défini sur Full.

s3cmd ls s3://trilio-starter-kit --recursive

Une fois que tous les composants de l’ambassadeur Helm sont terminés de télécharger vers la cible S3, vous devriez obtenir ces résultats :

2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04          311  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04          302  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04          305  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04          330  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...

kubectl get pods -n ambassador | grep metamover

ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx   1/1     Running   0          4m32s

kubectl logs pod/ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx -n ambassador -f

...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...

La sortie ressemble à ceci :

Maintenant, récupérez les données des journaux :

La sortie ressemble à ce qui suit.

helm delete ambassador -n ambassador

Enfin, vous pouvez vérifier que la sauvegarde est disponible également dans la console web en naviguant vers Gestion des ressources -> Ambassadeur -> Plans de sauvegarde. Remarquez qu’elle est dans l’état Disponible et que le déploiement Helm de l’ambassadeur a été sauvegardé dans la sous-vue Détails du composant.

kubectl get all -n ambassador

Suppression du déploiement Helm de l’ambassadeur et des ressources

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Maintenant, allez-y et simulez un désastre en supprimant intentionnellement la version ambassador de Helm release:

Si vous restaurez le même espace de noms, assurez-vous que les composants de l’application d’origine ont été supprimés. En particulier, le PVC de l’application est supprimé.

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

Si vous effectuez une restauration vers un autre cluster (scénario de migration), assurez-vous que TrilioVault for Kubernetes s’exécute également dans l’espace de noms/cluster distant. Pour restaurer dans un nouveau cluster (où le CR de sauvegarde n’existe pas), source.type doit être défini sur location. Veuillez vous référer à la Section de définition des ressources personnalisées pour la restauration pour voir un exemple de restauration par emplacement.

• Lorsque vous supprimez l’espace de noms ambassador, la ressource de l’équilibreur de charge associée au service ambassador sera également supprimée. Ainsi, lorsque vous restaurez le service ambassador, l’équilibreur de charge sera recréé par DigitalOcean. Le problème est que vous obtiendrez une NOUVELLE ADRESSE IP pour votre équilibreur de charge, donc vous devrez ajuster les enregistrements A pour diriger le trafic vers vos domaines hébergés sur le cluster.
• Pour restaurer une sauvegarde spécifique, vous devez créer un Restore CRD. Un CRD de restauration typique ressemble à ce qui suit :
• Dans cette configuration,

spec.source.type: Spécifie le type de sauvegarde à restaurer.

spec.source.backup: Contient une référence à l’objet de sauvegarde à restaurer.

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

spec.skipIfAlreadyExists: Spécifie s’il faut ignorer la restauration d’une ressource si elle existe déjà dans l’espace de noms restauré.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

Restaurer vous permet de restaurer la dernière sauvegarde réussie pour une application. Il est utilisé pour restaurer un seul espace de noms ou une version Helm, protégé par la CRD de sauvegarde. La CRD de sauvegarde est identifiée par son nom ambassador-helm-release-full-backup.

kubectl get restore ambassador-helm-release-restore -n ambassador

Tout d’abord, inspectez l’exemple de la CRD de restauration à partir du dépôt Git du Kit de Démarrage :

NAME                              STATUS      DATA SIZE   START TIME             END TIME               PERCENTAGE COMPLETED   DURATION
ambassador-helm-release-restore   Completed   0           2021-11-25T15:06:52Z   2021-11-25T15:07:35Z   100                    43.524191306s

Ensuite, créez la ressource de restauration en utilisant kubectl :

Enfin, inspectez le statut de l’objet de restauration :

La sortie ressemble à ce qui suit. Remarquez la colonne STATUT définie sur Terminé, ainsi que le POURCENTAGE TERMINÉ défini sur 100.

kubectl get all -n ambassador

Si la sortie ressemble à ceci, alors le processus de restauration de la version Helm ambassador est terminé avec succès.

NAME                                    READY   STATUS    RESTARTS   AGE
pod/ambassador-5bdc64f9f6-42wzr         1/1     Running   0          9m58s
pod/ambassador-5bdc64f9f6-nrkzd         1/1     Running   0          9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv    1/1     Running   0          9m58s
pod/ambassador-redis-64b7c668b9-69drs   1/1     Running   0          9m58s

NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
service/ambassador         LoadBalancer   10.245.173.90    157.245.23.93   80:30304/TCP,443:30577/TCP   9m59s
service/ambassador-admin   ClusterIP      10.245.217.211   <none>          8877/TCP,8005/TCP            9m59s
service/ambassador-redis   ClusterIP      10.245.77.142    <none>          6379/TCP                     9m59s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ambassador         2/2     2            2           9m59s
deployment.apps/ambassador-agent   1/1     1            1           9m59s
deployment.apps/ambassador-redis   1/1     1            1           9m59s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/ambassador-5bdc64f9f6         2         2         2       9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8    1         1         1       9m59s
replicaset.apps/ambassador-redis-64b7c668b9   1         1         1       9m59s

Vérification de l’intégrité des applications après restauration

kubectl get hosts -n ambassador

Vérifiez que toutes les ressources de l’espace de noms ambassador sont en place et en cours d’exécution :

NAME         HOSTNAME                   STATE   PHASE COMPLETED   PHASE PENDING   AGE
echo-host    echo.starter-kit.online    Ready                                     11m
quote-host   quote.starter-kit.online   Ready                                     11m

La sortie ressemble à ceci :

kubectl get mappings -n ambassador

Obtenez les hôtes ambassador :

NAME                          SOURCE HOST                SOURCE PREFIX                               DEST SERVICE     STATE   REASON
ambassador-devportal                                     /documentation/                             127.0.0.1:8500
ambassador-devportal-api                                 /openapi/                                   127.0.0.1:8500
ambassador-devportal-assets                              /documentation/(assets|styles)/(.*)(.css)   127.0.0.1:8500
ambassador-devportal-demo                                /docs/                                      127.0.0.1:8500
echo-backend                  echo.starter-kit.online    /echo/                                      echo.backend
quote-backend                 quote.starter-kit.online   /quote/                                     quote.backend

La sortie ressemble à ce qui suit. L’ÉTAT devrait être Prêt, ainsi que la colonne NOM D'HÔTE pointant vers le nom de domaine complet.

Obtenez les mappages ambassador :

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

La sortie ressemble à ce qui suit. Remarquez le echo-backend qui est associé à l’hôte echo.starter-kit.online et au préfixe de source /echo/, de même pour quote-backend.

Maintenant, vous devez mettre à jour vos enregistrements DNS A, car la ressource du répartiteur de charge DigitalOcean a été recréée et lui a été attribuée une nouvelle IP externe.

Enfin, vérifiez si les applications backend répondent également aux requêtes HTTP. Veuillez vous référer à Création des services backend de la pile Edge de l’Ambassador concernant les applications backend utilisées dans le tutoriel du Starter Kit.

La prochaine étape concerne la sauvegarde et la restauration de l’ensemble du cluster.

Étape 5 – Exemple de sauvegarde et restauration de l’ensemble du cluster

A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: starter-kit-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupComponents:
    - namespace: ambassador
    - namespace: backend
    - namespace: monitoring

Dans cette étape, vous simulerez un scénario de reprise après sinistre. L’ensemble du cluster DOKS sera supprimé, puis les applications importantes seront restaurées à partir d’une sauvegarde précédente.

Création de la sauvegarde du cluster DOKS

cd Kubernetes-Starter-Kit-Developers

L’idée principale ici est de réaliser une sauvegarde de cluster DOKS en incluant tous les espaces de noms importants contenant vos applications essentielles et configurations.

code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Remarquez que kube-system (ou d’autres espaces de noms liés au cluster DOKS) ne sont pas inclus dans la liste. En général, ils ne sont pas nécessaires, sauf s’il existe un cas spécial nécessitant que certaines configurations soient persistées à ce niveau.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Tout d’abord, changez le répertoire où le dépôt Git du Starter Kit a été cloné sur votre machine locale :

kubectl get clusterbackupplan starter-kit-cluster-backup-plan -n tvk

Ensuite, ouvrez et inspectez les fichiers de manifeste ClusterBackupPlan et ClusterBackup fournis dans le dépôt Starter Kit en utilisant un éditeur de votre choix (de préférence avec le support de validation YAML).

NAME                              TARGET             ...   STATUS
starter-kit-cluster-backup-plan   trilio-s3-target   ...   Available

Enfin, créez les ressources ClusterBackupPlan et ClusterBackup en utilisant kubectl :

kubectl get clusterbackup starter-kit-cluster-backup -n tvk

Maintenant, inspectez le statut du ClusterBackupPlan en utilisant kubectl :

NAME                        BACKUPPLAN                        BACKUP TYPE   STATUS      ...   PERCENTAGE COMPLETE
starter-kit-cluster-backup  starter-kit-cluster-backup-plan   Full          Available   ...   100

La sortie ressemble à ce qui suit. Remarquez la valeur de la colonne STATUS qui devrait être définie sur Available.

La sortie ressemble à ce qui suit. Remarquez la valeur de la colonne STATUS qui devrait être définie sur Available, ainsi que le PERCENTAGE COMPLETE défini sur 100.

Si la sortie ressemble à ce qui précède, alors tous les espaces de noms d’application importants ont été sauvegardés avec succès.

Il peut falloir un certain temps pour que la sauvegarde complète du cluster se termine, en fonction du nombre d’espaces de noms et de ressources associées impliquées dans le processus.

Vous pouvez également ouvrir le tableau de bord principal de la console Web et inspecter la sauvegarde multi-namespace (remarquez comment tous les espaces de noms importants qui ont été sauvegardés sont mis en évidence en vert, dans une structure en nid d’abeille) :

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME>

Recréer le cluster DOKS et restaurer les applications

Un aspect important à garder à l’esprit est que chaque fois que vous détruisez un cluster DOKS et que vous le restaurez ensuite, un nouveau répartiteur de charge avec une nouvelle adresse IP externe est également créé lorsque TVK restaure votre contrôleur d’entrée. Assurez-vous donc de mettre à jour vos enregistrements DNS A de DigitalOcean en conséquence.

Maintenant, supprimez l’ensemble du cluster DOKS (assurez-vous de remplacer les espaces réservés <> en conséquence) :

Ensuite, recréez le cluster comme décrit dans Configurer Kubernetes sur DigitalOcean.

Pour effectuer l’opération de restauration, vous devez installer l’application TVK comme décrit dans Étape 1 – Installation de TrilioVault pour Kubernetes. Il est important d’utiliser la même version du graphique Helm.

Après l’installation réussie, configurez la cible TVK comme décrit dans Étape 2 – Création d’une cible TrilioVault pour stocker les sauvegardes, et pointez-la vers le même bucket S3 où se trouvent vos données de sauvegarde. Assurez-vous également que la navigation dans la cible est activée.

Ensuite, vérifiez et activez 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ès à la console de gestion Web TVK.

Ensuite, accédez à Gestion des ressources -> Espace de noms TVK -> Cibles (dans le cas du Kit de démarrage, l’espace de noms TVK est tvk):

Ensuite, parcourez la cible et répertoriez les sauvegardes disponibles en cliquant sur le bouton Actions. Ensuite, sélectionnez l’option Lancer le navigateur dans le menu contextuel. Pour que cela fonctionne, la cible doit avoir le drapeau enableBrowsing défini sur true.

Maintenant, cliquez sur l’élément starter-kit-cluster-backup-plan de la liste, puis cliquez pour développer l’élément starter-kit-cluster-backup de la sous-fenêtre droite:

kubectl get all --all-namespaces

Pour démarrer le processus de restauration, cliquez sur le bouton Restaurer.

Vérification de l’état des applications du cluster DOKS

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Tout d’abord, vérifiez toutes les ressources Kubernetes du cluster.

Ensuite, assurez-vous que vos enregistrements A DNS sont mis à jour pour pointer vers la nouvelle adresse IP externe de votre équilibreur de charge.

Enfin, les applications backend devraient également répondre aux requêtes HTTP. Veuillez vous référer à Création des Services Backend de la pile Ambassador Edge concernant les applications backend utilisées dans le tutoriel Starter Kit.

Dans l’étape suivante, vous apprendrez comment effectuer des sauvegardes planifiées (ou automatiques) pour vos applications de cluster DOKS.

kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-5min
  namespace: tvk
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/5 * * * *" Étape 6 - Sauvegardes Planifiées

Effectuer des sauvegardes automatiques basées sur un planning est une fonctionnalité vraiment utile. Cela vous permet de remonter dans le temps et de restaurer le système à un état de fonctionnement précédent si quelque chose ne va pas. Cette section fournit un exemple de sauvegarde automatique sur un planning de 5 minutes (l’espace de noms kube-system a été sélectionné).

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-5min
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Tout d’abord, vous devez créer un CRD Policy de type Schedule qui définit l’ordonnancement de la sauvegarde au format cron (similaire au cron de Linux). Les politiques de planification peuvent être utilisées pour les CRD BackupPlan ou ClusterBackupPlan. Un CRD de politique de planification typique ressemble à ce qui suit (définit un ordonnancement de 5 minutes) :

# Déclencher toutes les 5 minutes

Ensuite, vous pouvez appliquer la politique de planification à un CRD ClusterBackupPlan, par exemple, comme indiqué ci-dessous :

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/scheduled-backup-every-5min.yaml

Vous remarquerez qu’il s’agit d’un CRD ClusterBackupPlan de base, faisant référence au CRD Policy défini précédemment via le champ spec.backupConfig.schedulePolicy. Vous pouvez créer des politiques distinctes pour les sauvegardes complètes ou incrémentielles, d’où la spécification de fullBackupPolicy ou incrementalBackupPolicy dans le spec.

kubectl get policies -n tvk

Maintenant, veuillez créer la politique de planification Policy en utilisant le manifeste d’exemple fourni par le tutoriel Starter Kit.

NAME                          POLICY     DEFAULT
scheduled-backup-every-5min   Schedule   false

Changez de répertoire pour aller là où le dépôt Git du Starter Kit a été cloné sur votre machine locale.

Vérifiez que la ressource de politique a été créée :
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-plan-scheduled.yaml

La sortie ressemble à ce qui suit. Remarquez le type POLICY défini sur Schedule.
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-scheduled.yaml

Enfin, créez les ressources pour les sauvegardes planifiées dans l’espace de nom kube-system :

kubectl get clusterbackupplan kube-system-ns-backup-plan-5min-schedule -n tvk

# Créer d’abord le plan de sauvegarde pour l’espace de noms kube-system

NAME                                       TARGET             ...   FULL BACKUP POLICY            STATUS
kube-system-ns-backup-plan-5min-schedule   trilio-s3-target   ...   scheduled-backup-every-5min   Available

# Créer et déclencher la sauvegarde planifiée pour l’espace de noms kube-system

kubectl get clusterbackup kube-system-ns-full-backup-scheduled -n tvk

Vérifiez l’état du plan de sauvegarde planifié pour kube-system:

NAME                                   BACKUPPLAN                                 BACKUP TYPE   STATUS      ...
kube-system-ns-full-backup-scheduled   kube-system-ns-backup-plan-5min-schedule   Full          Available   ...

La sortie ressemble à ce qui suit. Remarquez la valeur FULL BACKUP POLICY définie sur la ressource de stratégie de sauvegarde planifiée scheduled-backup-every-5min précédemment créée, ainsi que le STATUS qui devrait être Disponible.

Vérifiez l’état de la sauvegarde planifiée pour kube-system:

La sortie ressemble à ce qui suit. Remarquez la valeur BACKUPPLAN définie sur la ressource de plan de sauvegarde précédemment créée, ainsi que le STATUS qui devrait être Disponible.

Vous pouvez maintenant vérifier que les sauvegardes sont effectuées à intervalles réguliers (5 minutes), en interrogeant la ressource de sauvegarde de cluster et en inspectant la colonne START TIME (kubectl get clusterbackup -n tvk). Cela devrait refléter l’écart de 5 minutes, comme indiqué dans l’image ci-dessous :

À l’étape suivante, vous apprendrez à définir une politique de rétention pour vos sauvegardes.

Étape 7 – Politique de rétention des sauvegardes

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

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

• Utilisation des politiques de rétention
• Les politiques de rétention peuvent être utilisées pour les CRD (Custom Resource Definitions) BackupPlan ou ClusterBackupPlan. Un manifeste Policy typique pour le type Retention ressemble à ceci :
• La politique de rétention ci-dessus se traduit par :
• Chaque semaine, conserver une sauvegarde chaque mercredi.

Chaque mois, conserver une sauvegarde le 15 jour.

A typical ClusterBackupPlan example configuration that has a retention set looks like:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    retentionPolicy:
      fullBackupPolicy:
        name: ambassador-backups-retention-policy
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Chaque année, conserver une sauvegarde chaque mars.

Au total, il devrait y avoir 2 plus récentes sauvegardes disponibles.

Le flux de base pour la création d’une ressource de politique de rétention se déroule de la même manière que pour les sauvegardes planifiées. Vous avez besoin d’un CRD BackupPlan ou ClusterBackupPlan défini pour référencer la politique de rétention, puis avoir un objet Backup ou ClusterBackup pour déclencher le processus.

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

Remarquez qu’il utilise un champ retentionPolicy pour référencer la politique en question. Bien sûr, vous pouvez avoir un plan de sauvegarde qui a les deux types de politiques définis, de sorte qu’il puisse effectuer des sauvegardes planifiées, ainsi que gérer les stratégies de rétention.

Utilisation des politiques de nettoyage

Vous avez besoin d’un moyen de collecter les objets qui ne sont plus utilisés. Pour cela, vous devez introduire la CRD Cleanup Policy :

La politique de nettoyage ci-dessus doit être définie dans l’espace de nom d’installation de TVK. Ensuite, un travail cron est automatiquement créé pour vous, qui s’exécute toutes les 30 minutes et supprime les sauvegardes échouées en fonction de la valeur spécifiée pour backupdays dans le champ spec.

Conclusion

• Dans ce tutoriel, vous avez appris comment effectuer des sauvegardes ponctuelles ainsi que planifiées et comment tout restaurer.

• Toutes les tâches et opérations de base expliquées dans ce tutoriel sont destinées à vous donner une introduction de base et une compréhension de ce que TrilioVault pour Kubernetes est capable de faire.

• En savoir plus
  

Sauvegarde et restauration des données DOKS à l’aide de Velero