本文介绍了Kubernetes网络可观测性工具Kubeshark的安装与实战，重点讲解通过Helm快速部署、API Stream和KFL查询语言的使用，以及在生产环境中收窄采集范围的建议，帮助运维人员直接查看服务调用与流量细节，提升排障效率。
QUOTE
Kubeshark 最好的地方，不是让排障变得自动化，而是先把证据摊开。
—— python运维技术
最近看了一个 Kubernetes 网络可观测性工具，叫 Kubeshark。
如果你平时排过 Kubernetes 里的服务调用问题，应该能理解这种感觉：日志里看起来没什么，指标里只看到延迟变高，链路追踪又不一定每个服务都接好了。
最后只能一边 kubectl logs，一边猜请求到底走到了哪里。
Kubeshark 解决的就是这一段问题。
它不是替代 Prometheus，也不是替代日志系统。我的理解更简单：它像是 Kubernetes 里的“网络请求放大镜”，把集群里的服务调用、协议请求、状态码、延迟、Headers、Payload、DNS、gRPC、Redis、Kafka 这些东西直接抓出来给你看。
这篇不讲太多概念，主要看三件事：
怎么安装
装完以后先看哪里
哪些地方适合放到真实排障流程里。
本文看点
01
先用 Helm 跑通安装
02
重点看 API Stream 和 KFL
03
生产环境先收窄采集范围
01
INTRO
Kubeshark 是什么
Kubeshark 官方把它叫做 Kubernetes 网络可观测性工具。
它通过 eBPF 在内核层面捕获和索引集群网络流量，然后把这些流量按 Kubernetes、API 和网络语义组织起来。
简单说，它不只是让你看到 IP 和端口，还能看到来源 Pod、目标 Service、协议、请求路径、状态码、延迟这些更贴近排障的信息。
从官方仓库介绍看，它目前比较核心的能力有几类：
实时查看集群里的 API 调用
看服务之间的调用关系
通过 KFL 查询语言过滤流量
抓取和导出 PCAP，后续可以用 Wireshark 分析
支持 HTTP、gRPC、GraphQL、Redis、Kafka、DNS 等协议
支持和 AI Agent 通过 MCP 集成，让 AI 查询网络流量辅助分析。
我比较关心的不是“AI 能不能自动排障”这个说法。
我更关心它能不能先把证据拿出来。
很多生产问题不是没人会分析，而是信息散在太多地方：日志一份、指标一份、链路一份，网络抓包又是另一套工具。
Kubeshark 的价值在于，它能把服务调用这一层直接展开。
02
CHECKLIST
安装前准备
先说环境。
你至少需要：
一个可用的 Kubernetes 集群
本机已经配置好 kubectl，并且能访问目标集群
已安装 Helm
当前账号有安装 Helm Chart 所需的权限。
如果只是学习，建议先用测试集群、Kind、Minikube，或者临时命名空间。
不要一上来就放到生产全量集群里跑。
原因很简单：这类工具会处理集群流量。流量越大，CPU、内存和存储压力越明显。更关键的是，它可能看到请求内容，里面可能包含敏感信息。
能跑，不代表可以直接上生产。
03
INSTALL
使用 Helm 安装 Kubeshark
官方文档里推荐的方式是 Helm。
命令很短：
helm repo add kubeshark https://helm.kubeshark.com
helm install kubeshark kubeshark/kubeshark
安装完成后，先看一下 Pod 是否正常：
kubectl get pods
再看 Service：
kubectl get svc
如果你看到 kubeshark-front 这类服务，就可以先用本地端口转发打开 Dashboard：
kubectl port-forward service/kubeshark-front 8899:80
然后浏览器访问：
http://localhost:8899
如果页面能打开，说明 Kubeshark 已经开始工作了。
官方也提到，生产环境更建议用 Ingress Controller 暴露 Dashboard，而不是长期依赖 port-forward。
这个判断我也认同。port-forward 更适合本地试用和临时排障。
04
CLI
另一种方式：安装 CLI 后直接 tap
如果你是在 macOS 上，也可以用 Homebrew：
brew install kubeshark
kubeshark tap
这种方式对本地体验比较友好，适合快速看一下效果。
如果你是 Linux 或 Windows，也可以去 GitHub Releases 下载对应二进制。官方 release 页面里提供了 Linux AMD64、Linux ARM64、macOS、Windows 等版本。
不过如果是团队环境，我还是更建议先用 Helm。
Helm 更容易纳入变更流程，也方便后续通过 values 控制资源、采集范围、Ingress、认证和清理。
05
DASHBOARD
装完以后先看哪里
打开 Dashboard 后，不要急着点一堆页面。
我建议先看三个地方。
1. API Stream
API Stream 是最直观的地方。
它会展示集群里的 API 调用，包括协议、方法、状态码、源工作负载、目标工作负载、时间戳和延迟。
如果你正在排查某个服务 500、某个接口变慢、某个调用没有返回，先看这里。
点开一条请求以后，可以进一步看到：
Headers
Request / Response payload
TCP stream
Timing 信息
来源和目标工作负载。
这比单纯看日志多了一层视角。
日志通常是应用自己说了什么，而 Kubeshark 更接近“请求实际发生了什么”。
2. Workload Map
第二个值得看的地方是 Workload Map。
它会把工作负载之间的调用关系画出来。
排 Kubernetes 故障时，有些问题不是某一个 Pod 挂了，而是调用关系和我们想的不一样。比如：
前端没有打到预期的后端
某个服务突然多了一条外部调用
流量绕到了旧版本服务
一个不该访问数据库的服务，实际访问了数据库。
这种问题用日志也能查，但很慢。
图一出来，至少能先知道该往哪条链路上看。
3. KFL 查询
Kubeshark 有自己的查询语言，叫 KFL。
刚开始不需要学复杂语法，先记几个常用的就够了。
看 HTTP 流量：
http
看 DNS：
dns
看 Redis：
redis
看 4xx 和 5xx：
http && status_code >= 400
只看 5xx：
http && status_code >= 500
看某个命名空间：
dst.pod.namespace == "production"
看某个服务：
dst.service.name == "payment-service"
看 GET 请求里的 /api：
http && method == "GET" && url.contains("/api")
如果你怀疑某些请求带了敏感 Header，也可以查：
http && "authorization" in request.headers
这个查询有点敏感，但很实用。
它提醒我们：Kubeshark 不只是排障工具，也可能看到不该随便扩散的信息。
06
FILTERS
Display Filters 和 Capture Filters 不要混
这里有一个地方要特别注意。
Kubeshark 里有 Display Filters，也有 Capture Filters。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
比如你在 Dashboard 里输入：
http && status_code >= 500
这只是过滤展示结果，底层该采集的流量还是在采集。
Capture Filters 不一样。
它会影响 Kubeshark 实际采集哪些工作负载、哪些命名空间、哪些流量。官方文档也强调，Capture Filters 会影响 Raw Capture 和 L7 traffic indexing。
如果你在生产环境使用，一定要优先考虑 Capture Filters。
比如只采集某个命名空间：
tap:
regex: .*
namespaces:
- sock-shop
excludedNamespaces:
- kube-system
bpfOverride: ""
或者只匹配某类 Pod：
tap:
regex: catal.*
namespaces:
- sock-shop
excludedNamespaces:
- kube-system
bpfOverride: ""
我的建议是：测试环境可以放开一点，生产环境一定要收窄。
不要一上来就对整个集群全量采集。工具再好，也不能忽略资源消耗和数据边界。
07
TEST
如何模拟一点流量
如果你的集群里本来就有业务，可以直接打开 Dashboard 看实时流量。
如果只是测试，可以部署一个简单应用，然后用 curl 打几次请求。
比如你已有一个 Service：
kubectl get svc
找一个可以访问的服务后，在集群里临时起一个 curl Pod：
kubectl run curl --image=curlimages/curl -it --rm -- sh
进入容器后访问目标服务：
curl http://目标服务名:端口/
回到 Kubeshark Dashboard，就可以在 API Stream 里观察是否出现对应请求。
如果你看到请求、状态码、延迟、源 Pod 和目标 Service，说明这条链路已经能被观察到了。
08
FAQ
常见问题
1. 页面打不开
先看端口转发是否还在：
kubectl port-forward service/kubeshark-front 8899:80
如果 8899 被占用，可以换一个本地端口：
kubectl port-forward service/kubeshark-front 8898:80
然后访问：
http://localhost:8898
2. Dashboard 没有流量
先确认集群里真的有请求发生。
再检查：
kubectl get pods
看 Kubeshark 相关 Pod 是否正常。
如果你设置了 Capture Filters，要确认过滤条件没有把目标业务排除掉。
3. 集群资源压力变大
这类问题不要硬扛。
先缩小采集范围，再看 Kubeshark 自身 Pod 的 CPU、内存和重启情况。
kubectl top pods
kubectl get pods
如果出现 OOMKilled，说明资源配置或采集范围需要调整。
官方 Best Practices 也建议，新版本先在开发或测试集群验证，不要直接推进生产。
09
CLEANUP
如何卸载
如果你是用 Helm 安装的，清理很简单：
helm uninstall kubeshark
然后确认资源是否清理干净：
kubectl get pods
kubectl get svc
如果你是用 CLI 方式启动的，可以执行：
kubeshark clean
具体以你当时的安装方式为准。
10
THOUGHTS
我会怎么用它
如果放到我的排障习惯里，Kubeshark 不会是第一个打开的工具。
我一般还是先看告警、指标、日志和最近变更。
但当问题进入这些阶段时，Kubeshark 就有价值了：
服务之间到底怎么调用
状态码到底在哪里变了
请求是不是打到了错误服务
DNS 有没有异常
某条链路是不是慢在网络或协议层。
它适合补上日志和指标之间的那块空白。
尤其是微服务一多，调用关系不再靠脑子能记住的时候，Workload Map 和 API Stream 会很有用。
不过生产环境使用要克制。
我会按这个顺序来：
先在测试环境跑通
再只对一个命名空间或一组 Pod 开启采集
确认资源消耗和敏感数据边界
再考虑放入正式排障流程
如果要给更多人用，Dashboard 访问要接入认证和权限控制。
这不是保守，是生产环境的基本常识。
∞
THE END
最后
Kubeshark 这类工具最好的地方，不是让排障变得“自动化”，而是把证据摊开。
Kubernetes 里的很多问题，最怕的是靠猜。
请求有没有出去，打到了哪个服务，返回了什么状态码，慢在哪里，Header 和 Payload 里有没有异常，这些东西如果能直接看到，排障就会少走很多弯路。
但它也不是银弹。
日志、指标、链路追踪、事件、变更记录，这些还是要看。Kubeshark 更适合放在网络和 API 调用这一层，作为排障证据链的一部分。
如果你正在学 Kubernetes 排障，我建议可以在测试集群里装一次。
不用急着上生产，先把 Dashboard 打开，看几条真实请求，再试几个 KFL 查询。
能看懂请求怎么在集群里跑，比背很多概念更有用。
12
REFERENCES
参考资料
Kubeshark GitHub：https://github.com/kubeshark/kubeshark
Kubeshark Installation：https://docs.kubeshark.com/en/install
Kubeshark Introduction：https://docs.kubeshark.com/en/introduction
Kubeshark Dashboard：https://docs.kubeshark.com/en/ui
Kubeshark Display Filters / KFL：https://docs.kubeshark.com/en/display_filters
Kubeshark Capture Filters：https://docs.kubeshark.com/en/pod_targeting
Kubeshark Best Practices：https://docs.kubeshark.com/en/best_practice
我是 python运维技术，长期关注 Python、Linux、Kubernetes 和自动化运维里的真实问题。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
原文始发于微信公众号（python运维技术）：Kubeshark 安装与使用实战
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论