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
如果节点无响应，Kubernetes >=1.5 将不重新调度具有相同身份的 pod，直到确认它已被终止。关于 StatefulSet 的行为详解here。
Kubernetes（1.5 或更高版本）不会仅仅因为 节点不可访问。在不可达节点上运行的 Pod 进入 超时后的“终止”或“未知”状态。豆荚也可能进入 当用户尝试优雅地删除 Pod 时的这些状态 无法访问的节点。处于这种状态的 Pod 的唯一方法是 从 apiserver 中删除如下：
- 节点对象是 删除（由您或由节点控制器）。
- kubelet 开启 无响应的节点开始响应，杀死 Pod 并移除 来自 apiserver 的条目。
- 用户强制删除 Pod。
由于 pod 的名称是一个锁，我们永远不会创建两个具有相同身份的 pod，从而为 StatefulSet 提供了“最多一个”语义。用户可以通过执行强制删除（并手动确保 pod 被隔离）来覆盖此行为，但没有自动化可以导致两个具有相同身份的 pod。
Kubernetes 1.5 中的更改确保我们在 StatefulSet 的情况下优先考虑安全性。 Node Controller documentation 有一些有关更改的详细信息。你可以阅读完整的提案here。
【讨论】：