這個問題被討論過很多次，但我想聽聽使用下面的每個方法的一些最佳實踐和真實世界的例子：哪種方法更適合發現容器準備狀態？
設計容器，能夠檢查相關服務的健康。簡單腳本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，它們在運行主集裝箱之前按順序運行。