Sauvegarde et restauration multi-locataires dans Kubernetes : guide pratique de mise en œuvre

Introduction

La multi-location dans Kubernetes introduit des défis uniques pour la sauvegarde et la restauration. Lorsque plusieurs équipes ou applications partagent un cluster, une sauvegarde mal configurée peut exposer des données sensibles au-delà des frontières locataires, et une restauration échouée peut perturber des charges de travail sans lien. Ce guide va au-delà de la théorie pour fournir une approche pratique, axée sur les commandes, pour sauvegarder et restaurer des ressources délimitées par locataire dans Kubernetes.

Nous nous concentrons sur les réalités opérationnelles : identifier ce qu'il faut sauvegarder, sélectionner les outils appropriés, valider les sauvegardes et exécuter des procédures de restauration qui minimisent le rayon d'impact. Vous apprendrez à utiliser les fonctionnalités natives de Kubernetes comme les espaces de noms, les quotas de ressources et le RBAC (Role-Based Access Control, contrôle d'accès basé sur les rôles) pour isoler les données des locataires, et à les combiner avec des outils de sauvegarde comme Velero pour créer des plans de reprise après sinistre robustes. Chaque section comprend des commandes concrètes, des sorties attendues et des signaux d'échec à surveiller.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets dans les exemples, vérifier les résultats et documenter les chemins de récupération avant qu'un incident ne survienne.

Inventaire des versions et de l'environnement

Avant de mettre en œuvre la sauvegarde et la restauration, établissez un inventaire clair de la version de votre cluster, de sa topologie et du modèle de location existant. Cet inventaire sert de base de référence pour le dépannage et garantit la compatibilité avec les outils et procédures de sauvegarde.

Composants clés à inventorier :

• Versions du plan de contrôle et des nœuds Kubernetes (kubectl version)
• Moteur d'exécution de conteneurs et pilotes CSI (Container Storage Interface, interface de stockage de conteneurs) (pertinents pour les snapshots de volumes)
• Espaces de noms et frontières des locataires (kubectl get namespaces)
• Quotas de ressources et plages de limites par espace de noms
• Rôles et liaisons RBAC qui définissent l'accès des locataires
• Classes de stockage et demandes de volume persistant en cours d'utilisation
• Outils de sauvegarde existants (par exemple, Velero, Stash, Kasten)

Prérequis pour la mise en œuvre de la sauvegarde :

• Cluster Kubernetes version 1.18+ (pour les API de snapshot stables) avec les autorisations appropriées
• Une cible de sauvegarde : stockage d'objets compatible S3, NFS ou stockage blob cloud
• Autorisations RBAC adéquates pour que l'outil de sauvegarde puisse accéder à tous les espaces de noms des locataires
• Si vous utilisez des snapshots de volumes, un pilote CSI qui prend en charge les snapshots

Commandes pratiques d'inventaire :

Commencez par une observation en lecture seule de votre cluster :

kubectl version --short
kubectl get nodes -o wide
kubectl get namespaces --show-labels

Listez les quotas de ressources dans tous les espaces de noms pour comprendre les limites des locataires :

kubectl get resourcequota --all-namespaces

Passez en revue le RBAC pour les comptes de service liés à la sauvegarde :

kubectl get clusterrolebinding | grep velero
kubectl describe clusterrole velero

Vérifiez les classes de stockage et les demandes de volume persistant existantes :

kubectl get storageclass
kubectl get pvc --all-namespaces

Sorties attendues et signaux d'échec :

• Si kubectl get nodes affiche des nœuds dans l'état NotReady, résolvez les problèmes de nœuds avant de sauvegarder.
• Si les quotas de ressources sont absents, l'utilisation des ressources par les locataires peut être incontrôlée ; envisagez de les ajouter.
• Si le compte de service de l'outil de sauvegarde manque d'autorisations, les sauvegardes échoueront avec des erreurs RBAC.

Rayon d'impact et récupération : Tout changement aux ressources au niveau du cluster (par exemple, CRD (Custom Resource Definition, définition de ressource personnalisée), rôles de cluster) peut affecter tous les locataires. Avant d'installer un outil de sauvegarde, passez en revue ses autorisations requises et testez-le dans un cluster hors production si possible. Gardez un enregistrement des composants installés et de leurs versions pour faciliter le retour en arrière.

Chemin de configuration sécurisé

Configurer la sauvegarde et la restauration en toute sécurité nécessite une approche étape par étape qui minimise les risques. Cette section décrit un chemin de configuration qui sépare l'observation de l'intervention et inclut une vérification à chaque étape.

Étape 1 : Définir la portée de la sauvegarde par locataire

Dans les clusters multi-locataires, il est essentiel de sauvegarder les ressources de chaque locataire indépendamment. Utilisez la location basée sur les espaces de noms comme meilleure pratique, où chaque locataire possède un ou plusieurs espaces de noms. Étiquetez les espaces de noms pour permettre une sauvegarde sélective :

apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a
  labels:
    tenant: a
    backup: "true"

Appliquez le manifeste :

kubectl apply -f tenant-a-namespace.yaml

Vérifiez l'étiquette :

kubectl get namespace tenant-a --show-labels

Étape 2 : Installer et configurer l'outil de sauvegarde

Velero est un outil open source populaire pour la sauvegarde et la restauration Kubernetes. Installez-le avec les plugins appropriés pour votre fournisseur de stockage. Exemple d'installation avec AWS S3 :

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.2.0 \
  --bucket my-backup-bucket \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1 \
  --secret-file ./credentials-velero

Après l'installation, vérifiez que Velero est en cours d'exécution :

kubectl get pods -n velero
kubectl logs deployment/velero -n velero

Vérifiez que l'emplacement de stockage de sauvegarde est disponible :

velero backup-location get

Étape 3 : Créer des planifications de sauvegarde avec des sélecteurs spécifiques au locataire

Utilisez des sélecteurs d'étiquettes pour inclure uniquement les ressources du locataire dans une sauvegarde. Exemple de planification pour le locataire-a :

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: tenant-a-daily
  namespace: velero
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - tenant-a
    labelSelector:
      matchLabels:
        tenant: a
    ttl: 720h

Appliquez et vérifiez :

kubectl apply -f tenant-a-schedule.yaml
velero schedule get

Étape 4 : Valider la sauvegarde manuellement

Avant de compter sur les planifications, effectuez une sauvegarde à la demande et vérifiez qu'elle se termine :

velero backup create tenant-a-manual --include-namespaces tenant-a
velero backup describe tenant-a-manual
velero backup logs tenant-a-manual

Principes de configuration sécurisée :

• Utilisez les espaces de noms et les étiquettes pour isoler les données des locataires.
• Stockez les informations d'identification dans des secrets Kubernetes, pas dans des manifestes en texte brut.
• Testez régulièrement les sauvegardes en restaurant vers un espace de noms de préproduction.
• Surveillez l'état des tâches de sauvegarde et les alertes en cas d'échec.

Commandes de vérification pour une configuration sécurisée :

Après avoir appliqué tout changement, vérifiez les pods et les journaux pertinents :

kubectl get pods -n velero -o wide
kubectl describe pod <nom-du-pod> -n velero
kubectl logs <nom-du-pod> -n velero --previous

Pour les déploiements Velero, assurez-vous que le déploiement est déployé avec succès :

kubectl rollout status deployment/velero -n velero

Vérification et diagnostics

La vérification est le processus de confirmation que les sauvegardes sont valides et restaurables. Les diagnostics aident à identifier pourquoi une sauvegarde ou une restauration a échoué. Cette section fournit des étapes de vérification concrètes et des commandes de diagnostic.

Vérification de l'intégrité de la sauvegarde

Après avoir créé une sauvegarde, vérifiez son état et sa phase :

velero backup get

La sortie attendue doit afficher la phase Completed et aucune erreur :

NAME                STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
tenant-a-manual     Completed   0        0          2023-01-01 12:00:00 +0000 UTC   29d       default            <none>

Décrivez la sauvegarde pour plus de détails :

velero backup describe tenant-a-manual --details

Vérifiez les avertissements ou les erreurs dans le journal :

velero backup logs tenant-a-manual

S'il y a des erreurs, les causes courantes incluent des autorisations insuffisantes, un emplacement de stockage manquant ou des sélecteurs invalides.

Vérification de l'aptitude à la restauration

Effectuez une restauration de test vers un espace de noms différent pour garantir l'intégrité des données sans affecter les locataires de production :

velero restore create --from-backup tenant-a-manual --namespace-mappings tenant-a:tenant-a-restore

Surveillez la restauration :

velero restore get
velero restore describe tenant-a-restore
velero restore logs tenant-a-restore

Vérifiez que les ressources restaurées fonctionnent :

kubectl get all -n tenant-a-restore
kubectl get pvc -n tenant-a-restore

La sortie attendue doit montrer tous les déploiements, services et PVC créés.

Diagnostic des échecs courants de sauvegarde/restauration

1. Sauvegarde bloquée à InProgress : Vérifiez les journaux du pod Velero pour les erreurs. Souvent dû à des problèmes de snapshot de volume.

   kubectl logs deployment/velero -n velero | grep -i error

1. La restauration échoue avec l'erreur NotFound : La sauvegarde peut ne pas inclure la ressource référencée en raison d'une non-concordance du sélecteur d'étiquettes. Vérifiez la liste des ressources de la sauvegarde :

   velero backup describe <nom-de-la-sauvegarde> --details | grep -A5 "Resource List"

1. Échec de la restauration des PVC : Si vous utilisez le provisionnement dynamique, assurez-vous que la classe de stockage existe et prend en charge le snapshot. Vérifiez les événements :

   kubectl get events -n <espace-de-noms> --sort-by='.lastTimestamp'

Utilisation des diagnostics natifs de Kubernetes

Pour diagnostiquer les problèmes dans les espaces de noms des locataires avant la sauvegarde ou après la restauration :

• Vérifiez l'état et les événements des pods :

  kubectl get pods -n tenant-a -o wide
  kubectl describe pod <nom-du-pod> -n tenant-a

• Affichez les journaux des pods en boucle de crash :

  kubectl logs <nom-du-pod> -n tenant-a --previous

• Vérifiez l'état de déploiement des déploiements :

  kubectl rollout status deployment/<nom-du-déploiement> -n tenant-a

Considérations de performance

La sauvegarde et la restauration peuvent avoir un impact sur les performances du cluster. Surveillez l'utilisation des ressources pendant les opérations de sauvegarde :

kubectl top pods -n velero

Si les pods Velero consomment un CPU ou une mémoire excessifs, envisagez d'ajuster les limites de ressources dans le déploiement Velero.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous prépare à récupérer rapidement. Cette section décrit les échecs typiques de sauvegarde et de restauration dans les clusters multi-locataires et fournit des procédures de récupération.

Mode de défaillance 1 : Sauvegarde incomplète en raison d'autorisations RBAC manquantes

Symptômes : La sauvegarde se termine partiellement avec des erreurs ; les journaux affichent 403 Forbidden.

Diagnostic :

velero backup describe <nom-de-la-sauvegarde> --details
kubectl logs deployment/velero -n velero | grep -i forbidden

Récupération :

1. Passez en revue les autorisations requises de Velero :

   kubectl get clusterrole velero -o yaml

1. Comparez avec les autorisations documentées. Si elles manquent, mettez à jour le rôle de cluster :

   kubectl apply -f velero-clusterrole.yaml

1. Relancez la sauvegarde.

Mode de défaillance 2 : Conflit de restauration avec des ressources existantes

Symptômes : La restauration échoue avec des erreurs AlreadyExists pour certaines ressources.

Diagnostic :

velero restore describe <nom-de-la-restauration> --details

Récupération :

1. Identifiez les ressources en conflit.
2. Décidez de supprimer les ressources existantes ou de restaurer avec un nom différent. Par exemple, supprimez le déploiement en conflit :

   kubectl delete deployment <nom-du-déploiement> -n <espace-de-noms>

Ou utilisez le drapeau --existing-resource-policy de Velero pour ignorer ou mettre à jour :

   velero restore create --from-backup <nom-de-la-sauvegarde> --existing-resource-policy none

Mode de défaillance 3 : Échecs de snapshot de volume

Symptômes : La sauvegarde se termine mais les snapshots de volume échouent ; les données des PVC ne sont pas sauvegardées.

Diagnostic : Vérifiez les journaux Velero pour les erreurs de snapshot :

kubectl logs deployment/velero -n velero | grep -i snapshot

Récupération :

1. Vérifiez que le pilote CSI prend en charge les snapshots :

   kubectl get volumesnapshotclass

1. S'il n'y a pas de classe de snapshot, créez-en une appropriée pour votre fournisseur de stockage.
2. Relancez la sauvegarde.

Mode de défaillance 4 : Suppression accidentelle de l'espace de noms du locataire

Symptômes : Espace de noms du locataire supprimé, applications hors service.

Récupération avec Velero :

1. Trouvez la dernière sauvegarde pour l'espace de noms :

   velero backup get --include-namespaces tenant-a

1. Restaurez l'espace de noms :

   velero restore create --from-backup <nom-de-la-sauvegarde>

1. Vérifiez la restauration :

   kubectl get namespace tenant-a
   kubectl get all -n tenant-a

Stratégies de retour en arrière

Dans les clusters multi-locataires, les retours en arrière doivent être délimités par locataire pour éviter d'affecter les autres. Utilisez la restauration basée sur l'espace de noms pour revenir en arrière sur l'application d'un seul locataire. Par exemple, si une mise à jour de déploiement casse l'application du locataire-a, restaurez le manifeste de déploiement précédent à partir de la sauvegarde :

velero restore create --from-backup tenant-a-manual --include-resources deployments --namespace-mappings tenant-a:tenant-a

Alternativement, si vous utilisez GitOps, revenez en arrière sur le manifeste dans Git et synchronisez.

Vérification de la récupération

Après toute récupération, effectuez une validation :

• Vérifiez que les pods sont en cours d'exécution et prêts :

  kubectl get pods -n tenant-a -o wide

• Testez les points de terminaison de l'application.
• Vérifiez l'intégrité des données dans les bases de données.
• Assurez-vous qu'il n'y a pas de fuite de ressources entre locataires (par exemple, les services dans d'autres espaces de noms ne sont pas affectés).

Documentez chaque défaillance et récupération pour référence future.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour vous assurer que vos processus de sauvegarde et de restauration multi-locataires Kubernetes sont robustes et prêts.

Préparation

• [ ] Documenter la version du cluster, les fournisseurs de stockage et le modèle de location.
• [ ] Définir les politiques de sauvegarde par locataire : fréquence, rétention et portée.
• [ ] Étiqueter les espaces de noms avec des identifiants de locataire et des drapeaux de sauvegarde.
• [ ] Configurer le RBAC pour l'outil de sauvegarde avec le moindre privilège.
• [ ] Mettre en place la surveillance et les alertes pour les tâches de sauvegarde (par exemple, alertes Prometheus sur les métriques Velero).

Configuration de la sauvegarde

• [ ] Installer Velero (ou une alternative) avec les plugins appropriés.
• [ ] Créer un emplacement de stockage de sauvegarde et vérifier la connectivité.
• [ ] Créer des planifications avec des sélecteurs d'étiquettes par locataire.
• [ ] Effectuer une sauvegarde manuelle et vérifier la fin.
• [ ] Tester la restauration vers un espace de noms de préproduction.

Opérations en cours

• [ ] Surveiller les planifications de sauvegarde quotidiennement : velero schedule get.
• [ ] Examiner les journaux de sauvegarde chaque semaine pour les erreurs ou les avertissements.
• [ ] Tester la restauration au moins trimestriellement pour garantir la récupérabilité.
• [ ] Mettre à jour les politiques de sauvegarde lorsque les locataires changent.
• [ ] Faire tourner régulièrement les informations d'identification de sauvegarde.

Réponse aux incidents

• [ ] Avoir des procédures documentées pour les modes de défaillance courants (comme ci-dessus).
• [ ] Maintenir une liste de contacts pour chaque locataire.
• [ ] Après la récupération, effectuer une revue post-incident et mettre à jour les procédures.

Référence pratique des commandes

Remplacez l'espace de noms d'exemple tenant-a par votre espace de noms réel.

Vérification pour la liste de contrôle des opérations

Après avoir suivi la liste de contrôle, vérifiez :

• Toutes les planifications de sauvegarde sont actives et des sauvegardes récentes existent.
• Les objectifs de temps de récupération (RTO, Recovery Time Objective) et de point de récupération (RPO, Recovery Point Objective) sont respectés lors des restaurations de test.
• Aucune tâche de sauvegarde n'échoue silencieusement (configurez des alertes pour les échecs de tâches).
• Les quotas de ressources et le RBAC sont appliqués pendant la restauration.

Conclusion

Mettre en œuvre la sauvegarde et la restauration dans un environnement Kubernetes multi-locataires exige une planification minutieuse et une validation continue. En isolant les locataires avec des espaces de noms et des étiquettes, en utilisant des outils comme Velero avec des sélecteurs appropriés et en testant régulièrement les restaurations, vous pouvez parvenir à une reprise après sinistre fiable sans compromettre l'isolation des locataires.

Ce guide a fourni des étapes pratiques pour inventorier votre environnement, configurer les sauvegardes en toute sécurité, vérifier et diagnostiquer les problèmes, et récupérer après des défaillances. Les principaux points à retenir sont :

• Toujours observer avant de modifier : utilisez des commandes en lecture seule pour comprendre l'état actuel.
• Limitez le rayon d'impact avec des sauvegardes et des restaurations délimitées par locataire.
• Validez les sauvegardes en testant les restaurations de manière isolée.
• Documentez les procédures de récupération et tenez-les à jour.

Comme prochaine étape, mettez en œuvre une planification de sauvegarde pour un locataire dans votre cluster, testez le processus de restauration, puis étendez-vous à d'autres locataires en suivant les mêmes modèles. N'oubliez pas qu'une sauvegarde n'est aussi bonne que votre capacité à la restaurer.