Le lab Kubernetes local de la formation Observabilité

15 min

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Le lab de la formation Observabilité est un cluster Kubernetes local, Minikube, sur lequel tourne une vraie application à observer. Les leçons de pratique y installent une à une Prometheus, Grafana, Alertmanager et Loki, autour de l'OpenTelemetry Demo, un site e-commerce d'une vingtaine de microservices. Cette page présente ce lab avant que vous n'installiez quoi que ce soit : la machine qu'il demande, l'architecture de la stack, l'application observée, le dépôt Git qui porte les fichiers de configuration et l'accès aux interfaces. L'installation elle-même se fait dans la leçon Installer Minikube, Helm et kubectl, après une leçon de concepts sur ce qui sépare l'observabilité du monitoring.

Ce que vous allez apprendre

Situer chaque brique de la stack dans le trajet d'un signal
Vérifier que votre machine peut porter le lab
Cloner le dépôt du lab et y retrouver les values Helm d'une leçon
Accéder aux interfaces du lab par leur NodePort

Quelles leçons se jouent sur le lab ?

Six leçons se jouent sur le cluster, et elles gardent la numérotation du dépôt, de 00 à 05 : l'installation, l'application de démonstration, Prometheus, Grafana, les alertes et Loki. Ces leçons appellent « module 02 » ou « module 04 » une étape du lab : à ne pas confondre avec les modules de la formation, qui regroupent plusieurs leçons.

Les autres leçons de pratique, sur les exporters, PromQL, Loki avec Alloy, OpenTelemetry et le Collector, tournent hors du cluster. Elles n'ont donc pas de dossier dans le dépôt du lab : leurs fichiers sont dans la page.

Configuration matérielle requise

L'application de démonstration déploie à elle seule une vingtaine de microservices, auxquels s'ajoutent Prometheus, Grafana, Alertmanager et Loki. En dessous de 8 Go de RAM, Minikube commence à évincer des pods et les leçons du lab deviennent difficiles à valider.

Ressource	Minimum	Recommandé
RAM	8 Go	16 Go
CPU	4 cœurs	6+ cœurs
Disque	20 Go libres	40 Go libres
OS	Linux, macOS, Windows (WSL2)	Linux

Architecture de la stack

Chaque leçon du lab ajoute une brique au schéma ci-dessous, jamais plus d'une à la fois. Le principe reste constant : les applications émettent des signaux, un collecteur les route, une base spécialisée les stocke, et Grafana sert de point d'entrée unique pour les interroger. Repérez dès maintenant où se situe la brique que vous installez : cela évite de confondre un problème de collecte avec un problème de stockage.

Source · SVG

Stack technologique

Lisez ce tableau ligne par ligne : chaque signal suit le même trajet, mais avec des outils et surtout un langage de requête différents. C'est la principale source de confusion au début : PromQL et LogQL se ressemblent sans être interchangeables. La ligne des traces décrit la stack complète ; cette formation s'arrête à leur émission.

Signal	Collecte	Stockage	Requêtage	Visualisation
Métriques	OTel Collector	Prometheus TSDB	PromQL	Grafana
Logs	Promtail, Alloy	Loki	LogQL	Grafana
Traces	OTel Collector	Tempo, Jaeger	TraceQL	Grafana, Jaeger
Alertes	Prometheus Rules	Alertmanager	PromQL (règles)	Grafana

L'application de démonstration

Le lab observe l'OpenTelemetry Demo, l'application de référence de la CNCF pour l'observabilité : un site e-commerce d'une vingtaine de microservices, sollicité en continu par un générateur de charge.

Pourquoi cette application ?

Un « hello world » instrumenté ne produirait qu'une trace à un seul saut et des métriques sans variation, donc rien d'intéressant à observer. L'OpenTelemetry Demo génère au contraire du trafic continu, des appels entre services écrits dans des langages différents, et des pannes déclenchables à la demande.

Critère	Avantage
Multi-langage	Go, Java, .NET, Python, Node.js, Rust, représentatif du monde réel
Instrumentation native	Métriques et traces OpenTelemetry intégrées
Générateur de charge	Trafic réaliste automatique avec Locust
Scénarios d'erreur	Feature flags pour simuler des pannes
Open source	Maintenu par la CNCF, bien documenté

Architecture de l'application

Inutile de mémoriser ce schéma, mais gardez-le sous la main : quand une latence grimpera, c'est ici que vous identifierez quel service parle à quel autre. Les flèches représentent des appels applicatifs, pas des flux de télémétrie.

Source · SVG

Dépôt Git du lab

Les fichiers de values Helm utilisés dans le lab sont regroupés dans un dépôt public. Clonez-le avant de commencer : les leçons y font référence par leur chemin, et recopier à la main des centaines de lignes de YAML depuis une page web est la meilleure façon d'introduire une erreur d'indentation.

git clone https://github.com/stephrobert/lab-observability.git
cd lab-observability

Structure du dépôt

Un dossier par leçon de lab, nommé exactement comme elle, ce qui permet de retrouver un fichier de values sans chercher. Les leçons qui tournent hors du cluster n'ont pas de dossier, comme on l'a vu plus haut : leurs fichiers sont dans la page.

lab-observability/
├── 00-setup/                 # Scripts de vérification
├── 01-demo-app/
│   ├── values.yaml           # Helm values pour OTel Demo
│   └── otel-collector-values.yaml  # Config du Collector
├── 02-prometheus/
│   └── helm-values/
│       └── prometheus-minimal.yaml
├── 03-grafana/
│   └── helm-values/
│       └── grafana.yaml
├── 04-alerting/
│   ├── helm-values/
│   │   └── alertmanager.yaml
│   └── rules/                # Règles d'alerte
├── 05-loki/
│   └── helm-values/
│       └── loki-stack.yaml
└── README.md

Accès aux interfaces

Les interfaces sont exposées en NodePort, c'est-à-dire sur un port fixe de l'adresse IP de Minikube, et non en port-forward : l'accès survit ainsi à la fermeture du terminal. Aucune de ces interfaces n'est protégée en dehors du mot de passe Grafana ; ce lab reste strictement local et ne doit pas être exposé sur un réseau partagé.

Service	URL	Credentials
OTel Demo	http://<MINIKUBE_IP>:30080	Aucun
Prometheus	http://<MINIKUBE_IP>:30090	Aucun
Grafana	http://<MINIKUBE_IP>:30030	admin / admin
Alertmanager	http://<MINIKUBE_IP>:30093	Aucun

L'adresse de Minikube s'obtient avec une seule commande, à relancer après chaque recréation du cluster :

minikube ip

Conseils pour réussir

L'écueil le plus fréquent sur ce type de lab est de lire vite et de ne rien retenir. Les cinq réflexes ci-dessous coûtent quelques minutes par leçon et évitent de repartir de zéro. Le premier est le plus important : une erreur non corrigée se propage en cascade dans les leçons suivantes.

Suivez l'ordre des leçons

Chaque leçon du lab installe des composants utilisés par les suivantes. Sauter une leçon causera des erreurs.
Exécutez chaque commande

Ne vous contentez pas de lire. Tapez chaque commande et observez le résultat.
Validez avant d'avancer

Chaque leçon de lab se termine par une section « Validation ». Assurez-vous que tout fonctionne avant de continuer.
En cas de problème, consultez le dépannage

Chaque leçon contient une section « Dépannage » avec les erreurs courantes.
Passez le quiz de chaque leçon de pratique

Il vérifie que vous avez compris pourquoi, pas seulement comment : c'est lui qui valide la compétence.

À retenir

Le lab est un cluster Minikube local qui observe l'OpenTelemetry Demo, une vingtaine de microservices
Comptez 8 Go de RAM au minimum, 16 Go pour travailler confortablement
Les leçons 00 à 05 se jouent sur le cluster ; les autres tournent hors du cluster, fichiers dans la page
Le dépôt lab-observability porte un dossier par leçon de lab : clonez-le avant de commencer
Les interfaces sont en NodePort sur minikube ip, sans protection : le lab reste strictement local
Chaque leçon du lab installe ce que la suivante interroge : validez avant d'avancer