Question

如果第一个节点出现故障，是否有可能将 pod/deployment/statefulset 移动到另一个节点或在另一个节点上自动重新创建？有问题的 pod 设置为 1 个副本。那么是否可以为 kubernetes pod 配置某种故障转移？我已经尝试了 pod 关联设置，但没有任何东西自动移动，大约 10 分钟后。

上述 pod 的 yaml 如下所示：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ceph-rbd-sc-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: ceph-rbd-sc
---
apiVersion: v1
kind: Pod
metadata:
  name: ceph-rbd-pod-pvc-sc
  labels:
    app: ceph-rbd-pod-pvc-sc
spec:
  containers:
  - name:  ceph-rbd-pod-pvc-sc
    image: busybox
    command: ["sleep", "infinity"]
    volumeMounts:
    - mountPath: /mnt/ceph_rbd
      name: volume
  nodeSelector:
    etiket: worker
  volumes:
  - name: volume
    persistentVolumeClaim:
      claimName: ceph-rbd-sc-pvc
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            name: ceph-rbd-pod-pvc-sc
        topologyKey: "kubernetes.io/hostname"

编辑：

我设法让它工作。但是现在我有另一个问题，另一个节点中新创建的 pod 卡在“容器创建”中，而旧 pod 卡在“终止”中。我还收到 Multi-Attach error for volume 说明旧 pod 仍在使用 pv。任何带有 pv 的部署/状态集的情况都是一样的，只有当出现故障的节点重新联机时才能解决问题。有解决办法吗？

Answer 1

coderanger 的回答对 Pod 仍然有效。回答您上次的编辑：

您的问题与 CSI 有关。

当您的 Pod 使用访问模式为 RWO 的 PersistentVolume 时。
当托管您的 Pod 的节点无法访问时，会提示 Kubernetes 调度程序终止当前 Pod 并在另一个节点上创建一个新的 Pod

您的 PersistentVolume 无法附加到新节点。

这样做的原因是 CSI 引入了某种“租约”，将卷标记为绑定。

在以前的 CSI 规范和实现中，就 Kubernetes API 而言，此锁不可见。如果您的 ceph-csi 部署足够新，您应该找到可以删除的相应“VolumeAttachment”对象，以解决您的问题：

# kubectl get volumeattachments -n ci
NAME                                                                   ATTACHER           PV                                         NODE                ATTACHED   AGE
csi-194d3cfefe24d5f22616fabd3d2fb2ce5f79b16bdca75088476c2902e7751794   rbd.csi.ceph.com   pvc-902c3925-11e2-4f7f-aac0-59b1edc5acf4   melpomene.xxx.com   true       14d
csi-24847171efa99218448afac58918b6e0bb7b111d4d4497166ff2c4e37f18f047   rbd.csi.ceph.com   pvc-b37722f7-0176-412f-b6dc-08900e4b210d   clio.xxx.com        true       90d
....
kubectl delete -n ci volumeattachment csi-xxxyyyzzz

在设备映射器附加卷之前，这些 VolumeAttachments 由您的 CSI 配置器创建。

只有当相应的 PV 已经从给定节点释放后，它们才会被删除，根据其设备映射器 - 需要运行，kubelet up/Node 根据 API 标记为就绪。在此之前，其他节点无法映射它。没有超时，如果节点由于网络问题或突然关闭/强制关闭/重置而无法访问：其 RWO PV 卡住了。

见：https://github.com/ceph/ceph-csi/issues/740

对此的一种解决方法是不使用 CSI，而是坚持使用旧的 StorageClass，在您的情况下，在您的节点上安装 rbd。

虽然最后我检查了 -- k8s 1.19.x -- 我无法让它工作，我不记得出了什么问题，...... CSI 往往是做到这一点的“方式”，现在.尽管不适合生产使用，但遗憾的是，除非在具有自动缩放组的 IAAS 中运行，从 Kubernetes API 中删除节点（最终驱逐相应的 VolumeAttachments），或者使用某种 MachineHealthCheck，如 OpenShift 4 实现。

Answer 2

裸 Pod 是单个不可变对象。它没有任何这些美好的东西。相关：永远不要将裸 Pod 用于任何事情。如果您使用 Deployment 尝试此操作，您应该会看到它生成一个新的，以恢复到请求的副本数。如果新 Pod 是不可调度的，您应该会看到发出的事件解释了原因。例如，如果只有节点 1 与您指定的 nodeSelector 匹配，或者另一个 Pod 已经在另一个节点上运行，从而触发了反关联性。

自动将 Pod 移动到另一个节点

2 个答案: