我正在玩弄 Kubernetes，并设法将一个有状态的应用程序(jenkins 实例)部署到单个节点。 它使用 PVC 来确保我可以持久化我的 jenkins 数据(作业、插件等)。
现在，我想尝试故障转移。
我的星团有 2 个数字海滴。
目前我的 jenkins pod 只在一个节点上运行。 当这种情况下降时，Jenkins 变得不可用。
我现在正在寻找如何完成故障转移，从某种意义上说，当 jenkins pod 在我的节点上关闭时，它将在另一个节点上旋转。(因此，在此过程中的停机时间很短是可以的)。
当然，它必须使用相同的PVC，以便我的数据保持不变。
我相信，在阅读时，有状态集坎用于此？
任何指示都非常感谢！
此致敬意
Digital Ocean的Kubernetes服务仅支持PVC的ReadWriteOnce访问模式(见这里)。这意味着卷一次只能附加到一个节点。
我遇到了这篇博文，虽然专注于 Azure 上的 Jenkins，但也有同样的情况，只支持ReadWriteOnce.作者指出：
不过，对我来说的缺点在于Azure磁盘持久卷的访问模式是读写一次。这意味着 Azure 磁盘一次只能附加到一个群集节点。如果节点发生故障或更新，Azure 磁盘可能需要 1-5 分钟才能分离并附加到下一个可用节点。
请注意，Pod故障和节点故障是不同的事情。 由于DO仅支持ReadWriteOnce，因此在对节点故障的容忍度方面，尝试比现在更复杂的方法没有任何好处。由于卷ReadWriteOnce因此需要从故障节点卸载卷并重新装载到新节点，然后在新节点上计划新Pod。Kubernetes 会为你做这件事，你无能为力来优化它。
对于Pod故障，可以使用Deployment，因为要读取和写入相同的数据，不希望将不同的 PV 附加到不同的副本。这样做的好处可能非常有限，您将在同一节点上运行Pod的多个副本，因此这取决于 Jenkins 进程的扩展方式以及它是否可以支持这种类型的横向扩展模型，同时所有写入同一卷(而不是简单地垂直扩展内存或 CPU 请求)。
如果你真的想在面对节点和/或Pod故障时实现更高的可用性，并且你部署的 Jenkins 工作负载对本地卷的持久状态有硬性要求，你将需要考虑一个替代的卷插件，如 NFS，或迁移到不同的云提供商，如 GKE。
是的，您将使用部署或状态集，具体取决于用例。对于 Jenkins 来说，StatefulSet 是合适的。如果正在运行的 Pod 变得不可用，StatefulSet 控制器将看到该 Pod 并生成一个新 pod。
你所描述的是 Kubernetes for Pod 的默认行为，这些 Pod 由控制器管理，例如部署。
您应该将任何应用程序部署为部署(或其他控制器)，即使它仅由单个 Pod 组成。你从来没有真正将 Pod 直接部署到 Kubernetes 上。因此，在这种情况下，您无需执行任何特殊操作即可获得此行为。
当你的一个节点死亡时，Pod 也会死亡。部署控制器会检测到这一点，并创建一个新的 Pod。这反过来又被调度器检测到，调度程序将新 Pod 分配给节点。由于其中一个节点关闭，它会将 Pod 分配给另一个仍在运行的节点。一旦 Pod 被分配给这个节点，这个节点的 kubelet 就会在这个节点上运行这个 Pod 的容器。
好的，让我试着在这里提出我自己的问题。 我认为Amit Kumar Gupta最接近我认为这里正在发生的事情。
由于我在ReadWriteOnce中使用了部署和我的 PVC，所以我基本上被困在一个节点上运行 jenkins 的一个 pod。
weibelds答案让我意识到我是在问一个关于 Kubernetes 默认执行的概念的问题。 如果我的 Pod 出现故障(在我的例子中，我故意通过硬断电来模拟故障来关闭节点)，集群(控制器？)将检测到这一点并在另一个节点上生成一个新的 Pod。
到目前为止一切都很好，但后来我注意到我的新 pod 卡在ContainerCreating状态。
在我的新 pod(处于ContainerCreating状态的 pod)上运行describe显示了这一点
Warning FailedAttachVolume 16m attachdetach-controller Multi-Attach error for volume "pvc-cb772fdb-492b-4ef5-a63e-4e483b8798fd" Volume is already used by pod(s) jenkins-deployment-6ddd796846-dgpnm
Warning FailedMount 70s (x7 over 14m) kubelet, cc-pool-bg6u Unable to mount volumes for pod "jenkins-deployment-6ddd796846-wjbkl_default(93747d74-b208-421c-afa4-8d467e717649)": timeout expired waiting for volumes to attach or mount for pod "default"/"jenkins-deployment-6ddd796846-wjbkl". list of unmounted volumes=[jenkins-home]. list of unattached volumes=[jenkins-home default-token-wd6p7]
然后它开始打击我，这是有道理的。 这很可怜，但这是有道理的。
由于我在节点上进行了硬电源关闭，因此PV随之关闭。 因此，现在控制器尝试在新节点上启动一个新 pod，但它无法传输 PV，因为前一个 pod 上的 PV 变得无法访问。
当我阅读更多关于此的内容时，我读到DigitalOcean仅支持ReadWriteOnce，这让我想知道，我该如何为Digital Ocean上的Kubernetes集群上的有状态应用程序实现简单的故障转移，该应用程序仅由几个简单的液滴组成？