到目前为止，我确信一个人需要一个PVC才能从k8s doc中访问此示例中的PV：
added_by但是后来我在Docker doc中看到可以使用以下语法（例如使用nfs的语法）：
apiVersion: v1
kind: pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeclaim:
claimName: myclaim
我很困惑：
emptyDir卷是在将Pod分配给节点时首先创建的，并且只要该Pod在该节点上运行就存在。 您不需要pv和pvc来清空emptyDIr体积。
请注意，如果出于任何原因将Pod从节点中删除，则将永久删除emptyDir中的数据。
如果即使Pod崩溃或重新启动或Pod被删除或取消部署也要保留数据，则需要使用pv和pvc
再看下面的另一个例子，在这里不需要使用hostPath的pv和pvc
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional
type: Directory
如果您需要将数据存储在外部存储解决方案（例如nfs，azure文件存储，aws EBS，谷歌persistentDisk等）上，则需要创建pv和pvc。
不允许将pv直接安装到Pod，这违反kubernetes的设计原则。这会导致豆荚果肉和下层贮藏物下方紧密结合。
pvc可以在吊舱和固定体积之间进行光耦合。豆荚 不知道底层存储是用来存储容器数据的，并且pod不需要知道该信息。
pv和pvc是为Kubernetes集群中的工作负载静态和动态配置存储卷所必需的
,您可以挂载的各种东西都是Kubernetes API中Volume对象的一部分（它是PodSpec的一部分，而Pod是{{3}}的一部分）。这些都不是通过名称挂载特定PersistentVolume的选项。
（在某些特殊情况下，您可以看到NFS和各种群集存储系统之类的东西。这些大多早于持久卷。）
您在这里可以做的最好的事情是创建一个紧密绑定到单个永久卷的PVC，然后在pod规范中引用它。