Pod 状态停在 Init:0/1 十八分钟，describe 里 initContainer 的日志最后一行是 nc: bad address 'db'。乍看像缓存或者权限的锅，追下去往往不是。
kubectl describe pod api-6f7d8c9b5-8x2lk | grep -A12 'Init Containers' kubectl logs api-6f7d8c9b5-8x2lk -c init-db kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup db
追下去是这么回事：初始化容器在等一个数据库 Service，Service 还没创建或名字拼错，DNS 解析直接失败。initContainer 不成功，主容器不会启动，探针也不会介入。
碰到「初始化容器卡住」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
具体做法是，先看 initContainer 的日志和退出码 确认卡在哪条命令；在同一个命名空间 nslookup 一下 Service 名 确认解析结果；给 initContainer 加 activeDeadlineSeconds 避免无限等；依赖服务用 readiness 判断 不要只靠 sleep。
验收就看一点，initContainer 在 30 秒内完成 Pod 进入 Running describe 里 Init 状态变成 Completed。