2026-08-11 04:33:04 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文介绍了Kubeshark的安装与使用实战，强调其作为Kubernetes网络可观测性工具的价值，通过eBPF捕获集群流量并提供APIStream、WorkloadMap和KFL查询等功能。文章提供了Helm安装步骤、Dashboard使用指南、生产环境采集范围收窄建议以及常见问题解答，指出Kubeshark适合补充日志和指标之间的空白，但需注意资源消耗和数据边界。 综合评分： 75 文章分类： 实战经验,安全工具,网络安全

cover_image

Kubeshark 安装与使用实战

python运维技术

2026年7月27日 07:30 北京

在小说阅读器读本章

去阅读

QUOTE

Kubeshark 最好的地方，不是让排障变得自动化，而是先把证据摊开。

—— python运维技术

最近看了一个 Kubernetes 网络可观测性工具，叫 Kubeshark。

如果你平时排过 Kubernetes 里的服务调用问题，应该能理解这种感觉：日志里看起来没什么，指标里只看到延迟变高，链路追踪又不一定每个服务都接好了。

最后只能一边 kubectl logs，一边猜请求到底走到了哪里。

Kubeshark 解决的就是这一段问题。

它不是替代 Prometheus，也不是替代日志系统。我的理解更简单：它像是 Kubernetes 里的“网络请求放大镜”，把集群里的服务调用、协议请求、状态码、延迟、Headers、Payload、DNS、gRPC、Redis、Kafka 这些东西直接抓出来给你看。

这篇不讲太多概念，主要看三件事：

怎么安装

装完以后先看哪里

哪些地方适合放到真实排障流程里。

本文看点

先用 Helm 跑通安装

重点看 API Stream 和 KFL

生产环境先收窄采集范围

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 的价值在于，它能把服务调用这一层直接展开。

CHECKLIST

安装前准备

先说环境。

你至少需要：

一个可用的 Kubernetes 集群

本机已经配置好 kubectl，并且能访问目标集群

已安装 Helm

当前账号有安装 Helm Chart 所需的权限。

如果只是学习，建议先用测试集群、Kind、Minikube，或者临时命名空间。

不要一上来就放到生产全量集群里跑。

原因很简单：这类工具会处理集群流量。流量越大，CPU、内存和存储压力越明显。更关键的是，它可能看到请求内容，里面可能包含敏感信息。

能跑，不代表可以直接上生产。

INSTALL

使用 Helm 安装 Kubeshark

官方文档里推荐的方式是 Helm。

命令很短：

…bash

helm repo add kubeshark https://helm.kubeshark.com

helm install kubeshark kubeshark/kubeshark

安装完成后，先看一下 Pod 是否正常：

…bash

kubectl get pods

再看 Service：

…bash

kubectl get svc

如果你看到 kubeshark-front 这类服务，就可以先用本地端口转发打开 Dashboard：

…bash

kubectl port-forward service/kubeshark-front 8899:80

然后浏览器访问：

…text

http://localhost:8899

如果页面能打开，说明 Kubeshark 已经开始工作了。

官方也提到，生产环境更建议用 Ingress Controller 暴露 Dashboard，而不是长期依赖 port-forward。

这个判断我也认同。port-forward 更适合本地试用和临时排障。

CLI

另一种方式：安装 CLI 后直接 tap

如果你是在 macOS 上，也可以用 Homebrew：

…bash

brew install kubeshark

kubeshark tap

这种方式对本地体验比较友好，适合快速看一下效果。

如果你是 Linux 或 Windows，也可以去 GitHub Releases 下载对应二进制。官方 release 页面里提供了 Linux AMD64、Linux ARM64、macOS、Windows 等版本。

不过如果是团队环境，我还是更建议先用 Helm。

Helm 更容易纳入变更流程，也方便后续通过 values 控制资源、采集范围、Ingress、认证和清理。

DASHBOARD

装完以后先看哪里

打开 Dashboard 后，不要急着点一堆页面。

我建议先看三个地方。

API Stream

API Stream 是最直观的地方。

它会展示集群里的 API 调用，包括协议、方法、状态码、源工作负载、目标工作负载、时间戳和延迟。

如果你正在排查某个服务 500、某个接口变慢、某个调用没有返回，先看这里。

点开一条请求以后，可以进一步看到：

Headers

Request / Response payload

TCP stream

Timing 信息

来源和目标工作负载。

这比单纯看日志多了一层视角。

日志通常是应用自己说了什么，而 Kubeshark 更接近“请求实际发生了什么”。

Workload Map

第二个值得看的地方是 Workload Map。

它会把工作负载之间的调用关系画出来。

排 Kubernetes 故障时，有些问题不是某一个 Pod 挂了，而是调用关系和我们想的不一样。比如：

前端没有打到预期的后端

某个服务突然多了一条外部调用

流量绕到了旧版本服务

一个不该访问数据库的服务，实际访问了数据库。

这种问题用日志也能查，但很慢。

图一出来，至少能先知道该往哪条链路上看。

KFL 查询

Kubeshark 有自己的查询语言，叫 KFL。

刚开始不需要学复杂语法，先记几个常用的就够了。

看 HTTP 流量：

…text

http

看 DNS：

…text

dns

看 Redis：

…text

redis

看 4xx 和 5xx：

…text

http && status_code >= 400

只看 5xx：

…text

http && status_code >= 500

看某个命名空间：

…text

dst.pod.namespace == “production”

看某个服务：

…text

dst.service.name == “payment-service”

看 GET 请求里的 /api：

…text

http && method == “GET” && url.contains(“/api”)

如果你怀疑某些请求带了敏感 Header，也可以查：

…text

http && “authorization” in request.headers

这个查询有点敏感，但很实用。

它提醒我们：Kubeshark 不只是排障工具，也可能看到不该随便扩散的信息。

FILTERS

Display Filters 和 Capture Filters 不要混

这里有一个地方要特别注意。

Kubeshark 里有 Display Filters，也有 Capture Filters。

比如你在 Dashboard 里输入：

…text

http && status_code >= 500

这只是过滤展示结果，底层该采集的流量还是在采集。

Capture Filters 不一样。

它会影响 Kubeshark 实际采集哪些工作负载、哪些命名空间、哪些流量。官方文档也强调，Capture Filters 会影响 Raw Capture 和 L7 traffic indexing。

如果你在生产环境使用，一定要优先考虑 Capture Filters。

比如只采集某个命名空间：

…yaml

tap:

　　regex: .*

　　namespaces:

　　　　- sock-shop

　　excludedNamespaces:

　　　　- kube-system

　　bpfOverride: “”

或者只匹配某类 Pod：

…yaml

tap:

　　regex: catal.*

　　namespaces:

　　　　- sock-shop

　　excludedNamespaces:

　　　　- kube-system

　　bpfOverride: “”

我的建议是：测试环境可以放开一点，生产环境一定要收窄。

不要一上来就对整个集群全量采集。工具再好，也不能忽略资源消耗和数据边界。

TEST

如何模拟一点流量

如果你的集群里本来就有业务，可以直接打开 Dashboard 看实时流量。

如果只是测试，可以部署一个简单应用，然后用 curl 打几次请求。

比如你已有一个 Service：

…bash

kubectl get svc

找一个可以访问的服务后，在集群里临时起一个 curl Pod：

…bash

kubectl run curl –image=curlimages/curl -it –rm — sh

进入容器后访问目标服务：

…bash

curl http://目标服务名:端口/

回到 Kubeshark Dashboard，就可以在 API Stream 里观察是否出现对应请求。

如果你看到请求、状态码、延迟、源 Pod 和目标 Service，说明这条链路已经能被观察到了。

FAQ

常见问题

页面打不开

先看端口转发是否还在：

…bash

kubectl port-forward service/kubeshark-front 8899:80

如果 8899 被占用，可以换一个本地端口：

…bash

kubectl port-forward service/kubeshark-front 8898:80

然后访问：

…text

http://localhost:8898

Dashboard 没有流量

先确认集群里真的有请求发生。

再检查：

…bash

kubectl get pods

看 Kubeshark 相关 Pod 是否正常。

如果你设置了 Capture Filters，要确认过滤条件没有把目标业务排除掉。

集群资源压力变大

这类问题不要硬扛。

先缩小采集范围，再看 Kubeshark 自身 Pod 的 CPU、内存和重启情况。

…bash

kubectl top pods

kubectl get pods

如果出现 OOMKilled，说明资源配置或采集范围需要调整。

官方 Best Practices 也建议，新版本先在开发或测试集群验证，不要直接推进生产。

CLEANUP

如何卸载

如果你是用 Helm 安装的，清理很简单：

…bash

helm uninstall kubeshark

然后确认资源是否清理干净：

…bash

kubectl get pods

kubectl get svc

如果你是用 CLI 方式启动的，可以执行：

…bash

kubeshark clean

具体以你当时的安装方式为准。

THOUGHTS

我会怎么用它

如果放到我的排障习惯里，Kubeshark 不会是第一个打开的工具。

我一般还是先看告警、指标、日志和最近变更。

但当问题进入这些阶段时，Kubeshark 就有价值了：

服务之间到底怎么调用

状态码到底在哪里变了

请求是不是打到了错误服务

DNS 有没有异常

某条链路是不是慢在网络或协议层。

它适合补上日志和指标之间的那块空白。

尤其是微服务一多，调用关系不再靠脑子能记住的时候，Workload Map 和 API Stream 会很有用。

不过生产环境使用要克制。

我会按这个顺序来：

先在测试环境跑通

再只对一个命名空间或一组 Pod 开启采集

确认资源消耗和敏感数据边界

再考虑放入正式排障流程

如果要给更多人用，Dashboard 访问要接入认证和权限控制。

这不是保守，是生产环境的基本常识。

∞

THE END

最后

Kubeshark 这类工具最好的地方，不是让排障变得“自动化”，而是把证据摊开。

Kubernetes 里的很多问题，最怕的是靠猜。

请求有没有出去，打到了哪个服务，返回了什么状态码，慢在哪里，Header 和 Payload 里有没有异常，这些东西如果能直接看到，排障就会少走很多弯路。

但它也不是银弹。

日志、指标、链路追踪、事件、变更记录，这些还是要看。Kubeshark 更适合放在网络和 API 调用这一层，作为排障证据链的一部分。

如果你正在学 Kubernetes 排障，我建议可以在测试集群里装一次。

不用急着上生产，先把 Dashboard 打开，看几条真实请求，再试几个 KFL 查询。

能看懂请求怎么在集群里跑，比背很多概念更有用。

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

END

我是 python运维技术，长期关注 Python、Linux、Kubernetes 和自动化运维里的真实问题。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：python运维技术《Kubeshark 安装与使用实战》