Kubernetes pod失败,显示“无法连接或挂载卷”

ru9i0ody  于 2023-06-28  发布在  Kubernetes
关注(0)|答案(2)|浏览(239)

Kubernetes从1.18.13升级到1.19.5后,我随机收到一些pod的error bellow。一段时间后,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:法兰绒
  • CRI:Docker
  • 只有一个节点作为主节点和工作节点
  • 16核和32G RAM

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

PV

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 beside path相同。它们具有单独的文件夹:

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

目前我没有任何线索如何诊断这个问题:(
我很乐意得到建议。先谢谢你了。

8i9zcol2

8i9zcol21#

必须使用本地卷。按照下面的链接了解如何创建存储类,pv和pvc当您使用本地卷。
https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

lskq00tm

lskq00tm2#

我建议您通过查看VolumeAttachment事件来开始故障排除,以确定是哪个节点绑定了PV,也许您的卷仍链接到处于驱逐状态的节点,并被新节点替换。
您可以使用此命令检查PV名称和状态:

kubectl get pv

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

kubectl get volumeattachment

一旦你得到了你的PV的名称以及它被附加在哪个节点上,那么你就可以看到PV是否被绑定到正确的节点上,或者它是否被绑定到了一个不工作或被删除的前一个节点上。节点被逐出并被调度到来自池的新的可用节点中;要了解哪些节点已准备就绪并正在运行,可以使用以下命令:

kubectl get nodes

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

kubectl delete volumeattachment [csi-volumeattachment_name]

如果您需要查看有关此故障排除的详细指南,可以按照this link进行操作。

相关问题