Updated on Kubernetes

Kubernetes持久化数据存储-PVC

前面我们学习了 PV 的使用，但是在我们真正使用的时候是使用的 PVC，就类似于我们的服务是通过 Pod 来运行的，而不是 Node，只不过 Pod 跑在 Node 上而已，所以这节课我们就来给⼤家讲解下PVC 的使用方法。

1、准备工作

在使用 PVC 之前，我们还得把其他节点上的 nfs 客户端给安装上，比如我们这⾥：

img

我们需要在所有节点安装 nfs 客户端程序，安装方法请参考文章：《Kubernetes持久化数据存储-PV》，必须在所有节点都安装 nfs 客户端，否则可能会导致 PV 挂载不上的问题。

2、新建PVC

同样的，我们来新建⼀个数据卷声明，我们来请求 1Gi 的存储容量，访问模式也是 ReadWriteOnce，
YAML 文件如下：(pvc-nfs.yaml)

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-nfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

我们可以看到我们这里的声明方法几乎和新建 PV 是⼀样的，在新建 PVC 之前，我们可以看一下之前创建的 PV 的状态：

img

我们可以看到当前 pv1 是在 Available 的⼀个状态，所以这个时候我们的 PVC 可以和这个 PV 进行绑定；我们可以看到 pvc-nfs 创建成功了，状态是 Bound 状态了，这个时候我们再看下 PV 的状态呢：

img

同样我们可以看到 PV 也是 Bound 状态了，对应的声明是 default/pvc-nfs，就是 default 命名空间下面的 pvc-nfs，证明我们刚刚新建的 pvc-nfs 和我们的 pv1 绑定成功了。

疑问？

有的同学可能会觉得很奇怪，我们并没有在 pvc-nfs 中指定关于 pv 的什么标志，它们之间是怎么就关联起来了的呢？其实这是系统自动帮我们去匹配的，他会根据我们的声明要求去查找处于 Available 状态的 PV，如果没有找到的话那么我们的 PVC 就会⼀直处于 Pending 状态，找到了的话当然就会把当前的 PVC 和目标 PV 进⾏绑定，这个时候状态就会变成 Bound 状态了。比如我们新建⼀个 PVC，如下：(pvc2-nfs.yaml)

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc2-nfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  selector:
    matchLabels:
      app: nfs

我们这里声明⼀个 PV 资源的请求，邀请访问模式是 ReadWriteOnce，存储容量是 2Gi，最后我们还要求匹配具有标签 app=nfs 的 PV，但是可以这样要求吗？我们可以先查看下当前系统的所有 PV，发现都是 Bound 状态，并没有 Available 状态的 PV，所以我们可以想象到我们上⾯新建的 PVC 是没办法选择到合适的 PV 的，我们创建⼀下看看：

img

很显然是 Pending 状态，因为并没有合适的 PV 给你使用，现在我们来新建⼀个 PV，让上⾯的 PVC有合适的 PV 使用：（pv2.yaml）

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
  labels:
    app: nfs
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 172.16.200.1
    path: /data/k8s

我们这里新建⼀个名为 pv2 的 PV，具有标签 app=nfs，容量也是 2Gi，访问模式是ReadWraiteOnce，看上去这⼀切都很适合上面的 PVC，新建试⼀试。创建完 pv2 后，很快就发现该 PV 是 Bound 状态了，对应的 PVC 是 default/pvc2-nfs，证明上⾯的 pvc2-nfs 终于找到合适的 PV 进行绑定上了：

img

很显然成功了，有的同学可能又会说了，我们的 pv2 声明的容量是 2Gi，如果我 pvc2-nfs 这里声明的容量是 1Gi 的话呢？还能正常绑定吗？如果可以正常绑定的话，那剩下的 1Gi 容量还能使用吗？其实我也不清楚，怎么办？我们去实际测试下就知道了吧，先删除上⾯的 pvc2-nfs，然后我们把该PVC 里面的容量改成 1Gi，再新建试⼀试呢：

img

我们可以看到上main的 PVC 依然可以正常的绑定（绑定需要一个过程、小伙伴们不要着急），仔细看 CAPACITY 这⼀列的数据：2Gi，也就是说我们声明的 1Gi 是没什么用的，我 PV 是 2Gi，这里声明 1Gi 是不⾏的，你必须得使用 2Gi。

注：如果我们这⾥容量声明是 3Gi 呢？还可以正常绑定吗？大家可以思考⼀下，如果声明的容量大于PV 里面的容量的话，是没办法进行绑定的，感兴趣的小伙伴可以自己去测试一下。

3、使用PVC

上⾯我们已经知道怎么创建 PV 和 PVC 了，现在我们就来使用 PVC，这里我们同样使用之前的 nginx 的镜像来测试下：(nfs-pvc-deploy.yaml)

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pvc
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nfs-pvc
  template:
    metadata:
      labels:
        app: nfs-pvc
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: pvc2-nfs
---
apiVersion: v1
kind: Service
metadata:
  name: nfs-pvc
  labels:
    app: nfs-pvc-svc
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: web
  selector:
    app: nfs-pvc

我们这里使用 nginx 镜像，将容器的 /usr/share/nginx/html 目录通过 volume 挂载到名为 pvc2-nfs 的PVC 上⾯，然后创建⼀个 NodePort 类型的 Service 来暴露服务：

img

然后我们就可以通过任意节点的 IP:31373 端口来访问这里的 Nginx 服务了，但是这个时候我们来访问会出现403，这是为什么？我们再去看看 nfs 共享数据目录下面有没有数据呢？

img

[root@Master ~]# ls /data/k8s/
[root@Master ~]#

我们发现并没有任何数据，这是因为我们把容器目录/user/share/nginx/html和挂载到了pvc2-nfs这个PVC 上面，这里的 PVC 就是对应着我们上面的 nfs 的共享数据目录的，该目录下面还没有任何数据，所以我们访问就出现了403，现在我们在/data/k8s这个目录下⾯新建⼀个 index.html 的文件：

img

我们可以看到共享数据目录中已经有⼀个 index.html 的文件了，由于我们挂载了 pvc2-nfs 到上面的nginx 容器中去，是不是这个时候容器目录/user/share/nginx/html下面也有index.html这个文件了？所以这个时候我们再来访问下服务，任⼀节点IP:31373 ：

img

现在是不是正常了啊，但是我们可以看到容器中的数据是直接放到共享数据目录的根目录下⾯的，如果以后我们又有⼀个新的 nginx 容器也做了数据目录的挂载，是不是就会有冲突了，所以这个时候就不太好区分了，这个时候我们可以在 Pod 中使用⼀个新的属性：subPath，该属性可以来解决这个问题，我们只需要更改上⾯的 Pod 的 YAML 文件即可：

img

更改完 YAML ⽂件后，我们重新更新即可：

img

我们可以预想到现在我们访问上面的服务，是不是又会得到403的结果呢？因为nginxpvc-test目录下⾯还没有任何文件呢，我们把根目录下面的 index.html 文件移动到 nginxpvc-test ⽬录下面去是不是又可以访问了。

到这里我们就算完整的使用了⼀次 PVC 了，现在我们再来验证下数据是否会丢失，怎么验证？⾸先我们把上⾯的 Deployment 删除掉，这样他下面管理的3个 Pod 也会被⼀起删除掉：

img

Deployment 被删除掉了，但是 nfs 的数据共享目录下面的数据还在。当然了如果不在了，我们用他就没有任何意义了，现在我们再来重新创建上面的 Deployment，看看访问服务还能得到上面的正常输出结果：

img

可以看到 nfs-pvc 这个 Deployment 创建成功了，由于 Service 我们之前没有删除掉，所以这里提示已经存在，我们忽略就可以了，现在同样我们⽤任⼀节点 IP:31373 来访问这里的服务，是不是依然可以在页面上看到 Hello Kubernetes！这里的输出信息，证明我们的数据持久化已经成功了！

4、注意事项

上⾯我们演示了数据持久化，如果这个时候我们把 PV 给删除了，上面持久化的数据还会存在吗？如果是删除的 PVC 呢？在实际使用的项目中，是很有可能出现这种情况的？下⾯我们来实际验证下。我们先删除上⾯使⽤的 PV，然后再看看之前创建的 PVC 还会存在吗：

img

img

是不是觉得很奇怪，pvc2-nfs 仍然是 Bound 的状态，也就意味着我们还可以正常使用这个 PVC，但是如果我们有⼀个新的 Pod 来使用这个 PVC 会是怎样的情况呢？感兴趣的同学可以自己去验证一下。

注：如有 Pod 正在使用 pvc2-nfs 这个 PVC 的话，那么新建的 Pod 则仍可使用，如无 Pod 使用，则创建 Pod 挂载此 PVC 时会出现失败。感兴趣的同学可以自己去验证一下。

现在我们在恢复到最开始的状态，把 PV 和 PVC 添加回来，如果现在我们把使用 pvc2-nfs 关联的Pod 都删除，然后再删除该 PVC 的话，那么我们的持久化数据还存在吗？

img

我们可以看到 pv2-nfs 这个 PV 的状态已经变成了 Released 状态了（我这里删除非常慢，有点问题、截图后面补上），这个状态是不是表示 PVC 已经被释放了，现在可以被重新绑定了，由于我们设置的 PV 的回收策略是 Recycle，所以我们可以很明显的发现 nfs 的共享数据目录下⾯已经没有了数据了，这是因为我们把 PVC 给删除掉了，然后回收了数据。

注：这里大家一定要注意，并不是所有的存储后端的表现结果都是这样的，我们这里使用的是 nfs，其他存储后端肯能会有不⼀样的结果。大家在使用 PV 和 PVC 的时候⼀定要注意这些细节，不然⼀不小心就把数据搞丢了。

推荐文章