如何自动删除失败的 Kubernetes Ceph 节点？答案

【问题标题】：How can a failed Kubernetes Ceph node be deleted automatically?如何自动删除失败的 Kubernetes Ceph 节点？
【发布时间】：2020-07-28 20:39:19
【问题描述】：

在具有多个节点并在 RWO 模式下使用 Ceph 块卷的环境中，如果某个节点发生故障（无法访问且不会很快恢复）并且 Pod 被重新调度到另一个节点，则 Pod 无法启动：它有一个 Ceph 块 PVC。原因是该卷被另一个 pod '仍在使用'（因为节点发生故障，它的资源无法正确移除）。

如果我使用 kubectl delete node dead-node 从集群中删除节点，则 pod 可以启动，因为资源已被删除。

如何自动执行此操作？我想过的一些可能性是：

我可以为卷设置强制分离超时吗？
设置删除节点超时？
自动删除具有给定污点的节点？

我可以将ReadWriteMany模式与其他volume类型一起使用，可以让PV被多个pod使用，但并不理想。

【问题讨论】：

标签： kubernetes ceph

【解决方案1】：

您可能有一个 sidecar container 并在您的 pod 中调整 Readiness and Liveness 探针，以便在使用它的容器在一段时间内无法访问 Ceph 块卷时，该 pod 不会重新启动。（但可能对您的应用程序有其他影响）

类似这样的：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: ceph
  name: ceph-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
  - name: cephclient
    image: ceph
    volumeMounts:
    - name: ceph
      mountPath: /cephmountpoint
    livenessProbe:
      ... ? something
      initialDelaySeconds: 5
      periodSeconds: 3600 ? make this real long

✌️☮️

【讨论】：

您可能误解了这个问题：OP 有一个问题，即卷被“附加”到不健康的节点上，如果没有手动干预就无法分离。
谢谢。是的，我一开始就想防止这个问题?
我认为你无法阻止这种情况：比如节点断电、内核崩溃、cpu 烧毁、kubelet 崩溃或发生其他任何事情。有数百万种方法可以让节点不健康。
是的，但是 Ceph 不提供这种冗余吗？意思是如果它的节点出现故障？这不是“虚拟卷”吗？我关于防止它的想法不是关于防止 ceph 节点是否关闭，而是更多关于防止 pod 重新启动，如果 ceph 卷在一段时间内变得无响应，然后根据 ceph 冗余稍后自行恢复。我可能误解了 ceph 的工作原理。
我相信问题是关于 clients 而不是 ceph 服务器。 “原因是该卷被另一个 pod '仍在使用'（因为节点发生故障，它的资源无法正确删除）。”所以客户端节点消失了，kubernetes 仍然认为卷是附加的，除非你手动干预，否则不会解析。