当 Pod 卡在 Init:0/x 状态（初始化未完成）时，可以按以下思路逐层排查。
一、确认问题现象
kubectl get pod常见状态：
|-------------------------|----------------------|
| 状态 | 含义 |
| Init:0/x | 第一个初始化容器执行中 |
| Init:CrashLoopBackOff | 某个初始化容器反复失败 |
| Init:Error | 初始化命令执行失败 |
| Init:Completed | 所有初始化容器执行成功（主容器即将启动） |
二、快速定位是哪一个 Init 容器出问题
kubectl describe pod <pod-name>重点看：
- Init Containers 部分：哪个容器卡住；
- Events 事件日志：提示 DNS 失败、镜像拉取失败、命令错误等。
三、检查四大常见原因
1、 Service 未创建或命名空间不一致
-
现象 ：
nslookup myservice返回 NXDOMAIN。 -
原因 ：
myservice服务不在当前命名空间。 -
验证：
kubectl get svc -A | grep myservice
-
解决 ：
在命令中使用完整域名：myservice.<namespace>.svc.cluster.local
2、 CoreDNS 异常或未工作
-
现象：所有服务名都无法解析。
-
验证：
kubectl get pods -n kube-system -l k8s-app=kube-dns
状态应为 Running。
-
修复方法：
kubectl -n kube-system rollout restart deployment coredns
或查看配置：
kubectl -n kube-system logs -l k8s-app=kube-dns3、 Init 容器镜像过于精简，缺少命令
现象 ：日志中报 nslookup: not found。
原因 ：busybox 版本太小或工具被裁剪。
解决：
-
使用
busybox:1.35或busybox:latest -
或改用其他检测命令：
command: ['sh', '-c', 'until wget --spider --timeout=1 myservice:80; do echo waiting; sleep 2; done;']
4、 语法或逻辑错误
现象 ：CrashLoopBackOff，日志输出报错。
验证：
kubectl logs <pod-name> -c <init-container-name>检查点：
command格式是否正确；- Shell 语法是否匹配；
- 是否有权限访问命令。
四、网络验证辅助手段
创建临时测试 Pod：
kubectl run dns-test --image=busybox:latest -it --rm --restart=Never -- sh测试：
nslookup myservice.default.svc.cluster.local
wget -qO- myservice.default.svc.cluster.local如果能解析且访问正常，说明 DNS + Service 均无问题。
五、总结一张排查思维导图
[Pod Init卡住]
├── 查看状态 → kubectl describe pod
│
├── 检查命名空间
│ └── 使用完整域名 mysvc.default.svc.cluster.local
│
├── 检查CoreDNS运行状态
│ └── kubectl get pod -n kube-system -l k8s-app=kube-dns
│
├── 检查init镜像命令是否可用
│ └── busybox是否包含nslookup/wget
│
├── 查看init日志
│ └── kubectl logs pod -c init-xxx
│
└── 验证网络
└── kubectl run dns-test --image=busybox:latest -it --rm -- sh最佳实践建议
- 永远优先使用完整域名
如：mydb.default.svc.cluster.local
（简化域名依赖 search 配置，不同环境可能不一致） - 初始化逻辑简明可见
推荐直接 echo 检查日志输出，方便定位问题。 - initContainers 专注"准备"逻辑
比如等待依赖服务、加载配置、检查健康等。 - DNS 异常时先测试 CoreDNS
因为 K8s 内部所有服务发现都依赖它。