目录

一，PV和PVC

1，PV概念

2，PVC概念

3，PV与PVC之间的关系

3.1 PV和PVC的生命周期

3.2 一个PVC从创建到销毁的具体流程

3.3 三种回收策略

3.4 查看PV pvc的定义方式，规格

4，两种PV的提供方式

二，基于NFS创建静态PV资源和PVC资源

1，实验环境

2,所有节点安装NFS

3，在master节点创建共享目录

4，master授权共享目录

5，master编辑exports文件

6,master启动rpc和nfs

 7，master创建pv

 8，定义PVC

9,进行测试

 三，搭建storageclass+NFS 实现NFS的动态PV创建

 2，使用deployment来创建NFS Provisioner

 3，创建NFS存储管理器（provisioner）

 4，创建storageclass，复制建立pvc并调用NFS provisioner 进行预订的工作，并让pv与pvc建立关联。

 5，创建PVC和POD测试

一，PV和PVC

1，PV概念

  1. persistentVoiume（PV）是集群中由管理员配置的一段网络存储，集群中的资源就像一个节点是一个集群资源，可以从远程的NFS或分布式对象存储系统中创建得来（PV储存空间大小，访问方式）。
  2. PV是诸如卷之类的卷插件，但是只有独立于使用PV的任何单个pod的生命周期。
  3. 该API对象捕获存储的实现细节，即NFS、ISCSI 或云提供商特定的存储系统
  4. PV就是从存储设备中的空间创建出一个存储资源

2，PVC概念

  1.  PersistentVolumeClaim(PVC) 是用户存储的请求，PVC的使用逻辑：在pod中定义一个存储卷（该存储卷类型为PVC），定义的时候直接按指定大小，PVC必须与对应的PV建立关系，PVC会根据定义去PV申请，而PV是由存储空间创建出来的，PV和PVC是kubernetes抽象出来的一种存储资源
  2. 虽然PersistentVolumeClaim允许用户使用抽象存储资源，但是场景的需求是，用户需要根据不同的需求去创建PV,用于不同的场景，而此时需要集群管理员提供不同需求的PV，而不仅仅是PV的大小和访问模式，但又不需要用户了解这些卷的实现细节。
  3. 对应这样的需求，此时可以采用storageclass资源。

3，PV与PVC之间的关系

PV是集群中的资源，PVC是这些资源的请求，也是对资源的索引检查。

3.1 PV和PVC的生命周期

PV和PVC之间的相互作用遵循以下生命周期：

Provisioning(配置) ---> Binding(绑定) ---> Using(使用) ---> Releasing(释放) ---> Recycling(回收)
  • Provisioning：即PV的创建，可以直接创建PV（静态方式）也可以使用storageclass动态创建
  • binding：将PV分配给PVC
  • Using：Pod通过PVC使用该volume，并可以通过准入控制storageprotection，阻止删除正在使用的PVC。
  • Releasing：POD释放volume并删除PVC
  • Recycling：回收PV,可以保留PV以便下次使用，也可以直接从云存储中删除。

根据这五个阶段，pv的状态有以下4种：

Avaliable（可用）：表示可以状态。还未被任何PVC绑定

Bound（已绑定）：表示PV已经被绑定到PVC

Released（已释放）：表示PVC被删掉，但是资源尚未被集群回收

Failes（失败）：表示该PV的自动回收失败

3.2 一个PVC从创建到销毁的具体流程

  1. 一个PV创建完后状态会变成available，等待被pvc绑定
  2. 一旦被PVC绑定，PV的状态会变成Bound，就可以被定义了相应PVC的pod使用。
  3. Pod使用完成后会释放PV,PV的状态变成Released。
  4. 变成Released的PV会根据定义的回收策略做相应的回收工具。

3.3 三种回收策略

有三种回收策略，Retain，Delete和Recycle。

Retain就是保留现场，K8S集群什么也不做，等待用户收到去处理PV里的1数据，处理完成后，再手动删除PV。

Delete策略：K8S会自动删除该PV及里面的数据。

Recycle方式：K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的pvc绑定使用。

3.4 查看PV pvc的定义方式，规格

查看PV的定义方式

kubectl explain pv

FIELDS:
	apiVersion: v1
	kind: PersistentVolume
	metadata:    #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace
	  name: 
	spec

查看PV定义的规格

kubectl explain pv.spec

spec:
  nfs:（定义存储类型）
    path:（定义挂载卷路径）
    server:（定义服务器名称）
  accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）
    - ReadWriteOnce          #（RWO）存储可读可写，但只支持被单个 Pod 挂载
	- ReadOnlyMany           #（ROX）存储可以以只读的方式被多个 Pod 挂载
	- ReadWriteMany          #（RWX）存储可以以读写的方式被多个 Pod 共享
#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
  capacity:（定义存储能力，一般用于设置存储空间）
    storage: 2Gi （指定大小）
  storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
  persistentVolumeReclaimPolicy: Retain    #回收策略（Retain/Delete/Recycle）
#Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
#Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）

查看PVC的定义方式

kubectl explain pvc
KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:
   apiVersion	<string>
   kind	<string>  
   metadata	<Object>
   spec	<Object>

PV和PVC中的spec关键字段要匹配，比如存储（storage）大小，访问模式（accessModes）、存储类名称（storageClassName）

kubectl explain pvc.spec
spec:
  accessModes: （定义访问模式，必须是PV的访问模式的子集）
  resources:
    requests:
      storage: （定义申请资源的大小）
  storageClassName: （定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）

4，两种PV的提供方式

这里有两种PV的提供方式：静态或者动态

静态----直接固定存储空间

  1. 集群管理员创建一下PV,他们携带可供集群用户使用的真实存储的详细信息，它们存在于kubernetesAPI中可用于消费。

动态------通过存储类进行动态创建存储空间

  1. 当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试动态地为PVC配置卷，此配置基于storageClasses：PVC必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。

二，基于NFS创建静态PV资源和PVC资源

1，实验环境

 master192.168.135.90
node1192.168.135.196
node2192.168.135.200
nfs192.168.135.189

2,所有节点安装NFS

yum install -y nfs-utils rpcbind

3，在master节点创建共享目录

mkdir -p /data/{vol1,vol2,vol3,vol4,vol5}

4，master授权共享目录

[root@nfs189 data]#chmod 777 vol1/
[root@nfs189 data]#chmod 777 vol2
[root@nfs189 data]#chmod 777 vol3
[root@nfs189 data]#chmod 777 vol4
[root@nfs189 data]#chmod 777 vol5

5，master编辑exports文件

vim /etc/exports
/data/vol1 192.168.135.0/24(rw,no_root_squash,sync)
/data/vol2 192.168.135.0/24(rw,no_root_squash,sync)
/data/vol3 192.168.135.0/24(rw,no_root_squash,sync)
/data/vol4 192.168.135.0/24(rw,no_root_squash,sync)
/data/vol5 192.168.135.0/24(rw,no_root_squash,sync)

exportfs -rv

6,master启动rpc和nfs

#手动加载 NFS 共享服务时，应该先启动 rpcbind，再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs

#查看 rpcbind 端口是否开启，rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind

 7，master创建pv

这里定义了5个pv，并且定义挂载的路径已经访问模式，还有pv划分的大小。

[root@master demo]#cat pv-demo.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/vol1
    server: 192.168.135.189
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/vol2
    server: 192.168.135.189
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/vol3
    server: 192.168.135.189
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/vol4
    server: 192.168.135.189
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 4Gi
---
piVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/vol5
    server: 192.168.135.189 
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 5Gi

创建并查看

kubectl apply -f pv-demo.yaml 
kubectl get pv

[root@master demo]#kubectl apply -f pv-demo.yaml 
persistentvolume/pv001 unchanged
persistentvolume/pv002 unchanged
persistentvolume/pv003 unchanged
persistentvolume/pv004 unchanged
persistentvolume/pv005 configured
[root@master demo]#kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                   3m3s
pv002   2Gi        RWO            Retain           Available                                   3m3s
pv003   2Gi        RWO,RWX        Retain           Available                                   3m3s
pv004   4Gi        RWO,RWX        Retain           Available                                   3m3s
pv005   5Gi        RWO,RWX        Retain           Available                                   32s


kubectl describe pv pv001

kubectl explain pv

 8，定义PVC

这里定义了 PVC 的访问模式为多路读写，该访问模式必须在前面 PV 定义的访问模式之中。定义 PVC 申请的大小为 2Gi，此时 PVC 会自动去匹配多路读写且大小为 2Gi 的 PV ，匹配成功获取 PVC 的状态即为 Bound。

vim pvc-demo.yaml
---------------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-pvc
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc

发布并查看

kubectl apply -f pvc-dema.yaml
kubectl get pv

[root@master demo]#kubectl apply -f pvc-demo.yaml 
persistentvolumeclaim/mypvc created
pod/pv-pvc created
[root@master demo]#kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                           28m
pv002   2Gi        RWO            Retain           Available                                           28m
pv003   2Gi        RWO,RWX        Retain           Bound       default/mypvc                           28m
pv004   4Gi        RWO,RWX        Retain           Available                                           28m
pv005   5Gi        RWO,RWX        Retain           Available

9,进行测试

kubectl get pv
kubectl describe pv pv003
找到挂载点

[root@nfs189 data]#cd vol3/
[root@nfs189 vol3]#ls
[root@nfs189 vol3]#echo "this is is a vol3" >> index.htm

 测试访问

[root@master demo]#kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP            NODE    NOMINATED NODE   READINESS GATES
nginx-7f6dd89d46-fhv4z   1/1     Running   4          2d4h   10.244.2.49   node2   <none>           <none>
pod-example              1/1     Running   2          23h    10.244.2.48   node2   <none>           <none>
pv-pvc                   1/1     Running   0          13m    10.244.1.31   node1   <none>           <none>
[root@master demo]#curl 10.244.1.31
this is is a vol3

 三，搭建storageclass+NFS 实现NFS的动态PV创建

apiVersion: v1
kind: ServiceAccount
metadata:

name: nfs-client-provisioner

#创建集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nfs-client-provisioner-clusterrole
rules:

  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]

---

#集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nfs-client-provisioner-clusterrolebinding
subjects:

- kind: ServiceAccount
  name: nfs-client-provisioner
  namespace: default
  roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-clusterrole
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f pvc-demo.yaml

 2，使用deployment来创建NFS Provisioner

#由于 1.20 版本启用了 selfLink，所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错，解决方法如下： vim /etc/kubernetes/manifests/kube-apiserver.yaml

vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:

  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false       #添加这一行
    - --advertise-address=192.168.80.20
      ......

 

 3，创建NFS存储管理器（provisioner）

#创建 NFS Provisioner
vim nfs-client-provisioner.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner   	  #指定Service Account账户
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: nfs-storage       #配置provisioner的Name，确保该名称与StorageClass资源中的provisioner名称保持一致
            - name: NFS_SERVER
              value: stor01           #配置绑定的nfs服务器
            - name: NFS_PATH
              value: /opt/k8s          #配置绑定的nfs服务器目录
      volumes:              #申明nfs数据卷
        - name: nfs-client-root
          nfs:
            server: stor01
            path: /opt/k8s

 4，创建storageclass，复制建立pvc并调用NFS provisioner 进行预订的工作，并让pv与pvc建立关联。

vim nfs-client-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client-storageclass
provisioner: nfs-storage     #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
  archiveOnDelete: "false"   #false表示在删除PVC时不会对数据进行存档，即删除数据

 5，创建PVC和POD测试

kubectl apply -f test-pvc-pod.yaml

 

 

//PVC 通过 StorageClass 自动申请到空间
kubectl get pvc
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS              AGE
test-nfs-pvc   Bound    pvc-11670f39-782d-41b8-a842-eabe1859a456   1Gi        RWX            nfs-client-storageclass   2s
//查看 NFS 服务器上是否生成对应的目录，自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上
ls /opt/k8s/
default-test-nfs-pvc-pvc-11670f39-782d-41b8-a842-eabe1859a456

//进入 Pod 在挂载目录 /mnt 下写一个文件，然后查看 NFS 服务器上是否存在该文件
kubectl exec -it test-storageclass-pod sh
/ # cd /mnt/
/mnt # echo 'this is test file' > test.txt

//发现 NFS 服务器上存在，说明验证成功
cat /opt/k8s/test.txt

 

 

 

# 云原生 # kubernetes # java
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes