running ZooKeeper in Kubernetes的示例显示了在节点从连接中耗尽后如何在不同节点上重新安排pod，通常是因为必须对其执行维护。
使用与之前相同的身份重新安排pod，在本例中为myid ZooKeeper服务器，对应于每个pod zk-0的增量编号，zk-1等等
如果节点没有响应（可能是由于过载或网络问题），Kubernetes是否可以在原始pod仍在运行时重新安排另一个节点上的pod？
似乎是some of this behavior has been specified explicitly，但我不知道如何在云提供商上设置多个节点并尝试验证它。
答案 0 :(得分：3)
如果节点没有响应，Kubernetes＆gt; = 1.5将不重新安排具有相同标识的pod，直到确认它已被终止。关于StatefulSet的行为详细here。
Kubernetes（1.5或更新版本）不会因为a而删除Pod 节点无法访问。在无法访问的节点上运行的Pod进入 超时后“终止”或“未知”状态。豆荚也可能进入 当用户尝试正常删除一个Pod时，这些状态 无法访问的节点。 Pod处于这种状态的唯一方式是 从apiserver中删除如下：
- Node对象是 删除（由您或节点控制器删除）。
- kubelet上 无响应的节点开始响应，杀死Pod并删除 来自apiserver的进入。
- 强制用户删除Pod。
由于pod的名称是一个锁，我们从不创建具有相同标识的两个pod，为StatefulSets提供了“最多一个”语义。用户可以通过执行强制删除（并手动保证pod被隔离）来覆盖此行为，但是没有自动化可以导致两个具有相同标识的pod。
Kubernetes 1.5的变化确保我们在StatefulSets的情况下优先考虑安全性。 Node Controller documentation有关于此更改的一些详细信息。您可以阅读完整的提案here。