对象定位
Init 容器是 Pod 里在主容器之前运行的专用容器:按声明顺序串行执行,每个都必须正常退出(退出码 0)才轮到下一个,全部成功之后主容器才会启动。适用平台是 Kubernetes。它把「等依赖就绪」「准备数据目录」「生成配置文件」这类一次性动作从主容器里拆出去,让主容器进程保持单一职责,不用为了等数据库而在启动脚本里写循环。
基本信息
| 适用平台 | Kubernetes,Pod 级字段 spec.initContainers |
|---|---|
| 执行顺序 | 按数组顺序串行,前一个成功才启动下一个 |
| 失败行为 | 按 Pod 的 restartPolicy 重试,状态显示 Init:Error 或 Init:CrashLoopBackOff |
| 能力限制 | 不支持 lifecycle 与 readinessProbe,可以挂载卷、设资源限制与安全上下文 |
典型使用场景
- 等待依赖可用:直到数据库端口能连上再启动应用,避免主容器反复崩溃
- 数据初始化:把镜像里的种子数据复制到共享卷,或在空目录上生成默认配置
- 权限与属主准备:以 root 初始化挂载目录的属主与权限,主容器再以非 root 运行
- 配置渲染:结合模板与 ConfigMap 生成最终配置文件,主容器只负责读取
- 镜像拉取预热:提前拉取主容器镜像,缩短就绪时间
示例
示例
spec:
initContainers:
- name: wait-db
image: busybox:1.36
command: ['sh', '-c', 'until nc -z db 5432; do echo waiting; sleep 2; done']
- name: init-data
image: registry.example.com/tools:1.2
command: ['sh', '-c', 'cp -n /seed/* /data/ || true']
volumeMounts:
- name: data
mountPath: /data
containers:
- name: app
image: registry.example.com/app:1.26.0
volumeMounts:
- name: data
mountPath: /data查看进度与日志
查看进度与日志
kubectl get pod web-x -o wide # STATUS 形如 Init:0/2、Init:1/2
kubectl logs web-x -c wait-db # 指定 init 容器看日志
kubectl logs web-x -c init-data --previous # 上一次尝试的输出
kubectl describe pod web-x | grep -A12 'Init Containers' # 各自的退出码与原因状态读法
| 状态 | 含义 | 排查方向 |
|---|---|---|
| Init:0/2 | 第一个 init 容器还没成功 | 看第一个容器的日志 |
| Init:1/2 | 第一个已成功,卡在第二个 | 看第二个容器的日志与退出码 |
| Init:Error | 某个 init 容器非 0 退出 | describe 里的 Reason 与退出码 |
| Init:CrashLoopBackOff | 反复启动即失败 | 命令写错、依赖不可达或权限不足 |
Init 容器串行执行,每个必须是退出码 0 才算成功;Pod 状态里的 Init:0/2 之类就是当前进度,是最直观的卡点提示。
多个 init 容器共享 Pod 的卷与网络命名空间,但不与主容器共享文件系统,数据要通过卷传递。