我使用GKE并在Google Cloud中创建了一个集群。这是我的Persistent卷
apiVersion: v1
kind: PersistentVolume
metadata:
name: mongo-pv
spec:
capacity:
storage: 256Mi
accessModes:
- ReadWriteOnce
hostPath:
path: /tmp/db下面是创建持久卷的命令
kubectl create -f mongo-pv.yaml持久性体积要求
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongo-pvc
spec:
accessModes:
- ReadWriteOnce
volumeName: mongo-pv
resources:
requests:
storage: 256Mi应用使用
kubectl create -f mongo-pvc.yaml然而，获取PVC的命令总是显示挂起。它应该出现了。不确定yaml文件中有什么问题
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mongo-pvc Pending mongo-pv 0 standard-rwo更新
kubectl describe pvc mongo-pvc
Name: mongo-pvc
Namespace: default
StorageClass: standard-rwo
Status: Pending
Volume: mongo-pv
Labels: <none>
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 0
Access Modes:
VolumeMode: Filesystem
Used By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning VolumeMismatch 23s (x262 over 65m) persistentvolume-controller Cannot bind to requested volume "mongo-pv": storageClassName does not match
2条答案
按热度按时间uxhixvfz1#
PV的存储类名为空，但由于DefaultStorageClass准入插件，PVC的存储类名会自动填充为
standard-rwo。这些段落来自Kubernetes文档：
声明可以通过使用属性storageClassName指定StorageClass的名称来请求特定的类。只有请求类的PV（与PVC具有相同storageClassName的PV）可以绑定到PVC。
PVC不一定要请求一个类。storageClassName设置为“”的PVC始终被解释为请求不带类的PV，因此它只能绑定到不带类的PV（无注解或设置为“”的PV）。没有storageClassName的PVC并不完全相同，群集会根据是否打开DefaultStorageClass准入插件对其进行不同的处理。
我猜你应该关闭DefaultStorageClass准入插件并重新应用你的清单或者给予你的PV相同的存储类名，如下所示：
mzmfm0qo2#
如错误所示，它没有指向正确的
storageClass。使用kubectl get sc检查storageClassstandard-rwo是否已经存在（如果没有，则创建一个），并在声明卷时添加storageClassName。您不需要显式创建PV，当您使用storageClass创建PVC时，它将自动为您提供PV对象。