Kubeshark Kubernetes 网络事件调查

要解决什么问题

Kubernetes 里的网络故障往往没有直接的报错：Pod 连不上 Service、跨命名空间调用偶发超时、某个 Pod 突然被判定不健康，但 kubectl logs 和 Events 里什么都看不出来。因为问题发生在数据包层面——DNS 解析异常、TCP 重传、TLS 握手失败、HTTP 请求体被截断——这些信息默认不会留在任何日志里。

当你需要回答"A 服务到底向 B 发送了什么""这条请求链路在哪里断掉"时，通常得手动在节点上抓包、翻 ingress 日志，再对着拓扑图猜。这个技能要缩短这一步：直接查询集群的实时与历史流量，拿到数据包级别的证据。

技能如何工作

核心依赖是 Kubeshark 的 MCP 服务器。Kubeshark 已经部署在目标集群中，负责持续采集并索引工作负载之间的流量；技能通过 MCP 兼容客户端把查询能力暴露出来，让 Agent 可以按条件检索流量记录。

典型排查路径：

• 定位通信关系：先看集群中工作负载的连接拓扑，确认依赖关系、流量规模和协议使用情况
• 还原请求链路：针对可疑的服务路径，拉取经过该路径的历史流量，检查请求与响应的完整内容
• 检查 API 负载：直接查看请求体与响应体，验证是否出现了字段缺失、错误状态码或畸形报文
• 对比时间线：把流量异常的时间点与工作负载的重启、配置变更事件对齐

适用边界与注意点

• 前提是集群中已经部署了 Kubeshark，并且客户端支持 MCP；没有采集端，查询不会返回数据
• 事件响应场景适合 packet-level 取证；日常健康检查这类轻量需求，可能不值得为此引入整套流量采集
• 历史流量的保留时长取决于 Kubeshark 的部署配置，超出窗口的早期事件无法回溯
• 采集开销与集群规模相关，大集群中建议先明确查询范围，避免全量拉取带来额外负载

详细参数与协议说明见 Kubeshark MCP 文档：https://docs.kubeshark.com/en/mcp。