到目前为止,我确信需要 PVC 才能访问 PV,就像 k8s文档中的示例一样:
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
Run Code Online (Sandbox Code Playgroud)
但后来我在Docker 文档中看到可以使用以下语法(使用 nfs 的示例):
kind: Pod
apiVersion: v1
metadata:
name: nfs-in-a-pod
spec:
containers:
- name: app
image: alpine
volumeMounts:
- name: nfs-volume
mountPath: /var/nfs # Please change the destination you like the share to be mounted too
command: ["/bin/sh"]
args: ["-c", "sleep 500000"]
volumes:
- name: nfs-volume
nfs:
server: nfs.example.com # Please change this to your NFS server
path: /share1 # Please change this to the relevant share
Run Code Online (Sandbox Code Playgroud)
我很困惑:
当 Pod 被分配给节点时,emptyDir 卷首先被创建,并且只要 Pod 在该节点上运行,它就存在。空目录卷不需要 pv 和 pvc。
请注意,当 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
Run Code Online (Sandbox Code Playgroud)
如果您需要将数据存储在外部存储解决方案(例如 nfs、azure 文件存储、aws EBS、google permanentDisk 等)上,那么您需要创建 pv 和 pvc。
不允许将 pv 直接安装到 pod,这违反了 Kubernetes 设计原则。这会导致 pod vloume 和底层存储下方的紧密耦合。
pvc 实现 pod 和持久卷之间的轻耦合。Pod 不知道底层存储用于存储容器数据,并且 Pod 没有必要知道该信息。
为 kubernetes 集群中的工作负载静态和动态配置存储卷需要 pv 和 pvc