您正在查看 Kubernetes 版本的文档: v1.18
Kubernetes v1.18 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。
配置 Pod 以使用 PersistentVolume 作为存储
本文介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。 以下是该过程的总结:
集群管理员创建由物理存储支持的 PersistentVolume。管理员不将卷与任何 Pod 关联。
群集用户创建一个 PersistentVolumeClaim,它将自动绑定到合适的 PersistentVolume。
用户创建一个使用 PersistentVolumeClaim 作为存储的 Pod。
准备开始
在你的节点上创建一个 index.html 文件
打开集群中节点的一个 shell。
如何打开 shell 取决于集群的设置。
例如,如果您正在使用 Minikube,那么可以通过输入 minikube ssh
来打开节点的 shell。
在 shell 中,创建一个 /mnt/data
目录:
mkdir /mnt/data
在 /mnt/data
目录中创建一个 index.html 文件:
echo 'Hello from Kubernetes storage' > /mnt/data/index.html
创建 PersistentVolume
在本练习中,您将创建一个 hostPath 类型的 PersistentVolume。 Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟附带网络的存储。
在生产集群中,您不会使用 hostPath。集群管理员会提供网络存储资源,比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。 集群管理员还可以使用 StorageClasses 来设置动态提供存储。
下面是 hostPath PersistentVolume 的配置文件:
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
配置文件指定了该卷位于集群节点上的 /mnt/data
目录。
该配置还指定了 10 吉比特的卷大小和 ReadWriteOnce
的访问模式,这意味着该卷可以在单个节点上以读写方式挂载。
它为 PersistentVolume 定义了 StorageClass 名称 为 manual
,StorageClass 名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolume。
创建 PersistentVolume:
kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml
查看 PersistentVolume 的信息:
kubectl get pv task-pv-volume
输出结果显示该 PersistentVolume 的状态(STATUS)
为 Available
。
这意味着它还没有被绑定给 PersistentVolumeClaim。
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Available manual 4s
创建 PersistentVolumeClaim
下一步是创建一个 PersistentVolumeClaim。 Pod 使用 PersistentVolumeClaim 来请求物理存储。 在本练习中,您将创建一个 PersistentVolumeClaim,它请求至少 3 吉比特容量的卷,该卷至少可以为一个节点提供读写访问。
下面是 PersistentVolumeClaim 的配置文件:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
创建 PersistentVolumeClaim:
kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
创建 PersistentVolumeClaim 之后,Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。 如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume,则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。
再次查看 PersistentVolume 信息:
kubectl get pv task-pv-volume
现在输出的 STATUS
为 Bound
。
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim manual 2m
查看 PersistentVolumeClaim:
kubectl get pvc task-pv-claim
输出结果表明该 PersistentVolumeClaim 绑定了你的 PersistentVolume task-pv-volume
。
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE
task-pv-claim Bound task-pv-volume 10Gi RWO manual 30s
创建 Pod
下一步是创建一个 Pod, 该 Pod 使用你的 PersistentVolumeClaim 作为存储卷。
下面是 Pod 的 配置文件:
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
注意 Pod 的配置文件指定了 PersistentVolumeClaim,但没有指定 PersistentVolume。对 Pod 而言,PersistentVolumeClaim 就是一个存储卷。
创建 Pod:
kubectl create -f https://k8s.io/examples/pods/storage/pv-pod.yaml
检查 Pod 中的容器是否运行正常:
kubectl get pod task-pv-pod
打开一个 shell 访问 Pod 中的容器:
kubectl exec -it task-pv-pod -- /bin/bash
在 shell 中,验证 nginx 是否正在从 hostPath 卷提供 index.html
文件:
root@task-pv-pod:/# apt-get update
root@task-pv-pod:/# apt-get install curl
root@task-pv-pod:/# curl localhost
输出结果是你之前写到 hostPath 卷中的 index.html
文件中的内容:
Hello from Kubernetes storage
访问控制
使用 group ID(GID)配置的存储仅允许 Pod 使用相同的 GID 进行写入。 GID 不匹配或缺少将会导致许可被拒绝的错误。 为了减少与用户的协调,管理员可以使用 GID 对 PersistentVolume 进行注解。 这样 GID 就能自动的添加到使用 PersistentVolume 的任何 Pod 中。
使用 pv.beta.kubernetes.io/gid
注解的方法如下所示:
kind: PersistentVolume
apiVersion: v1
metadata:
name: pv1
annotations:
pv.beta.kubernetes.io/gid: "1234"
当 Pod 使用带有 GID 注解的 PersistentVolume 时,注解的 GID 会被应用于 Pod 中的所有容器,应用的方法与 Pod 的安全上下文中指定的 GID 相同。 每个 GID,无论是来自 PersistentVolume 注解还是来自 Pod 的规范,都应用于每个容器中运行的第一个进程。
说明:当 Pod 使用 PersistentVolume 时,与 PersistentVolume 关联的 GID 不会在 Pod 本身的资源对象上出现。
接下来
- 进一步了解 PersistentVolumes。
- 阅读持久存储设计文档。