Question

我有一个PersistentVolume，我指定如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv-shared
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/mypv-shared/

然后我创建了一个具有以下规范的PersistentVolumeClaim：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypv-shared-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

但是当我创建PVC时，运行kubectl get pv表明它绑定到随机生成的PV

NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                           STORAGECLASS   REASON    AGE
pvc-38c77920-a223-11e7-89cc-08002719b642   5Gi        RWX           Delete          Bound       default/mypv-shared             standard                 16m

我认为这在运行测试时会导致我的pod出现问题，因为我不确定该pod是否正确安装了指定的目录。在尝试在运行结束时复制测试日志时，我的pod在测试结束时崩溃。

原因是否真的是持久性卷/索赔，还是我应该调查其他内容？谢谢！

Answer 1

创建PVC动态配置PV，而不是使用您使用hostpath手动创建的PV。在PVC上只需设置.spec.storageClassName和空字符串（""）

来自documentation：

其storageClassName设置为""的PVC始终被解释为请求没有类的PV，因此它只能绑定到没有类的PV（没有注释或一组等于＆＃34） ;＆＃34）。没有storageClassName的PVC不完全相同......

所以创建这样的东西（我还添加了标签和选择器，以确保预期的PV与PVC配对;您可能不需要这个约束）：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv-shared
  labels:
    name: mypv-shared
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/mypv-shared/
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypv-shared-claim
spec:
  storageClassName: ""
  selector:
    matchLabels:
      name: mypv-shared
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

Kubernetes PersistentVolume和PersistentVolumeClaim可能会导致我的pod问题在复制日志时崩溃

1 个答案: