Radar Kubernetes MCP Server

Radar

待望のオープンソース Kubernetes UI。
単一バイナリ。アカウント不要。永久無料。

🌐 radarhq.io · ドキュメント · リリース

トポロジー、リソース、Helm、GitOps、トラフィック、監査、アップグレードの影響、AI エージェント向けの MCP コンテキストを、ノート PC またはクラスター内から確認できます。

30 秒でインストールして実行できます：

curl -fsSL https://get.radarhq.io | sh && kubectl radar

その他のインストール方法 ↓

Radar を選ぶ理由

• クラスターへのインストール不要 — ノート PC 上で動作し、K8s API に直接接続します
• 単一バイナリ — 依存関係、エージェント、CRD は不要です
• 大規模クラスターでも高速 — 数万個の Pod でテスト済み。実際のクラスターで変動が続く状況でも、応答性の高いビューとライブ更新を実現します
• プライバシーを重視した設計 — クラスターのデータはお使いのマシンから外に出ません。アカウント、エージェント、クラウド同期は不要です。利用状況の報告はオプトインしない限り無効で、オプトインした場合も、匿名の利用回数と大まかなクラスター情報（Kubernetes のバージョン、プラットフォーム、ノード数の範囲、既知のインテグレーション）のみを送信します（Radar が送信する情報）
• エアギャップ環境にも対応 — Kubernetes API に対して単一バイナリとして動作し、外部への送信がブロックされたロックダウン環境でも使用できます
• リアルタイム — インフォーマー経由でクラスターを監視し、SSE 経由でブラウザーに更新をプッシュします
• あらゆる環境で動作 — GKE、EKS、AKS、minikube、kind、k3s、または適合する任意のクラスターに対応します
• AI 対応 — 組み込みの MCP サーバーを使い、AI エージェントから Radar 経由でクラスターを調査、分析、操作できます
• クラスター内へのデプロイにも対応 — Helm でデプロイすると、RBAC でスコープを制限した権限を使ってチームで共有できます

「職場で Radar をデプロイしています。Kubernetes ダッシュボードとしては、最高のもののひとつです。」 — u/TheRealNetroxen

インストール

クイックインストール：

curl -fsSL https://get.radarhq.io | sh

Homebrew：

brew install kubectl-radar

こちらの tap からもインストールできます：brew install skyhook-io/tap/radar。

次に、kubectl radar を実行します。クイックインストール、PowerShell、Homebrew、Scoop では、radar という短縮コマンドも設定されます。Krew と直接ダウンロードの場合は、独自に radar のシンボリックリンクを追加しない限り、kubectl radar を使用します。

kubectl krew install radar

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar

irm https://get.radarhq.io/install.ps1 | iex

curl -fsSL https://get.radarhq.io | INSTALL_DIR="$HOME/.local/bin" sh

brew install --cask skyhook-io/tap/radar-desktop

sudo apt install ./radar-desktop_*.deb

sudo rpm -i radar-desktop_*.rpm

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar-desktop

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace

使い方

# Opens browser automatically
kubectl radar

# Quick install, PowerShell, Homebrew, and Scoop also set up the bare command
radar

クラスター内の Radar Cloud インストールを変更せずに確認するには、次を実行します：

radar cloud status
radar cloud status --context my-cluster
radar cloud status --context my-cluster --namespace radar --release radar

このコマンドは、インストールの所有者、チャートとイメージ、エージェントの準備状況、Cloud の設定を報告します。接続トークンは表示されません。--namespace と --release の両方を指定すると、該当するインストールを正確に選択します。ライブトンネルのステータスは、参照先の Kubernetes Secret にあるトークンを使って Radar Cloud が報告します。Secret または Hub が利用できない場合も、ローカルのインストール診断は実行されます。対話型ターミナルでは控えめなステータスカラーが使われます。プレーンテキストで出力するには、NO_COLOR を設定するか、出力をパイプに渡してください。URL、トークン、推奨コマンドにはスタイルが適用されません。

CLI フラグ

次の表では、一般的な起動時フラグを紹介します。詳細はCLI リファレンス全文をご覧ください。インストール済みバージョンの正確な情報は radar --help で確認できます。

応答の遅いクラスターや高レイテンシのクラスター向けの調整

デフォルトのタイムアウト（コンテキスト切り替えは30 s、初回描画のバックストップは5 m、namespace の LIST は5 s、スコープ候補は20件）は、高速で低レイテンシの接続経由で到達できる健全なクラスター向けに調整されています。SSH トンネル経由で接続するクラスター、地理的に離れたコントロールプレーン、API サーバーのスロットリング対象となるアカウントでは短すぎるため、次のいずれかの症状が現れます。

• キャッシュが最終的に同期するにもかかわらず、「コンテキストの切り替えがタイムアウトしました」というトーストが表示される
• アカウントにクラスター全体を対象とする list 権限があるにもかかわらず、「限定表示 — RBAC で全 namespace の一覧表示が許可されていません」と表示される（RBAC ではなく、LIST がタイムアウトしています）
• 対象の namespace が候補数の上限20件を超えたため、種類が警告なくアクセス拒否としてマークされる

4つのフラグは CLI、または対応する環境変数（RADAR_CONTEXT_SWITCH_TIMEOUT、RADAR_FIRST_PAINT_BACKSTOP、RADAR_NAMESPACE_LIST_TIMEOUT、RADAR_MAX_SCOPE_CANDIDATES）で値を大きくしてください。環境変数を使うと ps にシークレットが表示されず、クラスター内デプロイでは ConfigMap から値を読み込めます。

# CLI
kubectl radar \
  --context-switch-timeout=120s \
  --first-paint-backstop=10m \
  --namespace-list-timeout=30s \
  --max-scope-candidates=200

# Environment (e.g. in a Deployment manifest)
RADAR_CONTEXT_SWITCH_TIMEOUT=120s \
RADAR_FIRST_PAINT_BACKSTOP=10m \
RADAR_NAMESPACE_LIST_TIMEOUT=30s \
RADAR_MAX_SCOPE_CANDIDATES=200 \
  kubectl radar

フラグも環境変数も設定されていない場合はデフォルト値が維持されるため、既存のデプロイには影響しません。

ビュー

トポロジー

Kubernetes リソースのリアルタイムな接続関係を表示するインタラクティブなグラフです。

トポロジービュー — リソース間の関係を可視化

• 2つのモード：リソース（階層全体）とトラフィック（ネットワークフローの経路）
• namespace、アプリのラベルでグループ化、またはグループ化せずに表示
• リソースの種類でフィルタリング — ノードをクリックすると詳細を表示
• ELK.js による自動レイアウト、SSE によるライブ更新

リソース

リソースの種類ごとに最適化された列を備える、テーブル形式のリソースブラウザーです。

リソースビュー — クラスターの全リソースを閲覧、フィルタリング

• CRD を含むすべてのリソースの種類を閲覧
• 名前で検索し、ステータスや問題（CrashLoopBackOff、ImagePullBackOff など）でフィルタリング
• 任意のラベルやアノテーションからカスタム列を追加 — 並べ替え、フィルタリング、サイズ変更が可能
• リソースをクリックすると、YAML マニフェスト、関連リソース、ログ、イベントを表示
• Deployment、StatefulSet、DaemonSet、Argo Rollouts の通常コンテナまたは init コンテナのイメージを設定し、テーブル、ドロワー、ワークロードビュー、Applications でロールアウトの進行状況をリアルタイムに確認

イメージファイルシステムビューアー

Pod ビューからコンテナイメージのファイルシステムを直接調査できます。イメージをローカルにプルしたり、コンテナ内で exec を実行したりする必要はありません。

イメージファイルシステムビューアー — コンテナイメージの内容を閲覧

• Pod 内のコンテナイメージをクリックして、ファイルシステム全体を閲覧
• ファイルサイズ、アクセス権限、シンボリックリンクの参照先を表示するツリービュー
• イメージ全体からファイル名で検索
• 個々のファイルをダウンロードして調査
• 公開イメージ（Docker Hub、Quay、GHCR）と、クラスターの ImagePullSecrets を使用したプライベートレジストリ（GCR、ECR、ACR）に対応
• ディスクベースのレイヤーキャッシュにより、繰り返しのアクセスを高速化

タイムライン

Kubernetes のイベントとリソースの変更を統合したタイムラインです。

タイムラインビュー — クラスターのアクティビティをリアルタイムで追跡

• イベントの種類でフィルタリング（すべて、または警告のみ）
• リソース変更の差分で変更内容（レプリカ数、イメージなど）を表示
• 新しいイベントの発生に応じてリアルタイムに更新

Helm

クラスターにデプロイされたHelmリリースを管理できます。値やレンダリング済みマニフェストの確認、リビジョン間の差分表示、アップグレードの失敗や失敗後のロールバックパターンの特定、失敗したフックの診断、アップグレード、ロールバック、アンインストールが可能です。Radarは、設定済みのリポジトリまたは独自のOCIレジストリから利用可能なチャートのアップグレードを追跡し、対象バージョンを指定して選択できます。詳しい動作と制限については、Helm Supportを参照してください。

Helmビュー — Helmデプロイメントを管理

• ステータス、チャートバージョン、アプリバージョン、リソースの健全性、ストレージの名前空間、Fluxの所有権とともに、すべての名前空間にまたがるリリースを表示します
• 値の確認、値／マニフェスト／ノート／リソースにわたるリビジョンの比較、リリース履歴の表示ができます
• 失敗したアップグレード、保留中のまま進まない操作、ロールバック履歴、推定されたアトミック形式のロールバックを表示します
• 失敗または実行中のフックと、残存するJob、Pod、Event、編集済みログの証拠を関連付けます
• UIから直接、リリースのアップグレード、ロールバック、アンインストールができます

リソースの比較

同じ種類のKubernetesリソースを任意の2つ選び、並べて差分を確認できます。たとえば、ステージング環境のDeploymentを本番環境のものと比較したり、同一であるはずなのに異なる2つのPodを比較したりできます。

比較ビュー — フィールド単位で強調表示されるYAML差分を並べて表示

• 2つの起点：リソース詳細ドロワーのCompareボタン、またはリソーステーブルの比較モード（切り替えて2行を選択し、Compareをクリック）
• 並列表示または統合表示を切り替えられ、ワンクリックでAとBを入れ替えられます
• 差分のみモードでは変更のない範囲を折りたたみ、異なる箇所だけを表示します
• Specのみモードではstatusフィールドを除外し、観測された状態ではなく意図に焦点を当てます
• サーバーによって割り当てられるノイズ（managedFields、resourceVersion、kubectl.kubernetes.io/last-applied-configuration）は自動的に除去され、差分から意味のある情報を見つけやすくします。確認する必要がある場合は、Raw metadataをオンにしてください
• ピッカーでは同じ名前空間の候補が最初に表示されます。通常、比較対象として求めているリソースが見つかります
• 共有可能なURL：/compare?kind=&apiGroup=&a=ns/name&b=ns/name

リソーステーブルの比較モード — 2行を選択してCompareをクリック

TLS証明書の管理

すべての名前空間にわたるTLS証明書の詳細と有効期限を確認でき、証明書の期限切れによる障害を未然に防げます。

• TLS Secretを解析し、証明書のサブジェクト、発行者、有効期間を表示します
• ダッシュボードで証明書の有効期限を一覧できます
• TLSタイプのSecretなら、どのリソースでも詳細ビューから確認できます

GitOps

FluxCD と ArgoCD のリソースを一か所で監視、診断、管理できます。

GitOps のフリートビュー — Argo と Flux のアプリケーションを横並びで表示し、同期、健全性、ソース、宛先、ライフサイクル状態を確認できます

• ArgoCD（Application、ApplicationSet、AppProject）と FluxCD（GitRepository、OCIRepository、HelmRepository、Bucket、Kustomization、HelmRelease、Alert）のフリートビューとアプリごとの詳細ページ（Topology／Changes／Activity タブ）
• 診断パイプライン — フィールド単位の差分、リソースごとの最近のイベント、解消されない差分のループ検出、解析済みの操作失敗、ワンクリックで実行できる構造化された修復
• ライフサイクルの把握 — 古い Sync／Health バッジの代わりに Terminating チップを表示し、削除経過時間に応じて重大度を引き上げ、ゾンビリソースに対する変更操作を拒否します
• Radar の他の機能から相互にリンク — リソースのドロワーに Managed by チップを表示し、Topology、Timeline、Helm ビューから GitOps に移動でき、Flux ソース CR に Consumed by パネルを表示します
• MCP 統合 — manage_gitops から、ライフサイクル状態に応じて実行を拒否する同期／一時停止／再開／調整／ロールバックを利用できます

機能の一覧、RBAC の要件、デモクラスター、単一クラスターの対象範囲に関する注意事項については、GitOps ガイドを参照してください。

トラフィック

Hubble、Caretta、Istio、または Beyla を使って、サービス間のリアルタイムのネットワークトラフィックを可視化します。

トラフィックビュー — サービス間の通信をリアルタイムで確認できます

• トラフィックデータソースとして、Hubble（Cilium）、Istio、Caretta、Grafana Beyla を自動検出します
• Beyla（単独、または Grafana Alloy 経由）は、サービスメッシュなしで eBPF による L4 と HTTP の可視性を提供し、Prometheus から読み取ります
• Beyla では network 機能を有効にする必要があります。また、ポートごとのエッジを表示するには、attributes.select で dst.port と transport も指定する必要があります。どちらもデフォルトでは無効であり、Radar は一部のエッジを黙って表示するのではなく、トラフィックビューでその旨を示します
• サービス間の 1 秒あたりのリクエスト数を示す、アニメーション付きのフローグラフ
• 名前空間、プロトコル、またはステータスコードで絞り込めます
• 大規模クラスター向けに設計されています。非表示のトラフィックはデータソース側で絞り込まれ、更新ごとに最新フローの件数を上限内に保ち、その表示範囲を示します。また、フローリストでは選択したノードまたはエッジの背後にあるレコードを取得します
• Hubble のトラフィックは Pod ごとではなく、ワークロード（Deployment、StatefulSet など）ごとに描画されます。フローリストには Pod が表示されます。レイアウトできないほど大きなマップでは、接続を一覧表示し、障害を先に示して、範囲を絞り込む方法も提示します
• ワークロードにフォーカスすると（/、ノードの詳細、またはトラフィックソースの検出後にそのページに表示される Live traffic）、そのワークロードと通信先だけを確認できます。フォーカスは URL に含まれるため、共有できます
• トラフィックソースが検出されない場合は、セットアップウィザードからインストールできます

ワークロードのメトリクス

Deployment、StatefulSet、または DaemonSet の Metrics タブを開くと、リクエストレート、HTTP エラー、レイテンシ、CPU、メモリ、スロットリングを調査できます。Radar は既存の Prometheus 互換バックエンドを読み取ります。リソースのグラフには HTTP の計装は不要で、リクエストのグラフにはサポート対象の Beyla または Istio の観測データを使用します。

• メトリクスと所有者情報が保持されている場合、ワークロードの履歴には過去のレプリカも含まれます
• 現在の Pod を比較して、リソース使用量の外れ値を特定できます
• データの自動検出と識別チェックを行い、欠落または一部のみのデータには明示的なラベルを付けます

スクリーンショット、前提条件、サポート対象の構成、ローカルでのマルチクラスター設定の制限事項については、ワークロードのメトリクスを参照してください。

容量（Karpenter）

Karpenter が管理するフリートを読み取り専用で診断します。ポッドが Pending になっている理由、ポッドを受け入れられる NodePool、ノードが参加できない理由、フリートに対するディスラプションの影響を確認できます。Karpenter の NodePool が検出されると自動的に表示されます（RBAC による制御）。

• 概要 — クレームのライフサイクル詳細を含むフリート KPI、クラスターのスケジューリング容量バー（リクエストと割り当て可能量、範囲を超えて進行中の処理、スケール対象として誤解を招かない Pending 需要数）、優先順位付けされた運用シグナル、NodePool インベントリ
• NodePool の詳細 — 容量台帳（設定済み上限、プロビジョニング済み、余力、割り当て可能量、スケジュール済みリクエスト、未割り当て、実際の使用量）、クレームのライフサイクル、フリートの構成、ワークロードへの帰属
• 需要 — スケジューリングのシグネチャごとにグループ化された Pending ポッド。各グループをすべての NodePool の宣言済み制約と照合し、述語ごとの根拠を表示します。状態、プール、ワークロードで絞り込めます
• アクティビティ — Karpenter の正確なイベント語彙に基づいて分類されたプロビジョニング／ディスラプション／中断のエピソードと、根拠ごとの確信度
• すべての数値に値ごとの確実性（= ≥ ≤ ?）が示されます。利用できない値がゼロとして表示されることはなく、部分的な値が正確な値として表示されることもありません
• Issues、Pending ポッドのドロワー、Home の状態カードから、該当する診断に直接移動できます

詳しくはdocs/capacity.mdをご覧ください。

コスト分析

PromQL 互換バックエンドの OpenCost メトリクス、または Kubecost 3 Aggregator から Kubernetes の支出を追跡します。 自動モードでは、利用可能な Prometheus コストメトリクスを優先し、その後ローカルの Kubecost Aggregator を検出します。エージェントのみを実行するフェデレーション済みクラスターでは、Settings、設定、または Helm で中央 Aggregator の URL を指定できます。Radar は、利用可能な場合、稼働中の OpenCost または Kubecost ワークロードから設定済みの通貨を読み取り、そうでない場合は USD を使用します。ソースの変更は表示通貨の設定とは別にテストして適用できます。ソースが利用できない場合でも、表示通貨の設定は保存できます。Radar は値に通貨を表示しますが、換算は行いません。

• 割り当て済みワークロードコストを、クラスター全体のノード容量コストとは別に示す名前空間スコープ
• Prometheus の履歴が利用可能な場合、6h／24h／7d の期間セレクターを備えたコスト推移チャート
• 効率スコア付きの名前空間およびワークロードレベルのコスト内訳
• インスタンスタイプとリージョンの価格情報を含むノードコスト
• 互換性のある Prometheus メトリクス、または Kubecost の現在の割り当てデータが検出されると自動的に表示されます

クラスター監査

セキュリティ、信頼性、効率性を対象とする 44 項目のチェックを備えた、ベストプラクティスのプロアクティブなスキャナーです。Polaris、Kubescape、Trivy、NSA/CISA のガイドラインに着想を得ています。クラスター側に何もインストールせず、キャッシュされたデータに対して即座に実行できます。

• セキュリティ：特権コンテナー、権限昇格、危険または安全でないケイパビリティ、ホスト名前空間、コンテナーランタイムソケットのマウント、機密性の高いホストパス、ConfigMap 内のシークレット、自動マウントされるサービスアカウントトークン
• 信頼性：プローブの欠落、イメージタグ latest、レプリカが単一のデプロイメント、PDB／トポロジー分散の欠落、ポッドの HA リスク（すべてのレプリカが同じノード上にある）、孤立したサービス／Ingress、非推奨の API バージョン
• 効率性：CPU／メモリーのリクエストと制限の欠落、孤立した ConfigMap／Secret、利用者が確認されていない PVC、Pending が長期間続いている PVC、保持されている、または削除に失敗している Released PV、Failed PV
• チェックごとにグループ化された修正キュー。検索と、カテゴリ、重大度、フレームワークによる絞り込みに対応します。チェックを展開すると、影響を受けるリソースを確認できます
• 各検出結果には説明と修正ガイダンスが含まれ、チェックまたはカテゴリをその場で非表示にできます
• 設定可能：無視する名前空間（ワイルドカードパターン対応）、無効にするチェック。設定はセッションをまたいで保持されます
• リソースごとのオプトアウトには radarhq.io/ignore-checks アノテーション（カンマ区切りのチェック ID）を使用します。検出結果の帰属先であるリソースに設定することで、除外設定が担当者個人のローカル設定ではなくマニフェストとともに移動します
• フレームワークのラベル：NSA/CISA、CIS ベンチマーク
• AI によるクラスター分析向けの MCP ツール（get_cluster_audit）

ネットワークパス診断

Service、Ingress、HTTPRoute、GRPCRoute、Gateway をホップ順に診断します - 「このリソースに向けてトラフィックを送信した場合、正常なプロセスに到達するか、到達しない場合はどのホップで最初に途切れるか」に答えます。

• Radar がすでに実行している各種検出 (バックエンド Service の欠落、ポートの不一致、準備完了エンドポイントなし、親 Gateway に Accepted されていないルート、誤ったポートを対象にした readiness プローブ) を、トラフィックの流れに沿ったパスの形に組み合わせます
• アップストリーム (Service を指す Ingress / Route) は独立して判定されます - 1 つの壊れた Ingress が他の配信パスを断罪することはありません
• 最初のクリティカルなホップが明示的に示されるため、オペレーターはリスト全体を読まなくてもどこで途切れているかを特定できます。各検出結果には kubectl の再現手順が付属します
• オプションのワンショット到達性テストは、宣言されたパスに対して DNS / TCP / TLS / HTTP プローブを実行します - Radar がクラスタ内にある場合は直接 TCP、ノート PC から実行している場合は K8s API サーバープロキシ経由 - これにより、Radar がどこで動作していても同じボタンが機能します。プローブが静的判定を上書きすることはありません。証拠を追加するだけです。
• 対象の Pod を選択する NetworkPolicy は、呼び出し元に依存しない ingress ルールについて静的に評価されます。パスのポートを許可するルールがない場合は「ブロックされる」という WARNING 予測、送信元が制限されている場合は注意喚起、アウトバウンド egress に関する注記が表示されます。これは予測であり、判定ではありません - 強制を担うのは CNI だけであるため、クラスタ内でのライブプローブがそれを確認または格下げします
• 静的トレースは、インメモリの informer キャッシュに対する純粋関数です。ノート PC からのアクティブプロービングはクラスタの通常の RBAC (get services/proxy、get pods/proxy) を使用し、クラスタ内モードではデータパスに直接アクセスします。
• リソース詳細ビューの Reachability タブから (また、AI コンシューマー向けには MCP の diagnose ツールのネットワークブランチから) 利用できます - docs/reachability.md を参照してください

Kubernetes アップグレードへの影響

コントロールプレーンをアップグレードする前に、Checks → Upgrade impact を開いてください。Radar は現在のクラスタを対象の Kubernetes マイナーバージョンと比較し、証拠に基づく互換性、ヘルス、アドミッション、ドレイン、ランタイム、構成のチェックを必要なアクション順に並べます。リリース固有のチェックは、その Kubernetes マイナーバージョンが選択したアップグレードパスに含まれる場合にのみ表示されます。現在のカタログは Kubernetes 1.37 までレビュー済みです。

• スキップされたマイナーバージョン、対象リリースで削除された API、サポートされていない kubelet または kube-proxy のスキューのほか、Kubernetes 1.36 で無効化された gitRepo ボリュームドライバー、削除またはロックされた Kubernetes 1.37 のフィーチャーゲートや scheduling.k8s.io/v1alpha2 オブジェクトといったブロッカーを検出します
• FlexVolume の露出や名称変更されたコントロールプレーンメトリクスといった運用上の影響が想定される項目を警告としてフラグ付けする一方、非推奨の Service externalIPs のような意図に依存する構成はレビュー対象のままにします
• ライブリソース、集約 API の可用性、Helm リリースマニフェスト、kubectl の最後に適用された構成、API サーバーの使用状況メトリクス、PrometheusRule 式を検査します
• 助言的な検出結果、想定される影響、欠落した証拠を 1 つの状態に平坦化するのではなく、Passed、Review、Warning、Blocked、Incomplete、Not applicable を区別します
• 現在のアイデンティティが読み取れるすべての namespace をスキャンします。ヘッダーの namespace ピッカーは閲覧用フィルターのままであり、アップグレード分析の範囲を狭めることはありません
• 同梱カタログの境界と、サンプリングまたは利用不可のデータに関する証拠の範囲を表示します

チェックカタログ、カバレッジのセマンティクス、RBAC に関する注意事項については、Kubernetes アップグレード影響ガイド を参照してください。

アクセス制御（RBAC の可視化）

3 回も kubectl describe を実行せずに、任意の ServiceAccount が実際にできることを確認できます。

• ServiceAccount の詳細：直接のバインディング、有効な権限（バインディングごとの表示と重複を排除した一覧表示）、暗黙のグループ（system:authenticated、system:serviceaccounts）を介して継承される権限、および「使用中の Pod」による確認
• Pod の詳細：Pod の SA が付与する最も広範なルールを表示する「権限」セクションに加え、SA にワイルドカード、cluster-admin、権限昇格の動詞、またはクラスタ全体を対象とする create pods がある場合の影響範囲アラート
• ワークロードの詳細（Deployment／StatefulSet／DaemonSet）：「権限」セクションをワークロード単位で表示します。ワークロードが起動するすべての Pod は、これらの権限を継承します
• Namespace の詳細：ここで設定されている RoleBinding と、Subject がこの Namespace を参照する ClusterRoleBinding を含む RBAC の概要
• Role／ClusterRole の詳細：この Role にバインドされている対象と、対象の概要をインライン表示
• RoleBinding の詳細：バインディングが付与するルールのインラインプレビューに加え、広範なグループ（system:authenticated、system:unauthenticated、system:masters）が対象に含まれる場合の警告
• 「自分の権限」パネル：現在のユーザーに対する、Namespace スコープのライブ SelfSubjectRulesReview。 「なぜ X を実行できないのか」の迅速なデバッグに役立ちます
• MCP：get_subject_permissions ツールを通じて、AI エージェントが同じデータを利用し、「この SA は過剰な権限を持っているか？」「侵害された場合の影響範囲は？」といった問い合わせができます

まず読み取り専用の可視化を提供します。検討中の追加機能（RBAC 監査チェック、動詞 × リソースのマトリックス、対象エクスプローラー、グラフ表示、UI 内編集、「can-i」クエリ）は #1090 で管理しています。

AI 連携（MCP）

Radar には、AI エージェント（Claude Code、Codex、Cursor、GitHub Copilot（VS Code および CLI）、OpenCode、Google Antigravity、その他すべての MCP クライアント）が Radar を通じてクラスターを調査、分析、操作できる、組み込みの Model Context Protocol（MCP）サーバーが含まれています。

生の kubectl 出力（LLM のコンテキストウィンドウを大量に消費する冗長な YAML）の代わりに、AI には事前処理され、トークン使用量が最適化されたデータが提供されます。トポロジーグラフ、ヘルス評価、重複排除されたイベント、フィルタリング済みログなどが含まれます。診断はデフォルトで読み取り専用です。オプションのクラスター内ルートプロービングでは、短期間で自動削除されるプローブ Pod を使用します。再起動、スケーリング、適用、ロールバックなどの書き込み操作は、クライアントによる確認が必要なものとして示され、Kubernetes RBAC によって制限されます。

デフォルトで有効です。--no-mcp ですべての MCP エンドポイントを無効にするか、 読み取り専用の MCP ツールのみを公開するには --mcp-read-only を指定して /mcp-readonly に接続します。 この設定は UI や REST API の書き込みを制限しません。設定方法と設定の優先順位については MCP ガイド を参照してください。

認証

クラスター内で共有するデプロイでは、Radar はユーザーごとの Kubernetes RBAC を用いた、オプションのユーザー認証をサポートしています。

• プロキシモード — oauth2-proxy、Pomerium、Cloudflare Access、または転送ヘッダーを設定する任意の認証プロキシで動作します
• OIDC モード — Google、Okta、Dex、Keycloak、または任意の OIDC プロバイダーを通じた組み込みログイン
• K8s の偽装機能を使用した、ユーザーごとの Namespace スコープ設定と書き込み権限の制御
• UI は自動的に適応し、ユーザーに RBAC 権限がある場合のみボタンが表示されます

デフォルトでは認証なし（ローカル利用）です。設定方法については 認証ガイド を参照してください。

サポート対象のリソース

Radar はクラスター内のあらゆる CRD を自動検出します。よく使われるツールには、トポロジーエッジ、詳細ビュー、AI による要約を備えた専用の統合機能があります。 デフォルトのチャート RBAC は、以下に挙げる組み込みの Kubernetes 種別（ワークロード、ネットワーク（NetworkPolicies と PodDisruptionBudgets を含む）、設定、ストレージ（PersistentVolumes、PersistentVolumeClaims、StorageClasses）、HorizontalPodAutoscalers、ServiceAccounts、LimitRanges、ResourceQuotas、Nodes、Namespaces、Events）を対象とします。Kubernetes 1.37 では、API サーバーが通知する場合、Radar は Workload、PodGroup、CompositePodGroup、PodCertificateRequest、ClusterTrustBundle の各 API も表示します。スケジューリング API は機能ゲートで制御されますが、証明書 API は安定版で、デフォルトで有効です。これらは専用のレンダラーではなく、汎用リソースブラウザーを使用します。RBAC オブジェクト（Roles、ClusterRoles、RoleBindings、ClusterRoleBindings）は、rbac.viewRBAC=true でオプトインできます。CRD ベースの統合（Gateway API、VerticalPodAutoscaler、Calico、ArgoCD、FluxCD、cert-manager など）には、クラスターへの CRD のインストールと、読み取りアクセスの付与の両方が必要です。ほとんどのグループは rbac.crdGroups.<name>（例：gatewayApi、verticalPodAutoscaler、calico）でデフォルト有効です。values.yaml を確認するか、rbac.additionalRules でカスタムルールを追加してください。

アップグレード影響の確認でも、対象の種別が提供されているクラスターでは、CSIStorageCapacities、FlowSchemas、PriorityLevelConfigurations、PodSecurityPolicies への一覧取得のみのアクセスが使用されます。これらの読み取りではソースマニフェストの証拠を確認しますが、Radar のリソースブラウザーに種別が追加されることはありません。

キーボードショートカット

トポロジー： パン（ドラッグ）、ズーム（スクロール）、選択（クリック）、複数選択（Shift+クリック）

セキュリティ

Radar はお客様自身の認証情報を使ってクラスターを読み取り、クラスターのデータはローカルに保持します。マニフェスト、ログ、イベント、メトリクス、リソースデータを Skyhook にアップロードすることはなく、アカウント、エージェント、クラウドバックエンドも必要ありません。脆弱性を見つけた場合は、[email protected] まで非公開で報告してください。手順と対応期間については SECURITY.md をご覧ください。

開発

ソースからのビルドとコントリビューションについては、**開発ガイド**をご覧ください。自動化とインテグレーションについては、HTTP API リファレンスをご覧ください。

クイックスタート：

git clone https://github.com/skyhook-io/radar.git
cd radar
make deps

# Terminal 1: Frontend with hot reload (port 9273)
make watch-frontend

# Terminal 2: Backend with hot reload (port 9280)
make watch-backend

コントリビューション

コントリビューションを歓迎します！開発ワークフロー、プルリクエストの手順、コーディング規約の詳細については、コントリビューションガイドをお読みください。

質問やアイデアがあれば、GitHub Discussionsをご利用ください。または、radarhq.io/communityにぜひお越しください。

概要

Radar は Skyhook（YC W23）が開発・保守しており、Apache-2.0 ライセンスのオープンソースです。OSS 版はすべての機能を利用でき、Radar の実行方法として推奨されています。

SSO と共有ダッシュボードを備えたホスト型のマルチクラスター Radar をお求めのチーム向けに、Radar Cloudも提供しています。

ライセンス

Apache 2.0 — LICENSEをご覧ください。

オープンソース。いつまでも無料。
_{Skyhookが開発}