这个问题已经讨论了很多次，但我想听听一些使用以下每种方法的最佳实践和实际例子：
设计能够检查相关服务健康状况的容器。简单脚本whait-for-it对于这种开发容器非常有用，但不适合更复杂的部署。例如，数据库可以接受连接，但尚未进行迁移。
使容器能够在Consul / etcd中发布自己的状态。所有相关服务都将轮询某个包含所需服务状态的端点。看起来不错，但似乎多余，不是吗？
通过外部调度程序管理容器的启动顺序。
在交付过程中，如Swarm / Kubernetes / etc等缺席/存在协调器的情况下，上述哪种方法更可取？
答案 0 :(得分：3)
我可以对kubernetes的观点进行一些尝试。
设计能够检查相关服务健康状况的容器。简单的脚本对于这种开发容器非常有用，但不适合更复杂的部署。例如，数据库可以接受连接，但尚未应用迁移。
这听起来像你想要区分活跃和准备。 Kubernetes允许both types of probes用于这些，您可以用来检查健康状况并在提供任何流量之前等待。
使容器能够在Consul / etcd中发布自己的状态。所有相关服务都将轮询某个包含所需服务状态的端点。看起来不错，但似乎多余，不是吗？
我同意。必须单独维护状态不是优选的。但是，在绝对必要的情况下，如果您确实要存储资源的状态，则可以使用third party resource。
通过外部调度程序管理容器的启动顺序。
这似乎与讨论大致相同。但是，Pet Sets很快将被Kubernetes v1.5中的有状态集替换，为您提供确定性的pod初始化顺序。对于单个容器上的容器，有init-containers在运行主容器之前按顺序连续运行。