Radar Kubernetes MCP Server

Radar

缺失已久的开源 Kubernetes UI。
单个二进制文件。无需账户。永久免费。

🌐 radarhq.io · 文档 · 发布版本

拓扑、资源、Helm、GitOps、流量、审计、升级影响，以及为 AI Agent 提供的 MCP 上下文——可在笔记本电脑上使用，也可在集群内部署。

30 秒内完成安装并运行：

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

更多安装选项 ↓

为什么选择 Radar？

• 集群上零安装 — 在笔记本电脑上运行，直接与 K8s API 通信
• 单个二进制文件 — 无依赖、无 Agent、无 CRD
• 适用于大型集群 — 已在数万个 Pod 的集群上测试，视图响应迅速，并可在集群实际变化时实时更新
• 设计上注重隐私 — 集群数据留在你的设备上。无需账户、无需 Agent、无需云同步。除非你选择启用，否则不会报告使用情况；启用后也只会发送匿名使用次数和粗略的集群信息：Kubernetes 版本、平台、节点数量范围、已知集成（Radar 会发送哪些信息）
• 适合隔离网络环境 — 作为单个二进制文件通过 Kubernetes API 运行，也适用于阻止出站流量的受限环境
• 实时运行 — 通过 informer 监视集群，并通过 SSE 将更新推送到浏览器
• 适用于各种环境 — GKE、EKS、AKS、minikube、kind、k3s，或任何符合规范的集群
• 为 AI 做好准备 — 内置的 MCP 服务可让 AI Agent 通过 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 和直接下载使用 kubectl radar，除非你自行添加 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

该命令会报告安装归属、Chart 和镜像、Agent 就绪情况以及 Cloud 配置，但不会打印连接令牌。同时传入 --namespace 和 --release 可指定精确的安装。Radar Cloud 会使用所引用 Kubernetes Secret 中的令牌报告实时隧道状态。如果 Secret 或 Hub 不可用，仍会运行本地安装诊断。交互式终端会使用克制的状态颜色；设置 NO_COLOR（或通过管道传递输出）即可显示纯文本。URL、令牌和建议的命令不会添加样式。

CLI 标志

下表介绍了常见的启动标志。请参阅 CLI 完整参考；对于已安装的版本，radar --help 是权威依据。

针对缓慢或高延迟集群进行调优

默认超时时限（上下文切换 30 s、首次渲染兜底 5 m、命名空间 LIST 5 s、范围候选项 20 个）针对通过快速、低延迟连接访问的健康集群进行了调优。对于通过 SSH 隧道访问的集群、地理位置遥远的控制平面，或受 API 服务器限流影响的账号，这些时限过短，会导致以下三种症状之一：

• 缓存最终确实完成同步，但仍弹出“上下文切换超时”提示
• 即使账号拥有集群范围的列表权限，也会显示“列表受限 — RBAC 不允许列出所有命名空间”（实际上是 LIST 超时，而不是 RBAC 问题）
• 命名空间超出 20 个候选项的上限，其所属的资源类型会被静默标记为拒绝访问

可通过 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 资源之间的连接关系。

拓扑视图 — 可视化资源关系

• 两种模式：资源（完整层级结构）和流量（网络流路径）
• 按命名空间、应用标签分组，或选择不分组
• 按资源类型筛选 — 点击任意节点查看完整详情
• 由 ELK.js 驱动自动布局，通过 SSE 实时更新

资源

基于表格的资源浏览器，可根据资源类型智能显示列。

资源视图 — 浏览并筛选所有集群资源

• 浏览所有资源类型，包括 CRD
• 按名称搜索，按状态或问题筛选（CrashLoopBackOff、ImagePullBackOff 等）
• 从任意标签或注解添加自定义列 — 支持排序、筛选和调整大小
• 点击任意资源即可查看 YAML 清单、相关资源、日志和事件
• 在 Deployments、StatefulSets、DaemonSets 和 Argo Rollouts 上设置常规容器或初始化容器的镜像，并在表格、抽屉、工作负载视图和 Applications 中查看实时发布进度

镜像文件系统查看器

直接从 Pod 视图检查容器镜像的文件系统 — 无需在本地拉取镜像，也无需进入容器执行命令。

镜像文件系统查看器 — 浏览容器镜像内容

• 点击 Pod 中的任意容器镜像，即可浏览其完整文件系统
• 树状视图显示文件大小、权限和符号链接目标
• 按名称搜索整个镜像中的文件
• 下载单个文件以供检查
• 支持使用集群的 ImagePullSecrets 访问公共镜像（Docker Hub、Quay、GHCR）和私有镜像仓库（GCR、ECR、ACR）
• 基于磁盘的层缓存，可加快重复访问速度

时间线

统一展示 Kubernetes 事件和资源变更的时间线。

时间线视图 — 实时跟踪集群活动

• 按事件类型筛选（全部或仅警告）
• 显示资源变更差异，指出具体变更内容（副本数、镜像等）
• 新事件发生时实时更新

Helm

管理集群中部署的 Helm 发行版 — 查看 Values 和渲染后的清单、对比修订版本、识别升级失败和失败后回滚模式、诊断失败的钩子，以及升级、回滚和卸载。Radar 会跟踪可用的图表升级（来自已配置的仓库或你自己的 OCI 注册表），并允许你选择特定的目标版本。详细行为和限制请参阅 Helm 支持。

Helm 视图 — 管理 Helm 部署

• 查看所有命名空间中的发行版，包括状态、图表版本、应用版本、资源健康状况、存储命名空间和 Flux 归属
• 检查 Values，对比 Values、清单、注释和资源的修订版本，并查看发行版历史记录
• 显示升级失败、操作卡在待处理状态、回滚历史记录和推断出的原子式回滚
• 将失败或正在运行的钩子与剩余的 Job、Pod、Event 及脱敏日志证据关联起来
• 直接在 UI 中升级、回滚或卸载发行版

比较资源

并排比较任意两个同类型的 Kubernetes 资源 — 例如比较预发布环境中的 Deployment 与其生产环境对应项，或比较两个本应相同却并不相同的 Pod。

比较视图 — 并排显示 YAML 差异并突出显示字段级差异

• 两种入口：资源详情抽屉中的 Compare 按钮，或资源表格中的比较模式（切换模式、选择两行，然后点击 Compare）
• 并排或统一视图，可一键交换 A ↔ B
• 仅显示差异模式会折叠未更改的区域，让你只看到差异
• 仅显示 Spec 模式会移除 status 字段，让你关注期望状态而非观测到的状态
• 自动剔除服务器分配的噪声（managedFields、resourceVersion、kubectl.kubernetes.io/last-applied-configuration），让差异聚焦于有效信息 — 如果确实要查看这些内容，可启用原始元数据
• 选择器会优先显示同一命名空间中的候选资源 — 通常这就是你要比较的资源
• 可分享的 URL：/compare?kind=&apiGroup=&a=ns/name&b=ns/name

资源表格中的比较模式 — 选择两行，然后点击 Compare

TLS 证书管理

查看所有命名空间中的 TLS 证书详情和到期日期 — 在证书到期导致服务中断之前及时发现。

• 解析 TLS Secret，显示证书主题、颁发者和有效期
• 在仪表板级别概览证书到期情况
• 可从任何 TLS 类型 Secret 的资源详情视图中使用

GitOps

在一处监控、诊断和管理 FluxCD 与 ArgoCD 资源。

GitOps 机群视图 — 并排查看 Argo + Flux 应用，以及同步、健康状况、来源、目标和生命周期状态

• 机群视图 + 单个应用详情页（Topology / Changes / Activity 标签页），适用于 ArgoCD（Application、ApplicationSet、AppProject）和 FluxCD（GitRepository、OCIRepository、HelmRepository、Bucket、Kustomization、HelmRelease、Alert）
• 诊断流程 — 字段级差异、每个资源的近期事件、卡住的差异循环检测、解析后的操作失败信息，以及结构化的一键修复
• 生命周期感知 — Terminating 标记会取代过时的 Sync/Health 徽标；严重程度随删除时间递增；对僵尸资源拒绝执行变更操作
• 与 Radar 其他部分交叉关联 — 资源抽屉中的 Managed by 标记、从 Topology + Timeline + Helm 视图跳转到 GitOps，以及 Flux 源 CR 上的 Consumed by 面板
• MCP 集成 — manage_gitops 提供 sync / suspend / resume / reconcile / rollback 操作，并会感知生命周期状态并拒绝不适用的操作

请参阅 GitOps 指南，了解完整的功能矩阵、RBAC 要求、演示集群和单集群范围说明。

流量

使用 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 会在流量视图中说明这一点，而不会悄然显示不完整的边
• 使用动画流量图显示服务之间每秒的请求数
• 按命名空间、协议或状态码筛选
• 专为大型集群打造：在数据源处过滤隐藏流量，每次刷新保留数量有上限的最新流量，并说明涵盖的时间范围；流量列表会获取所选节点或边背后的记录
• Hubble 流量按工作负载（Deployment、StatefulSet 等）绘制，而非按 Pod 绘制；流量列表仍保留 Pod 信息。对于过大而无法布局的图，会列出其中的连接，优先显示失败连接，并提供缩小范围的方法
• 聚焦某个工作负载（/、节点详情，或检测到流量源后其页面上的 Live traffic），即可只查看该工作负载及其通信对象；聚焦信息位于 URL 中，可供分享
• 如果未检测到流量源，设置向导会引导安装

工作负载指标

打开 Deployment、StatefulSet 或 DaemonSet 的 Metrics 标签页，排查 请求速率、HTTP 错误、延迟、CPU、内存和限流情况。Radar 会读取现有的 兼容 Prometheus 的后端；资源图表不需要 HTTP 检测，且请求图表使用受支持的 Beyla 或 Istio 观测数据。

• 工作负载历史会在保留指标和所有权信息时包含之前的副本
• 对比当前 Pod，找出资源异常值
• 自动发现并检查身份信息，明确标注缺失或不完整的数据

请参阅工作负载指标，了解截图、先决条件、 支持的配置以及本地多集群设置的限制。

容量（Karpenter）

针对由 Karpenter 管理的集群进行只读诊断——为什么我的 Pod 处于 Pending 状态，哪个 NodePool 可以接纳它，为什么我的节点没有加入，干扰事件对我的集群有什么影响？检测到 Karpenter NodePool 时会自动显示（受 RBAC 控制）。

• 概览 — 集群 KPI，包含声明生命周期详情、集群调度容量条（请求量与可分配量、超出边界的进行中容量、如实显示且不按比例缩放的待处理需求）、按优先级排列的运维信号，以及 NodePool 清单
• NodePool 详情 — 容量账本（配置上限、已供给容量、余量、可分配容量、已调度请求、未分配容量、实际使用量）、声明生命周期、集群组成和工作负载归因
• 需求 — 按调度签名分组的待处理 Pod；针对每个 NodePool 声明的约束评估每组 Pod，并提供逐项谓词证据；可按状态、池和工作负载筛选
• 活动 — 根据 Karpenter 的精确事件词汇对供给、干扰和中断事件分类，并为每项证据标注置信度
• 每个数量都带有逐值确定性标记（= ≥ ≤ ?）——不可用时绝不显示为零，不完整时绝不显示为精确值
• 问题、待处理 Pod 抽屉和主页状态卡片均可直接链接到相应诊断

完整参考请参阅 docs/capacity.md。

成本洞察

通过 PromQL 兼容后端中的 OpenCost 指标或 Kubecost 3 Aggregator 跟踪 Kubernetes 开支。 自动模式会继续使用可用的 Prometheus 成本指标，随后发现本地 Kubecost Aggregator；仅运行联邦 Agent 的集群可在设置、配置或 Helm 中使用其中央 Aggregator URL。Radar 会在运行中的 OpenCost 或 Kubecost 工作负载可用时读取其配置的货币，否则使用 USD。数据源变更会单独测试和应用，与显示货币偏好分开；即使数据源不可用，也可以保存货币偏好。Radar 会标注数值，但不会进行换算。

• 已分配的工作负载成本，并单独标明命名空间范围的成本与集群范围的节点容量成本
• Prometheus 历史数据可用时，提供带 6h/24h/7d 范围选择器的成本趋势图
• 命名空间和工作负载级别的成本明细，并提供效率评分
• 节点成本，包含实例类型和区域定价
• 检测到兼容的 Prometheus 指标或 Kubecost 当前分配数据时自动显示

集群审计

主动式最佳实践扫描器，涵盖安全性、可靠性和效率方面的 44 项检查，灵感来自 Polaris、Kubescape、Trivy 以及 NSA/CISA 指南。使用缓存数据即时运行，无需在集群侧安装任何内容。

• 安全性：特权容器、权限提升、危险/不安全能力、主机命名空间、容器运行时套接字挂载、敏感主机路径、ConfigMaps 中的 Secrets、自动挂载的服务账号令牌
• 可靠性：缺少探针、镜像标签为 latest、单副本 Deployment、缺少 PDB/拓扑分布约束、Pod 高可用风险（所有副本都位于同一节点）、孤立的 Service/Ingress、已弃用的 API 版本
• 效率：缺少 CPU/内存请求和限制、孤立的 ConfigMaps/Secrets、未观察到消费者的 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、端口不匹配、没有就绪端点、Route 未被父 Gateway 接受、就绪探针指向错误端口）整合为沿流量路径排序的路径视图
• 独立判断上游资源（指向 Service 的 Ingress / Route）——一个故障的 Ingress 不会导致其他流量路径也被判定为故障
• 明确指出首个关键跳，帮助操作者快速定位故障，无需通读整个列表；每条发现都附带一个 kubectl 复现命令
• 可选的一键可达性测试会针对声明的路径运行 DNS / TCP / TLS / HTTP 探测——Radar 在集群内时直接进行 TCP 连接，从笔记本电脑运行时则使用 K8s API server 代理——因此无论 Radar 在何处运行，同一按钮都能正常工作。探测结果不会覆盖静态判定，只会补充证据。
• 对选中目标 Pod 的 NetworkPolicy 进行静态评估，检查与调用方无关的入站规则：如果没有规则允许路径所用端口，则给出“可能阻止”的 WARNING 预测；也可能给出来源限制提示或出站流量说明。这只是预测，而非判定——只有 CNI 才有最终执行权，因此实时集群内探测会确认或降低该预测的可信度
• 静态追踪是针对内存中 informer 缓存运行的纯函数。从笔记本电脑进行主动探测时，使用集群的常规 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 版本偏差、重叠的 PodDisruptionBudget、Kubernetes 1.36 中禁用的 gitRepo 卷驱动，以及 Kubernetes 1.37 中已移除或被锁定的功能门控或 scheduling.k8s.io/v1alpha2 对象
• 将 FlexVolume 暴露风险和控制平面指标重命名等可能造成运维影响的问题标记为警告；而将依赖使用意图的配置（例如已弃用的 Service externalIPs）标记为需审核
• 检查实时资源、聚合 API 可用性、Helm 发布清单、kubectl 上次应用的配置、API server 使用指标和 PrometheusRule 表达式
• 区分 Passed、Review、Warning、Blocked、Incomplete 和 Not applicable，而不是将建议性发现、可能的影响和缺失的证据混为一种状态
• 扫描当前身份有权读取的所有命名空间；页眉中的命名空间选择器仍仅用于浏览筛选，不会缩小升级分析范围
• 显示内置目录的边界，以及抽样或不可用数据的证据范围

有关检查目录、覆盖范围说明和 RBAC 注意事项，请参阅 Kubernetes 升级影响指南。

访问控制（RBAC 可见性）

查看任何 ServiceAccount 实际能执行哪些操作——无需连续执行三次 kubectl describe。

• ServiceAccount 详情：直接绑定、有效权限（按绑定展示，以及去重后的平铺视图）、通过隐式组继承的授权（system:authenticated、system:serviceaccounts），以及用于完整追踪的“被 Pod 使用”
• Pod 详情：“权限”部分展示 Pod 的 SA 授予的最宽泛规则；如果 SA 拥有通配符、cluster-admin、权限提升动词或集群范围的 create pods 权限，则显示爆炸半径警告
• 工作负载详情（Deployment / StatefulSet / DaemonSet）：“权限”部分同样展示权限，但从工作负载层面呈现——该工作负载创建的每个 Pod 都会继承这些授权
• 命名空间详情：RBAC 摘要，包含在此处配置的 RoleBindings，以及主题引用此命名空间的 ClusterRoleBindings
• Role / ClusterRole 详情：绑定到此角色的对象，并在行内显示主题摘要
• RoleBinding 详情：行内预览此绑定授予的规则；当主题包含宽泛的组（system:authenticated、system:unauthenticated、system:masters）时显示警告
• “我的权限”面板：针对当前用户的命名空间范围实时 SelfSubjectRulesReview，便于快速排查“为什么我无法执行 X”
• MCP：get_subject_permissions 工具向 AI Agent 提供相同数据，用于查询“这个 SA 是否权限过高？”/“遭到入侵时的爆炸半径有多大？”

首先提供只读可见性；后续考虑加入的功能（RBAC 审计检查、动词 × 资源矩阵、主题浏览器、关系图视图、界面内编辑、“can-i”查询）已在 #1090 中跟踪。

AI 集成（MCP）

Radar 内置了 Model Context Protocol（MCP）服务，让 AI Agent——Claude Code、Codex、Cursor、GitHub Copilot（VS Code 和 CLI）、OpenCode、Google Antigravity 以及任何其他 MCP 客户端——能够通过 Radar 检查、调查和操作你的集群。

AI 获得的不是原始 kubectl 输出（冗长的 YAML 会迅速耗尽大模型的上下文窗口），而是经过预处理和令牌优化的数据：拓扑图、健康评估、去重后的事件和经过筛选的日志。诊断默认只读；可选的集群内路由探测会使用短暂运行且会自行删除的探测 Pod。重启、扩缩容、应用和回滚等写入操作会标记为需要客户端确认，并通过 Kubernetes RBAC 强制执行。

默认启用。使用 --no-mcp 禁用所有 MCP 端点，或使用 --mcp-read-only 仅开放 只读 MCP 工具，并连接到 /mcp-readonly。 此设置不会限制 UI 或 REST API 的写入操作。有关设置和配置优先级，请参阅 MCP 指南。

身份验证

对于共享的集群内部署，Radar 支持可选的用户身份验证，并为每位用户单独应用 Kubernetes RBAC。

• 代理模式——支持 oauth2-proxy、Pomerium、Cloudflare Access，或任何会设置转发标头的身份验证代理
• OIDC 模式——内置登录支持 Google、Okta、Dex、Keycloak 或任何 OIDC 提供方
• 通过 K8s impersonation 实现按用户限定命名空间范围和写入授权
• 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 已稳定，默认启用。这些 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，也不需要账户、Agent 或云后端。发现漏洞？请通过 [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 的推荐方式。

对于希望使用托管式多集群 Radar，并需要 SSO 和共享仪表板的团队，我们还提供 Radar Cloud。

许可证

Apache 2.0 — 请参阅 LICENSE

开源，永久免费。
_{由 Skyhook 构建}