Sauvegarde et restauration du tableau de bord Kubernetes : guide pratique d'exploitation

Introduction

Le tableau de bord Kubernetes Web UI (souvent appelé simplement « le tableau de bord ») est une interface administrative critique pour de nombreux clusters. Perdre sa configuration, ses jetons d'accès ou ses réglages personnalisés peut perturber la gestion du cluster. Ce guide explique comment sauvegarder et restaurer le tableau de bord, en couvrant l'inventaire des versions, la configuration sûre, la vérification, la récupération après échec et les listes de contrôle opérationnelles.

Vous apprendrez des commandes concrètes pour observer l'état actuel, exporter et importer des ressources, valider une restauration et récupérer des échecs courants. L'accent est mis sur des procédures pratiques et reproductibles utilisant kubectl et des manifestes YAML. Nous supposons que vous disposez d'un cluster Kubernetes en cours d'exécution avec le tableau de bord déployé, probablement via le manifeste recommandé ou le chart Helm.

Testez toujours ces procédures dans un environnement hors production d'abord. L'objectif est de rendre la sauvegarde et la restauration routinières, à faible risque et vérifiables.

Inventaire des versions et de l'environnement

Avant de toucher à quoi que ce soit, sachez exactement ce que vous exécutez. Commencez par vérifier la version du serveur Kubernetes et les détails du déploiement du tableau de bord.

kubectl version --short
kubectl get pods -n kubernetes-dashboard -o wide

La sortie attendue montre les versions client et serveur, ainsi qu'une liste des pods du tableau de bord avec leur état, leur âge et leur nœud. Par exemple :

Client Version: v1.27.3
Server Version: v1.27.3
NAME                                   READY   STATUS    RESTARTS   AGE   IP            NODE
dashboard-metrics-scraper-7c8f8b8d-9x2k   1/1     Running   0          5d    10.244.1.5    node-1
kubernetes-dashboard-6c8b8d8d-7z2k   1/1     Running   0          5d    10.244.1.6    node-1

Ensuite, inspectez les déploiements et le service du tableau de bord :

kubectl get deployment -n kubernetes-dashboard
kubectl get service -n kubernetes-dashboard kubernetes-dashboard-kong-proxy -o yaml

Recherchez la version de l'image, les réplicas, les limites de ressources et toute annotation ou étiquette personnalisée. Notez-les pour une comparaison ultérieure. Vérifiez aussi les secrets utilisés par le tableau de bord. Pour l'authentification, suivez le guide à l'adresse https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md pour créer un utilisateur d'exemple et obtenir son jeton.

kubectl get secrets -n kubernetes-dashboard

Notez tous les jetons de compte de service ou noms de secrets créés, car certaines méthodes de sauvegarde incluent les secrets. Vérifiez les liaisons RBAC :

kubectl get clusterrolebinding kubernetes-dashboard
kubectl get rolebinding -n kubernetes-dashboard

Cet inventaire vous assure de connaître les composants existants, leurs versions et leurs dépendances. Sans cela, une sauvegarde pourrait manquer des éléments critiques comme des rôles personnalisés ou des annotations.

Chemin de configuration sûre

Configurer le tableau de bord en toute sécurité signifie comprendre ce qui peut être modifié sans casser l'accès. Les éléments de configuration courants incluent :

• Type de service (ClusterIP, NodePort, LoadBalancer)
• Règles d'ingress
• Certificats TLS
• Mode d'authentification (jeton vs basic)
• Définitions de ressources personnalisées (CRD) pour les plugins

Pour éviter de perdre la configuration lors d'une sauvegarde, exportez les définitions YAML actuelles :

kubectl get deployment -n kubernetes-dashboard -o yaml > dashboard-deployment-backup.yaml
kubectl get service -n kubernetes-dashboard kubernetes-dashboard-kong-proxy -o yaml > dashboard-service-backup.yaml
kubectl get configmap -n kubernetes-dashboard -o yaml > dashboard-configmaps-backup.yaml

Si vous utilisez Helm, vous pouvez capturer les valeurs de la version :

helm get values kubernetes-dashboard -n kubernetes-dashboard > dashboard-values.yaml
helm get manifest kubernetes-dashboard -n kubernetes-dashboard > dashboard-manifest.yaml

Stockez ces fichiers dans un système de contrôle de version. Lorsque vous apportez des modifications de configuration, appliquez-les de manière contrôlée :

kubectl apply -f dashboard-deployment-backup.yaml --dry-run=client
kubectl apply -f dashboard-deployment-backup.yaml
kubectl wait --for=condition=available deployment --all -n kubernetes-dashboard --timeout=300s

Vérifiez toujours que le déploiement se termine avant de continuer. Utilisez kubectl port-forward pour tester l'accès localement :

kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard-kong-proxy 8443:443

Ouvrez ensuite https://localhost:8443 dans un navigateur (acceptez le certificat auto-signé) et connectez-vous avec un jeton valide. Cela garantit que le tableau de bord fonctionne après chaque modification.

Vérification et diagnostics

Vérifier l'état du tableau de bord avant et après la sauvegarde/restauration est essentiel. Voici des commandes de diagnostic :

Listez les pods du tableau de bord et consultez les journaux de l'un d'eux :

kubectl get pods -n kubernetes-dashboard
kubectl logs -n kubernetes-dashboard <dashboard-pod-name> --tail=50

Recherchez des erreurs comme Failed to watch *v1.Secret ou Unauthorized. Si un pod est en boucle de crash :

kubectl describe pod -n kubernetes-dashboard <pod-name>
kubectl logs -n kubernetes-dashboard <pod-name> --previous

Vérifiez les endpoints du service :

kubectl get endpoints -n kubernetes-dashboard kubernetes-dashboard-kong-proxy

La sortie attendue doit montrer au moins une adresse IP et un port, correspondant aux IP des pods. Si les endpoints sont vides, le sélecteur de service peut être incorrect ou les pods ne sont pas prêts.

Testez l'accès API depuis l'intérieur du cluster :

kubectl run -it --rm debug --image=curlimages/curl --restart=Never -n kubernetes-dashboard -- curl -k https://kubernetes-dashboard-kong-proxy:443

Cela devrait renvoyer le HTML du tableau de bord ou une redirection. Pour l'authentification, utilisez un jeton bearer valide (par exemple, celui de l'utilisateur d'exemple créé selon le guide). Copiez le jeton et utilisez-le pour vous connecter. Après une restauration, vous devez répéter ces vérifications pour confirmer que le tableau de bord est pleinement fonctionnel.

Modes d'échec et récupération

Les opérations de sauvegarde et de restauration peuvent mal tourner de plusieurs façons. Comprendre les modes d'échec probables vous aide à récupérer rapidement.

Échec courant : secret ou jeton manquant

Symptôme : les pods du tableau de bord ne démarrent pas avec MountVolume.SetUp failed for volume "kubernetes-dashboard-certs" ou secret "kubernetes-dashboard-certs" not found.

Le tableau de bord attend certains secrets. Si vous n'avez sauvegardé que le déploiement, les secrets peuvent être perdus. Récupération :

kubectl get secret -n kubernetes-dashboard

S'ils manquent, recréez le secret. Pour les certificats TLS, vous pouvez en générer un nouveau :

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout dashboard.key -out dashboard.crt -subj "/CN=kubernetes-dashboard"
kubectl create secret tls kubernetes-dashboard-certs --key dashboard.key --cert dashboard.crt -n kubernetes-dashboard

Redémarrez ensuite les déploiements :

kubectl rollout restart deployment --all -n kubernetes-dashboard

Échec courant : mauvaise version d'image

Symptôme : ImagePullBackOff ou crash des pods en raison d'une incompatibilité d'API.

Vérifiez toujours que l'étiquette de l'image correspond à votre version de Kubernetes. L'image du tableau de bord est kubernetesui/dashboard:<version>. Pour Kubernetes 1.27, utilisez v2.7.0. Si vous avez restauré un ancien manifeste avec une image incompatible, mettez à jour l'étiquette et réappliquez :

spec:
  containers:
  - name: kubernetes-dashboard
    image: kubernetesui/dashboard:v2.7.0

Ensuite :

kubectl apply -f dashboard-deployment-backup.yaml
kubectl wait --for=condition=available deployment --all -n kubernetes-dashboard --timeout=300s

Échec courant : RBAC cassé

Symptôme : le tableau de bord se charge mais affiche Forbidden ou aucune ressource.

Vérifiez le compte de service et les liaisons de rôle :

kubectl auth can-i list pods --as=system:serviceaccount:kubernetes-dashboard:kubernetes-dashboard -n default

Si la réponse est no, restaurez la ClusterRoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard

Appliquez et retestez.

Échec courant : dérive de configuration

Symptôme : le tableau de bord fonctionne mais les réglages personnalisés (comme les limites de ressources ou les annotations) ont disparu.

Gardez une sauvegarde complète de tout le YAML dans un contrôle de version. Après la restauration, comparez avec l'original :

diff <(kubectl get deployment -n kubernetes-dashboard -o yaml) dashboard-deployment-backup.yaml

Si des différences existent au-delà des métadonnées attendues (par exemple, resourceVersion), investigatez et réconciliez.

Pièges courants

Voici des erreurs fréquentes dans la sauvegarde/restauration du tableau de bord et comment les éviter.

Piège 1 : sauvegarder uniquement le déploiement, pas l'état complet

Pourquoi cela arrive : on suppose que le tableau de bord n'est qu'un pod. Mais il a besoin de secrets, de configmaps, de services et de RBAC.

Comment l'éviter : utilisez une commande de sauvegarde complète :

kubectl get all,secret,configmap,serviceaccount,role,rolebinding,clusterrole,clusterrolebinding -n kubernetes-dashboard -o yaml > dashboard-full-backup.yaml

Cela capture tout dans le namespace. Pour les ressources au niveau du cluster (ClusterRole, ClusterRoleBinding), utilisez :

kubectl get clusterrole,clusterrolebinding -o yaml | grep -A 20 kubernetes-dashboard > dashboard-cluster-backup.yaml

Stockez les deux fichiers.

Piège 2 : ne pas tester le processus de restauration

Pourquoi cela arrive : les sauvegardes sont faites mais jamais restaurées jusqu'à un incident, et elles échouent alors en raison de composants manquants ou d'incompatibilités de version.

Comment l'éviter : testez régulièrement la restauration dans un cluster de staging. Automatisez avec un script qui déploie la sauvegarde et exécute des commandes de vérification.

Piège 3 : utiliser un jeton statique ou un mot de passe dans le fichier de sauvegarde

Pourquoi cela arrive : les secrets sont exportés dans la sauvegarde et peuvent être stockés en texte clair.

Comment l'éviter : chiffrez les fichiers de sauvegarde ou stockez-les dans un coffre sécurisé. Évitez de committer des secrets bruts dans Git. Si vous devez utiliser Git, utilisez un outil comme Sealed Secrets ou SOPS.

Piège 4 : ne pas épingler les versions d'image

Pourquoi cela arrive : les manifestes peuvent utiliser l'étiquette latest, qui change au fil du temps.

Comment l'éviter : spécifiez toujours une version précise dans le YAML de sauvegarde. Par exemple, kubernetesui/dashboard:v2.7.0.

Piège 5 : ignorer RBAC pendant la restauration

Pourquoi cela arrive : le tableau de bord peut démarrer mais les utilisateurs ne peuvent pas se connecter en raison de permissions manquantes.

Comment l'éviter : incluez les ressources RBAC dans la sauvegarde et vérifiez avec kubectl auth can-i après la restauration.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour chaque opération de sauvegarde ou de restauration.

Liste de contrôle de sauvegarde

• [ ] Confirmer l'accès au cluster : kubectl cluster-info
• [ ] Enregistrer la version actuelle du tableau de bord : kubectl get deployment -n kubernetes-dashboard -o jsonpath='{.items[].spec.template.spec.containers[].image}'
• [ ] Exporter toutes les ressources du namespace : kubectl get all,secret,configmap,serviceaccount -n kubernetes-dashboard -o yaml > dashboard-ns-backup-$(date +%Y%m%d).yaml
• [ ] Exporter le RBAC au niveau du cluster : kubectl get clusterrole,clusterrolebinding -o yaml | grep -B 2 -A 10 kubernetes-dashboard > dashboard-rbac-backup-$(date +%Y%m%d).yaml
• [ ] Stocker les fichiers de sauvegarde dans un emplacement sécurisé (par exemple, bucket S3 chiffré ou Git avec SOPS)
• [ ] Enregistrer les versions de kubectl et de Kubernetes pour référence ultérieure
• [ ] Responsable : l'ingénieur DevOps (par exemple, Priya Shah) examine la sauvegarde trimestriellement

Liste de contrôle de restauration

• [ ] Vérifier que la version du cluster cible correspond à la source de sauvegarde (ou noter les différences)
• [ ] Créer le namespace s'il manque : kubectl create namespace kubernetes-dashboard
• [ ] Appliquer les ressources du namespace : kubectl apply -f dashboard-ns-backup.yaml
• [ ] Appliquer RBAC : kubectl apply -f dashboard-rbac-backup.yaml
• [ ] Vérifier l'état des pods : kubectl get pods -n kubernetes-dashboard
• [ ] Vérifier le service : kubectl get svc -n kubernetes-dashboard
• [ ] Tester l'accès : kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard-kong-proxy 8443:443 et se connecter avec un jeton
• [ ] Exécuter les diagnostics : kubectl get pods -n kubernetes-dashboard et kubectl logs -n kubernetes-dashboard <dashboard-pod-name> --tail=50
• [ ] Documenter le résultat de la restauration et les différences dans un runbook
• [ ] Responsable : le responsable de plateforme (par exemple, Alex Chen) approuve les tests de restauration

Post-vérification

• [ ] Confirmer que tous les pods sont Running et Ready
• [ ] Confirmer l'absence d'états CrashLoopBackOff ou Error
• [ ] Confirmer que l'authentification par jeton fonctionne pour un utilisateur de test
• [ ] Confirmer que l'interface du tableau de bord s'affiche et peut lister les pods dans le namespace par défaut
• [ ] Planifier le prochain test de sauvegarde : mensuellement, avec un rappel dans le calendrier de l'équipe

Conclusion

Sauvegarder et restaurer le tableau de bord Kubernetes Web UI est une compétence opérationnelle critique. En suivant les procédures décrites ici, vous pouvez vous assurer que la configuration de votre tableau de bord est sûre, récupérable et vérifiable. Commencez par un inventaire complet, exportez toutes les ressources pertinentes, testez le processus de restauration et formez votre équipe aux étapes de récupération.

N'oubliez pas de versionner vos sauvegardes, de sécuriser vos secrets et de valider régulièrement que la restauration fonctionne. Avec ces pratiques, vous minimiserez les temps d'arrêt et maintiendrez une interface administrative fiable pour votre cluster Kubernetes.