k8s之PV、PVC

k8s的光伏和聚氯乙烯

一、目录、PVC和PV1.3 PV概念1.2 PVC概念1.3 PV和PVC的关系1.4提供PV的两种方式二。基于nfs创建静态PV资源和PVC资源2.1配置nfs存储(192.168.80.14)2.2 k8s主节点定义PV2.3定义PVC2.4测试多访问读写三基于动态存储创建PV和pvc3.1存储类的用处3.2存储类的yaml格式

一、PVC和PV

1.1 PV概念

1.PersistentVolume(PV)是网络存储的一部分，由集群中的管理员配置。集群中的资源就像节点是集群资源一样，可以从远程NFS或分布式对象存储系统(pv存储空间大小、访问模式)创建。

2.Pv是一个卷插件，如一个卷，但仅独立于使用Pv的任何单个pod的生命周期。

3.此API对象捕获存储的实施细节，即NFS、isCSI或云提供商特定的存储系统。

4.PV是从存储设备中的空间创建存储资源。

1.2 PVC概念

PersistentVolumeClaim (Pvc)是用户存储的请求。Pvc的使用逻辑：在podt中定义了一个存储卷(存储卷类型是pvc)。定义时，直接按指定尺寸。pvc必须与相应的pv建立关系。根据定义，pvc将适用于pv，而pv是由存储空间创建的。Pr和pvc是kubernetes提取的一种存储资源。

虽然PersistentVolumeClaims允许用户使用抽象的存储资源，但共同的需求是用户需要根据不同的需求为不同的场景创建V。此时，集群管理员有必要为Pv提供不同的需求，不仅是Pv的大小和访问方式，还有必要让用户知道这些卷的实现细节。

对于这样的需求，此时可以使用storageclass资源。

1.3 PV与PVC之间的关系

是光伏集群中的一种资源。Pvc是对这些资源的请求，也是对资源的索引检查。光伏和聚氯乙烯之间的相互作用遵循这个生命周期：供应-绑定-使用-释放-回收。

1.4 两种PV的提供方式

提供PV有两种方式，静态或动态。

静态直接固定存储空间：

集群管理员创建一些PVS。它们携带集群用户可用的真实存储的详细信息。它们存在于Ktbernetes API中，可用于消费。

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

当管理员创建的静态PVS与用户的PvC不匹配时，群集可能会尝试为Pvc动态配置卷。该配置基于StorageClasses: PvC。必须请求存储类，并且管理员必须已经创建并配置了该类，然后才能执行动态配置。要求声明此类以有效禁用其自身的动态配置。

二、基于nfs创建静态PV资源和PVC资源

2.1 配置nfs存储（192.168.80.14）

1.mkdir -p /data/v{1.5}

chmod 777-R/数据/*

2.vim/etc/出口

/data/v1 192.168.10.0/24(rw，no _ root _ puck，sync)

/data/v2 192.168.10.0/24(rw，no _ root _ puck，sync)

/data/v3 192.168.10.0/24(rw，no _ root _ puck，sync)

/data/v4 192.168.10.0/24(rw，no _ root _ puck，sync)

/data/v5 192.168.10.0/24(rw，no _ root _ puck，sync)

3.系统ctl启动rpcbind

systemctl启动nfs

4.showmount -e

5.主机名ctl集-主机名nfs01

苏联（USSR的缩写）

6.echo '11111' /data/v1/index.html

echo '22222' /data/v2/index.html

echo '33333' /data/v3/index.html

echo '44444' /data/v4/index.html

echo '55555' /data/v5/index.html

2.2 k8s的master节点定义PV

//在此定义5。

个Pv，并且定义挂载的路径以及访问模式，还有pv划分的大小
vim pv-demo.yaml
==========================================================
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /data/v1
server: nfs01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /data/v2
server: nfs01
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /data/v3
server: nfs01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /data/v4
server: nfs01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv005
labels:
name: pv005
spec:
nfs:
path: /data/v5
server: nfs01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 5Gi
==========================================================
kubectl apply -f pv-demo.yaml
kubectl get pv

2.3 定义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-demo.yaml
kubectl get pv

2.4 测试多路读写

1. 我们通过相同的存储卷，只修改pod的名称
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改pod的名称后，apply执行创建
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 查看ip
kubectl get pod -o wide 
4. curl进行测试，查看是否共享存储卷，多路读写

三、基于动态storageclass创建pv与pvc

3.1 storageclass的用处

在pv和pvc使用过程中存在的问题，在pvc申请存储空间时，未必就有现成的pv符合pvc申请的需求，上面nfs在做pvc可以成功的因素是因为我们做了指定的需求处理。当PvC申请的存储空间不一定有满足PvC要求的Pv时,Kubernetes为管理员提供了描述存储"class(类)"的方法(StorageClass）。举个例子，在存储系统中划分一个1TB的存储空间提供给Kubernetes使用，当用户需要一个10G的PvC时，会立即通过restful发送请求，从而让存储空间创建一个10G的image，之后在我们的集群中定义成10c的Pv供给给当前的Pvc作为挂载使用。在此之前我们的存储系统必须支持restful接口，比如ceph分布式存储，而glusterfs则需要借助第三方接口完成这样的请求

3.2 storageclass的yaml格式

kubectl explain storageclass #storageclass也是k8s上的资源
KIND: Storageclass
VERSION: storage.k8s.io/vl
FIELDS:
  allowVolumeExpansion boolean
  allowedTopologies[]Objectapiversionstring
  kind string
  metadata object
  mountOptions []string挂载选项
  parameters map[string]string#参数，取决于分配器，可以接受不同的参数。例如，参数type的值 io1和参数iopsPerGB特定于EBS PV。当参数被省略时,会使用默认值。
  provisioner string-requred-#存储分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
  reclaimPolicy string#回收策略，可以是 Delete或者 Retain。如果 StorageClass 对象被创建时没有指定 reclaimPolicy，它将默认为 Delete。
  volumeBindingModestring#卷的绑定模式

StorageClass 中包含 provisioner、parameters和 reclaimPolicy字段，当 class需要动态分配 PersistentVolume时会使用到。由于storageclass需要一个独立的存储系统，此处就不再演示。从其他资料查看定义storageclass的方式如下:
==========================================================
kind: storageClass
apiversion: storage.k8s.io/v1432
metadata :
  name : standard
provisioner: kubernetes.iol aws-ebs435 parameters:
  type: gp2
reclaimPolicy: Retain
mountoptions:
  - debug