Kubernetes pod 失败并显示“无法附加或挂载卷”

Question

在 Kubernetes 从 1.18.13 升级到 1.19.5 后，我随机收到一些 pod 的错误如下。 一段时间后 pod 无法启动（这是一个简单的 pod，不属于部署）

  Warning  FailedMount  99s   kubelet  Unable to attach or mount volumes: unmounted volumes=[red-tmp data logs docker src red-conf], unattached volumes=[red-tmp data logs docker src red-conf]: timed out waiting for the condition

• 在 1.18 上我们没有这样的问题，在升级过程中 K8S 也没有显示任何错误或不兼容消息。
• 没有来自任何其他 K8S 组件的额外日志（试图增加 kubelet 的详细级别）
• 磁盘空间和其他主机的指标（如 LA、RAM）一切正常
• 没有网络存储，只有本地数据
• PV 和 PVC 在 Pod 之前创建，我们不会更改它们
• 尝试使用更高版本的 K8S 但没有运气

我们有非常标准的设置，没有任何特殊的自定义：

• CNI：法兰绒
• 国际广播电台：码头工人
• 只有一个节点作为master和worker
• 16 核和 32G 内存

pod 定义示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: provision
    ver: latest
  name: provision
  namespace: red
spec:
  containers:
  - args:
    - wait
    command:
    - provision.sh
    image: app-tests
    imagePullPolicy: IfNotPresent
    name: provision
    volumeMounts:
    - mountPath: /opt/app/be
      name: src
    - mountPath: /opt/app/be/conf
      name: red-conf
    - mountPath: /opt/app/be/tmp
      name: red-tmp
    - mountPath: /var/lib/app
      name: data
    - mountPath: /var/log/app
      name: logs
    - mountPath: /var/run/docker.sock
      name: docker
  dnsConfig:
    options:
    - name: ndots
      value: "2"
  dnsPolicy: ClusterFirst
  enableServiceLinks: false
  restartPolicy: Never
  volumes:
  - hostPath:
      path: /opt/agent/projects/app-backend
      type: Directory
    name: src
  - name: red-conf
    persistentVolumeClaim:
      claimName: conf
  - name: red-tmp
    persistentVolumeClaim:
      claimName: tmp
  - name: data
    persistentVolumeClaim:
      claimName: data
  - name: logs
    persistentVolumeClaim:
      claimName: logs
  - hostPath:
      path: /var/run/docker.sock
      type: Socket
    name: docker

光伏

apiVersion: v1
kind: PersistentVolume
metadata:
  name: red-conf
  labels:
    namespace: red
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 2Gi
  hostPath:
    path: /var/lib/docker/k8s/red-conf
  persistentVolumeReclaimPolicy: Retain
  storageClassName: red-conf
  volumeMode: Filesystem

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: conf
  namespace: red
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: red-conf
  volumeMode: Filesystem
  volumeName: red-conf

tmp data logs pv 具有与路径旁边的conf相同的设置。 他们有单独的文件夹：

/var/lib/docker/k8s/red-tmp
/var/lib/docker/k8s/red-data
/var/lib/docker/k8s/red-logs

目前我没有任何线索如何诊断问题:(

很高兴得到建议。 提前致谢。

Answer 1

您必须使用本地卷。 按照以下链接了解如何在使用本地卷时创建存储类、pv 和 pvc。

https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

Answer 2

我建议您通过查看VolumeAttachment事件与哪个节点绑定了 PV 来开始故障排除，也许您的卷仍然链接到处于驱逐状态并被新节点替换的节点。

您可以使用此命令检查您的 PV 名称和状态：

kubectl get pv

然后，要查看哪个节点具有正确的卷附件，可以使用以下命令：

kubectl get volumeattachment

一旦你获得了你的 PV 的名称以及它连接到哪个节点，那么你将能够查看 PV 是否绑定到正确的节点，或者它是否绑定到先前不工作或已删除的节点。 该节点被驱逐并从池中调度到一个新的可用节点； 要知道哪些节点已准备好并正在运行，您可以使用以下命令：

kubectl get nodes

如果您检测到您的 PV 与不再存在的节点绑定，则需要使用以下命令删除 VolumeAttachment：

kubectl delete volumeattachment [csi-volumeattachment_name] 

如果您需要查看有关此故障排除的详细指南，可以点击此链接。