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

Question

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

1. 设计能够检查相关服务健康状况的容器。简单脚本whait-for-it对于这种开发容器非常有用，但不适合更复杂的部署。例如，数据库可以接受连接，但尚未进行迁移。

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

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

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

Answer 1

我可以对kubernetes的观点进行一些尝试。

  

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

这听起来像你想要区分活跃和准备。 Kubernetes允许both types of probes用于这些，您可以用来检查健康状况并在提供任何流量之前等待。

  

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

我同意。必须单独维护状态不是优选的。但是，在绝对必要的情况下，如果您确实要存储资源的状态，则可以使用third party resource。

  

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

这似乎与讨论大致相同。但是，Pet Sets很快将被Kubernetes v1.5中的有状态集替换，为您提供确定性的pod初始化顺序。对于单个容器上的容器，有init-containers在运行主容器之前按顺序连续运行。