Kubernetes Tips：用 Ephemeral Containers 排障（不污染生产镜像）

在不把 curl/dig/tcpdump 打进生产镜像的前提下，安全地进入 Pod 排查 DNS/网络/依赖问题。

Ephemeral Container（临时调试容器）允许你在 不修改 Deployment 镜像 的情况下，把一个调试容器“挂”到现有 Pod 上，用来排查线上问题。

它特别适合：

生产镜像极简（distroless/scratch），没有 curl/dig/tcpdump
你需要在 Pod 内部 复现网络/DNS/依赖问题
你希望生产镜像保持干净、安全、可审计

前置条件

集群版本需要支持 ephemeral containers（较新的版本已稳定支持）
需要 RBAC 权限：pods/ephemeralcontainers（注意是子资源）

最常用的一条命令

给指定 Pod 加一个临时调试容器：

kubectl debug -n <ns> -it pod/<pod> --image=busybox:1.36 --target=<container-name>

说明：

--image 选一个你信任的调试镜像
--target 会让调试容器尽可能共享目标容器的命名空间（尤其是进程空间），方便看进程/调试
如果你只是想做网络/DNS 检查，不一定需要 --target

你能用它做什么（实战场景）

1）DNS 与服务解析

nslookup kubernetes.default.svc.cluster.local
nslookup <svc>.<ns>.svc.cluster.local
cat /etc/resolv.conf

很多“服务突然不可用”的根因其实是：

DNS 被 NetworkPolicy egress 拦了
CoreDNS 异常
节点网络/CNI 问题导致间歇性解析失败

2）验证 Service 连通性（从 Pod 内）

wget -S -O- http://<service>.<ns>.svc.cluster.local:8080/readyz
nc -vz <service>.<ns>.svc.cluster.local 8080

你想验证的是：在同一 Pod 网络命名空间里，请求到底能不能走通。

3）检查环境变量与挂载（尽量只读）

排障时常见的“配置错了”：

env 变量缺失/写错
ConfigMap/Secret 没挂载成功
文件路径不一致

建议排障动作尽量只读：

env
ls -la /path
cat /etc/hosts

选什么调试镜像更合理

不同任务需要不同工具：

BusyBox：够小，适合基础网络与文件检查
Alpine：可拓展，但临时安装包可能需要外网访问（不一定允许）
工具箱镜像：带 curl/dig/tcpdump/mtr 等，效率高但体积大、风险也更大

生产建议维护一个“认证过的调试镜像”：

固定 tag 或 digest（可复现）
定期安全扫描
只包含必要工具

这样排障不会临时“随便拉一个镜像”，降低供应链风险。

理解 `--target`：什么时候必须用

多数网络排障只需要共享 Pod 的网络命名空间就够了（默认就是共享）。

你更可能需要 --target 的情况：

想看目标容器进程（或在允许情况下 strace）
想对“卡死”的进程做诊断

如果平台/策略禁止进程命名空间共享，你至少仍然能做网络/DNS 层面的排查。

重要限制（别把它当成长期方案）

Ephemeral containers 的定位就是“临时排障”，因此：

不是 Pod spec 的一部分，不应该成为“长期修复”
不会被重启（退出就退出了）
不应该对外提供服务端口

正确修复应该回到：

配置/镜像/代码/部署清单
GitOps/CI 的流程

安全与流程（最容易被忽视，但最重要）

临时调试容器本质上是“把人带进生产 Pod”：

需要更严格的 RBAC（限制谁能用）
需要审计（谁、什么时候、为什么）
需要流程（事故单/工单编号，排查结论落档）

推荐做法：

RBAC 最小化：只给少数 SRE/值班组
统一调试镜像：防止供应链风险
只读排障优先：尽量不改线上文件与状态

Bonus：当问题在“节点层”而非 Pod 层

有时候根因在节点或平台：

CNI 路由/iptables/eBPF 问题
磁盘压力导致驱逐
kubelet/containerd 异常

部分平台支持 kubectl debug node/<node> 做节点排障（通常需要更高权限）。这类能力非常强，必须更严格控制。

Checklist

生产镜像保持极简，不打包调试工具
用 ephemeral containers 快速复现 Pod 内真实网络/DNS
RBAC 控制 pods/ephemeralcontainers，并审计使用记录
排障只读优先，修复走发布流程而不是“线上手改”

参考链接

FAQ

Q: 生产环境能用吗？ A: 可以用于排障，但不会自动重启。建议用 RBAC 限制谁可以注入临时容器。

Q: 为什么不能挂载新卷或暴露端口？ A: 临时容器设计用于调试，限制变更以避免影响业务。

Q: 怎么查看临时容器日志？ A: 用 kubectl logs <pod> -c <ephemeral-container-name>，必要时 kubectl describe pod 查看状态。