容器里没有ls？从内核证据到nsenter抓包的完整排障指南

“面试被问：容器里连 ls 都没有，网络故障怎么抓包？”——这题我第一次听到时也愣了几秒。很多人的第一反应是：没工具怎么排障？装个 busybox？或者顶多点两下 curl？但面试官真正想看的，往往不是你能不能背出 tcpdump 的过滤参数，而是当环境退化到几乎什么都没有时，你脑子里有没有一套完整的排障框架。

现实里这种问题并不罕见。为了减小镜像体积，越来越多的服务改用 distroless、scratch，或者一个只有 sh 和少量二进制的最小基础镜像。于是生产环境里经常出现这种场景：容器起来了，应用日志却在拼命报错，你想进去看一眼网络状况，结果连 ls 都不在。更麻烦的是，越是在这种“什么都没有”的时刻，越说明系统可能已经处于比较紧张的状态——留给你的操作空间很小，时间也很有限。

这篇文章不会只告诉你“装一个 tcpdump 就行”，那没有意义。我会按面试题的真实考察点展开：先讲清楚为什么容器里会没有 ls，再给出不需要安装任何工具就能拿到的“内核证据层”；然后重点演示 nsenter 如何从宿主机侧进入容器的网络命名空间进行抓包；接着介绍 kubectl debug、共享网络命名空间、Debug Sidecar 等几种把抓包工具“送进”容器的可行方案；最后，即使真的没有 tcpdump，也有一系列应急替代手段，比如读 conntrack、用 /dev/tcp、用 nc 做简易流量监听。读完你会得到一套可直接复用的方法，而不是一个孤立的命令。

1. 面试官这一问，究竟在考什么

先把问题的背景说清楚。容器里没有 ls，本质上不是运维随机碰到的问题，而是镜像设计走向极致的必然结果。scratch 镜像化连 shell 都没有，distroless 镜像刻意不包含包管理器、shell、调试工具，很多 Alpine 基础镜像虽然没有装 tcpdump，但还能用 sh 执行一些基础命令。这类镜像的好处是体积小、攻击面小、依赖少，坏处是故障发生时你能直接操作的东西特别少。

面试官问“容器里连 ls 都没有，网络故障怎么抓包”，真正考察的是一个工程判断：你知道在最小工具条件下应该先看什么吗？你知道工具可以来自容器之外吗？你知道抓包只是定位手段，而不是排障目标吗？

一个容易踩坑的回答是，直接说我进入容器装一个 tcpdump。这个回答的问题在于，生产环境未必允许你随便装包，也不一定有网络源，更不一定有足够的权限。另一个跑偏的回答是，说用 kubectl exec 进容器里跑 ping。这个回答忽略了最核心的目标——你连 ls 都没有，凭什么确定 ping 一定存在？所以更稳妥的思路，是把排障拆成三层：先看内核暴露的信息，再想办法把外部工具引入容器的网络命名空间，最后才考虑抓包分析和业务链路判断。只要这个框架是清晰的，面试官基本就会认可你的工程能力。

这篇文章的读者，应该是正在准备面试的后端开发、平台工程师、SRE，以及已经在生产环境里遇到过类似问题的同学。读完之后，你不仅知道“抓包用 tcpdump”，还能说出在没有 tcpdump 时，还有哪些替代路径，以及每条路径的局限和风险。

2. 不装任何新工具，先把“内核证据层”读完

很多人在排障时习惯性地先找工具，但忽略了操作系统的真相来源：procfs 和 sysfs。这两个文件系统几乎不以镜像体积为目标而裁剪，即使 scratch 容器里没有 ls，只要内核挂载了 /proc，你依然可以读到大量的网络状态信息。换句话说，哪怕容器里只有一个能执行命令的入口，也已经够做一轮初步定位了。

2.1 /proc/net 目录：看连接、端口和路由

进入容器后，第一步不是想着抓包，而是确认链路的基本状态是否正常。可以按顺序读这几个文件：

cat /proc/net/dev cat /proc/net/tcp cat /proc/net/tcp6 cat /proc/net/udp cat /proc/net/route

/proc/net/dev 会告诉你容器网卡上有多少收发包、有没有大量错误包和丢包；/proc/net/tcp 会显示当前 TCP 连接表，虽然格式比较原始，但关键信息都在；/proc/net/route 则能看到路由表是否包含默认路由。它们不依赖像 ip、route、ss 这样的外部命令，只要有 cat 就能读。

读 /proc/net/tcp 时需要知道一个细节：IP 和端口都是十六进制表示的，状态码也是一个数字。0A 代表 LISTEN，01 代表 ESTABLISHED，02 代表 SYN_SENT，03 代表 SYN_RECV，06 代表 TIME_WAIT。如果连接一直在 SYN_SENT，说明 SYN 包发出去了但没有收到响应；如果是八位十六进制表示的本地地址，比如 0100007F:0035，那么它就是 127.0.0.1:53，因为十六进制的小端字节序正好是倒序的 IP 地址。当我们做最小化排障时，不需要看得特别细，只要能判断“端口有没有监听”“连接挂在哪个状态”，就已经省下很多排查时间。

2.2 /etc/resolv.conf：DNS 问题先别动手抓包

另一个被很多人忽略的证据是 /etc/resolv.conf。容器内的 DNS 配置通常由 Kubernetes 或 Docker 写入，如果这个文件内容异常，那么应用报的“网络超时”很可能根本不是网络问题，而是域名解析问题。

cat /etc/resolv.conf

重点关注三个字段：nameserver、search、options。nameserver 指向的 DNS 服务是否可达；search 域是否配置正确；options 里的 ndots 是否过大，可能导致额外的 DNS 查询次数。实际项目中曾见过一种很典型的故障：容器内应用访问某个内部服务超时，抓包抓了半天，发现流量其实一直在反复查询一个不存在的 DNS 服务器。其实只要早一点看 /etc/resolv.conf，就能把排查范围从链路层直接拉到 DNS 配置层。

另外，/proc/sys/net 下面也有很多内核网络参数，比如 /proc/sys/net/ipv4/tcp_somaxconn、/proc/sys/net/ipv4/tcp_abort_on_overflow。当服务端 accept 队列溢出时，内核可能直接丢弃连接或发送 RST，这类问题用 tcpdump 也能看到，但不读内核参数很难快速想到原因。所以在“什么都没有”的容器里，先读 /proc 和 /etc 下的文件，是一种性价比极高的排障方式。

2.3 sh、cat、grep 之外的“极简三板斧”

即使镜像里只有 sh，我们仍然能组合出一些有效操作。比如用 fd 在 /proc 里查看进程打开了哪些 socket 文件描述符，用 /proc/进程号/net 查看某个进程的网络命名空间信息，用 /proc/进程号/fd 判断应用是否还持有已经断开的连接。这里有一个思路：容器排障不一定要追求执行高级命令，只要能把文件系统里的信息读到，很多问题就能定位到方向。

一个经常被忽略的细节是，/proc/net 实际上是当前网络命名空间的符号视图。/proc/1/net 与 /proc/self/net 在现代内核中通常指向同一个 netns，所以如果你在容器里执行 cat /proc/net/tcp，看到的是容器自己的连接表。这个“命名空间”的概念，是后面理解 nsenter、共享网络命名空间和临时容器的基础。

3. 从宿主机进入容器的网络命名空间：nsenter 实战

如果容器里没有 shell，或者连执行命令的能力都没有，那就需要换一条思路：工具不需要进入容器，只要进入容器的网络命名空间就够了。这是 nsenter 的核心作用，也是生产环境排障时非常高效的方式。

3.1 为什么 nsenter 能绕过容器内没有工具的问题

Linux 的 namespace 把系统资源隔离成了多个独立视图。容器本质上是一组 namespace 的组合，网络命名空间包含网卡、路由、iptables 规则、连接跟踪表等。nsenter 可以让你从宿主机进入指定进程所在的某个 namespace，然后在这个 namespace 里执行宿主机上的命令。于是，即使容器里连 sh 都没有，只要宿主机有 ip、ss、tcpdump，你依然能在容器的网络视图里操作。

需要特别强调的是，进入宿主机并操作网络命名空间，需要合适的权限，并且在很多生产环境里，这类操作应该先走审批流程。nsenter 不该被用作随意入侵其他容器的工具，而是应该在明确授权、最小化影响范围的前提下，用于故障排障。

3.2 核心命令：从 PID 到命名空间

首先找到容器主进程在宿主机上的 PID。使用 Docker 时，可以用 docker inspect 拿到：

docker inspect -f '{{.State.Pid}}' your-container-name

拿到 PID 后，就可以用 nsenter 进入该 PID 的网络命名空间执行命令：

nsenter -t 12345 -n ip addr nsenter -t 12345 -n ss -tnp nsenter -t 12345 -n ip route

这里的 -t 指定目标 PID，-n 表示进入网络命名空间。执行之后，你看到的网络状态就是容器自己的，包括 eth0 的 IP、默认路由、监听端口等。这一步非常直观：容器里没有 ls 没关系，宿主机上有的是工具。

如果要在容器网络命名空间里抓包，前提是宿主机上装了 tcpdump，并且当前用户有权限执行：

nsenter -t 12345 -n tcpdump -i any -nn -s 0 -w /tmp/container-netns.pcap

在容器网络命名空间里抓包，抓到的是容器自身网络栈的流量。这个 pcap 文件里能看到容器对外连接的全部 TCP 握手、RST、重传等关键证据。相比在宿主机物理网卡上抓包，这种方式更精准，避免了同一宿主机上其他容器流量带来的干扰。

3.3 抓包文件怎么保存和清理

一个容易忽略的问题是文件保存位置。如果直接写成 /tmp/xxx.pcap，那么这个文件在宿主机上，不在容器里。这样做的好处是抓包不占用容器可写层，也不会因为容器重启而丢失证据；坏处是如果宿主机 /tmp 空间不足，抓包可能中断。工程上更推荐先确认磁盘使用量，再指定明确的输出目录，并且抓包结束后立即清理，避免敏感流量长期留在磁盘上。

抓包时长也要控制。生产环境里，建议先抓 30 到 60 秒，把问题复现窗口覆盖住就好，不要无限期抓下去。如果需要循环抓包并分片保存，可以用 tcpdump 的 -G 参数按秒切换文件、-W 限制文件数量，这样能避免单个文件过大。不过要记住，这些参数是宿主机 tcpdump 的用法，与容器内是否有 tcpdump 无关。

4. 把抓包工具“送进”容器的几种可靠方式

如果不想登录宿主机，或者不方便使用 nsenter，那就要考虑把抓包工具实时分发给容器。这是 Kubernetes 和 Docker 生态里很常见的操作，也是面试时可以重点展开的部分。

4.1 kubectl debug 临时容器

Kubernetes 提供了 ephemeral container 机制，从 1.23 版本开始有 kubectl debug 命令用来创建临时调试容器。具体命令可以写成这样：

kubectl debug -it your-pod --image=nicolaka/netshoot --target=your-container

--target 指定要和哪个容器共享调试上下文。官方建议用 netshoot 这类自带网络工具集的镜像，里面通常包括了 ip、ss、curl、tcpdump、nc 等。临时容器加入 Pod 后，与目标 pod 共享网络命名空间，所以它看到的网卡、路由和连接状态就是目标容器的网络视图。

这里的注意事项是，临时容器并不一定支持所有运行时和所有网络插件，具体版本兼容性要以你的集群为准。还有一个细节：临时容器默认不会主动修改目标容器的进程，你依然需要根据场景选择抓包对象。比如我要抓应用容器访问数据库的包，那么只要在临时容器里执行 tcpdump 即可，不需要进入应用容器的进程视角。

4.2 使用 Docker 共享网络命名空间

如果你在 Docker 环境下排障，另一个快速方式是启动一个新的容器，并让它和故障容器共享网络命名空间。这样新容器就可以拿着自己的工具，抓故障容器的流量。

docker run -it --rm --network=container:your-container-name nicolaka/netshoot tcpdump -i eth0 -nn

--network=container:xxx 的意思是，新容器不创建自己的网络命名空间，而是直接复用目标容器的网络栈。两者的区别在于，这不算“进入容器进程”，而是共享同一个网络视图。这种方法的优点是启动快、不影响故障容器；缺点是如果故障容器已经无法访问网络，那共享它的网络栈也只能看到同样的故障现象，不如从宿主机侧抓包灵活。

4.3 Debug Sidecar：平时备好，故障时直接抓

更推荐的一种做法，是在设计和发布阶段就预留一个 Debug Sidecar 容器。比如在同一个 Pod 里，除了主应用容器，再放一个只跑 sleep 的调试容器，镜像里预先装好 tcpdump、curl、ip、ss 等工具。入流量和故障发生时，直接进入这个 sidecar 操作，不需要临时拉取镜像，也不需要修改运行中的 Pod。

spec: containers: - name: app image: your-app:1.0.0 - name: debug image: nicolaka/netshoot command: ["sleep", "3600"]

同一个 Pod 内的容器默认共享网络命名空间，所以 debug 容器抓到的包就是主应用水位线上的真实流量。这是一种“以少量资源换取排障能力”的思路，很多中大型团队已经在用。它的缺陷是会增加每个 Pod 的资源开销，也会增加镜像仓库的拉取压力，因此是否采用，取决于你们对故障恢复速度和可观测性的要求。

5. 没有 tcpdump 的应急替代方案

如果宿主机上也没有 tcpdump，或者缺少权限安装，那么问题会变得更棘手。但即便如此，仍有一些能落地的应急替代方案。它们未必能像 tcpdump 一样还原完整报文，但用来判断“连接有没有建立”“数据有没有到达”“端口是否监听”还是可以的。

5.1 利用宿主机的 veth 接口在链路层抓包

容器的网卡在宿主机上通常对应一个 veth 接口。你可以从宿主机上找到这个 veth，然后在 veth 上抓包，这和在容器网络命名空间里抓到的流量基本一致。找到 veth 的通用方法，是先在容器里确认 eth0 的 ifindex，再到宿主机上匹配同名的虚拟接口。这个操作依赖 /sys 文件系统和宿主机网络工具，所以容器里没有 ls 也可以完成大半。

但这种方法有一个明显的限制：如果宿主机上的 veth 接口接收流量很少，可能是因为流量直接被本地路由转发到其他接口，或者有 iptables 规则在更早的链上处理。所以 veth 抓包更适合作为辅助手段，而不是唯一证据。

5.2 用 /dev/tcp 做连通性探测

bash 提供了一种十分取巧的 TCP 测试方式：/dev/tcp。它不是真实存在的设备文件，而是 bash 解释器提供的一个虚拟路径。当你在 bash 里重定向到 /dev/tcp/host/port 时，bash 会尝试建立一次 TCP 连接。这个方法适合快速验证目标端口是否可达，也能做一些简单的应用层探测。

timeout 3 bash -c 'echo > /dev/tcp/10.0.0.5/3306' && echo "port open" || echo "port closed"

这个命令的好处是不需要 nc、telnet 等外部工具，只要有 bash 就能跑。缺点也明显：它只验证 TCP 层能否握手，不提供 RTT、重传、丢包等细节，也不能抓完整包。所以在“什么都没有”的容器里，它的价值是快速二分：连不上，是超时还是拒绝；能连上，那问题很可能不在网络层，而在应用层。

5.3 用 nc 当简易流量监听器

如果容器里恰好有 nc，那么可以把它当成一个最简化的服务端，监听某个端口并显示收到的字节。比如要确认某个内部服务有没有往固定端口发送数据，可以临时运行：

nc -lk 18080 | xxd

-l 表示监听，-k 表示保持连接，管道后的 xxd 用来把收到的内容以十六进制展示。它只能看到数据内容，看不到 TCP 状态、重传和时序，所以它不是 tcpdump 的替代品，但在应急时能帮助你判断“有没有流量过来、流量大概是什么”。更复杂一点的场景，可以看 nc 是否支持 -v 输出连接明细，但这取决于具体发行版的 nc 版本，不要假设所有镜像都有。

5.4 从 conntrack 看连接状态

conntrack 是 Linux 的连接跟踪机制，很多 NAT、iptables 场景都会依赖它。在宿主机上，可以读取 /proc/net/nf_conntrack 来查看当前连接跟踪表，判断某个容器的连接处于什么状态，比如是否完成了 SNAT、是否还停留在 SYN_SENT。也可以执行宿主机上的 conntrack 命令：

cat /proc/net/nf_conntrack | grep 10.0.0.5

需要注意的是，/proc/net/nf_conntrack 并非所有系统都存在，它依赖内核模块加载情况。读取连接跟踪表属于比较底层的信息，但如果现场连 tcpdump 都没有，conntrack 表能告诉我们很多 NAT 超时、连接泄漏和回包路径的判断依据。尤其是在 Kubernetes 服务访问、DNAT 转发这类链路里，conntrack 表往往是定位“连接被中断”的关键。

6. 完整排障案例：服务连不上数据库，从出现症状到定位

把上面的方法串起来，看一个真实的排障模式。假设有一个 Java 服务运行在 Kubernetes Pod 里，基础镜像非常精简，只有 sh，没有 ls，没有 netstat，也没有 tcpdump。应用日志每隔几秒报一次 unable to connect to database，connect timeout。我们的目标是把“容器网络问题”和“数据库端问题”区分开。

6.1 排障流程

第一步，先看容器里的内核证据。执行：

kubectl exec -it <pod> -- sh -c 'cat /proc/net/route && cat /etc/resolv.conf'

确认默认路由存在，DNS 配置正确。如果 DNS 指向的是一个不可达的 ClusterIP，或者搜索域配置错乱，那下一步就要先修 DNS，而不是急着抓包。

第二步，验证数据库端口是否可达。在 pod 里执行：

timeout 3 bash -c 'echo > /dev/tcp/db-svc.ns.svc.cluster.local/3306' && echo ok || echo fail

如果 DNS 可以解析，但 TCP 连接超时，那问题大概率在中间链路，比如 NetworkPolicy、安全组、节点路由或数据库防火墙；如果端口直接被拒绝，那就要检查数据库端是否真的在监听。这一步已经能把问题范围缩小到一两个方向。

第三步，进入容器的网络命名空间抓包。如果集群支持临时容器，就用 netshoot 镜像；如果不支持，则到宿主机上通过 nsenter 进入 Pod 的 netns。重点抓 TCP SYN 和 SYN-ACK 的交互情况。抓到 SYN 发出但没有 SYN-ACK，说明报文在中间某段被丢弃；抓到 SYN 后收到 RST，说明对端端口没有监听或对端防火墙主动拒绝；抓到完整握手但随后立刻断开，说明问题很可能在连接池、鉴权或数据库服务端的应用逻辑。

6.2 抓到包以后怎么判断

判断逻辑可以总结成一组决策分支：

• 只有 SYN，没有 SYN-ACK：网络路径不通，检查路由、防火墙、NetworkPolicy。
• SYN 后有 RST：对端未监听端口，或者对端安全策略拒绝连接。
• 握手成功，但应用层立刻关闭：很可能是数据库账号权限、连接池配置或服务端主动断开。
• 握手成功，但数据达到不了应用层：需要继续看应用日志、连接数等，而不是继续在网络层找问题。

这个决策分支比单纯的“抓包”更有价值，因为抓包只是过程，定位才是目标。面试时如果能把排障流程讲成这样，就已经展示了你对容器网络、内核状态和抓包工具的完整理解。

7. 常见问题与排查清单

这里的每一条都很具体，因为这些现象在实际排障中并不会主动告诉你哪里错，需要靠经验快速匹配。遇到第一类“没有 shell”的报错时，很多新手会反复尝试换 shell 路径，其实换一条外部路径更高效。

8. 最佳实践与工程建议

从“面试题”回到“工程落地”，我认为更重要的是把这些临时操作沉淀成团队规范。平时没人愿意折腾 Debug Sidecar、权限模型和抓包流程，但故障来临时，没有规范的组织往往会因为乱抓包、乱授权而火上浇油。

第一，构建镜像时不要为了“小而美”把所有排障能力都删掉。这里不是说要保留完整操作系统，而是建议维护单独的 debug 镜像。生产镜像用精简版，排障镜像包含 ip、ss、tcpdump、curl、jq，并尽量随应用版本一起发布，避免临时从公网拉取。

第二，在 Kubernetes 里尽量用临时容器或预置 sidecar 完成排障，而不是直接给应用容器加 NET_ADMIN、NET_RAW 权限。应用容器越精简，越应该把调试能力限制在独立容器里。这样既保留了镜像体积优势，又避免给生产应用增加不必要的权限面。

第三，抓包应该先授权、先规划、再执行。生产环境流量可能包含敏感数据，抓包行为本身也可能带来性能影响。建议明确谁会发起抓包、在哪个节点抓、抓多久、存到哪里、抓完怎么清理。最好提前准备一套标准操作流程，把命令固化下来，而不是每次都临时敲。

第四，把可观测性做在前面，减少“靠抓包救命”的频率。在业务正常时，可以先通过监控指标、日志和链路追踪观测网络质量。例如对数据库连接池、超时次数、TCP 重传率、DNS 解析耗时的指标做指标卡点。很多网络故障在发生前会先表现为少量重传和延迟抖动，这时候监控指标比抓包更容易被发现。

第五，教学和演练同样重要。可以让团队定期做一次“无 ls 容器排障演练”，让每名成员在只有 sh 的容器里解决一次模拟故障。演练材料不用很复杂，两个容器互相访问，一个模拟 DNS 错误，一个模拟网络策略阻断，就能覆盖大部分核心技能。这样面试题里的场景才会变成团队的真实作战能力。

9. 总结与后续学习方向

回到面试题，“容器里连 ls 都没有，网络故障怎么抓包”最稳妥的回答框架是这样：先读取 /proc 和 /etc 下的内核证据快速定位方向；再通过 nsenter、kubectl debug、共享网络命名空间引入外部工具；最后用 tcpdump 或应急替代方案做精确抓包，并用连接状态判断故障落在网络层、系统层还是应用层。这个框架不依赖某个具体镜像里有没有 ls，也不依赖 tcpdump 一定存在。

继续往下深入，可以补充学习三个方向：Linux 网络命名空间与 veth 的原理、conntrack 与 NAT 行为、eBPF 在可观测性上的应用。理解了这些底层机制之后，哪怕哪天进入一个完全陌生的容器，你也能依靠内核状态、宿主机工具和网络知识快速定位。建议把这篇文章收藏备用，把 nsenter、kubectl debug 和应急抓包命令整理成自己的排障手册。面试时能说出框架，而生产环境里能真的解决问题，才是这类题目真正想筛选的能力。