k8s 里的kv和kvs

最新推荐文章于 2024-02-29 15:26:55 发布

YJ Thoreau

最新推荐文章于 2024-02-29 15:26:55 发布

阅读量785

点赞数

分类专栏： Docker技术集群与应用文章标签：容器

本文链接：https://blog.csdn.net/qq_44135433/article/details/121488994

版权

Docker技术集群与应用专栏收录该内容

29 篇文章 2 订阅

订阅专栏

一： PVC和PV概述

1.1 什么是pvc和pv

PersistentVolume (PV)是集群中已由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源。PV是诸如卷之类的卷插件,但是具有独立于使用Pv的任何单个pod的生命周期。该API对象捕获存储的实现细节,即NFS, iscs1或云提供商特定的存储系统。

PersistentVolumeClaim (PVC)是用户存储的请求。PVC的使用逻辑:在pod中定义一个存储卷(该存储卷类型为PVC) ,定义的时候直接指定大小, pvc必须与对应的pv建立关系, pvc会根据定义去pv申请, 而pv是由存储空间创建出来的。pv和pvc是kubernetes抽象出来的一种存储资源。

虽然PersistentvolumeClaims允许用户使用抽象存储资源,但是常见的需求是,用户需要根据不同的需求去创建PV,用于不同的场景。而此时需要集群管理员提供不同需求的PV,而不仅仅是PV的大小和访问模式,但又不需要用户了解这些卷的实现细节**。对于这样的需求,此时可以采用storageclass资源。**

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

PV和pvc之间的相互作用遵循这个生命周期

Provisioning (配置)–> Binding (绑定)–Using (使用)–> Releasing (放) —> Recycling (回收)

1.2两种pv的提供方式

PV的提供方式有两种，分别是静态和动态

静态----> 直接固定存储空间
- 集群管理员创建一些pv。它们携带可供集群用户使用的正式存储的详细信息。它们存在于kubernetes API 中，可用于消费。
动态----> 通过存储类进行动态创建空间
- 当管理员创建的静态pv都不匹配用户的pvc时，集群可能会尝试动态的为pvc配置卷。此配置基于StorageClasses: PVC 必须请求存储类，并且管理员必须已创建并配该类才能进行动态的配置。要求该类的声明有效地为自己禁用动态配置

小结

PV 就是从存储设备的空间创建出一个存储资源(逻辑上存在）

静态：由k8s管理员创建的，供k8s集群（pod）使用的存储资源，可以从远程的NFS，或者分布式对象存储系统中创建得来（pv存储空间大小，访问方式）
动态storageClass(存储类资源）：用于动态的自动创建pvc申请的pv资源供pod使用

pod 使用pvc ----请求------> PV资源 ------> 存储设备中

二：查看pv和pvc的定义方式

2.1 使用explain 查看pv的定义方式

2.1.1 查看pv的定义方式

kubectl  explain pv  #查看pv的定义方式

FIELDS:
  apiVersion
  kind
  metadata
  spec

2.1.2 查看pv定义的规格

[root@master ~]# kubectl  explain pv.spec
spec:
  nfs (定义存储类型)
    path (定义挂载卷路径)
    server (定义服务器名称)
  accessModes (定义访问模型,有以下三种访问模型,以列表的方式存在,也就是说可以定义多个访问模式)
    ReadwriteOnce (RWO) 单节点读写
    ReadonlyMany (ROX) 多节点只读
    ReadwriteMany (RWX) 多节点读写
  capacity (定义PV空间的大小)
    storage (指定大小)

2.2 使用explain 查看pvc的定义方式

2.2.1 查看pvc的定义方式

kubectl  explain  pvc  #查看pvc的定义方式
KIND:  PersistentVolumeClaim
VERSION:  v1
FIELDS:
    apiVersion: <string>
    kind <string>
    metadata <Object>
    spec <Object>

2.2.2 查看pvc的规格

kubectl  explain pvc.spec  #查看pvc的规格

spec:
	accessModes (定义访问模式,必须是pv的访问模式的子集)
	resources (定义申请资源的大小)
	  requests:  
	  storage:

三：配置nfs使用pv和pvc

3.1配置nfs存储

[root@nfs ~]# yum -y install nfs-utils rpcbind
[root@nfs ~]# mkdir -p /data/volumes/v{1..5}
[root@nfs ~]# ls -R /data/
[root@nfs ~]# chmod  -R 777 /data/*

#配置nfs共享的目录
[root@nfs ~]# for i in {1..5}
do 
echo "/data/volumes/v$1 192.168.23.0/24(rw,no_root_squash,sync)" >> /etc/exports
done 


#写入网页内容
[root@nfs ~]# for i in {1..5}
do
echo "this is pv00$i" > /data/volumes/v$i/index.html
done

[root@nfs ~]# systemctl  start rpcbind
[root@nfs ~]# systemctl start nfs
[root@nfs ~]# exportfs  -arv
[root@nfs ~]# showmount  -e

3.2 定义pv

定义5个 pv，并且定义挂载的路径及访问模式，pv划分大小

[root@master ~]# vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: stor01
  accessModes: 
    - ReadWriteMany
    - ReadWriteOnce
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: stor01
  accessModes: 
    - ReadWriteOnce
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: stor01
  accessModes: 
    - ReadWriteMany
    - ReadWriteOnce
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: stor01
  accessModes: 
    - ReadWriteMany
    - ReadWriteOnce
  capacity:
    storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: stor01
  accessModes: 
    - ReadWriteMany
    - ReadWriteOnce
  capacity:
    storage: 5Gi

[root@master ~]# kubectl  apply  -f pv-demo.yaml 
[root@master ~]# kubectl  get pv

3.3 定义pvc

3.3.1 情况1

pvc请求的访问模式accessMode 及 storage大小(capacity 栏）都完全符合

[root@master ~]# vim pod-vol-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-vo1-pvc
  namespace: default
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
       claimName: mypvc

[root@master ~]# kubectl  apply -f  pod-vol-pvc.yaml 
persistentvolumeclaim/mypvc created
pod/pod-vo1-pvc created
[root@master ~]# kubectl  get pods,pv -o wide

[root@master ~]# curl 10.244.1.151
this is pv003

3.3.2 情况2

在访问模式符合的情况下，大小不符合，则会再所以大于请求大小的pv中，选择大小最接近的

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc-test02
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-vo2-pvc
  namespace: default
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
       claimName: mypvc-test02

[root@master ~]# kubectl  apply  -f  pod-vol-pvc.yaml 
persistentvolumeclaim/mypvc-test02 created
pod/pod-vo2-pvc created
[root@master ~]# kubectl  get pods,pv,pvc  -o wide
[root@master ~]# curl 10.244.2.117
this is pv004

3.3.3 情况3

在访问模式不符合，或者大小没有满足的（都效于），则pod和pvc都处于pending状态

[root@master ~]# vim   pod-vol-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc-test03
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 7Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-vo3-pvc
  namespace: default
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
       claimName: mypvc-test03

[root@master ~]# kubectl  apply  -f  pod-vol-pvc.yaml 
persistentvolumeclaim/mypvc-test03 created
pod/pod-vo3-pvc created
[root@master ~]# kubectl  get pods,pv,pvc  -o wide

[root@master ~]# kubectl  get pods,pv,pvc  -o wide

[root@master ~]# kubectl  describe  pod pod-vo3-pvc

3.3.4 情况4

使用多主机读写 RWX (ReadWriteMany) 模式，将新创建的pod 加入到已有的pvc 中

[root@master ~]# vim pod-vol-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-vo4-pvc
  namespace: default
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
       claimName: mypvc-test02

[root@master ~]# kubectl  apply  -f  pod-vol-pvc.yaml 
pod/pod-vo4-pvc created
[root@master ~]# kubectl  get pods,pv,pvc  -o wide
[root@master ~]# curl  10.244.1.152
this is pv004

3.3.4 pvc绑定情况和多节点读写的小结

当pvc请求的类型accessModes 和存储storage大小没有完全符合的pv时

会在 accessModes类型相同的情况下
- 选择storage存储大于请求的pv，
- 在多个都大于时，会选择最接近的。
在类型accessModes都没有符合的情况下，或者storage存储大小都小于请求的时候
- pod和pvc会处于pnding状态

多节点读写：

在创建pod时，pod.spec.volumes.claimName 的值使用已有的pvc 名,可以是pod使用已有的pvc，从而使用pv

3.4 删除pvc绑定

[root@master ~]# kubectl  describe  persistentvolumeclaims mypvc-test02
....
Mounted By:    pod-vo2-pvc
               pod-vo4-pvc

.....

#先删除使用这个pvc的所有pod
[root@master ~]# kubectl delete  pod pod-vo{2,4}-pvc
pod "pod-vo2-pvc" deleted
pod "pod-vo4-pvc" deleted


#再删除pvc
[root@master ~]# kubectl delete  persistentvolumeclaims mypvc-test02
persistentvolumeclaim "mypvc-test02" deleted


#查看发现pvc确实被删除了，但是，相应的pv处于Released状态，此时pv无法被新pvc绑定
[root@master ~]# kubectl  get pods,pv,pvc  -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
persistentvolume/pv004   4Gi        RWO,RWX        Retain           Released    default/mypvc-test02                           73m   Filesystem

使用 edit 在线对pv 资源进行编辑，删除claiRef段落。保存后，通过命令查看，其状态就自动变为了Available，PV即可重新使用

[root@master ~]# kubectl  edit  persistentvolume pv004
...
 #删除
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: mypvc-test02
    namespace: default
    resourceVersion: "242922"
    uid: 95ef0c00-754e-4a8e-81c3-f8ee4d5f9824
.....

[root@master ~]# kubectl  get pods,pv,pvc  -o wide

NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE   VOLUMEMODE

persistentvolume/pv004   4Gi        RWO,RWX        Retain           Available                                           81m   Filesystem

四：storageClass

4.1 为什么做storageClass

在pv和pvc使用过程中存在的问题,在pvc申请存储空间时,未必就有现成的pv符合pvc申请的需求,上面nfs在做pvc可以成功的因素是因为我们做了指定的需求处理。

那么当PVC申请的存储空间不一定有满足PVC要求的PV时,又该如何处理呢? ? ?为此, Kubernetes为管理员提供了描述存储"Class(类) "的方法(StorageClass) 。

举个例子,在存储系统中划分一个1TB的存储空间提供给Kubernetes使用,当用户需要一个10G的PVC时,会立即通过restful发送请求,从而让存储空间创建一个10G的image,之后在我们的集群中定义成10G的PV供给给当前的PVc作为挂载使用。在此之前我们的存储系统必须支持restful接口,比如ceph分布式存储,而glusterfs则需要借助第三方接口完成这样的请求。

4.2示例

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

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