我有一个 23 节点的集群，在 AWS 上跨 4 个可用区运行 CoreOS Stable 681.2.0。所有节点都在运行 etcd2 和 flannel。在这 23 个节点中，8 个是专用的 etcd2 节点，其余的专门指定为 etcd2 代理。
为集群安排了 3 个 nginx 加容器、一个私有(private) Docker 注册表、SkyDNS 和我们的 4 个应用程序容器。应用程序容器向 etcd2 注册，nginx 容器接收任何更改，呈现必要的文件，最后重新加载。
这一切都很好，直到单个 etcd2 节点因任何原因不可用。
如果投票 etcd2 成员集群失去与其他投票 etcd2 成员的连接，则调度到队列的所有服务都会变得不稳定。预定服务开始停止和启动，无需我的干预。
作为测试，我开始停止托管投票 etcd2 节点的 EC2 实例，直到失去法定人数。第一个etcd2节点停止后，开始出现上述症状。在第二个节点之后，服务变得不稳定，没有可观察到的变化。然后，在第三个停止后，法定人数丢失，所有单位都未计划。然后我再次启动所有三个 etcd2 节点，在 60 秒内集群恢复到稳定状态。
随后的测试产生相同的结果。
我是否遇到了 etcd2、fleet 或 CoreOS 中的已知错误？
即使 etcd 因任何原因不可用，我是否可以修改设置以将单元安排到节点上？
最佳答案
我也经历过同样的事情。就我而言，当我运行 1 个特定单元时，它导致一切都炸了。计划好的和完美运行的单元在没有任何通知的情况下突然丢失，甚至机器退出集群。
我仍然不确定确切的问题是什么，但我认为它可能与 etcd 与 etcd2 有关。我在单元文件中依赖于 etcd.service，这(我认为，不确定)导致 CoreOS 尝试启动 etcd.service，而 etcd2.service 已经在运行。在我的情况下，这可能导致了冲突，并弄乱了单位和机器的 etcd 注册表。
类似的事情可能发生在你身上，所以我建议你检查每台主机是运行 etcd 还是 etcd2 并检查你的单元文件，看看它们依赖哪一个。
关于amazon-ec2 - CoreOS、Fleet 和 Etcd2 容错，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/31249941/