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
目前我没有任何线索如何诊断这个问题:(
我很乐意得到建议。先谢谢你了。
2条答案
按热度按时间8i9zcol21#
必须使用本地卷。按照下面的链接了解如何创建存储类,pv和pvc当您使用本地卷。
https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/
lskq00tm2#
我建议您通过查看VolumeAttachment事件来开始故障排除,以确定是哪个节点绑定了PV,也许您的卷仍链接到处于驱逐状态的节点,并被新节点替换。
您可以使用此命令检查PV名称和状态:
然后,要查看哪个节点具有正确的卷附件,可以使用以下命令:
一旦你得到了你的PV的名称以及它被附加在哪个节点上,那么你就可以看到PV是否被绑定到正确的节点上,或者它是否被绑定到了一个不工作或被删除的前一个节点上。节点被逐出并被调度到来自池的新的可用节点中;要了解哪些节点已准备就绪并正在运行,可以使用以下命令:
如果检测到PV绑定到不再存在的节点,则需要使用以下命令删除VolumeAttachment:
如果您需要查看有关此故障排除的详细指南,可以按照this link进行操作。