Kubernetes挂载卷一直超时,即使卷可以从sudo挂载



我有一个只读的持久卷,我试图挂载到statfulset上,但是在对程序进行了一些更改并重新创建pod之后,pod现在不能再挂载到卷上了。

PV yaml file:

apiVersion: v1
kind: PersistentVolume
metadata:
name: foo-pv
spec:
capacity:
storage: 2Gi
accessModes:
- ReadOnlyMany
nfs:
server: <ip>
path: "/var/foo"
claimRef:
name: foo-pvc
namespace: foo

PVC yaml文件:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: foo
spec:
accessModes:
- ReadOnlyMany
storageClassName: ""
volumeName: foo-pv
resources:
requests:
storage: 2Gi

Statefulset yaml:

apiVersion: v1
kind: Service
metadata:
name: foo-service
spec:
type: ClusterIP
ports:
- name: http 
port: 80
selector:
app: foo-app
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: foo-statefulset
namespace: foo
spec:
selector:
matchLabels:
app: foo-app
serviceName: foo-app
replicas: 1
template:
metadata:
labels:
app: foo-app
spec:
serviceAccountName: foo-service-account
containers:
- name: fooContainer
image: <image>
imagePullPolicy: Always
volumeMounts:
- name: writer-data
mountPath: <path>
- name: nfs-objectd
mountPath: <path>
volumes:      
- name: nfs-foo
persistentVolumeClaim:
claimName: foo-pvc          
volumeClaimTemplates:
- metadata:
name: writer-data
spec:
accessModes: [ "ReadWriteMany" ]
storageClassName: "foo-sc"
resources:
requests:
storage: 2Gi

k description pod reports "无法挂载或挂载卷:unmounted volumes=[nfs-foo]: timed out waiting for the condition"在运行kubernetes的机器和NFS之间有一个防火墙,但是端口已经解除了阻塞,并且文件夹已经导出,以便在NFS端挂载。运行sudo mount -t nfs:/var/foo/var/foo可以成功挂载nfs,所以我不明白为什么kuebernetes不再挂载它了。它已经被卡住好几天了。还有其他的方法来调试这个吗?谢谢!

基于错误" cannot attach or mount volume .......超时等待条件",有一些类似的问题报告给产品团队,这是一个已知的问题。但是,当节点被抢占时,这个错误在可抢占/spot节点上更容易观察到。在其他用户出现类似问题时,升级控制平面版本暂时解决了可抢占/spot节点中的此问题。

另外,如果您在集群中没有使用任何可抢占/spot节点,那么当旧节点被新节点替换时可能会发生此问题。如果您仍然面临这个问题,请尝试将控制平面升级到相同的版本,即您可以执行以下命令:

$ gcloud container clusters upgrade CLUSTER_NAME --master --zone ZONE --cluster-version VERSION

解决此问题的另一个方法是使用以下命令删除过时的VolumeAttachment:

$ kubectl delete volumeattachment [volumeattachment_name]

在运行命令并因此删除VolumeAttachment之后,pod最终应该拾取并重试。你可以在这里阅读更多关于这个问题及其原因的信息。

最新更新