Kubernetes---配置 Pod 以使用 PersistentVolume 作为存储

--山海--

已于 2022-09-15 13:41:43 修改

阅读量1k

点赞数

分类专栏： Kubernetes 文章标签： kubernetes docker 容器

于 2022-09-13 17:05:33 首次发布

本文链接：https://blog.csdn.net/AnNan1997/article/details/126836307

版权

Kubernetes 专栏收录该内容

9 篇文章 4 订阅

订阅专栏

配置 Pod 以使用 PersistentVolume 作为存储

一、创建 index.html 文件

在一个node节点创建index.html文件，内容如下：

echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
[root@node1 data]# pwd
/mnt/data
[root@node1 data]# cat index.html
Hello from Kubernetes storage

现在，节点操作已完成。

二、创建 PersistentVolume

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

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

PersistentVolume配置文件内容如下：

[root@master k8s]# cat pv-volume.yaml
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 GB，访问模式为 ReadWriteOnce，这意味着该卷可以被单个节点以读写方式安装。配置文件还在 PersistentVolume 中定义了 StorageClass 的名称为 manual。它将用于将 PersistentVolumeClaim 的请求绑定到此 PersistentVolume。

创建 PersistentVolume：

[root@master k8s]# kubectl apply -f pv-volume.yaml
persistentvolume/task-pv-volume created

查看 PersistentVolume 的信息：

[root@master k8s]# kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Available           manual                  12s

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

三、创建 PersistentVolumeClaim

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

下面是 PersistentVolumeClaim 的配置文件：

[root@master ~]# cat /home/app/k8s/pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

创建 PersistentVolumeClaim：

[root@master k8s]# kubectl apply -f pv-claim.yaml
persistentvolumeclaim/task-pv-claim created

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

再次查看 PersistentVolume 信息：

[root@master k8s]# kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Bound    default/task-pv-claim   manual                  119s

查看 PersistentVolumeClaim：

[root@master k8s]# kubectl get pvc task-pv-claim
NAME            STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
task-pv-claim   Bound    task-pv-volume   10Gi       RWO            manual         26s

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

四、创建 Pod

Pod 的配置文件内容如下：

[root@master ~]# cat /home/app/k8s/pv-pod.yaml
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：

[root@master k8s]# kubectl apply -f pv-pod.yaml
pod/task-pv-pod created

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

[root@master k8s]# kubectl get pod task-pv-pod
NAME          READY   STATUS    RESTARTS   AGE
task-pv-pod   1/1     Running   0          3m33s

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

[root@master ~]# kubectl exec -it task-pv-pod -- /bin/bash
root@task-pv-pod:/#

在 Shell 中，验证 nginx 是否正在从 hostPath 卷提供 index.html 文件：

# 一定要在上一步 "kubectl exec" 所返回的 Shell 中执行下面三个命令
root@task-pv-pod:/# apt update
Get:1 http://security.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:2 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [182 kB]
Get:3 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:4 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8184 kB]
Ign:5 http://deb.debian.org/debian bullseye/main amd64 Packages
Ign:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages
Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8184 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2596 B]
Fetched 4412 kB in 2min 21s (31.4 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
40 packages can be upgraded. Run 'apt list --upgradable' to see them.

root@task-pv-pod:/# apt install curl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libcurl4
The following packages will be upgraded:
  curl libcurl4
2 upgraded, 0 newly installed, 0 to remove and 38 not upgraded.
Need to get 615 kB of archives.
After this operation, 10.2 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://deb.debian.org/debian bullseye/main amd64 curl amd64 7.74.0-1.3+deb11u3 [269 kB]
Get:2 http://deb.debian.org/debian bullseye/main amd64 libcurl4 amd64 7.74.0-1.3+deb11u3 [345 kB]
Fetched 615 kB in 1s (412 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 7815 files and directories currently installed.)
Preparing to unpack .../curl_7.74.0-1.3+deb11u3_amd64.deb ...
Unpacking curl (7.74.0-1.3+deb11u3) over (7.74.0-1.3+deb11u1) ...
Preparing to unpack .../libcurl4_7.74.0-1.3+deb11u3_amd64.deb ...
Unpacking libcurl4:amd64 (7.74.0-1.3+deb11u3) over (7.74.0-1.3+deb11u1) ...
Setting up libcurl4:amd64 (7.74.0-1.3+deb11u3) ...
Setting up curl (7.74.0-1.3+deb11u3) ...
Processing triggers for libc-bin (2.31-13+deb11u2) ...

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

root@task-pv-pod:/# curl http://localhost/
Hello from Kubernetes storage

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

五、清理环境

删除 Pod、PersistentVolumeClaim 和 PersistentVolume 对象：

[root@master k8s]# kubectl delete pod task-pv-pod
pod "task-pv-pod" deleted
[root@master k8s]# kubectl delete pvc task-pv-claim
persistentvolumeclaim "task-pv-claim" deleted
[root@master k8s]# kubectl delete pv task-pv-volume
persistentvolume "task-pv-volume" deleted

在节点的 Shell 上，删除创建的目录和文件：

[root@master k8s]# cd /mnt/data/
[root@master data]# ls
index.html
[root@master data]# rm -rf index.html
[root@master data]# cd ..
[root@master mnt]# rm -rf data/
[root@master mnt]# ls
[root@master mnt]#

六、在两个地方挂载相同的 PersistentVolume

yaml配置文件如下：

[root@master k8s]# cat pv-duplicate.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
      # 网站数据挂载
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
      # Nginx 配置挂载
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        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 注解的方法如下所示：

apiVersion: v1
kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

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