Article 6 : Monitoring minimaliste avec Prometheus & Grafana

Intégration de Prometheus & Grafana pour monitorer mon cluster Kubernetes auto-hébergé, avec accès HTTPS public, dashboard par défaut personnalisé et sécurité maintenue, le tout dans une logique MVP GitOps.

Dans cette sixième étape, j'intègre un système de monitoring pour superviser mon cluster Kubernetes, toujours dans une logique MVP, auto-hébergée, et sans complexité inutile.

Objectif : visibilité simple et efficace

Je veux pouvoir visualiser l'état de mon cluster en un coup d’œil : CPU, mémoire, pods, réseau. Pas de sur-ingénierie, pas d’alerts emails, juste un dashboard clair.

J'utilise le chart Helm kube-prometheus-stack, largement adopté en prod, même s’il est ici sous-utilisé dans un but pédagogique.

Installation via Helm

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm upgrade --install monitoring prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --create-namespace \ --values prometheus-stack-values.yaml 

J'ai désactivé alertmanager dans le values.yaml, car je ne souhaite pas gérer d'alertes pour ce MVP :

alertmanager: enabled: false 

Pourquoi ne pas utiliser le module Prometheus de MicroK8s ?

MicroK8s propose un module prometheus activable en une ligne :

microk8s enable prometheus 

Mais ce module reste une boîte noire difficile à intégrer dans un workflow GitOps :

• Il n'est pas versionné dans le dépôt Git
• Il n'offre quasiment aucun contrôle sur la configuration ou les versions
• Il ne permet pas de séparer proprement Grafana et Prometheus

En choisissant le chart Helm kube-prometheus-stack, je garde la maîtrise complète de la configuration via mon values.yaml, je peux versionner mon infrastructure, et je rends mon setup portatif sur n'importe quel autre cluster Kubernetes cloud ou local.

Accès à Grafana

J'ai créé un Ingress à grafana.woulf.fr avec certificat HTTPS géré par cert-manager.

L'accès admin est protégé par un Secret Kubernetes (non committé) défini comme :

grafana: admin: existingSecret: monitoring-grafana 

Création du Secret

kubectl -n monitoring create secret generic monitoring-grafana \ --from-literal=admin-user=admin \ --from-literal=admin-password=******** 

Et pour permettre un accès public simple, j’ai activé l'accès anonyme avec le rôle Viewer (lecture seule) :

grafana: grafana.ini: auth.anonymous: enabled: true org_name: Main Org. org_role: Viewer hide_version: true 

Dashboard par défaut

J'ai choisi le dashboard Kubernetes / Compute Resources / Cluster fourni par défaut dans le chart, puis je l’ai exporté, versionné dans un ConfigMap, et monté comme dashboard d’accueil :

grafana: grafana.ini: dashboards: default_home_dashboard_path: /var/lib/grafana/dashboards/grafana-dashboard-home/default.json dashboardsConfigMaps: grafana-dashboard-home: grafana-dashboard-home sidecar: dashboards: enabled: true label: grafana_dashboard searchNamespace: ALL 

Le ConfigMap correspondant est versionné dans le repo d’infra, et porte le label grafana_dashboard: "1" pour être pris en compte automatiquement par le sidecar Grafana.

📁 Un ConfigMap est une ressource Kubernetes qui permet de monter des fichiers non sensibles dans un pod.
Il est rechargé automatiquement en cas de modification.

Résultat

• Grafana accessible publiquement, en HTTPS
• Dashboard par défaut lisible et utile
• Aucun login requis pour consulter l’état du cluster
• Compte admin sécurisé via Secret Kubernetes

Cette approche respecte les bonnes pratiques DevOps, tout en restant simple et facilement compréhensible pour un visiteur ou un recruteur.

🧠 Et en production ?

Ce setup est volontairement minimaliste et pédagogique, mais plusieurs aspects seraient renforcés dans un contexte de production :

• Alertmanager serait activé, avec des routes d’alerte vers des services externes (email, Slack, etc.), pour être notifié dès qu’un composant tombe.
• L’accès Grafana ne serait pas ouvert en anonyme : il serait restreint par IP, protégé par un proxy ou connecté à un SSO/LDAP.
• Le mot de passe admin ne serait pas géré via un Secret statique, mais externalisé via Vault ou une solution de gestion de secrets (SealedSecrets, ExternalSecrets).
• Les dashboards seraient provisionnés via API ou fichiers dédiés, avec une stratégie de gestion de version plus modulaire.
• Le certificat TLS serait géré via des mécanismes de rotation automatique à plus grande échelle (wildcard DNS, ACME DNS challenge...).

Mais dans le cadre de ce MVP, cette configuration me donne un bon équilibre entre simplicité, lisibilité, sécurité de base et maintenabilité GitOps.

⚡ Prochaine étape : ajout de loki pour la collecte de logs centralisée ? Ou test d’ArgoCD pour GitOps avancé ?

C'est ouvert !