Init 容器是什么
Init 容器在主容器启动之前按顺序执行,每一个都必须成功退出,之后主容器才会启动。它适合做依赖等待、数据库迁移、生成配置文件这类一次性的准备工作。任何一步失败,整个初始化序列会按 Pod 的重启策略重试;Init 容器不支持生命周期钩子与就绪探针,但支持资源限制,并且与主容器共享卷和网络命名空间,因此既能传文件也能直接探测本地端口。
基本信息
| 执行顺序 | 依次串行执行,全部成功后才启动主容器 |
|---|---|
| 失败语义 | 失败即按 Pod 的重启策略重试整个初始化序列 |
| 能力限制 | 不支持 lifecycle 与 readinessProbe,支持资源限制 |
| 共享资源 | 与主容器共享卷与网络命名空间 |
| 排错方式 | kubectl logs <pod> -c <init 容器名> 单独查看初始化日志 |
典型使用场景
- 等待数据库或消息队列真正可连接之后再启动应用
- 执行数据库结构迁移脚本,保证应用启动前表结构已就绪
- 生成或渲染配置文件写入共享卷,供主容器读取
- 调整共享卷的属主与权限,让非 root 主容器可以正常写入
- 一次性拉取初始化数据或预热缓存,避免主容器启动时抢资源
等待依赖示例
等待依赖示例
spec:
initContainers:
- name: wait-db
image: busybox:1.36
command: ["sh", "-c", "until nc -z db 3306; do echo waiting db; sleep 2; done"]
resources:
requests: { cpu: 50m, memory: 64Mi }
containers:
- name: app
image: registry.example.com/team/app:1.2.3
与主容器对比
| 维度 | Init 容器 | 主容器 |
|---|---|---|
| 执行方式 | 串行执行且必须成功退出 | 长期运行 |
| 就绪探针 | 不支持 | 支持 |
| 生命周期钩子 | 不支持 | 支持 |
| 资源限制 | 支持 | 支持 |
| 失败影响 | 主容器不会启动 | 按重启策略处理 |
把『依赖就绪』放进 Init 容器只解决了启动时序:运行过程中依赖发生闪断,仍然需要应用侧具备重连与降级能力,两者的职责并不相同。
用固定等待时间(例如睡 30 秒)代替真实探测并不稳妥:环境稍慢就会失败重试,应改为循环探测,直到依赖真的可用再退出。