Cilium 网络策略的 kubectl‑capture 功能取代了我们用于调试的 tcpdump sidecar
Source: Dev.to
请提供您希望翻译的正文内容（除代码块和 URL 之外），我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！
tcpdump Sidecars 的问题
在采用 Cilium 的 kubectl‑capture 之前，我们团队依赖 tcpdump sidecar 来排查丢包、策略配置错误和连通性问题。此工作流存在三个核心缺陷：
- 运维开销: 每次调试都需要补丁 pod 规范，添加带有 tcpdump 的 sidecar 容器，重启工作负载，并在捕获完成后进行清理。
- 安全风险: tcpdump sidecar 需要特权访问或 host‑network 模式才能捕获流量，扩大了生产 pod 的攻击面。
- 上下文受限: sidecar 捕获缺乏与 Cilium 网络策略的原生集成，难以将捕获的数据包与特定的策略规则或端点身份关联。
什么是 Cilium kubectl‑capture？
Cilium 是一个基于 eBPF 的 Kubernetes 网络和安全层，提供高级网络策略执行、负载均衡和可观测性。kubectl‑capture 插件（随 Cilium CLI 捆绑）利用 eBPF 的底层内核可视性，直接从 Cilium 管理的端点捕获数据包——无需 sidecar。
与传统的数据包捕获不同，kubectl‑capture 将捕获绑定到 Cilium 的原生构件：你可以按端点 IP、Pod 标签、网络策略名称、目标端口，甚至特定的策略判定（允许/丢弃）来过滤流量。捕获可以直接流式传输到本地机器，或保存为文件，以便使用 Wireshark 等工具进行离线分析。
我们如何从 Sidecar 切换到 kubectl‑capture
将调试工作流迁移完成仅用了不到一天时间。下面是使用 kubectl‑capture 调试被丢弃的网络策略的快速示例：
# 捕获标记为 app=web 的 Pod 的流量，过滤端口 80 上被丢弃的报文
kubectl capture --pod-labels app=web --port 80 --verdict dropped -o capture.pcap旧的 Sidecar 工作流
-
为 web Pod 的 Deployment 打补丁，添加一个
tcpdumpsidecar 并设置hostNetwork: true。 -
等待 Pod 重启后，进入 sidecar：
kubectl exec -it web-pod -- tcpdump -i eth0 port 80 -w capture.pcap -
使用
kubectl cp将捕获文件复制到本地。 -
从 Deployment 中移除 sidecar 并再次重启 Pod 以完成清理。
kubectl‑capture 工作流省去了上述四步中的三步，无需 Pod 重启或配置更改。
我们看到的主要收益
- 零开销： eBPF 捕获在内核中运行，对性能影响极小，不像占用 pod 资源的 sidecar。
- 更好的策略上下文： 捕获数据包含 Cilium 元数据，如策略名称、端点 ID 和判决结果，让你准确知道是哪条规则允许或丢弃了数据包。
- 提升安全性： 无需特权 sidecar 或主机网络访问 ——
kubectl‑capture使用 Cilium 已有的 eBPF 程序进行流量捕获。 - 更快的调试： 自从切换到
kubectl‑capture后，网络策略问题的平均修复时间（MTTR）降低约 60%。
实际案例：调试被丢弃的入口策略
上个月，我们为前端 pod 新增的入口策略导致来自 API 网关的合法流量被丢弃。使用 tcpdump sidecar 的话，需要对三个前端 pod 打补丁、重启它们，并在通用的数据包捕获中筛选。我们改为运行：
kubectl capture --pod-labels app=frontend --source-ip 10.2.3.4 --verdict dropped -o frontend-drop.pcap捕获结果显示，该策略缺少允许来自网关的 Cilium 端点 ID 的规则。我们更新并应用了策略，并通过一次 kubectl‑capture 命令验证了修复——无需重启。
结论
Cilium 的 kubectl‑capture 功能已经彻底取代了我们用于网络策略调试的 tcpdump sidecar 工作流。它更快、更安全，并且与我们管理 Kubernetes 网络的方式高度集成。如果您在生产环境中运行 Cilium，kubectl‑capture 是调试工具箱中必备的工具。