配置 Pod 以使用 PersistentVolume 作为存储

本文将向你介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。 以下是该过程的总结:

  1. 你作为集群管理员创建由物理存储支持的 PersistentVolume。你不会将该卷与任何 Pod 关联。

  2. 你现在以开发人员或者集群用户的角色创建一个 PersistentVolumeClaim, 它将自动绑定到合适的 PersistentVolume。

  3. 你创建一个使用以上 PersistentVolumeClaim 作为存储的 Pod。

准备开始

  • 你需要一个包含单个节点的 Kubernetes 集群,并且必须配置 kubectl 命令行工具以便与集群交互。 如果还没有单节点集群,可以使用 Minikube 创建一个。

  • 熟悉持久卷文档。

在你的节点上创建一个 index.html 文件

打开集群中的某个节点的 Shell。 如何打开 Shell 取决于集群的设置。 例如,如果你正在使用 Minikube,那么可以通过输入 minikube ssh 来打开节点的 Shell。

在该节点的 Shell 中,创建一个 /mnt/data 目录:

  1. # 这里假定你的节点使用 "sudo" 来以超级用户角色执行命令
  2. sudo mkdir /mnt/data

/mnt/data 目录中创建一个 index.html 文件:

  1. # 这里再次假定你的节点使用 "sudo" 来以超级用户角色执行命令
  2. sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

说明: 如果你的节点使用某工具而不是 sudo 来完成超级用户访问,你可以将上述命令中的 sudo 替换为该工具的名称。

测试 index.html 文件确实存在:

  1. cat /mnt/data/index.html

输出应该是:

  1. Hello from Kubernetes storage

现在你可以关闭节点的 Shell 了。

创建 PersistentVolume

在本练习中,你将创建一个 hostPath 类型的 PersistentVolume。 Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟网络附加存储。

在生产集群中,你不会使用 hostPath。 集群管理员会提供网络存储资源,比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。 集群管理员还可以使用 StorageClasses 来设置动态提供存储

下面是 hostPath PersistentVolume 的配置文件:

pods/storage/pv-volume.yaml 配置 Pod 以使用 PersistentVolume 作为存储 - 图1

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4. name: task-pv-volume
  5. labels:
  6. type: local
  7. spec:
  8. storageClassName: manual
  9. capacity:
  10. storage: 10Gi
  11. accessModes:
  12. - ReadWriteOnce
  13. hostPath:
  14. path: "/mnt/data"

此配置文件指定卷位于集群节点上的 /mnt/data 路径。 其配置还指定了卷的容量大小为 10 GB,访问模式为 ReadWriteOnce, 这意味着该卷可以被单个节点以读写方式安装。 此配置文件还在 PersistentVolume 中定义了 StorageClass 的名称manual。 它将用于将 PersistentVolumeClaim 的请求绑定到此 PersistentVolume。

创建 PersistentVolume:

  1. kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

查看 PersistentVolume 的信息:

  1. kubectl get pv task-pv-volume

输出结果显示该 PersistentVolume 的状态(STATUS)Available。 这意味着它还没有被绑定给 PersistentVolumeClaim。

  1. NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
  2. task-pv-volume 10Gi RWO Retain Available manual 4s

创建 PersistentVolumeClaim

下一步是创建一个 PersistentVolumeClaim。 Pod 使用 PersistentVolumeClaim 来请求物理存储。 在本练习中,你将创建一个 PersistentVolumeClaim,它请求至少 3 GB 容量的卷, 该卷至少可以为一个节点提供读写访问。

下面是 PersistentVolumeClaim 的配置文件:

pods/storage/pv-claim.yaml 配置 Pod 以使用 PersistentVolume 作为存储 - 图2

  1. apiVersion: v1
  2. kind: PersistentVolumeClaim
  3. metadata:
  4. name: task-pv-claim
  5. spec:
  6. storageClassName: manual
  7. accessModes:
  8. - ReadWriteOnce
  9. resources:
  10. requests:
  11. storage: 3Gi

创建 PersistentVolumeClaim:

  1. kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

创建 PersistentVolumeClaim 之后,Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。 如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume, 则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。

再次查看 PersistentVolume 信息:

  1. kubectl get pv task-pv-volume

现在输出的 STATUSBound

  1. NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
  2. task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim manual 2m

查看 PersistentVolumeClaim:

  1. kubectl get pvc task-pv-claim

输出结果表明该 PersistentVolumeClaim 绑定了你的 PersistentVolume task-pv-volume

  1. NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE
  2. task-pv-claim Bound task-pv-volume 10Gi RWO manual 30s

创建 Pod

下一步是创建一个使用你的 PersistentVolumeClaim 作为存储卷的 Pod。

下面是此 Pod 的配置文件:

pods/storage/pv-pod.yaml 配置 Pod 以使用 PersistentVolume 作为存储 - 图3

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: task-pv-pod
  5. spec:
  6. volumes:
  7. - name: task-pv-storage
  8. persistentVolumeClaim:
  9. claimName: task-pv-claim
  10. containers:
  11. - name: task-pv-container
  12. image: nginx
  13. ports:
  14. - containerPort: 80
  15. name: "http-server"
  16. volumeMounts:
  17. - mountPath: "/usr/share/nginx/html"
  18. name: task-pv-storage

注意 Pod 的配置文件指定了 PersistentVolumeClaim,但没有指定 PersistentVolume。 对 Pod 而言,PersistentVolumeClaim 就是一个存储卷。

创建 Pod:

  1. kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

检查 Pod 中的容器是否运行正常:

  1. kubectl get pod task-pv-pod

打开一个 Shell 访问 Pod 中的容器:

  1. kubectl exec -it task-pv-pod -- /bin/bash

在 Shell 中,验证 Nginx 是否正在从 hostPath 卷提供 index.html 文件:

  1. # 一定要在上一步 "kubectl exec" 所返回的 Shell 中执行下面三个命令
  2. apt update
  3. apt install curl
  4. curl http://localhost/

输出结果是你之前写到 hostPath 卷中的 index.html 文件中的内容:

  1. Hello from Kubernetes storage

如果你看到此消息,则证明你已经成功地配置了 Pod 使用 PersistentVolumeClaim 的存储。

清理

删除 Pod、PersistentVolumeClaim 和 PersistentVolume 对象:

  1. kubectl delete pod task-pv-pod
  2. kubectl delete pvc task-pv-claim
  3. kubectl delete pv task-pv-volume

如果你还没有连接到集群中节点的 Shell,可以按之前所做操作,打开一个新的 Shell。

在节点的 Shell 上,删除你所创建的目录和文件:

  1. # 这里假定你使用 "sudo" 来以超级用户的角色执行命令
  2. sudo rm /mnt/data/index.html
  3. sudo rmdir /mnt/data

你现在可以关闭连接到节点的 Shell。

在两个地方挂载相同的 persistentVolume

pods/storage/pv-duplicate.yaml 配置 Pod 以使用 PersistentVolume 作为存储 - 图4

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: test
  5. spec:
  6. containers:
  7. - name: test
  8. image: nginx
  9. volumeMounts:
  10. # 网站数据挂载
  11. - name: config
  12. mountPath: /usr/share/nginx/html
  13. subPath: html
  14. # Nginx 配置挂载
  15. - name: config
  16. mountPath: /etc/nginx/nginx.conf
  17. subPath: nginx.conf
  18. volumes:
  19. - name: config
  20. persistentVolumeClaim:
  21. claimName: test-nfs-claim

你可以在 nginx 容器上执行两个卷挂载:

/usr/share/nginx/html 用于静态网站 /etc/nginx/nginx.conf 作为默认配置

访问控制

使用组 ID(GID)配置的存储仅允许 Pod 使用相同的 GID 进行写入。 GID 不匹配或缺失将会导致无权访问错误。 为了减少与用户的协调,管理员可以对 PersistentVolume 添加 GID 注解。 这样 GID 就能自动添加到使用 PersistentVolume 的任何 Pod 中。

使用 pv.beta.kubernetes.io/gid 注解的方法如下所示:

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. apiVersion: v1
  4. metadata:
  5. name: pv1
  6. annotations:
  7. pv.beta.kubernetes.io/gid: "1234"

当 Pod 使用带有 GID 注解的 PersistentVolume 时,注解的 GID 会被应用于 Pod 中的所有容器, 应用的方法与 Pod 的安全上下文中指定的 GID 相同。 每个 GID,无论是来自 PersistentVolume 注解还是来自 Pod 规约,都会被应用于每个容器中运行的第一个进程。

说明: 当 Pod 使用 PersistentVolume 时,与 PersistentVolume 关联的 GID 不会在 Pod 资源本身的对象上出现。

接下来

参考