UStackUStack
Radar icon

Radar

Radar est une UI Kubernetes open source pour inspecter la topologie, les événements, les releases Helm et l’état GitOps sur un ou plusieurs clusters.

Radar

Qu'est-ce que Radar ?

Radar est une UI Kubernetes open source conçue pour rendre les opérations multi-clusters plus faciles à comprendre et à déboguer que l'utilisation seule de kubectl. Elle fournit une interface graphique pour inspecter la topologie des clusters, les événements, les charges de travail et les signaux opérationnels associés sur les clusters connectés.

Le projet peut être exécuté comme un seul binaire Go en local ou auto-hébergé dans un cluster Kubernetes, sous licence Apache 2.0 et sans compte requis pour la version OSS. Une offre Radar Cloud séparée ajoute des fonctionnalités non prévues pour un simple binaire, telles que l'agrégation de flottes, la rétention persistante, les alertes routées, SSO et journaux d'audit.

Fonctionnalités principales

  • Vues de topologie et de dépendances : Visualisez les relations de services en direct (y compris le trafic est-ouest et les flux d'entrée) pour comprendre comment les composants se connectent.
  • Chronologie et navigation des événements : Inspectez les événements Kubernetes et rembobinez la chronologie pour suivre ce qui s'est passé lors d'un incident.
  • Visibilité des charges de travail et versions : Recherchez sur les clusters et comparez les versions de charges de travail côte à côte.
  • Inspection des charts/releases Helm : Consultez l'historique des releases Helm comme les révisions et fichiers de valeurs, et auditez les changements entre révisions.
  • Visibilité GitOps avec Argo CD et Flux : Voyez l'état de synchronisation des applications aux côtés des ressources produites, avec support natif pour Argo CD et Flux.
  • Inspection d'images (visionneuse de système de fichiers d'images) : Inspectez les images conteneurs, y compris une visionneuse de système de fichiers, pour examiner le contenu pendant le débogage.
  • Audits de clusters et actions liées à la sécurité : Utilisez les vues d'audit (y compris le concept de « journaux d'audit » dans Radar Cloud) pour examiner les changements et actions privilégiées.
  • MCP pour agents IA : Exposez la fonctionnalité via « MCP for AI agents », permettant aux agents IA d'interagir avec Radar.

Comment utiliser Radar

  1. Choisir le mode d'installation : Exécutez Radar comme un outil local ou auto-hébergez-le dans votre cluster. Le site liste les options d'installation incluant un script shell d'une ligne (via curl + sh), Homebrew, une app desktop et l'installation in-cluster.
  2. Se connecter à Kubernetes : Pour le chemin auto-hébergé/in-cluster, installez Radar et utilisez-le depuis votre environnement ; pour l'usage local, exécutez-le avec accès à votre contexte Kubernetes.
  3. Commencer par la recherche et la navigation : Utilisez la recherche de l'UI pour trouver des ressources par nom, label ou type sur les clusters connectés, puis ouvrez la charge de travail ou ressource pertinente pour voir la chronologie, le contexte topologique et les détails associés.

Cas d'usage

  • Dépannage d'incidents sans SSH et fouille de logs : Quand une alerte se déclenche (par exemple, un pod qui plante dans un namespace inconnu), recherchez sur vos clusters, accédez aux logs et suivez la chronologie des événements depuis la même UI.
  • Vue d'ensemble « qu'est-ce qui échoue ? » à l'échelle de la flotte : Obtenez une vue unique des pods défaillants, certificats expirants, paquets dérivés ou vérifications de santé échouées sur plusieurs clusters, plutôt que de vérifier chaque cluster séparément.
  • Débogage de synchronisation GitOps : Si une application n'atteint pas l'état attendu, utilisez le support Argo CD/Flux pour inspecter l'état de synchronisation aux côtés des ressources produites.
  • Audit des changements Helm et préparation au rollback : Quand des releases changent de manière inattendue, examinez les révisions Helm et fichiers de valeurs, comparez les changements entre révisions et identifiez la révision précédente pour rollback.
  • Analyse de trafic et topologie pour dépendances de services : Inspectez les graphiques de trafic en direct (trafic est-ouest, flux d'entrée et santé des certificats TLS) pour comprendre quels services dépendent des autres.

FAQ

Radar est-il open source ?
Oui. La page indique que Radar est open source et sous licence Apache 2.0.

Ai-je besoin d'un compte pour utiliser la version OSS ?
Non. Le site indique que l'expérience OSS en binaire unique ne nécessite pas de compte.

Radar peut-il s'exécuter en local ou in-cluster ?
Oui. Il peut s'exécuter en local comme un binaire unique ou auto-hébergé dans votre cluster.

Que ajoute Radar Cloud par rapport au binaire OSS ?
La page décrit Radar Cloud comme ajoutant l'agrégation de flottes, la rétention persistante, les alertes routées, SSO et journaux d'audit — des fonctionnalités au-delà de ce qu'un binaire unique peut raisonnablement faire.

Radar s'intègre-t-il avec les outils GitOps ?
Oui. Il liste un support natif pour Argo CD et Flux pour visualiser l'état de synchronisation et les ressources produites.

Alternatives

  • kubectl (et les plugins kubectl) : Idéal lorsque vous avez besoin d'une inspection en ligne de commande directe pour un cluster unique ou une requête ponctuelle rapide ; il manque la navigation multi-clusters consolidée et basée sur une UI décrite pour Radar.
  • Autres tableaux de bord/monitoring Kubernetes : Ces UIs alternatives peuvent offrir des vues similaires à la topologie et l'inspection des événements/charges de travail, mais la page Radar met l'accent sur son champ d'application combiné (topologie, Helm, GitOps, audits, inspection d'images) et son approche OSS en binaire unique.
  • Outils d'agrégation Fleet : Pour les organisations axées sur la gestion de multiples clusters avec des vues centralisées, ces outils peuvent chevaucher le workflow orienté flotte de Radar, bien que Radar Cloud cible spécifiquement l'agrégation de flotte et la rétention.
  • Tableaux de bord centrés GitOps : Si votre besoin principal est l'état des applications GitOps, les tableaux de bord natifs GitOps peuvent se concentrer sur la synchronisation/état, tandis que le positionnement de Radar inclut aussi la visibilité des releases Helm, la topologie et un contexte plus large de débogage d'incidents.