running ZooKeeper in Kubernetes的例子显示了如何在节点从连接中耗尽后在不同节点上重新安排 pod，这通常是因为必须对其执行维护。
pod 被重新调度为与之前相同的标识，在本例中为 myid ZooKeeper 服务器，对应于每个 pod zk-0 的增量编号， zk-1 等等
如果一个节点没有响应(可能是由于过载或网络问题)，Kubernetes 是否可以在原始 pod 仍在运行时将 pod 重新调度到另一个节点上？
好像some of this behavior has been specified explicitly ，但我不知道如何验证它，除非在云提供商上设置多个节点并进行尝试。
最佳答案
如果一个节点没有响应，Kubernetes >=1.5 将不会重新调度具有相同标识的 pod，直到确认它已被终止。关于 StatefulSet 的行为详述 here .
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the ‘Terminating’ or ‘Unknown’ state after a timeout. Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
- The Node object is deleted (either by you, or by the Node Controller).
- The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
- Force deletion of the Pod by the user.
由于 pod 的名称是一把锁，我们永远不会创建两个具有相同标识的 pod，这为我们提供了 StatefulSet 的“至多一个”语义。用户可以通过执行强制删除(并手动保证 pod 被隔离)来覆盖此行为，但没有自动化可以导致两个 pod 具有相同的身份。
Kubernetes 1.5 中的变化确保我们在使用 StatefulSet 时优先考虑安全性。 Node Controller documentation有一些关于变化的细节。您可以阅读完整的提案 here .
关于Kubernetes 在节点变得不可访问后重新安排 pod，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41926177/