Kubernetes 通过 Init Container 和 readinessProbe 实现等效于 Docker Compose depends_on 的就绪等待，核心是等待服务真正可服务而非仅容器运行。
在从 docker compose 迁移到 kubernetes 的过渡期，依赖启动顺序本身不能直接照搬，但它的设计意图——“让服务按逻辑先后就绪”——仍是核心目标。kubernetes 不提供 depends_on 这种声明式顺序控制，而是用更健壮、分布式友好的机制来实现等效效果。关键不是复制语法，而是把 compose 里隐含的依赖逻辑，映射成 k8s 可执行的就绪保障策略。
依赖顺序的本质是就绪等待，不是容器启动排队
Compose 的 depends_on 容易让人误以为“先启 A 再启 B 就万事大吉”，但实际上 PostgreSQL 容器 running ≠ 可接受连接，Redis 容器 running ≠ 已加载 RDB、监听 6379。Kubernetes 明确区分了三个状态：
- ContainerCreating：镜像拉取、挂载卷等准备中
- Running：进程已启动（对应 Compose 的 “container running”）
- Ready：通过 readiness probe 检查，确认可服务流量（这才是真正需要等待的点）
所以迁移时，要把原来靠 depends_on 暗示的“等 DB 启动”，显式转为 “等 DB Ready”。
用 Init Container 替代 depends_on 的粗粒度等待
Init Container 是最贴近 depends_on 语义的迁移方案，尤其适合一次性前置检查，比如等数据库端口通、API 响应 200、或执行 migrate 脚本：
- 它在主容器启动前运行，失败会重试（可配
restartPolicy: Always），成功才继续 - 命令简洁：用
nc -z db-svc 5432或curl -f http://api-svc/health即可 - 不侵入主应用镜像，无需改代码，适配所有服务
例如，原 Compose 中 web 依赖 db：
web:depends_on:
- db
迁移到 K8s 后，web Pod 的 spec 中加入：
- name: wait-for-db
image: busybox
command: ['sh', '-c', 'until nc -z db-svc 5432; do sleep 2; done']
用 Readiness Probe + 应用层重试兜底真实就绪
Init Container 解决“能否连上”，但不保证“能否正确响应”。比如 Redis 容器已监听端口，但主从同步未完成，或应用第一次调用 cache.incr 仍报错。这时需双保险：
- 为主容器配置
readinessProbe，调用真实业务健康端点（如/health/redis） - 应用代码内嵌指数退避重试（如 3 次，间隔 1s/2s/4s），避免启动瞬间失败退出
- K8s 不会将未就绪的 Pod 加入 Service Endpoints，天然隔离未达标实例
这比 Compose 单靠 healthcheck + condition: service_healthy 更可靠，因为 probe 在每个 Pod 实例上独立运行，不依赖集群级状态同步。
过渡期建议：先用 Kompose 转换，再逐项强化就绪逻辑
Kompose 工具能将 docker-compose.yml 自动转成 K8s YAML，但它只做语法映射，depends_on 会被忽略，healthcheck 也不会自动变成 probe。所以推荐分三步走：
- 用
kompose convert生成基础 Deployment/Service，保留镜像、环境变量、端口等 - 人工补全 Init Container 和 readinessProbe，对照原 Compose 的 healthcheck 内容设计检查逻辑
- 本地用 Kind 或 Minikube 验证：删掉一个 Pod，观察新 Pod 是否真等 DB 就绪后再提供服务
不复杂但容易忽略
