这个问题被讨论过很多次，但我想听听使用下面的每个方法的一些最佳实践和真实世界的例子：哪种方法更适合发现容器准备状态？
设计容器，能够检查相关服务的健康。简单脚本whait-for-it对于这类开发容器可能有用，但不适用于更复杂的部署。例如，数据库可以接受连接，但迁移尚未应用。
使容器能够在Consul/etcd中发布自己的状态。所有相关服务都将轮询某个包含所需服务状态的端点。看起来不错，但看起来多余，不是吗？
通过外部调度程序管理容器的启动顺序。
在交付过程中，上述哪种方法在Swarm/Kubernetes/etc等缺席/在线协调员环境中更可取？
我可以在这些kubernetes视角刺伤。
设计能够检查相关服务健康的容器。简单的脚本whait-for-it可以用于这种开发容器，但不适用于更复杂的部署。例如，数据库可以接受连接，但迁移尚未应用。
这听起来像你想区分生存和准备。 Kubernetes允许both types of probes这些，你可以用它来检查健康状况，并在服务任何流量之前等待。
使容器能够在Consul/etcd中发布自己的状态。所有相关服务都将轮询某个包含所需服务状态的端点。看起来不错，但看起来多余，不是吗？
我同意。不得不单独维护状态不是首选。但是，如果您确实需要存储资源状态，则可以使用third party resource。
通过外部调度程序管理容器的启动顺序。
这似乎与讨论主要相关。然而，Pet Sets，即将被Kubernetes v1.5中的状态集所取代，可为您确定pod的初始化顺序。对于单个吊舱上的集装箱，有init-containers，它们在运行主集装箱之前按顺序运行。