K3S/Velero - A (long) way to DevSecOps - Épisode 6

Rappel de la saga : A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6, Épisode 7, Épisode 8.

Edit 23/07/2020 : Remplacement de « local-path », par un nouveau provisionner de stockage (OpenEBS) qui supporte bien Velero. Un PR a été soumis, et apportera prochainement le support du stockage par défaut de K3S.

Le projet Velero

Historique

Le projet Velero naît sous le nom de « Ark » sous contrôle de l’entreprise Heptio. En 2018 alors que VMWare se rend compte de l’ampleur des technologies Kubernetes, l’entreprise décide d’absorber des compétences pour rattraper son retard sur ces technologies « Cloud-Native ». Il suffit de checker la page Wikipédia de VMWare pour se rendre compte de l’effort accordé aux technos Cloud, et le résultat qu’est aujourd’hui l’offre mature de PKS :

Velero est donc aujourd’hui sous contrôle de VMWare et l’offre « open source » de VMWare se retrouve sous le nom de VMWare Tanzu. On y retrouve Velero toujours librement accessible.

Fonctionnement

Bon, je ne vais pas refaire une nième description de ce logiciel. En gros Velero va sauvegarder tous les éléments permettant de restaurer une application. Une petite démo sympathique se trouve ici.

La sauvegarde des éléments constituant une application peut-être effectuée sur un stockage compatible AWS, c’est ici que l’on va utiliser Minio.

Projet démo

Depuis les dernières releases, il y a un petit projet démo qui est inclus dans Velero. Nous n’allons pas l’utiliser mais il y a toutes les ressources nécessaires pour comprendre rapidement le fonctionnement de Velero.

Installation et utilisation

Installation d’OpenEBS

Avec Helm c’est simple :

helm repo add openebs https://openebs.github.io/charts
helm repo update
helm install --namespace openebs --name openebs openebs/openebs

Installation de Minio

Il est possible d’installer Minio directement sur le cluster Kubernetes. Dans mon cas je l’ai installé ailleurs, pour déporter la sauvegarde en dehors du cluster (disaster recovery). Dans le projet de démo il y a le fichier Manifest nécessaire pour déployer Minio.

Installation de Velero

Ici tout se passe en une ligne de commande. Il faut néanmoins préparer le fichier permettant de se connecter à Minio. Fichier exemple (secrets) :

[default]
aws_access_key_id = accessid
aws_secret_access_key = secretpassword

Il suffit de lancer la commande velero disponible dans la release de votre choix (auparavant il faut créer un bucket sur votre Minio – ici le nom est velero, et d’avoir l’URL de votre Minio – remplacer anywhere.com) :

velero install --provider aws --bucket velero --secret-file secrets --use-volume-snapshots=false --use-restic --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=https://anywhere.com,publicUrl=https://anywhere.com --plugins velero/velero-plugin-for-aws:v1.0.0

La commande velero va pouvoir être utilisée par la suite pour gérer les sauvegardes (elle va se connecter automatiquement sur les APIs de l’application nouvellement déployée sur votre K8S).

Vous pouvez déjà vérifier l’état de santé de votre déploiement avec cette commande :

kubectl get deployments/velero -n velero

Le résultat attendu :

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
velero   1/1     1            1           1h

Utilisation de Velero

J’ai déployé rapidement un Prometheus/Grafana sur mon infra K3S, on va le sauvegarder, le détruire puis le restaurer.

Monitoring

Voir l’épisode précédent.

Attention : il faut customiser le déploiement en utilisant « openebs-hostpath » en tant que StorageClass.

Visualisation du fonctionnement de Grafana

Sauvegarde du namespace Monitoring

Annotation des volumes de stockage (propre à mon déploiement) :

kubectl -n monitoring annotate pod/prometheus-server-596d96465b-lxnnc  backup.velero.io/backup-volumes=storage-volume
kubectl -n monitoring annotate pod/prometheus-alertmanager-644cf8f47c-bf5b4 backup.velero.io/backup-volumes=storage-volume
kubectl -n monitoring annotate pod/grafana-7fb88c95b7-lxzb2 backup.velero.io/backup-volumes=storage

velero backup create monitoring-save --include-namespaces monitoring

Vérification de la sauvegarde

# velero get backup

Visualisation dans Minio

Destruction de l’application

kubectl delete namespace monitoring

Vérification du statut

# kubectl get all -n monitoring
No resources found in monitoring namespace.

Restauration de l’application

velero restore create monitoring-restore --from-backup monitoring-save

Vérification du statut

# velero restore get
NAME                 BACKUP            STATUS      ERRORS   WARNINGS   CREATED                          SELECTOR
monitoring-restore   monitoring-save   Completed   0        0          2020-07-23 11:56:40 +0200 CEST   <none>

Tout est bien restauré et l’application est de retour, et on voit bien le petit temps d’indisponibilité sur la supervision :

Bonus

Politique de sauvegarde

Il est possible via la commande velero de programmer (scheduler :-p) des sauvegardes périodiques.

Toutes les heures avec un maximum d’une journée :

velero schedule create monitoring-hourly --schedule="@every 1h" --ttl 24h0m0s --include-namespaces monitoring

Tous les jours avec un maximum d’une semaine :

velero schedule create monitoring-daily --schedule="@every 24h" --ttl 168h0m0s --include-namespaces monitoring

Conclusion

Nous avons vu depuis le début de cette suite d’articles comment :

• installer K3S,
• déployer un provisionner de stockage (NFS ou vous pouvez utiliser Longhorn, comme je suis retourné sur un master node only, je vais utiliser OpenEBS),
• superviser rapidement le cluster avec une solution de monitoring,
• déployer ses premières applications (WordPress / Portainer),
• les sauvegarder et les restaurer et mettre en place une politique de sauvegarde.

C’est déjà une bonne base d’un point de vue infra, il faudra voir ce que l’on veut approfondir par la suite, plus d’un point vue DevOps. Si vous avez des commentaires, des compléments, n’hésitez pas : ici ou sur Twitter, c’est permis !!! Kenavo.