云原生|kubernetes|持久化存储pv，pvc和StorageClass的学习（二）-阿里云开发者社区

示例：

deploy-nginx.yaml

此pod的挂载目录不需要提前建立，因为Ensure the file directory is created

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
        volumeMounts:
        - mountPath: /var/local/aaa
          name: mydir
        - mountPath: /var/local/aaa/1.txt
          name: myfile
      volumes:
      - name: mydir
        hostPath:
          path: /var/local/aaa
          type: DirectoryOrCreate
      - name: myfile
        hostPath:
          path: /var/local/aaa/1.txt
          type: FileOrCreate

查询该pod运行在192.168.217.17上，进入17服务器的/var/local/aaa目录下，是可以看到1.txt的

[root@slave1 aaa]# pwd
/var/local/aaa
[root@slave1 aaa]# ls
1.txt

三，local 本地存储

本地持久化存储至少需要两个文件，一个是pv文件，一个是pvc文件，当然，配置本地持久存储就是使用，也就需要部署文件了，并且还需要sc做优化，因此，至多4个文件。

大体规则如下：

pv需要设置node亲和，部署文件也需要设置节点亲和，两者亲和是一样的，也就是必须是选择的同一个节点。
官方建议使用StorageClass，也就是sc，sc设置绑定模式为 WaitForFirstConsumer，也就是延迟绑定
nginx-pv.yaml pv文件，pv必须要设置nodeSelector---节点亲和

下面的文件将StorageClass相关注释去掉就可以了，此时一个完整的使用案例就是需要4个文件了。如果保留注释，那么三个文件就可以部署了。

apiVersion: v1
kind: Namespace
metadata:
  name: web
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nginx-pv
  namespace: web
  labels:
    type: local
spec:
  capacity:
    storage: 3Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
#  storageClassName: local-storage
  local:
    path: "/opt/nginx/data"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key:  kubernetes.io/hostname
          operator: In
          values:
          - k8s-node2

nginx-pvc.yaml pvc文件

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
  namespace: web
  labels:
    app: nginx-pvc
spec:
  accessModes:
  - ReadWriteOnce #此处需要和pv对应才能匹配
  resources:
    requests:
      storage: 2Gi
#  storageClassName: local-storage #此处需要和StorageClass.yaml匹配

nginx-sc.yaml sc文件：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain

deploy-nginx.yaml 部署文件:

这里使用了两个节点亲和，保留一个就可以啦

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: web
spec:
  containers:
  - name: nginx
    image: nginx:1.18
    volumeMounts:
    - name: nginx-persistent-storage
      mountPath: "/usr/share/nginx/html" #不需要修改，映射到镜像内部目录
  volumes:
    - name: nginx-persistent-storage
      persistentVolumeClaim:
        claimName: nginx-pvc #对应到pvc的名字
  tolerations:
  - operator: Exists
    effect: NoExecute
  nodeName: k8s-node2
  affinity:  #亲和性设置
    nodeAffinity: #申明是node亲和策略
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        nodeSelectorTerms:
        - matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签，实际没有设置此标签，所以会匹配失败
          - key: node
            operator: In
            values: ["web","dev"]

四，nfs持久化存储属于网络存储，这个也是使用比较普遍的一个存储方式。

nfs服务安装在192.168.217.18服务器上，nfs服务的安装流程如下（centos服务器为例）：

所有节点都安装

yum install nfs rpcbind nfs-utils -y

在18服务器上：

[root@slave2 local]# cat /etc/exports
/data/nfs-sc  10.244.0.0/16(rw,no_root_squash,no_subtree_check) 192.168.217.16(rw,no_root_squash,no_subtree_check) 192.168.217.0/24(rw,no_root_squash,no_subtree_check) *(rw,no_root_squash,subtree_check)
systemctl enable nfs rpcbind
systemctl restart nfs rpcbind
验证：
[root@slave2 local]# showmount -e 192.168.217.18
Export list for 192.168.217.18:
/data/nfs-sc (everyone)

直接使用nfs存储部署一个nginx持久化存储：

nfs存储卷可以将现有的nfs-server上的存储空间挂载到Pod中使用。当删除Pod时，nfs存储卷的内容会被保留，卷仅是被卸载而不是删除。而且NFS是文件系统级共享服务，支持被多个Pod挂载使用。定义NFS存储卷时支持嵌套使用3个字段：
server：NFS Server的地址或域名
path：NFS Server共享的目录
readOnly：是否以只读方式挂载，默认false

部署示例：

deploy-nginx-volume-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-nfs-demo
  namespace: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-nfs-demo
  template:
    metadata:
      labels:
        app: volume-nfs-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: nfs-volume
          mountPath: /usr/share/nginx/html/mysite
      volumes:
      - name: nfs-volume
        nfs:
         server: 192.168.217.18
         path: /data/nfs-s

测试：

在18服务器上建立测试文件

[root@slave2 nfs-sc]# echo "192.168.217.18" >index.html
[root@slave2 nfs-sc]# pwd
/data/nfs-sc

回到集群，查看是否正确挂载：

[root@master nginx]# k exec -it volume-nfs-demo-6dd859c5fc-8ntzs -n web -- /bin/bash
root@volume-nfs-demo-6dd859c5fc-8ntzs:/# curl localhost/mysite/
192.168.217.18

OK，利用nfs网络存储实现数据持久化我们已经可以比较简单的实现了，但问题也比较多，这么一个持久化存储需要我们自己来维护，磁盘限额，挂载方式，回收策略等等还是需要人工处理，这未免不太合适了，并且可能集群内不会只使用一种存储资源，可能会使用ceph，iscsi等等其他的各种存储资源，因此在k8s中，给我们提供了一个新的对象资源，叫做PV，不同的PV会对应到不用的存储资源，这样我们在部署pod的时候直接调用集群内部的pv，即可完成对存储资源的使用，但是呢，直接调用PV的话，有个问题就是，这个pv是否满足我们的需求，因为我们可能需要的是存储能力比较大存储资源，所以这个时候需要一个一个去对比pv，这样很耗费资源，这个时候又引入了我们的pvc。我们在创建pod的时候会附带一个PVC的请求，PVC的请求相当于就是去寻找一个合适的pv，进行绑定，这样我们的pod就会使用到这个pv了。也就是说让我们的pvc去寻找pv，而不是我们的pod资源去寻找。

注：pv和pvc并不是一一对应的，pvc和pv是一一对应的关系，这个不要搞错了（这个需要反复强调）。

nfs服务结合pv和pvc的应用

PV和PVC介绍

PV是由k8s集群管理员在全局级别配置的存储卷，它通过支持的存储卷插件及给定的配置参数关联到指定存储系统的存储空间，这个的存储空间可能是ceph rbd-image、nfs共享的目录和cephfs文件系统等等，也就是说PV的数据最终是保存在后端的存储系统上的。PV将存储系统上的存储空间抽象为集群级别的API资源，由管理员负责创建维护。

将PV提供的存储空间用于Pod对象存储卷时，用户需要先在namespace中创建PVC资源声明需要的存储空间大小和访问模式等属性，接下来PV控制器会选择合适的PV与PVC进行绑定。随后，在Pod资源中通过persistenVolumeCliam卷插件指定要使用的PVC对象就可以使用这个PVC绑定的PV的存储空间。

总结来说，PV和PVC就是在用户和存储系统之间添加的一个中间层，管理员事先定义好PV，用户通过PVC声明要使用的存储特性来绑定符合条件的最佳PV，从而实现了用户和存储系统之间的解耦，用户不需要了解存储系统的具体使用方式，只需要定义PVC就可以。

云原生|kubernetes|持久化存储pv，pvc和StorageClass的学习（二）

示例：

deploy-nginx.yaml

三，local 本地存储

nginx-pvc.yaml pvc文件

nginx-sc.yaml sc文件：

deploy-nginx.yaml 部署文件:

四，nfs持久化存储属于网络存储，这个也是使用比较普遍的一个存储方式。

部署示例：

PV和PVC介绍

相关概念（pv，pvc）：

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像