Radar : voir, diagnostiquer et réparer un cluster Kubernetes

Objectifs

1. Installer Radar en vérifiant ce qu'on télécharge, et savoir ce que le premier lancement a réellement chargé.
2. Trouver la cause d'une panne en moins de commandes qu'avec kubectl seul, et mesurer l'écart.
3. Lire un cluster qu'on ne connaît pas : posture, ressources, topologie, ce qui a changé.
4. Diagnostiquer un chemin réseau hop par hop, et distinguer une prédiction d'un verdict.
5. Gérer des releases Helm et diagnostiquer un drift GitOps, sur Argo CD comme sur Flux.
6. Auditer la configuration, et savoir ce qu'un warning d'audit n'est pas.
7. Préparer une montée de version de Kubernetes sur des preuves, pas sur une note globale.
8. Voir ce qu'un ServiceAccount peut vraiment faire, et le rayon d'action d'un pod compromis.
9. Brancher un agent sur le serveur MCP, choisir ce qu'il a le droit de faire, et mesurer ce que cela coûte en tokens.
10. Déployer Radar dans le cluster pour une équipe, et dire ce qu'il ne fera pas à votre place.

Comment cette formation est faite

Chaque commande publiée ici a été exécutée, et chaque sortie de terminal est réelle. Les versions aussi ont été vérifiées auprès de la source qui fait autorité plutôt que citées de mémoire.

Radar publie vite : 8 versions en 4 semaines pendant la préparation de cette formation. Tout ce qui est affirmé ici vient donc du binaire installé, pas de sa page d'accueil. Quand le README annonce 31 contrôles d'audit et que le binaire en rend 39, la formation dit les 2 choses et montre la commande qui tranche.

Les chapitres suivent la même trame que les autres formations de l'atelier : le problème, un tableau des termes à ne pas confondre, la démonstration mesurée, 2 exemples complets qu'on peut copier et exécuter en entier, les pièges, puis un travail pratique avec son corrigé.

On mesure d'abord, on installe ensuite

Le module 01 ne parle pas de Radar. Il prend un cluster qui tourne et y mesure 4 choses avec kubectl et rien d'autre : combien de commandes pour trouver la cause d'un Deployment à 0/1, ce qu'un kubectl get dit d'un cluster de 152 ressources, ce que les tableaux de bord existants répondent, et ce qu'un agent fait de 4 000 lignes de YAML.

Ces 4 chiffres sont la référence. Chaque module suivant y revient et dit ce qu'il en a fait.

Ce que Radar est, et ce qu'il n'est pas

Un seul binaire de 124 Mio, sans agent, sans CRD, sans compte. Il lit le cluster par l'API avec vos credentials, garde les données sur votre machine, et pousse les mises à jour au navigateur. Il s'installe aussi dans le cluster pour une équipe, avec authentification et RBAC par utilisateur.

Il embarque un serveur MCP de 30 outils, dont 7 qui écrivent. C'est ce qui le distingue des autres UI Kubernetes, et c'est ce que le dernier module traite en premier.

Ce n'est pas un système de supervision : il ne stocke pas d'historique long, il n'alerte pas, et il ne remplace ni Prometheus ni votre chaîne d'incident. Le dernier module fait la liste de ce qu'il laisse à votre charge.

La formation tient en 5 modules et 47 chapitres. Radar est un binaire qu'on lit, pas une plateforme qu'on exploite pendant des années : l'étaler davantage aurait obligé à remplir, et remplir se voit.

Le fil rouge

Une application, Boutique, celle des formations Istio et Cilium : un front, une API, un worker, PostgreSQL et Redis, répartie sur 3 namespaces cloisonnés et 2 clusters fédérés.

Elle arrive avec une panne réelle, trouvée par Radar au premier appel pendant la préparation de cette formation : un Deployment à 0/1 depuis 22 heures, que personne n'avait vu.

Le lab

Six machines, 4 vCPU et 8 Go chacune, sous Ubuntu 26.04, livrées nues.

Le cluster A en prend 4 : un control plane et 3 workers. C'est celui qu'on lit pendant toute la formation. Trois workers, et pas 2, parce que 3 chapitres en dépendent : le drain d'une machine par le serveur MCP a besoin que les pods aient où aller, le contrôle d'audit « toutes les répliques sur la même machine » ne se démontre dans les 2 sens qu'à partir de 3, et la topologie d'une application sur 3 namespaces se lit mal quand tout atterrit au même endroit.

Le cluster B en prend 2 : un control plane et un worker. Il ne sert pas à faire du multi-cluster, la vue GitOps de Radar étant mono-cluster. Il sert à 2 choses : manipuler plusieurs contextes, et surtout recevoir tout ce qui casse. Rater une upgrade Helm exprès, provoquer un drift GitOps, déployer Radar avec de l'authentification : cela se fait sur B, pour que A reste stable.

Les 2 clusters tournent sous Cilium avec Hubble, pour une seule raison : sans source de trafic, la vue Traffic de Radar est vide. Le premier module y ajoute ensuite ce qui manque pour que Radar ait tout à montrer : metrics-server, cert-manager, Argo CD, Flux et OpenCost.

Radar tourne sur votre poste, pas sur le lab, jusqu'au module 14 qui l'installe dans le cluster.

Ce que ce lab ne montrera pas

Par honnêteté, et parce qu'on ne raconte pas ce qu'on n'a pas exécuté : la vue Capacity, qui demande Karpenter, et la détection de trafic par Istio ou par Beyla, puisque ce lab est en Cilium. Les chapitres concernés montrent la détection à vide et disent pourquoi.

Les coûts, eux, sont enseignés pour de vrai : OpenCost est installé sur le lab et produit de vraies allocations. Ce qui est approximatif, ce sont les prix, qui viennent de son barème par défaut et non d'une facture. Le chapitre le dit avant de montrer le moindre chiffre.

Prérequis

Kubernetes au niveau du quotidien : Pod, Deployment, Service, namespace, RBAC, et l'usage courant de kubectl. Des notions de Helm. La ligne de commande Linux ou macOS.

Aucune connaissance de MCP n'est supposée : le module 13 s'en charge.