我正在玩弄Kubernetes，并设法将一个全状态应用程序（jenkins实例）部署到单个节点上。 它使用PVC来确保我可以保留我的詹金斯数据（工作，插件等）。
现在，我想尝试故障转移。
我的集群有2个数字海洋飞沫。
当前，我的jenkins吊舱仅在一个节点上运行。 当出现这种情况时，Jenkins变得不可用。
我现在正在某种程度上考虑如何完成故障转移，即当詹金斯（Jenkins）吊舱在我的节点上下降时，它将在另一个节点上旋转。 （因此，在此过程中可以将停机时间缩短）。
当然，它必须使用相同的PVC，以便我的数据保持完整。
我相信在阅读时可以使用StatefulSet kan吗？
非常感谢任何指针！
最诚挚的问候
答案 0 :(得分：3)
Digital Ocean的Kubernetes服务仅支持PVC的ReadWriteOnce访问模式（请参阅here）。这意味着该卷一次只能连接到一个节点。
我碰到了this blogpost，尽管它专注于Azure上的Jenkins，但同样只支持ReadWriteOnce。作者指出：
对我来说，缺点是，Azure Disk永久卷的访问模式为ReadWriteOnce。这意味着一次Azure磁盘一次只能连接到一个群集节点。如果节点发生故障或更新，则Azure磁盘可能需要1-5分钟之间的任何时间被分离并附加到下一个可用节点。
请注意，Pod故障和节点故障是不同的事情。由于DO仅支持ReadWriteOnce，因此就节点故障的容忍度而言，尝试比您现在拥有的更为复杂的方法没有任何好处。由于卷是ReadWriteOnce，因此需要从发生故障的节点上卸载该卷，然后将其重新安装到新节点上，然后在新节点上安排新的Pod。 Kubernetes将为您做到这一点，而您没有太多可以优化它的方法。
对于Pod失败，可以使用Deployment，因为要读取和写入相同的数据，不需要将不同的PV附加到不同的副本。这样做的好处可能非常有限，您将在同一个节点上运行Pod的多个副本，因此这取决于Jenkins流程的扩展方式以及它是否可以支持这种类型的水平横向输出模型。全部写入同一卷（与简单地垂直扩展内存或CPU请求相反）。
如果您真的想在遇到节点和/或Pod故障时实现更高的可用性，并且您正在部署的Jenkins工作负载对本地卷具有持久状态的硬性要求，则需要考虑替代的批量插件（如NFS），或迁移到其他云提供商（如GKE）。
答案 1 :(得分：0)
是的，您将根据用例使用Deployment或StatefulSet。对于詹金斯来说，使用StatefulSet是合适的。如果正在运行的Pod不可用，则StatefulSet控制器将看到该状态并生成一个新Pod。
答案 2 :(得分：0)
您要描述的是Kubernetes for Pod的默认行为，该行为由控制器（例如Deployment）管理。
即使任何应用程序仅由一个Pod组成，也应将其部署为Deployment（或另一个控制器）。您从未真正将Pods直接部署到Kubernetes。因此，在这种情况下，您无需执行任何特殊操作即可获得此行为。
当您的一个节点死亡时，Pod也将死亡。部署控制器会检测到此情况，这会创建一个新的Pod。依次由调度程序检测到，调度程序将新的Pod分配给一个节点。由于其中一个节点已关闭，因此会将Pod分配给仍在运行的另一个节点。将Pod分配到此节点后，此节点的kubelet将在此节点上运行此Pod的容器。
答案 3 :(得分：0)
好的，让我尝试在这里回答自己的问题。
我认为Amit Kumar Gupta与我所认为的最接近。
由于我在ReadWriteOnce中使用Deployment和PVC，因此我基本上只能在一个节点上使用一个运行jenkins的pod。
weibelds的答案使我意识到，我在问有关Kubernetes默认执行的概念的问题。
如果我的Pod发生故障（在我的情况下，我是通过强行掉电以模拟故障来有意关闭一个节点），则集群（控制器？）将检测到此情况，并在另一个节点上产生一个新Pod。
到目前为止，一切都很好，但是后来我注意到我的新Pod处于ContainerCreating状态。
在我的新Pod（处于describe状态的Pod上运行ContainerCreating会显示
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，但由于前一个Pod上的PV无法访问，因此它无法传输PV。
当我阅读更多内容时，我读到DigitalOcean仅支持ReadWriteOnce，这让我想知道，如何在数字海洋上的Kubernetes集群上实现一个有状态应用程序的简单故障转移，包括只是几个简单的液滴？