哪种方法更适合发现容器的准备情况？

这个问题已经讨论了很多次了，但是我想听听一些使用下面每种方法的最佳实践和真实案例：

在交付过程中，上述哪种方法在Swarm / Kubernetes /等缺席/在场协调员的情况下更可取？

我可以在这些的kubernetes观点刺伤。

devise能够检查相关服务健康的容器。简单的脚本可以用于这种开发容器，但不适合更复杂的部署。例如，数据库可以接受连接，但迁移尚未应用。

这听起来像你想区分生存和准备。 Kubernetes允许这两种types的探测器，您可以使用它来检查健康状况，并在服务任何stream量之前等待。

使容器能够在Consul / etcd中发布自己的状态。所有从属服务将轮询某个包含所需服务状态的端点。看起来不错，但似乎多余，不是吗？

我同意。不得不单独维护状态不是首选。但是，在绝对必要的情况下，如果您确实想要存储资源状态，则可以使用第三方资源。

通过外部调度程序pipe理容器的启动顺序。

这似乎与讨论主要是相关的。但是，即将被Kubernetes v1.5中的Stateful Sets取代的宠物集（ Pet Sets）会给出确定性的Pod初始化顺序。对于单个容器上的容器，有一些init容器在运行主容器之前按顺序运行。