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

Ce que vous saurez faire

1. Monter un cluster Kubernetes de zéro sur 3 machines nues, avec Cilium, Hubble et un Service de type LoadBalancer qui fonctionne vraiment.
2. Installer la pile que Radar doit trouver pour ne rien afficher de vide, et savoir quelle vue chaque composant débloque.
3. Lire un cluster que vous ne connaissez pas : ressources, détail, topologie, trafic réel, ce qui a changé.
4. Trouver la cause d'une panne en un geste, là où la ligne de commande demande 6 décisions.
5. Suivre un chemin réseau hop par hop, et distinguer une prédiction d'un verdict.
6. Retrouver la règle qui a jeté un paquet, et le hook Helm qui a bloqué une upgrade.
7. Obtenir des coûts réels sur un cluster hors cloud, en sachant ce qui est mesuré et ce qui est supposé.
8. Brancher un agent sur 30 outils MCP, lui donner une identité qui ne peut que lire, et aller de l'audit à la pull request sans toucher au cluster.
9. Déployer Radar pour une équipe : TLS, SSO Keycloak, et des droits par utilisateur portés par le RBAC de Kubernetes.

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.

Chaque vue enseignée porte une capture annotée : un cadre de couleur autour de la zone dont on parle, une pastille numérotée à côté, dans l'ordre des gestes. Le texte ne répète pas ce que la capture montre ; il dit ce qu'on ne voit pas.

Radar publie vite : 12 versions en 50 jours pendant la préparation de cette formation. Tout ce qui est affirmé ici vient donc du binaire installé, la v1.13.0, pas d'une page d'accueil.

Et quand une chose ne marche pas, la formation le dit. Le bouton de sonde in-cluster qui rend 404, une règle Prometheus qui n'alerte jamais parce que sa métrique n'existe pas, un rôle « lecture seule » qui laisse lire tous les mots de passe : ces trois-là ont été trouvés en écrivant les chapitres, et ils y sont.

Le lab, que vous montez vous-même

Le premier module ne parle pas de Radar : il monte le terrain, de zéro.

Trois machines nues, Ubuntu 26.04, 6 vCPU et 6 Go, sur le même segment réseau. Vous les obtenez comme vous voulez. Dessus : Kubernetes v1.36.4 par kubeadm, sans kube-proxy, Cilium 1.20.1 en routage natif avec Hubble, LB-IPAM et annonces L2, puis metrics-server, cert-manager, Prometheus, OpenCost et Argo CD.

Un second cluster, managé, sert de contrôle de réalité : ce que Radar montre d'un cluster qu'on ne maîtrise pas, et ce qui y diffère. Le même Cilium, réglé autrement, et des choix qu'on ne peut pas changer.

Le fil rouge

Boutique, un front, une API, un worker, PostgreSQL et un cache Redis, répartis sur 3 namespaces cloisonnés. Les images sont publiques : vous la déployez par un simple kubectl apply.

Elle sert de terrain à toutes les pannes de la formation, que vous provoquez vous-même par un script : un nom de service non qualifié qui coupe le worker, un selector qui ne désigne personne, une NetworkPolicy qui bloque plus que prévu, un hook Helm qui refuse une upgrade.

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

Un seul binaire, 123 Mio sur le disque, 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 embarque un serveur MCP de 30 outils, dont 7 qui écrivent. C'est ce qui le distingue des autres UI Kubernetes.

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 chapitre fait la liste de ce qu'il laisse à votre charge.

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 06 s'en charge.