我有一个访问模式为ReadOnlyMany的pvc。我创建了一个使用上述pvc的pod,发现我可以写入挂载路径。这是预期的行为还是与我正在使用的音量插件有关。
ReadOnlyMany
zhte4eai1#
没有更多的信息很难说它是什么。最常见的错误是:1)就像@vaqars在评论中提到的那样,它可能在pod/deployment manifest中缺少readOnly:true元素。
readOnly:true
volumes: - name: <volumeName> persistentVolumeClaim: claimName: <claimName> readOnly: true
2)您的PersistentVolume和PersistentVolumeClaim没有accessMode: ReadOnlyMany。3)您的卷插件可能不支持ReadOnlyMany。请在此检查您的Volume Plugin是否支持此访问模式。
accessMode: ReadOnlyMany
svujldwt2#
将pvc上的accessMode设置为ReadOnlyMany并不能保证底层pv不允许写入。更重要的是,将pv的accessMode设置为ReadOnlyMany并不能保证底层存储会拒绝写入。正如这里的官方文档中所写的:
pvc
accessMode
pv
注意:Kubernetes使用卷访问模式匹配PersistentVolumeClaims和PersistentVolumes。在一些情况下,卷访问模式还约束PersistentVolume可以被挂载的位置。卷访问模式在装载存储后不强制执行写保护。即使将访问模式指定为ReadWriteOnce、ReadOnlyMany或ReadWriteMany,它们也不会对卷设置任何约束。例如,即使PersistentVolume被创建为ReadOnlyMany,也不能保证它是只读的。如果访问模式指定为ReadWriteOncePod,则卷受到限制,只能挂载到单个Pod上。
如果你想自己测试一下,这里有一个可复制的示例,它是从Kubernetes in action的 Chapter06 中的示例修改而来的(使用minikube version v1.30.1,Kubernetes version v1.26.3测试):
minikube version v1.30.1
Kubernetes version v1.26.3
└► cat mongodb-pv-hostpath.yaml apiVersion: v1 kind: PersistentVolume metadata: name: mongodb-pv spec: capacity: storage: 1Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain hostPath: path: /tmp/mongodb └► cat mongodb-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mongodb-pvc spec: resources: requests: storage: 1Gi accessModes: - ReadOnlyMany storageClassName: "" └► cat mongodb-pod-pvc.yaml apiVersion: v1 kind: Pod metadata: name: mongodb spec: containers: - image: mongo name: mongodb volumeMounts: - name: mongodb-data mountPath: /data/db ports: - containerPort: 27017 protocol: TCP volumes: - name: mongodb-data persistentVolumeClaim: claimName: mongodb-pvc
将所有这些文件应用到minikube集群后,即使挂载的卷设置为ReadOnlyMany,也可以运行k exec -it mongodb -- mongosh并运行成功的命令来写入mongoDB。
k exec -it mongodb -- mongosh
2条答案
按热度按时间zhte4eai1#
没有更多的信息很难说它是什么。
最常见的错误是:
1)就像@vaqars在评论中提到的那样,它可能在pod/deployment manifest中缺少
readOnly:true
元素。2)您的PersistentVolume和PersistentVolumeClaim没有
accessMode: ReadOnlyMany
。3)您的卷插件可能不支持
ReadOnlyMany
。请在此检查您的Volume Plugin是否支持此访问模式。svujldwt2#
将
pvc
上的accessMode
设置为ReadOnlyMany
并不能保证底层pv
不允许写入。更重要的是,将pv
的accessMode
设置为ReadOnlyMany
并不能保证底层存储会拒绝写入。正如这里的官方文档中所写的:注意:Kubernetes使用卷访问模式匹配PersistentVolumeClaims和PersistentVolumes。在一些情况下,卷访问模式还约束PersistentVolume可以被挂载的位置。卷访问模式在装载存储后不强制执行写保护。即使将访问模式指定为ReadWriteOnce、ReadOnlyMany或ReadWriteMany,它们也不会对卷设置任何约束。例如,即使PersistentVolume被创建为ReadOnlyMany,也不能保证它是只读的。如果访问模式指定为ReadWriteOncePod,则卷受到限制,只能挂载到单个Pod上。
如果你想自己测试一下,这里有一个可复制的示例,它是从Kubernetes in action的 Chapter06 中的示例修改而来的(使用
minikube version v1.30.1
,Kubernetes version v1.26.3
测试):将所有这些文件应用到minikube集群后,即使挂载的卷设置为
ReadOnlyMany
,也可以运行k exec -it mongodb -- mongosh
并运行成功的命令来写入mongoDB。