Init容器是Kubernetes中按定义顺序串行执行的预启动环节，每个必须成功退出后才启动下一个，全部完成后主容器才并行启动；其生命周期短暂、不支持探针，通过共享卷与主容器通信，实现初始化与业务逻辑解耦。
Kubernetes 通过 Init 容器（Init Containers） 来处理容器启动时的初始化逻辑，而不是把准备动作塞进主应用容器里。它提供了一个清晰、可控、可复用的“预启动阶段”，让初始化任务与业务逻辑彻底解耦。
Init 容器的核心执行机制
Init 容器不是并行运行的附属组件，而是 Pod 启动流程中的强制前置环节：
- 多个 Init 容器按 YAML 中定义的顺序 串行执行，前一个必须以 exit code 0 成功退出，后一个才开始
- 所有 Init 容器全部成功完成后，主容器（spec.containers）才会被同时启动
- 任一 Init 容器失败，Pod 不会进入 Running 状态；Kubernetes 根据 restartPolicy 决定是否重启整个 Pod（Never 不重试，OnFailure/Always 会重建 Pod）
- Init 容器生命周期极短——任务完成即终止，不会长期运行或参与后续健康检查
为什么不用主容器自己做初始化？
把初始化逻辑硬编码到主镜像中，会带来实际运维问题：
- 镜像臃肿：为了一次性操作（比如用 curl 检查 DB），不得不在生产镜像里打包调试工具
- 权限风险：需要 root 权限修改内核参数或挂载目录，但主容器通常应以非 root 运行
- 启动不可控：主容器可能因依赖未就绪而反复 CrashLoopBackOff，日志混乱、排障困难
- 职责混杂：业务代码里夹杂环境探测、配置生成等非业务逻辑，违反单一职责原则
典型初始化任务怎么落地
常见场景都有对应实践模式，关键在于选择合适镜像和命令逻辑：
- 等待依赖服务就绪：用 busybox 或 curl 镜像执行 nc -z db:3306 或 curl -f http://api:8080/health，失败则 sleep 2 后重试
- 生成配置文件：挂载 ConfigMap/Secret + emptyDir 卷，在 Init 容器中用 envsubst 或 sed 渲染模板，写入共享卷供主容器读取
- 设置系统参数或目录权限：用特权 init 镜像运行 sysctl -w 或 chmod -R 755 /data，避免主容器需额外权限
- 预加载数据或下载资源：从对象存储拉取大体积模型文件、初始化数据库 schema 脚本等
使用时要注意的关键细节
Init 容器看似简单，但几个限制点容易踩坑：
- 不支持 livenessProbe 和 readinessProbe —— 它没有“就绪”概念，只管跑完或失败
- 必须保证脚本幂等：多次执行不能导致重复创建、重复初始化（比如 mkdir -p、echo >> config）
- 共享卷是主要通信方式：Init 容器和主容器通过同一 volumeName 传递文件或状态
- 资源限制要合理：Init 容器虽短暂，但若占用过多 CPU/Memory，会影响 Pod 调度和主容器启动
