1. 概述
Kubernetes 是目前最主流的容器编排平台，广泛用于管理微服务架构。然而，在部署这类架构时，常常会遇到一个现实问题：由于服务之间存在依赖关系，某些服务必须按照特定顺序启动。
从设计角度来说，我们应尽量设计无状态（stateless）的容器，这样它们可以随时重启、替换或扩展，而不会影响系统整体的健康状态。但在实际场景中，有时仍需要对启动顺序进行控制。
本文将介绍几种在 Kubernetes 中控制服务、Pod 和 Deployment 启动顺序的方法。
2. Init Containers（初始化容器）
当需要在单个 Pod 内部控制初始化顺序时，可以使用 Kubernetes 的 Init Containers（初始化容器） 机制。✅
Init Containers 是在主应用容器启动之前执行的特殊容器，用于完成必要的初始化工作。
它与普通容器有两个关键区别：
- ✅ Init Containers 会顺序执行，直到完成才会启动主容器。
- ❌ 不支持 livenessProbe、readinessProbe 等健康检查机制。
如果某个 Init Container 执行失败，Kubernetes 会根据 restartPolicy 进行重试。若 restartPolicy 为 Never，则整个 Pod 会被标记为失败。
示例
下面是一个使用 Init Containers 的 Pod 定义：
apiVersion: v1
kind: Pod
metadata:
name: init-demo
spec:
containers:
- name: main-app
image: main-app-image
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: alpine
command: ['sh', '-c', 'until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: alpine
command: ['sh', '-c', 'until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done;']
在这个例子中，两个初始化容器分别等待 myservice 和 mydb 服务可用后，主容器才会启动。这种机制非常适合用于解决服务依赖问题。
3. 控制 Pod 的启动顺序
有时我们需要确保一个 Pod 已经进入 Ready 状态后，再继续后续操作。这在自动化部署流水线中非常有用。
在 Kubernetes 中，我们可以通过组合使用 kubectl run 和 kubectl wait 命令来实现这一目的。
示例
以 Apache HTTP Server 为例：
$ kubectl run myhttpd -n default --image=httpd:latest --restart=Never
$ kubectl wait pods -n default -l run=myhttpd --for condition=Ready --timeout=90s
- 第一条命令创建一个名为
myhttpd的 Pod。 - 第二条命令等待该 Pod 进入 Ready 状态，最多等待 90 秒。
我们也可以使用如下命令查看 Pod 的状态详情：
$ kubectl get pod -n default -l run=myhttpd -o jsonpath="{.items[*].status.conditions}" | jq
小结
这种机制非常适合用于串行化部署流程，例如：
- 先部署数据库 Pod
- 等待数据库 Pod Ready
- 再部署依赖数据库的应用 Pod
4. 控制 Deployment 的启动顺序
Deployment 是 Kubernetes 中更高级别的资源类型，用于管理 ReplicaSet，进而控制 Pod 生命周期。在部署多个 Deployment 时，有时也需要控制它们的启动顺序。
Kubernetes 提供了 rollout 命令来监控 Deployment 的状态。
示例
以 NGINX Deployment 为例：
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/deployment.yaml
部署完成后，我们可以通过如下命令重启并监控其状态：
$ kubectl rollout restart deployment nginx-deployment -n default
$ kubectl rollout status deployment nginx-deployment -n default --timeout=90s
kubectl rollout restart会触发 Deployment 的滚动更新。kubectl rollout status会持续检查更新状态，直到完成或超时。
小结
通过这种方式，我们可以确保一个 Deployment 完全就绪后，再进行下一个操作。例如：
- 部署基础服务 Deployment A
- 使用 rollout status 等待 A 就绪
- 再部署依赖 A 的 Deployment B
5. 总结
本文介绍了三种在 Kubernetes 中控制启动顺序的方法：
| 方法 | 适用场景 | 关键命令/机制 |
|---|---|---|
| Init Containers | 单个 Pod 内部顺序控制 | Pod spec 中定义 initContainers |
| kubectl wait | 控制 Pod 是否 Ready | kubectl wait --for=condition=Ready |
| rollout status | 控制 Deployment 更新状态 | kubectl rollout status |
虽然 Kubernetes 鼓励无状态设计，但在实际生产环境中，服务依赖仍然存在。通过上述方法，我们可以优雅地控制资源的启动顺序，从而提升系统的稳定性和可靠性。✅
💡 Tips
在编写 Init Containers 时，注意避免死循环或无限等待，否则可能导致 Pod 一直处于 Pending 状态。可以考虑加入超时逻辑或使用 sidecar 模式替代。