Kubernetes 如何使用 InitContainers 初始化依赖服务

InitContainer 是主容器启动前的前置任务执行器，确保依赖就绪、配置到位、数据可用：通过 nslookup/nc 等探测等待服务；用 emptyDir 共享卷传递证书或配置；按 YAML 顺序串行执行多阶段初始化。

在 Kubernetes 中，InitContainers 是专门用于在主容器启动前完成依赖准备的“前置任务执行器”。它不替代运行时健康检查，但能确保 Pod 启动那一刻，关键依赖已就绪、配置已到位、数据已可用。

等服务就绪：用循环探测确认依赖可达

InitContainer 最常见用途是等待数据库、缓存或下游服务启动完成。它通过轻量工具（如 nslookup、nc、curl）持续探测，直到目标服务响应才退出。

1. 用 nslookup 检查 DNS 解析是否生效（确认 Service 已创建且 Endpoint 就绪）
2. 用 nc -z host port 验证端口监听（确认服务进程已启动并绑定）
3. 避免写死 IP 或跳过 DNS——必须依赖 Kubernetes Service 名称，否则无法跨节点通信

共享配置与凭证：通过 emptyDir 卷传递初始化结果

InitContainer 和主容器可挂载同一 emptyDir 卷，实现安全的数据交接。比如从 Vault 获取密钥、下载 TLS 证书、生成配置文件后，直接写入共享路径，主容器启动即读取。

1. emptyDir 不持久，但生命周期覆盖整个 Pod，足够支撑启动阶段数据传递
2. 主容器的 volumeMount 必须与 InitContainer 的 mountPath 完全一致，否则路径不可见
3. 敏感内容（如 token、私钥）不应硬编码进镜像，应由 InitContainer 动态注入

多阶段串行执行：按顺序完成复杂初始化链路

多个 InitContainer 按 YAML 中声明顺序依次运行，前一个成功退出（exit 0）后，下一个才启动。适合需要严格先后关系的场景。

1. 例如：先拉取配置 → 再执行数据库迁移 → 最后设置特性开关
2. 每个 InitContainer 可使用不同镜像（alpine 做探测、postgres 做 migrate、redis-cli 控制开关），无需把所有工具塞进主镜像
3. 任一失败将导致整个 Pod 重启（默认 restartPolicy: Always），便于快速暴露问题

注意边界与风险控制

InitContainer 是启动期“守门人”，不是长期运行守护者。它只管“那一刻是否就绪”，不管“之后是否稳定”。

1. 必须设置 activeDeadlineSeconds 防止无限等待（如 300 秒超时后 Pod 进入 Failed 状态）
2. 不能配置 livenessProbe / readinessProbe —— 它们本就不支持，靠 exit code 判定成败
3. 资源请求（requests）要显式声明，否则可能因调度失败卡在 Pending 状态