InitContainer 可以理解为主容器正式启动前的一道“准备工序”：它的作用，就是把依赖、配置和数据这些前提条件先处理妥当。常见做法包括用 nslookup、nc 这类探测手段持续等待目标服务就绪；通过 emptyDir 共享卷传递证书或配置文件；再按照 YAML 中定义的顺序，串行完成多个阶段的初始化任务。
在 Kubernetes 体系里，InitContainers 更像是主容器正式启动前的一道“准备工序”：专门把依赖初始化这类前置工作先做完。它并不是用来替代运行时健康检查的，但价值恰恰在于，能够让 Pod 在启动的那个时间点上，关键依赖已经就绪、配置已经落地、数据也已经处于可用状态。
等服务就绪：用循环探测确认依赖可达
InitContainer 最常见用途是等待数据库、缓存或下游服务启动完成。它通过轻量工具（如 nslookup、nc、curl）持续探测，直到目标服务响应才退出。
- 用
nslookup检查 DNS 解析是否生效（确认 Service 已创建且 Endpoint 就绪） - 用
nc -z host port验证端口监听（确认服务进程已启动并绑定） - 避免写死 IP 或跳过 DNS——必须依赖 Kubernetes Service 名称，否则无法跨节点通信
共享配置与凭证：通过 emptyDir 卷传递初始化结果
InitContainer 和主容器可挂载同一 emptyDir 卷，实现安全的数据交接。比如从 Vault 获取密钥、下载 TLS 证书、生成配置文件后，直接写入共享路径，主容器启动即读取。
- emptyDir 不持久，但生命周期覆盖整个 Pod，足够支撑启动阶段数据传递
- 主容器的 volumeMount 必须与 InitContainer 的 mountPath 完全一致，否则路径不可见
- 敏感内容（如 token、私钥）不应硬编码进镜像，应由 InitContainer 动态注入
多阶段串行执行：按顺序完成复杂初始化链路
多个 InitContainer 按 YAML 中声明顺序依次运行，前一个成功退出（exit 0）后，下一个才启动。适合需要严格先后关系的场景。
- 例如：先拉取配置 → 再执行数据库迁移 → 最后设置特性开关
- 每个 InitContainer 可使用不同镜像（alpine 做探测、postgres 做 migrate、redis-cli 控制开关），无需把所有工具塞进主镜像
- 任一失败将导致整个 Pod 重启（默认 restartPolicy: Always），便于快速暴露问题
注意边界与风险控制
InitContainer 是启动期“守门人”，不是长期运行守护者。它只管“那一刻是否就绪”，不管“之后是否稳定”。
- 必须设置
activeDeadlineSeconds防止无限等待（如 300 秒超时后 Pod 进入 Failed 状态） - 不能配置 livenessProbe / readinessProbe —— 它们本就不支持，靠 exit code 判定成败
- 资源请求（requests）要显式声明，否则可能因调度失败卡在 Pending 状态
