K8s网络不通先查哪一跳?Radar网络路径诊断Reachability静态追踪+主动探测原理详解

K8s网络不通先查哪一跳?Radar网络路径诊断Reachability静态追踪主动探测原理详解【免费下载链接】radarThe missing open-source Kubernetes UI with a built-in MCP server for AI agents. See whats broken, why, and what changed. Issues, Topology, event timeline, Helm, GitOps, live service traffic, and cluster audits - all in one Go binary.项目地址: https://gitcode.com/gh_mirrors/radar32/radar当你遇到Kubernetes 网络不通时最痛苦的不是服务挂了而是不知道断在哪一跳——Ingress、Service、Endpoints、Pod任何一环都可能出问题。开源 Kubernetes UI 工具Radar的Reachability网络可达性网络路径诊断功能专门回答一个问题如果流量发往这个资源它能不能到达健康进程如果不能第一跳断在哪里Radar 是单二进制的开源 K8s UI内置拓扑、资源、Helm、GitOps、流量、审计与 MCP 服务器。Reachability 于 v1.9.1 引入支持 Service、Ingress、HTTPRoute/GRPCRoute、Gateway 四类网络入口资源官方文档见 docs/reachability.md。为什么 K8s 网络故障排查这么难传统排查方式是逐层kubectl getcurlDNS 解析了吗Ingress 有 backend 吗Service selector 匹配到 Pod 吗Pod Ready 了吗每一跳都要人肉确认。Radar 的做法是把整条路径画成一张按流量方向排列的跳hop图并给每一跳附上资源引用Kind / Namespace / Name与边标签如HTTPRoute → ServiceFindings复用 Radar 已有问题管道的检测结果挂到故障可观测的那一跳kubectl 复现命令每条 finding 都自带一条可直接粘贴的排查命令心智模型Upstream 并行Downstream 链式Radar 把路径分成两段判定逻辑完全不同方向结构判定规则Upstreams指向主体的入口并行多个 Ingress 各判各的只有全部 broken 才整体 brokenDownstream从主体向下的链路链式Service → 选中的 Pods第一个 critical 发现即brokenAt断点这意味着一个 Service 同时被 Ingress A 和 Ingress B 引用时A 坏了不代表 Service 坏了——B 还在正常送流量。下图展示了一个 Service 同时被 Ingress 和 HTTPRoute 两个入口引用的场景Radar 对每个入口独立判定右侧面板显示 HTTPRoute 未挂载到任何 listener原理详解静态追踪层永远在线静态层回答配置接对了吗实现在 internal/trace/trace.go纯函数跑在内存 informer 缓存上 零逐次 API 请求 · 零 RBAC 请求 · 零用户配置它检查每跳的 declared 配置 当前 Pod 状态端口是否存在如gwroute:backend-port-mismatchHTTPRoute 引用了不存在的 Service 端口、Gateway 路由的父条件AcceptedFalse/ResolvedRefsFalse、Pod 的 selected/ready 数量、headless 与无 selector 标记等。性能目标典型 100ms200 Pod 的 namespace 300ms打开 Reachability 标签页时 UI 每 5 秒轮询一次客户端缓存保证切页秒开。刻意不做的事保持可信不读 EndpointSlice——端点信号用 Pod readiness 近似并诚实标注endpointSource: pod-readinessNetworkPolicy 只预测、不裁决——CNI 才是唯一执行权威Radar 给出的是集群网络规则会拦截这些 Pod 的流量这类预测性警告不加新 CRD——一切来自 Radar 既有的 informer 缓存原理详解主动探测层DNS/TCP/TLS/HTTP 分层主动层回答真发一个请求哪层先失败。核心探测实现在 pkg/probe/probe.go每一层有严格超时高层成功严格蕴含低层成功层超时说明DNS250ms解析声明的主机名区分 split-horizon 场景TCP700ms直连 ClusterIP:port 或 PodIP:portTLS1sHTTPS 才走证书信任失败 ≠ 不可达HTTP1s仅 HTTP 形态端口非 HTTP 端口如 Redis 6379止步于 TCP总预算 3 秒各跳并行执行单个死跳不会拖垮整轮。打开标签页时自动跑一次代理视角探测Run test可重跑In-cluster Job 测试保持手动点击。关键设计探测目标必须来自集群声明的配置Service 端口、Ingress 地址、Gateway listener不接受用户随手输入的 URL同时内置 SSRF 防护拒绝直接探测回环地址、link-local 地址含云厂商 metadata 端点 169.254.169.254、100.100.100.100 等。一个 Ingress 主体的典型探测Radar 从你的机器拨打 Ingress 声明的主机名DNS → TCP → TLS → HTTP后端应答 308 重定向。注意顶部判定措辞的克制非 HTTP 服务与双协议端口Redis 这类非 HTTP 服务只验证到 TCP底部明确标注TCP connections only — application protocol not checked绝不冒充应用层可达kube-dns 在 53 端口同时声明 TCP 和 UDPRadar 把两条路径拆开TCP 可测UDP 保留为明示的缺口而不是悄悄吞掉观测点Vantage从哪打决定证明了什么这是 Radar 最核心的概念——探测结果脱离从哪发起毫无意义。界面围绕两个显式选择构建测哪条路径PATH 选择器每条声明路由一行从哪个观测点三种视角胶囊Radar on your machine作为客户端直拨API-server proxy经 K8s API 的/proxy/子资源中继In-cluster probe集群内一次性探针 Pod切换观测点会真正重绘路径图、重算判定——笔记本上的成功永远不会被画进 in-cluster 泳道。Radar 宁可说从这个视角无法确认也绝不给健康路径泼脏水。In-cluster 探针一次性自毁 Job 的安全模型集群内测试创建短命 Job 跑radar probe实现在 internal/reachability/runner.go。这是整个诊断面唯一的变更操作因此被重重设防防线细节RBAC 预检创建前逐项校验create jobs/list pods/get pods/log缺一项直接拒绝并给可复制的 kubectl 兜底命令Pod 规格non-root、只读根文件系统、drop ALL capabilities、不挂载 SA token生命周期25 秒 ActiveDeadline、60 秒 TTL 兜底清理、单次调用最多 5 个 Job镜像解析四级回退显式--reachability-image→ 自读 radar 自身运行镜像 →RADAR_IMAGE环境变量 → 版本匹配的公开镜像结果折叠探针 Pod 身份与真实客户端不同其失败只作信息参考绝不升级静态判定权限不足时 Radar 会降级为一条可直接复制执行的 kubectl 命令参数与 Job 完全一致而不是给你一个误导性结果。判定语义四种结论 结果可信度路由结果outcome滚动汇总为判定verdict判定触发条件healthy所有被测路由在真实流量上可达degraded5xx、部分路由失败、或良性 scale-to-0读作琥珀色而非红色broken真实路径上出现不可达unknown无法主动测试或仅经 API-server 代理可达——永不给自信的绿色每个路由还带独立的可信度real按真实流量方式测试可设定判定与indirect仅经 API-server 代理只标注、不置绿。把unknown当作暂停并调查信号——它意味着追踪无法诚实回答而不是一切正常。探针失败但业务正常先怀疑视角再怀疑工作负载配置健康但探测失败时常见四因均与负载本身无关Service mesh mTLSIstio/Linkerd网外探测无 mesh 证书TLS 层必失败——识别特征Pod 带istio-proxysidecar 或 mesh 标签。此时应信任集群内测试NetworkPolicy策略放行真实负载间流量、却拦了 Radar 的代理身份DNS split-horizon内部域名在你的笔记本上解析不出来探测以附原因的跳过呈现而非失败API-server 中继限制中继被拒或拨不到仅内部地址处理方式跑Test in-cluster从真实数据平面探测若真实流量确实被丢去 Traffic 视图的逐流面板看插件上报的原因与 NetworkPolicy 归因。小结Radar Reachability 的设计哲学可以浓缩为一句话把网络不通变成第一跳断在哪并且每个结论都带着它从哪个视角、用什么证据得出。静态追踪纯缓存函数永远在线回答配置是否正确接线主动探测DNS/TCP/TLS/HTTP 分层 3 秒预算回答真实请求走到哪层失败观测点一等公民笔记本 / API-server 中继 / 集群内探针三泳道互不污染安全边界RBAC 预检 自毁探针 Job 可复制 kubectl 兜底AI Agent 同样受益内置 MCP 服务器的通用diagnose工具对网络入口类资源直接返回这份路径化诊断传in_cluster: true可跑集群内探测一次调用拿到路径形状的答案。 更多资料官方功能文档docs/reachability.md静态路径追踪源码internal/trace/trace.go分层探测实现pkg/probe/probe.go集群内探针 Runnerinternal/reachability/runner.go多路由探针编排internal/reachability/incluster.go【免费下载链接】radarThe missing open-source Kubernetes UI with a built-in MCP server for AI agents. See whats broken, why, and what changed. Issues, Topology, event timeline, Helm, GitOps, live service traffic, and cluster audits - all in one Go binary.项目地址: https://gitcode.com/gh_mirrors/radar32/radar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考