容器内排障该不该用：先看它解决的问题是不是你的问题

distroless 与 scratch 镜像里没有 sh，docker exec 会直接报 not found

它擅长的是无 shell 的精简镜像；如果你只是网络与 DNS 问题，用现成的东西更省事。

先说结论

容器排障的正确姿势是「从宿主看容器」，而不是非要挤进容器里

• 适合：无 shell 的精简镜像
• 不适合：进程被 OOM 或信号杀死
• 学习成本：docker inspect 的 State.Pid 是宿主上的 PID，用它才能 nsenter 进命名空间
• 最大收益：docker stop 先发 SIGTERM，等 10 秒再 SIGKILL，退出码 137 就是被强杀
• 最大风险：往生产容器里 exec 装 curl，重启后全部丢失

它到底解决什么

distroless 与 scratch 镜像里没有 sh，docker exec 会直接报 not found。

换句话说，它把「无 shell 的精简镜像」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

往生产容器里 exec 装 curl，重启后全部丢失

docker logs 里看不到崩溃原因，其实是进程被 SIGKILL 没留日志

在容器里改配置不落盘，下一次发布被镜像覆盖

和替代方案比

--net=container:x 让调试容器共用网络命名空间，可以用它的 curl 访问对端的回环地址。

这台工具的关键细节

几个决定长期体验的点：

• docker inspect 的 State.Pid 是宿主上的 PID，用它才能 nsenter 进命名空间
• docker stop 先发 SIGTERM，等 10 秒再 SIGKILL，退出码 137 就是被强杀
• 容器里的 /proc 是命名空间视图，看到的进程只是容器内的

我的建议

容器排障的正确姿势是「从宿主看容器」，而不是非要挤进容器里。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

工具是解法，不是身份。