Checklist des opérations de production pour l'interface web Kubernetes Dashboard avec exemples pratiques

Introduction

L'interface web Kubernetes Dashboard est un outil essentiel pour visualiser et gérer les charges de travail d'un cluster. En production, sa fiabilité opérationnelle dépend toutefois du maintien de la bonne version, de l'application de changements de configuration sécurisés, d'un diagnostic proactif des problèmes et de la mise en place de chemins de reprise clairs. Sans approche structurée, les équipes peuvent être confrontées à des incidents récurrents, une dérive de configuration ou des failles de sécurité.

Cet article fournit une checklist opérationnelle pratique, illustrée d'exemples, pour le Kubernetes Dashboard en production. Il s'adresse aux développeurs, consultants DevOps et équipes de startups qui gèrent des clusters Kubernetes. La checklist couvre les domaines suivants :

• Inventaire des versions et de l'environnement
• Chemins de configuration sécurisés
• Vérification et diagnostics
• Modes de défaillance et reprise
• Tâches d'exploitation courantes

Chaque section comprend des commandes concrètes, les sorties attendues, les signaux de défaillance et les décisions de reprise. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables fictives plutôt que des secrets, vérifier les résultats et documenter la marche à suivre lorsque les états attendus ne sont pas atteints.

Inventaire des versions et de l'environnement

Avant toute intervention, vous devez savoir exactement quelle version du Dashboard vous exécutez, sa topologie de déploiement et les prérequis environnants. Cette base de référence évite les incompatibilités entre l'interface, le serveur d'API et vos contrôles d'accès.

Identifier la version du Dashboard déployée

Exécutez les commandes en lecture seule suivantes :

kubectl get pods -n kubernetes-dashboard -o wide

La sortie attendue affiche les pods du dashboard avec leur IP, leur nœud et leur statut. Par exemple :

NAME                                             READY   STATUS    RESTARTS   AGE   IP           NODE
dashboard-metrics-scraper-7c5b7c4b7b-4mz6q       1/1     Running   0          12d   10.244.1.5   node-1
kubernetes-dashboard-5c7b5b4c4d-8q2wz            1/1     Running   0          12d   10.244.2.3   node-2

Pour obtenir la version exacte de l'image :

kubectl get deployment kubernetes-dashboard -n kubernetes-dashboard -o jsonpath='{.spec.template.spec.containers[0].image}'

Exemple de sortie :

kubernetesui/dashboard:v2.7.0

Consultez les notes de version correspondantes. Vérifiez la compatibilité avec votre version de Kubernetes. Par exemple, le Dashboard v2.7.0 est compatible avec Kubernetes 1.22 à 1.26. Si vous utilisez Kubernetes 1.28, vous devez mettre à niveau le Dashboard vers la version 3.0.0 ou ultérieure.

Vérifier les prérequis

Le Dashboard nécessite :

• Un cluster Kubernetes en cours d'exécution (version dans la plage prise en charge)
• RBAC activé (standard dans la plupart des clusters)
• Un accès réseau au serveur d'API depuis votre navigateur ou via un proxy
• Si vous utilisez l'authentification par jeton, un jeton de compte de service valide
• Si vous utilisez une Ingress, un contrôleur d'Ingress et un certificat TLS correctement configurés

Pour confirmer que RBAC est activé :

kubectl api-versions | grep rbac.authorization.k8s.io

La sortie attendue inclut rbac.authorization.k8s.io/v1.

Documenter la topologie

Créez un document d'inventaire avec les détails concrets suivants :

Ce tableau vous offre un aperçu clair. Lorsque quelque chose change, mettez à jour l'inventaire.

Commandes de vérification pratiques

Utilisez la séquence suivante pour collecter des informations complètes sur l'environnement :

kubectl get all -n kubernetes-dashboard
kubectl describe deployment kubernetes-dashboard -n kubernetes-dashboard
kubectl get events -n kubernetes-dashboard --sort-by=.lastTimestamp | tail -20

Recherchez :

• Les erreurs ImagePullBackOff indiquant des problèmes de registre
• Les CrashLoopBackOff sur le metrics scraper
• Les événements FailedScheduling dus à des contraintes de ressources

Par exemple, si vous voyez FailedScheduling avec Insufficient cpu, vous savez que le pool de nœuds doit être mis à l'échelle.

Chemins de configuration sécurisés

Les changements de configuration exigent de la prudence. Le principe est le suivant : effectuez un changement à la fois, observez le résultat et ayez un plan de retour en arrière. Évitez de modifier directement les ressources actives lorsque des manifests sont disponibles.

Gérer la configuration comme du code

Stockez la configuration du Dashboard (Deployment, Service, RBAC, Ingress) dans un dépôt Git. Utilisez kubectl apply avec des manifests pour la reproductibilité.

Exemple : mettez à jour la version de l'image du Dashboard dans dashboard-deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
    spec:
      containers:
      - name: kubernetes-dashboard
        image: kubernetesui/dashboard:v2.7.0   # Changez vers la nouvelle version
        ports:
        - containerPort: 8443
          protocol: TCP
        args:
          - --auto-generate-certificates
          - --namespace=kubernetes-dashboard

Appliquez avec :

kubectl apply -f dashboard-deployment.yaml

Vérifiez le déploiement :

kubectl rollout status deployment/kubernetes-dashboard -n kubernetes-dashboard

Sortie attendue :

deployment "kubernetes-dashboard" successfully rolled out

Si le déploiement échoue, revenez en arrière :

kubectl rollout undo deployment/kubernetes-dashboard -n kubernetes-dashboard

Sécuriser la configuration d'authentification

N'utilisez jamais le certificat auto-signé par défaut en production. Fournissez plutôt votre propre certificat TLS via un secret :

kubectl create secret tls kubernetes-dashboard-certs \
  --cert=/chemin/vers/tls.crt \
  --key=/chemin/vers/tls.key \
  -n kubernetes-dashboard

Référencez-le dans les arguments du déploiement du Dashboard :

args:
  - --tls-cert-file=/certs/tls.crt
  - --tls-key-file=/certs/tls.key
  - --auto-generate-certificates=false

Montez le secret en tant que volume :

volumes:
- name: kubernetes-dashboard-certs
  secret:
    secretName: kubernetes-dashboard-certs

Et dans le conteneur :

volumeMounts:
- name: kubernetes-dashboard-certs
  mountPath: /certs

Appliquez et vérifiez que le pod redémarre avec les nouveaux certificats.

Utiliser un compte de service dédié avec privilèges minimaux

Au lieu d'utiliser les privilèges d'administration par défaut, créez un compte de service avec accès en lecture seule pour les opérations quotidiennes :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-viewer
  namespace: kubernetes-dashboard

Liez-le à un ClusterRole en lecture seule (comme view) :

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

Générez un jeton pour ce compte de service pour la connexion au dashboard (après avoir créé le compte et la liaison) :

kubectl create token dashboard-viewer -n kubernetes-dashboard

Ce jeton expire par défaut. Pour des jetons à longue durée de vie, créez un secret manuellement et extrayez le jeton.

Checklist de vérification de la configuration

Après tout changement de configuration, exécutez :

kubectl get pods -n kubernetes-dashboard
kubectl logs -n kubernetes-dashboard deployment/kubernetes-dashboard --tail=20
curl -I https://dashboard.example.com

Vérifiez :

• Pods prêts et sans redémarrage
• Aucune erreur de certificat TLS dans les journaux
• HTTP 200 ou redirection depuis l'Ingress

Vérification et diagnostics

La vérification continue garantit que le Dashboard est sain et réactif. Les diagnostics aident à identifier les goulots d'étranglement de performance, les problèmes de connectivité ou l'épuisement des ressources.

Contrôles de santé

Le déploiement du Dashboard inclut des sondes de vivacité et de disponibilité par défaut. Vérifiez qu'elles sont configurées :

kubectl get deployment kubernetes-dashboard -n kubernetes-dashboard -o yaml | grep -A5 -B5 probes

Extrait attendu :

livenessProbe:
  httpGet:
    path: /
    port: 8443
    scheme: HTTPS
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /
    port: 8443
    scheme: HTTPS
  initialDelaySeconds: 5
  periodSeconds: 10

Si les sondes échouent, le pod redémarre ou devient indisponible. Utilisez kubectl describe pod pour voir les événements d'échec des sondes.

Analyse des journaux

Pour identifier rapidement les erreurs :

kubectl logs -n kubernetes-dashboard deployment/kubernetes-dashboard --tail=50

Erreurs courantes :

• x509: certificate signed by unknown authority – indique une incompatibilité de certificat
• context deadline exceeded – probablement serveur d'API injoignable
• 503 Service Unavailable du metrics scraper – vérifiez le pod du metrics scraper

Test de connectivité réseau

Depuis l'intérieur du cluster, testez le service du Dashboard :

kubectl run curl-test -it --rm --image=curlimages/curl -n kubernetes-dashboard -- sh

Puis dans le pod :

curl -k https://kubernetes-dashboard:443

Une réponse réussie avec du contenu HTML confirme que le service fonctionne. Testez depuis l'extérieur via l'Ingress :

curl -I https://dashboard.example.com

Recherchez HTTP/2 200 ou HTTP/1.1 200 OK.

Diagnostics de performance

Une latence élevée du Dashboard peut provenir de la charge du serveur d'API ou de grands ensembles de ressources. Surveillez les métriques du serveur d'API :

kubectl get --raw /metrics | grep apiserver_request_duration_seconds_sum

Si les requêtes du Dashboard expirent, augmentez le --token-ttl ou ajustez les paramètres --insecure-bind-address en fonction de votre modèle d'accès. Mais généralement, le problème vient de la charge globale de l'API du cluster.

Commandes de diagnostic utiles

• kubectl top nodes et kubectl top pods -n kubernetes-dashboard – vérifient l'utilisation des ressources
• kubectl get events -n kubernetes-dashboard --sort-by=.lastTimestamp – événements récents
• kubectl exec -it <pod> -n kubernetes-dashboard -- netstat -tulpn – ports en écoute dans le pod
• kubectl port-forward svc/kubernetes-dashboard 8443:443 -n kubernetes-dashboard – accès local pour les tests

Lors de l'utilisation du port-forward, ouvrez https://localhost:8443 dans votre navigateur et acceptez le certificat auto-signé si vous l'utilisez encore.

Modes de défaillance et reprise

Connaître les schémas de défaillance courants permet une reprise plus rapide. Voici des scénarios de défaillance spécifiques avec les étapes de détection et de reprise.

Scénario 1 : Pod du Dashboard en CrashLoopBackOff

Détection :

kubectl get pods -n kubernetes-dashboard

La sortie montre un nombre de redémarrages croissant et le statut CrashLoopBackOff.

Investigation :

kubectl describe pod <nom-du-pod> -n kubernetes-dashboard
kubectl logs <nom-du-pod> -n kubernetes-dashboard --previous

Causes possibles :

• Volume de certificat mal configuré
• ConfigMap manquante
• Arguments incompatibles

Reprise :

Si le problème vient du certificat, corrigez le secret et le montage, puis supprimez le pod pour forcer le redémarrage :

kubectl delete pod <nom-du-pod> -n kubernetes-dashboard

Si le problème vient des arguments, revenez à la version précédente du déploiement :

kubectl rollout undo deployment/kubernetes-dashboard -n kubernetes-dashboard

Scénario 2 : Impossible de se connecter au Dashboard

Détection : Le jeton est rejeté ou le navigateur affiche une erreur d'authentification.

Investigation :

Vérifiez que le jeton appartient à un compte de service valide :

kubectl get serviceaccount <nom-du-sa> -n kubernetes-dashboard
kubectl get clusterrolebinding <nom-du-binding> -o yaml

Si vous utilisez OIDC, vérifiez les paramètres --oidc-issuer et client dans le déploiement.

Reprise :

Générez un nouveau jeton :

kubectl create token <nom-du-sa> -n kubernetes-dashboard

Ou, si vous utilisez un secret de jeton à longue durée de vie, extrayez-le :

kubectl get secret <nom-du-secret> -n kubernetes-dashboard -o jsonpath='{.data.token}' | base64 -d

Assurez-vous que le compte de service dispose des liaisons RBAC appropriées.

Scénario 3 : Le Dashboard n'affiche aucune donnée ni métrique

Détection : Les graphiques CPU/mémoire sont vides.

Investigation :

Vérifiez le pod du metrics scraper :

kubectl get pods -n kubernetes-dashboard | grep metrics-scraper
kubectl logs -n kubernetes-dashboard deployment/dashboard-metrics-scraper

Erreur courante : dial tcp: lookup kubernetes-dashboard on 10.96.0.10:53: no such host ou metrics server non déployé.

Reprise :

Assurez-vous que le metrics-server est installé dans le cluster :

kubectl get deployment metrics-server -n kube-system

S'il est absent, installez-le. Vérifiez également que le DNS du service scraper est correct.

Scénario 4 : L'Ingress du Dashboard renvoie 502 Bad Gateway

Détection : curl -I https://dashboard.example.com renvoie 502.

Investigation :

Vérifiez la ressource Ingress et les endpoints du service :

kubectl get ingress -n kubernetes-dashboard
kubectl get endpoints kubernetes-dashboard -n kubernetes-dashboard

Si les endpoints sont vides, le sélecteur du service ne correspond pas aux pods. Vérifiez kubectl get pods -n kubernetes-dashboard --show-labels et le sélecteur du service.

Reprise :

Corrigez le sélecteur du service ou les étiquettes des pods pour qu'ils correspondent, puis vérifiez à nouveau l'Ingress.

Checklist de vérification après reprise

Après toute reprise, vérifiez :

• Le pod du Dashboard est en cours d'exécution sans redémarrage
• La connexion fonctionne avec un jeton valide
• Les métriques s'affichent correctement
• L'Ingress renvoie 200 OK
• Les journaux ne montrent aucune erreur au cours des 5 dernières minutes

Checklist des opérations

Utilisez cette checklist résumée comme référence rapide pour les opérations routinières et réactives. Chaque élément comprend la commande ou l'action et le résultat attendu.

Cette checklist doit être intégrée dans les runbooks de votre équipe et automatisée lorsque cela est possible.

Conclusion

Un Kubernetes Web UI Dashboard prêt pour la production exige plus qu'un simple déploiement réussi. Il nécessite une approche disciplinée de la gestion des versions, du contrôle de la configuration, des diagnostics et de la reprise sur défaillance. La checklist et les exemples de cet article fournissent une base pour construire votre propre runbook opérationnel.

Les principes clés demeurent :

• Observer avant de modifier : toujours recueillir l'état actuel et les journaux.
• Limiter le rayon d'impact : changer une variable à la fois.
• Protéger les secrets : éviter de journaliser les jetons ; utiliser des variables fictives.
• Vérifier les résultats : utiliser des commandes explicites avec les sorties attendues.
• Documenter la reprise : savoir comment revenir en arrière avant d'en avoir besoin.

Comme prochaine étape, choisissez une vérification à faible risque dans cet article, comme la vérification de la compatibilité de la version du Dashboard. Enregistrez l'état actuel, exécutez la commande et comparez le résultat avec la sortie attendue. Procédez ensuite à l'examen de votre configuration d'authentification et de certificat. En intégrant ces pratiques dans vos opérations régulières, vous réduirez les temps d'arrêt et améliorerez la fiabilité de votre Kubernetes Dashboard en production.