理解并使用存储卷 · K8S 实践 02

在 Kubernetes 中，容器会被频繁地创建和销毁。当容器被销毁时，保存在容器中的数据也会被清除。为了持久化容器的数据，Kubernetes 引入了 Volume 的概念。

Volume 是 Pod 中能够被多个容器访问的共享目录。它被定义在 Pod 上，然后被一个 Pod 里的多个容器挂载 ¹ 到具体的文件目录下。 Kubernetes 通过 Volume 实现同一个 Pod 中不同容器之间的数据共享以及数据的持久化存储。 Volume 的生命容器不与 Pod 中单个容器的生命周期相关 ²，当容器终止或者重启时，Volume 中的数据也不会丢失。

Kubernetes 中支持的 Volume 类型包含：

简单存储：EmptyDir、HostPath、NFS
高级存储：PV、PVC
配置存储：ConfigMap、Secret

本文将依次介绍它们的使用。

1 准备工作

笔者拥有一个包含 11 个节点的集群，这些节点（私网 IP 地址为 192.168.23.160~192.168.23.170）相互之间可以免密登录，且均不具备公网 IP。在本机（macOS 10.15）通过 ssh 登录到节点 ubuntu 上获取各节点信息：

k8s@ubuntu:~$ k get no -o wide
NAME              STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
ubuntu            Ready    control-plane,master   27d   v1.22.2   192.168.23.160   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-large-2    Ready    <none>                 27d   v1.22.2   192.168.23.161   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-large-3    Ready    <none>                 27d   v1.22.2   192.168.23.162   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-medium-1   Ready    <none>                 27d   v1.22.2   192.168.23.163   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-medium-2   Ready    <none>                 27d   v1.22.2   192.168.23.164   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-medium-3   Ready    <none>                 27d   v1.22.2   192.168.23.165   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-medium-4   Ready    <none>                 27d   v1.22.2   192.168.23.166   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-small-1    Ready    <none>                 27d   v1.22.2   192.168.23.167   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-small-2    Ready    <none>                 27d   v1.22.2   192.168.23.168   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-small-3    Ready    <none>                 27d   v1.22.2   192.168.23.169   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9
worker-small-4    Ready    <none>                 27d   v1.22.2   192.168.23.170   <none>        Ubuntu 18.04.5 LTS   4.15.0-112-generic   docker://20.10.9

2 使用简单存储

2.1 使用 EmptyDir

EmptyDir 是最基础的 Volume 类型，是宿主机上的一个空目录。 EmptyDir 是在 Pod 被分配到节点时被创建的，它的初始内容为空，且无须指定宿主机上的某个目录，因为 Kubernetes 会自动分配一个临时目录。当 Pod 销毁时，EmptyDir 中的数据也会被永久删除。由于这些特性，EmptyDir 用途主要是：

临时空间。用于某些应用程序运行时所需的临时目录，且无须永久保留；
数据共享。在一个 Pod 内，一个容器需要从另一个容器中获取数据。

我们按照如下方式创建一个 Pod，其内部包含两个容器，分别为 nginx Container 和 busybox Container，二者都将 logs-volume 这个存储卷挂载到自身的某个目录下。我们使用 EmptyDir 实现 Pod 内的数据共享：

# volume-emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume-emptydir
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    # 将名为 logs-volume 的存储卷挂载到本 Pod 内的路径 / var/log/nginx 上
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox
    # busybox Container 的启动命令为实时读取指定文件中内容
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    # 将名为 logs-volume 的存储卷挂载到本 Pod 内的路径 / logs 上
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  # 声明一个 emptyDir 类型的存储卷，其名称为 logs-volume
  volumes:
  - name: logs-volume
    emptyDir: {}

通过 apply 命令创建上述资源对象：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f volume-emptydir.yaml
pod/volume-emptydir created
k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP             NODE             NOMINATED NODE   READINESS GATES
volume-emptydir   2/2     Running   0          43s   10.244.2.175   worker-large-3   <none>           <none>

接下来，我们检验存储卷是否正常工作。在一个窗口中通过 curl 命令访问 10.244.2.175 的 80 端口，在另一个窗口中实时打印 busybox Container 的日志：

# tty0: 发起两次访问
k8s@ubuntu:~/learn-k8s/14-volume$ curl 10.244.2.175
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...
k8s@ubuntu:~/learn-k8s/14-volume$ curl 10.244.2.175
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...

# tty1: 打印日志
k8s@ubuntu:~$ k logs -f volume-emptydir -c busybox
10.244.0.0 - - [08/Nov/2021:13:33:14 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"
10.244.0.0 - - [08/Nov/2021:13:33:24 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"

当我们删除 volume-emptydir 这个 Pod 时，logs-volume 这个存储卷也随之被销毁。

2.2 使用 HostPath

HostPath 就是将集群内某个节点中的一个实际目录挂在到 Pod 中，以供容器使用。 HostPath 和 EmptyDir 的主要区别是，当删除挂载了对应存储卷的 Pod 的时候，宿主机上对应的目录不会随之被销毁。

类似地，我们创建一个 Pod，其内部有两个容器，都将 logs-volume 这个存储卷挂载到自身的某个目录下，存储卷的类型选择 HostPath：

# volume-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  # 声明一个 hostPath 类型的存储卷，其名称为 logs-volume
  - name: logs-volume
    hostPath:
      path: /home/k8s/learn-k8s/hostpath-dir/logs      # 该存储卷在宿主机上的对应目录
      type: DirectoryOrCreate

上述文件中，volume.spec.volumes.hostPath.type 的类型有很多，例如宿主机文件或目录（DirectoryOrCreate、Directory、FileOrCreate 以及 File），还可以是 Socket、字符设备或者块设备。成功部署之后，可以发现 volume-hostpath 被调度到了节点 worker-large-3 上：

k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
volume-hostpath   2/2     Running   0          3m42s   10.244.2.177   worker-large-3   <none>           <none>

接下来我们打开三个窗口，前两个窗口登录到节点 ubuntu 上，分别用于访问 10.244.2.177 和打印 busybox Container 的日志，第三个窗口登录到节点 worker-large-3 上，观察路径 /home/k8s/learn-k8s/hostpath-dir/logs 是否被成功创建以及是否在 Pod 被销毁后仍然存在：

# tty0: 发起两次访问
k8s@ubuntu:~/learn-k8s/14-volume$ curl 10.244.2.177
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...
k8s@ubuntu:~/learn-k8s/14-volume$ curl 10.244.2.177
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...

# tty1: 打印日志
k8s@ubuntu:~$ k logs -f volume-hostpath -c busybox
10.244.0.0 - - [08/Nov/2021:13:58:01 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"
10.244.0.0 - - [08/Nov/2021:13:58:11 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"

# tty2: 观察路径内容（在 volume-hostpath 被销毁后仍然存在）
k8s@worker-large-3:~$ cd /home/k8s/learn-k8s/hostpath-dir/logs
k8s@worker-large-3:~/learn-k8s/hostpath-dir/logs$ ll
total 12
drwxr-xr-x 2 root root 4096 Nov  8 21:53 ./
drwxr-xr-x 3 root root 4096 Nov  8 21:53 ../
-rw-r--r-- 1 root root    0 Nov  8 21:53 access.log
-rw-r--r-- 1 root root 1307 Nov  8 21:53 error.log
k8s@worker-large-3:~/learn-k8s/hostpath-dir/logs$ cat access.log
10.244.0.0 - - [08/Nov/2021:13:58:01 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"
10.244.0.0 - - [08/Nov/2021:13:58:11 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"

得益于 HostPath 的这种特性，它常用于被挂载到一些计算任务上（Job 或 CronJob），用来存储这些任务的计算结果。

2.3 使用 nfs

HostPath 已经可以解决数据持久化存储的问题。但是，HostPath 能否正常工作依赖于被调度到的节点的健康状态。试想，一旦 Pod 被调度到的节点出现故障，kube-scheduler 将该 Pod 重新调度到一个新节点上，那就可能造成数据的丢失。一个理想的思路是，将数据的存储独立于具体的节点。因此，Kubernetes 引入了 nfs 这种的类型的存储卷，通过在集群内搭建一台独立的 nfs 服务器来实现数据的共享与存储。

我们将节点 ubuntu 作为 nfs server，其余节点视为 nfs client³。因此，需要在 ubuntu 节点上运行 sudo apt update && sudo apt install nfs-kernel-server、在其余节点上运行 sudo apt update && sudo apt install nfs-common 来安装对应的服务端和客户端程序。

在节点 ubuntu 上，我们要共享的目录为 /srv/nfs4。我们首先创建该目录，然后将该目录添加到 nfs server 的配置文件 /etc/exports 中，然后重新启动 nfs server：

# 启动 nfs server 并检查状态
k8s@ubuntu:/srv/nfs4$ sudo service nfs-server start
k8s@ubuntu:/srv/nfs4$ sudo service nfs-server status
● nfs-server.service - NFS server and services
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2021-11-08 22:17:18 CST; 12h ago
 Main PID: 8934 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/nfs-server.service

Nov 08 22:17:18 ubuntu systemd[1]: Starting NFS server and services...
Nov 08 22:17:18 ubuntu systemd[1]: Started NFS server and services.

# 添加共享目录到配置
k8s@ubuntu:/srv/nfs4$ sudo vim /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
# 添加本行，将 / srv/nfs4 共享给处于 192.168.23.0/24 网段的节点，且无需 root 权限
/srv/nfs4        192.168.23.0/24(rw,sync,no_root_squash)

# 重新启动以更新配置
k8s@ubuntu:~/learn-k8s/14-volume$ sudo /etc/init.d/nfs-kernel-server restart
[ok] Restarting nfs-kernel-server (via systemctl): nfs-kernel-server.service.

至此，准备工作完毕。接下来，我们创建 nfs 类型的存储卷：

# volume-nfs.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  # 声明一个 nfs 类型的存储卷，其名称为 logs-volume，nfs server 所在节点为 192.168.23.160（ubuntu）
  - name: logs-volume
    nfs:
      server: 192.168.23.160
      path: /srv/nfs4

创建成功之后，我们通过 curl 命令访问该 Pod，则访问信息不仅会被记录在 busybox Container 的日志中，也会出现在 ubuntu 节点的共享目录下：

# tty0
k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
volume-nfs   2/2     Running   0          3m18s   10.244.2.178   worker-large-3   <none>           <none>
k8s@ubuntu:~/learn-k8s/14-volume$ curl 10.244.2.178
...
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...
# 文件已被写入共享目录
k8s@ubuntu:~/learn-k8s/14-volume$ ll /srv/nfs4/
total 20
drwxr-xr-x 2 root root 4096 Nov  9 11:14 ./
drwxr-xr-x 3 root root 4096 Nov  9 10:47 ../
-rw-r--r-- 1 root root   91 Nov  9 11:20 access.log
-rw-r--r-- 1 root root 6476 Nov  9 11:16 error.log
k8s@ubuntu:~/learn-k8s/14-volume$ cat /srv/nfs4/access.log
10.244.0.0 - - [09/Nov/2021:03:19:59 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"

# tty1
k8s@ubuntu:~$ k logs -f volume-nfs -c busybox
10.244.0.0 - - [09/Nov/2021:03:19:59 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.58.0" "-"

nfs 是常用的存储卷。它使得 Pod 的输出可以被存储到特定的共享目录文件夹中。当有多 Pod 需要执行，且它们之间存在复杂输入输出依赖关系的时候，nfs 是一个不错的选择。

3 使用高级存储

nfs 似乎已经很好用了。但是，人类社会是要分工的，不断往精细化方向发展。作为存储卷的普通用户，他们不应该被要求能够搭建 nfs 系统、并在 yaml 文件中配置它们。此外，除了 nfs，常用的网络文件系统还有很多，例如 CIFS、GlusterFS 等。为了屏蔽底层存储的实现细节，方便用户使用，Kubernetes 引入了 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）这两种资源对象。

PV 意为持久卷，是对底层的共享存储的一种抽象。一般情况下 PV 由 Kubernetes 管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
PVC 意为持久卷声明，是一般 Kubernetes 用户对于存储需求的一种声明，是用户向 Kubernetes 系统发出的一种资源需求申请。

PV 和 PVC 的工作原理如图 1 所示。基于此，关于持久卷，就有了如下三种角色划分：

底层文件系统，如 nfs、CephFS 等：由存储工程师维护；
PV：由 Kubernetes 管理员维护；
PVC：由一般 Kubernetes 用户负责申请。

图 1 PV 和 PVC 的工作原理。

3.1 创建 PV

一个典型的 PV 的资源清单文件应当包含如下部分：

apiVersion: v1
kind: PersistentVolume
metadata:
  # PV 是集群级别的，不隶属于任何（虚拟的集群）命名空间
  name: some-pv
spec:
  nfs:        # 存储类型，与底层存储系统对应
  capacity:   # 存储能力
    storage: 2Gi
  accessModes:        # 访问模式
  storageClassName:   # 存储类别
  persistentVolumeReclaimPolicy:    # 回收策略

其中，访问模式（accessModes）用于描述用户对存储资源的访问权限，包含如下几种模式：

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

访问模式依赖于底层存储系统的支持。

persistentVolumeReclaimPolicy 指的是回收策略，意为党 PV 不再被使用了之后，Kubernetes 对其的处理方式。支持的策略包含：

Retain（保留）：保留数据，需要管理员手工清理数据
Recycle（回收）：清除 PV 中的数据，效果相当于执行 rm -rf /the-volume/*
Delete（删除）：与 PV 相连的后端存储完成 Volume 的删除操作，这常见于云服务商的存储服务

storageClassName 是存储类别，用于 PVC 和 PV 之间的匹配。若声明了 storageClassName，则有：

具有特定类别的 PV 只能与请求了该类别的 PVC 进行绑定
未设定类别的 PV 则只能与不请求任何类别的 PVC 进行绑定

在一个 PV 的生命周期中，可能会处于 4 种不同的阶段：

Available（可用）：表示可用状态，还未被任何 PVC 绑定
Bound（已绑定）：表示 PV 已经被 PVC 绑定
Released（已释放）：表示 PVC 被删除，但是资源还未被集群重新声明
Failed（失败）：表示该 PV 的自动回收失败

我们采用 nfs 作为底层存储实现，创建 3 个 PV，分别对应 nfs 中暴露的三个路径。为此，我们首先创建 nfs 共享目录并重启 nfs server：

# 创建目录并更新配置
k8s@ubuntu:~$ sudo mkdir /srv/nfs4/{pv1,pv2,pv3} -pv
[sudo] password for k8s:
mkdir: created directory '/srv/nfs4/pv1'
mkdir: created directory '/srv/nfs4/pv2'
mkdir: created directory '/srv/nfs4/pv3'
k8s@ubuntu:~$ ll /srv/nfs4/
total 20
drwxr-xr-x 5 root root 4096 Nov  9 15:13 ./
drwxr-xr-x 3 root root 4096 Nov  9 10:47 ../
drwxr-xr-x 2 root root 4096 Nov  9 15:13 pv1/
drwxr-xr-x 2 root root 4096 Nov  9 15:13 pv2/
drwxr-xr-x 2 root root 4096 Nov  9 15:13 pv3/
k8s@ubuntu:~$ sudo vim /etc/exports
# 添加如下行
/srv/nfs4/pv1        192.168.23.0/24(rw,sync,no_root_squash)
/srv/nfs4/pv2        192.168.23.0/24(rw,sync,no_root_squash)
/srv/nfs4/pv3        192.168.23.0/24(rw,sync,no_root_squash)
# 重启
k8s@ubuntu:~$ sudo /etc/init.d/nfs-kernel-server restart
[ok] Restarting nfs-kernel-server (via systemctl): nfs-kernel-server.service.

现在，我们（作为 Kubernetes 管理员）声明三个 PV，分别对应 nfs 暴露的三个共享目录：

# pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /srv/nfs4/pv1
    server: 192.168.23.160
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /srv/nfs4/pv2
    server: 192.168.23.160
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  capacity:
    storage: 3Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /srv/nfs4/pv3
    server: 192.168.23.160

创建成功后，可以看到其状态：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f pv.yaml
persistentvolume/pv1 created
persistentvolume/pv2 created
persistentvolume/pv3 created
k8s@ubuntu:~/learn-k8s/14-volume$ k get pv -o wide
NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE   VOLUMEMODE
pv1    1Gi        RWX            Retain           Available                                   8s    Filesystem
pv2    2Gi        RWX            Retain           Available                                   7s    Filesystem
pv3    3Gi        RWX            Retain           Available                                   7s    Filesystem

3.2 创建 PVC

一个典型的 PVC 的资源清单文件应当包含如下部分：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev      # PVC 是命名空间级别的资源对象
spec:
  accessModes:        # 访问模式
  selector:           # 采用标签对 PV 选择
  storageClassName:   # 存储类别
  resources:          # 请求空间
    requests:
      storage: 5Gi

其中，访问模式（accessModes）、存储类别（storageClassName）与 PV 并无二致。

现在，我们（作为一般用户）发起对集群内的 PV 的申请：

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi    # 集群内不存在满足此要求的 PV，因此一定会绑定失败

创建之后，可以看到 pvc3 一直处于 pending 状态，这是因为集群中不存在能满足其资源请求的 PV。

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f pvc.yaml
persistentvolumeclaim/pvc1 created
persistentvolumeclaim/pvc2 created
persistentvolumeclaim/pvc3 created
k8s@ubuntu:~/learn-k8s/14-volume$ k get pvc -o wide
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
pvc1        Bound     pv1      1Gi        RWX                           4s    Filesystem
pvc2        Bound     pv2      2Gi        RWX                           4s    Filesystem
pvc3        Pending                                                     4s    Filesystem

3.3 使用 PVC

现在，pvc1 和 pvc2 已经被成功创建，对于 Pod 而言，只需要把它们当作集群内可以用的存储卷即可。我们声明如下的资源对象，发起对 pvc1 和 pvc2 的使用：

# pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","while true; do echo pod1>> /root/out.txt; sleep 10; done;"]
    # 将名为 volume 的存储卷挂载到 / root / 目录下
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    # 声明一个名为 volume 的存储卷，这是一个已经创建了的 PVC
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        readOnly: false   # 存储卷可写
---
apiVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","while true; do echo pod2>> /root/out.txt; sleep 10; done;"]
    # 将名为 volume 的存储卷挂载到 / root / 目录下
    volumeMounts:
    - name: volume
      mountPath: /root/
  volumes:
    # 声明一个名为 volume 的存储卷，这是一个已经创建了的 PVC
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false   # 存储卷可写

通过 apply 命令部署上述资源，那么，应该可以在 nfs 的第一个共享目录（/srv/nfs4/pv1）和第二个共享目录（/srv/nfs4/pv1）上看到这两个 Pod 的输出：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f pods.yaml
pod/pod1 created
pod/pod2 created
k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME   READY   STATUS              RESTARTS   AGE   IP       NODE             NOMINATED NODE   READINESS GATES
pod1   0/1     ContainerCreating   0          6s    <none>   worker-large-3   <none>           <none>
pod2   0/1     ContainerCreating   0          6s    <none>   worker-large-2   <none>           <none>
k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP             NODE             NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          22s   10.244.2.179   worker-large-3   <none>           <none>
pod2   1/1     Running   0          22s   10.244.1.124   worker-large-2   <none>           <none>
k8s@ubuntu:~/learn-k8s/14-volume$ ll /srv/nfs4/pv1
total 12
drwxr-xr-x 2 root root 4096 Nov  9 15:46 ./
drwxr-xr-x 5 root root 4096 Nov  9 15:13 ../
-rw-r--r-- 1 root root   10 Nov  9 15:46 out.txt
k8s@ubuntu:~/learn-k8s/14-volume$ cat /srv/nfs4/pv1/out.txt
pod1
pod1
pod1
k8s@ubuntu:~/learn-k8s/14-volume$  cat /srv/nfs4/pv2/out.txt
pod2
pod2
pod2
pod2
pod2

3.4 PV 和 PVC 的生命周期

PVC 和 PV 是一一对应的，PV 和 PVC 之间的相互作用遵循以下生命周期：

资源供应：管理员手动创建底层存储和 PV。
资源绑定：用户创建 PVC，Kubernetes 负责根据 PVC 的声明去寻找 PV，并绑定。
- 在用户定义好 PVC 之后，系统将根据 PVC 对存储资源的请求在已存在的 PV 中选择一个满足条件的；
- 一旦找到，就将该 PV 与用户定义的 PVC 进行绑定，用户的应用就可以使用这个 PVC 了。如果找不到，PVC 则会一直处于 Pending 状态，直到符合其要求的 PV 出现；
- PV 一旦绑定到某个 PVC 上，就会被这个 PVC 独占，不能再与其他 PVC 进行绑定了。
资源使用：用户可在 Pod 中像使用一般 Volume 一样使用 PVC：将 PVC 挂载到容器内的某个路径进行使用。
资源释放：用户删除 PVC 来释放 PV。当存储资源使用完毕后，用户可以删除 PVC，与该 PVC 绑定的 PV 将会被标记为 “已释放”，但还不能立刻与其他 PVC 进行绑定。通过之前 PVC 写入的数据可能还被留在存储设备上，只有在清除之后该 PV 才能再次使用。
资源回收：Kubernetes 根据 PV 设置的回收策略进行资源的回收。对于 PV，管理员可以设定回收策略，用于设置与之绑定的 PVC 释放资源之后如何处理遗留数据的问题。只有 PV 的存储空间完成回收，才能供新的 PVC 绑定和使用。

图 2 可视化了这一过程。

图 2 PV 和 PVC 的生命周期。

4 使用配置存储

顾名思义，配置存储，是用来存储配置信息的。接下来将分别介绍 ConfigMap 和 Secret。

4.1 使用 ConfigMap

我们主要关注 ConfigMap 资源清单文件中的 data 字段：

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap
data:
  # info 和 tmp 是文件名，内部存放的是配置信息
  info: |
    username:admin
    password:123456
  tmp: |
    gender:female

创建并查看：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f configmap.yaml
configmap/configmap created
k8s@ubuntu:~/learn-k8s/14-volume$ k get cm configmap
NAME        DATA   AGE
configmap   2      13s
k8s@ubuntu:~/learn-k8s/14-volume$ k describe cm configmap
Name:         configmap
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
info:
----
username:admin
password:123456

tmp:
----
gender:female


BinaryData
====

Events:  <none>

接下来，我们创建一个 Pod，用于消费上述 ConfigMap：

# pod-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
spec:
  containers:
  - name: nginx
    image: nginx
    # 将名为 config 的 ConfigMap 挂载到 / configmap/config 目录上
    volumeMounts:
    - name: config
      mountPath: /configmap/config
  # 声明一个名为 config 的存储卷，它是一个已经创建了的 ConfigMap
  volumes:
  - name: config
    configMap:
      name: configmap

部署后可看到：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f pod-configmap.yaml
pod/pod-configmap created
k8s@ubuntu:~/learn-k8s/14-volume$ k get po pod-configmap
NAME            READY   STATUS    RESTARTS   AGE
pod-configmap   1/1     Running   0          20s
k8s@ubuntu:~/learn-k8s/14-volume$ k exec -it pod-configmap -- /bin/bash
root@pod-configmap:/# cd /configmap/config
# 查看 config files 是否存在
root@pod-configmap:/configmap/config# ls -al
total 12
drwxrwxrwx 3 root root 4096 Nov  9 08:35 .
drwxr-xr-x 3 root root 4096 Nov  9 08:35 ..
drwxr-xr-x 2 root root 4096 Nov  9 08:35 ..2021_11_09_08_35_17.943161345
lrwxrwxrwx 1 root root   31 Nov  9 08:35 ..data -> ..2021_11_09_08_35_17.943161345
lrwxrwxrwx 1 root root   11 Nov  9 08:35 info -> ..data/info
lrwxrwxrwx 1 root root   10 Nov  9 08:35 tmp -> ..data/tmp
# 打印内容
root@pod-configmap:/configmap/config# cat info
username:admin
password:123456
root@pod-configmap:/configmap/config# cat tmp
gender:female
root@pod-configmap:/configmap/config# exit
exit

注意，如果我们通过 edit 命令动态更新这个名为 config 的 ConfigMap，那么进入到 pod-configmap 内部可发现对应的配置文件也同步更新。

4.2 使用 Secret

Secret 和 ConfigMap 相比，主要用于存储敏感的配置信息，如密码、秘钥、证书等。Sceret 可以作为 Volume 的一个域被容器挂载，还可以被用作 Pod 内容器的环境变量（通过设定 pod.spec.containers.env.valueFrom.secretKeyRef 字段）。我们定义一个如下的 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: secret
type: Opaque      # Used to facilitate programmatic handling of secret data.
data:
  # key-value
  username: YWRtaW4=
  password: MTIzNDU2

其中 value 字段是经过 base64 编码之后所形成的：

k8s@ubuntu:~/learn-k8s/14-volume$ echo -n 'admin' | base64
YWRtaW4=
k8s@ubuntu:~/learn-k8s/14-volume$ echo -n '123456' | base64
MTIzNDU2

创建上述资源对象，然后查看详情：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f secret.yaml
secret/secret created
k8s@ubuntu:~/learn-k8s/14-volume$ k describe secret secret
Name:         secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
username:  5 bytes    # 出于安全考虑，这里并不显示编码后的字符串
password:  6 bytes

同样地，我们创建一个 Pod，用于消费上述 Secret：

# pod-secret.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
spec:
  containers:
  - name: nginx
    image: nginx
    # 将名为 config 的 Secret 挂载到 / secret/config 目录上
    volumeMounts:
    - name: config
      mountPath: /secret/config
  # 声明一个名为 config 的存储卷，它是一个已经创建了的 Secret
  volumes:
  - name: config
    secret:
      secretName: secret

部署后可看到：

k8s@ubuntu:~/learn-k8s/14-volume$ k apply -f pod-secret.yaml
pod/pod-secret created
k8s@ubuntu:~/learn-k8s/14-volume$ k get po -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP             NODE             NOMINATED NODE   READINESS GATES
pod-secret      1/1     Running   0          20s   10.244.2.180   worker-large-3   <none>           <none>
k8s@ubuntu:~/learn-k8s/14-volume$ k exec -it pod-secret -- /bin/bash
root@pod-secret:/# ls -al /secret/config
total 4
drwxrwxrwt 3 root root  120 Nov  9 09:07 .
drwxr-xr-x 3 root root 4096 Nov  9 09:07 ..
drwxr-xr-x 2 root root   80 Nov  9 09:07 ..2021_11_09_09_07_07.464266466
lrwxrwxrwx 1 root root   31 Nov  9 09:07 ..data -> ..2021_11_09_09_07_07.464266466
lrwxrwxrwx 1 root root   15 Nov  9 09:07 password -> ..data/password
lrwxrwxrwx 1 root root   15 Nov  9 09:07 username -> ..data/username
# 在 Pod 内部，我们看到的就是解码之后的字符串了
root@pod-secret:/# more /secret/config/username
admin
root@pod-secret:/# more /secret/config/password
123456
root@pod-secret:/# exit
exit

5 总结

数据存储是一个程序正常运行所必然发生的行为。本文依次介绍了各种存储的优缺点，并给出了实验分析。对于复杂的应用程序，如工作流可组织成 DAG 形式的应用，DAG 中的一个节点可作为单个 Pod 启动，此时 Pod 与 Pod 之间存在输入输出依赖，一个好的存储方案的选择就至关重要。此时，孩子 Pod 在被调度时，应当确保其来自某个父亲 Pod 的输出数据已经可以从某个目录中获取，从而减少调度的 pending 时长。这似乎还可以和探针结合起来使用。

参考

本文部分改写自黑马 K8S 视频教程的相关章节，感兴趣的读者可自行前往学习。

转载申请

本作品采用知识共享署名 4.0 国际许可协议进行许可，转载时请注明原文链接。您必须给出适当的署名，并标明是否对本文作了修改。

所谓挂载，就是将一个文件设备 “安装” 到操作系统的文件目录树上（为其分配一个路径）。这样，用户就可以在操作系统中，通过路径直接访问到该文件设备。例如，当我们往 Windows PC 上插入一个 U 盘时，可以在文件资源管理器上看到类似 G:\ 这样的文件路径。同理，为容器挂载存储卷，就是将该存储卷（例如，宿主机上的某个目录或通过网络可达的外部文件设备）视为类似于 U 盘这样的文件设备，将其 “安装” 到容器 Pod（本质上是一个精简完整的“机器”）的操作系统中，使得我们可以在该 Pod 中以特定的文件路径访问到这个被安装的存储卷。 ↩︎
Volume 不与 Pod 中单个容器的生命周期相关，但可能与 Pod 的生命周期相关。这取决于 Volume 的类型。 ↩︎
在企业内部，出于高可用的目的，nfs 通常被部署在子网内一台或多台与 K8S 集群独立的服务器上。 ↩︎