这个问题已经讨论过很多次了，但我想听听一些使用以下每种方法的最佳实践和实际示例：
设计能够检查相关服务运行状况的容器。简单的脚本whait-for-it 可以用于这种开发容器，但不适合更复杂的部署。例如，数据库可以接受连接，但尚未应用迁移。
使容器能够在 Consul/etcd 中发布自己的状态。所有依赖服务将轮询包含所需服务状态的某些端点。看起来不错，但似乎是多余的，不是吗？
通过外部调度程序管理容器的启动顺序。
在交付过程中的缺席/在场编排器（如 Swarm/Kubernetes/等）的情况下，上述哪种方法更可取？
【问题讨论】：
标签： docker containers kubernetes docker-swarm service-discovery
我可以从 kubernetes 的角度来看看这些。
设计能够检查依赖服务健康状况的容器。简单的脚本 whait-for-it 对于这种开发容器很有用，但不适合更复杂的部署。例如，数据库可以接受连接，但尚未应用迁移。
这听起来像是您想区分活跃度和就绪度。 Kubernetes 允许 both types of probes 用于这些，您可以使用它来检查运行状况并在服务任何流量之前等待。
使容器能够在 Consul/etcd 中发布自己的状态。所有依赖服务将轮询包含所需服务状态的某些端点。看起来不错，但似乎是多余的，不是吗？
我同意。不必单独维护状态不是首选。但是，在绝对必要的情况下，如果你真的想存储资源的状态，可以使用third party resource。
通过外部调度器管理容器的启动顺序。
这似乎与讨论无关。但是，Pet Sets 很快将被 Kubernetes v1.5 中的 Stateful Sets 取代，它为您提供了 pod 初始化的确定顺序。对于单个 pod 上的容器，init-containers 在运行主容器之前按顺序依次运行。
【讨论】：