k8s存储持久化(nfs用例)

在k8s中对于存储的资源抽象了两个概念,分别是PersistentVolume(PV)、PersistentVolumeClaim(PVC)。

  • PV是集群中的资源
  • PVC是对这些资源的请求。

PV和PVC都只是抽象的概念,在k8s中是通过插件的方式提供具体的存储实现,目前包含有NFS、ceph、iSCSI和云提供商指定的存储系统,

一、认识PV/PVC/StorageClass

1、概念介绍

  管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API,用于抽象如何根据消费方式提供存储的详细信息。为此,我们引入了两个新的API资源:PersistentVolume和PersistentVolumeClaim

       PV :PersistentVolume(持久化卷),是对底层的共享存储的一种抽象,PV 由管理员进行创建和配置,它和具体的底层的共享存储技术的实现方式有关,比如 Ceph、GlusterFS、NFS 等,都是通过插件机制完成与共享存储的对接。

  PersistentVolumeClaim(PVC)是由用户进行存储的请求。 它类似于pod。 Pod消耗节点资源,PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式(例如,可以一次读/写或多次只读)。

  虽然PersistentVolumeClaims允许用户使用抽象存储资源,但是PersistentVolumes对于不同的问题,用户通常需要具有不同属性(例如性能)。群集管理员需要能够提供各种PersistentVolumes不同的方式,而不仅仅是大小和访问模式,而不会让用户了解这些卷的实现方式。对于这些需求,有StorageClass 资源。

  StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别,或备份策略,或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”。

       PV是运维人员来创建的,开发操作PVC,可是大规模集群中可能会有很多PV,如果这些PV都需要运维手动来处理这也是一件很繁琐的事情,所以就有了动态供给概念,也就是Dynamic Provisioning,动态供给的关键就是StorageClass,它的作用就是创建PV模板。创建StorageClass里面需要定义PV属性比如存储类型、大小等;另外创建这种PV需要用到存储插件。最终效果是,用户提交PVC,里面指定存储类型,如果符合我们定义的StorageClass,则会为其自动创建PV并进行绑定。

  PVC和PV是一一对应的。

PV和PVC中的spec关键字段要匹配,比如存储(storage)大小。

PV和PVC中的storageClassName字段必须一致。

2、生命周期

  PV是群集中的资源。PVC是对这些资源的请求,并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期:

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

  •  供应准备Provisioning---通过集群外的存储系统或者云平台来提供存储持久化支持。
    •  - 静态提供Static:集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中,可用于消费
    •  - 动态提供Dynamic:当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时,集群可能会尝试为PVC动态配置卷。 此配置基于StorageClasses:PVC必须请求一个类,并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。
  •  绑定Binding---用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前,pvc会保持未绑定状态。
  •  使用Using---用户可在pod中像volume一样使用pvc。
  •  释放Releasing---用户删除pvc来回收存储资源,pv将变成“released”状态。由于还保留着之前的数据,这些数据需要根据不同的策略来处理,否则这些存储资源无法被其他pvc使用。
  •  回收Recycling---pv可以设置三种回收策略:保留(Retain),回收(Recycle)和删除(Delete)。
    •  - 保留策略:允许人工处理保留的数据。
    •  - 删除策略:将删除pv和外部关联的存储资源,需要插件支持。
    •  - 回收策略:将执行清除操作,之后可以被新的pvc使用,需要插件支持。

 注:目前只有NFS和HostPath类型卷支持回收策略,AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

3、PV类型

  •  GCEPersistentDisk
  •  AWSElasticBlockStore
  •  AzureFile
  •  AzureDisk
  •  FC (Fibre Channel)
  •  Flexvolume
  •  Flocker
  •  NFS
  •  iSCSI
  •  RBD (Ceph Block Device)
  •  CephFS
  •  Cinder (OpenStack block storage)
  •  Glusterfs
  •  VsphereVolume
  •  Quobyte Volumes
  •  HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
  •  Portworx Volumes
  •  ScaleIO Volumes
  •  StorageOS

4、PV卷阶段状态

  •  Available – 资源尚未被claim使用
  •  Bound – 卷已经被绑定到claim了
  •  Released – claim被删除,卷处于释放状态,但未被集群回收。
  •  Failed – 卷自动回收失败

二、创建PV演示

1、准备nfs服务

  在nfs服务器上先建立存储卷对应的目录

[root@nfs ~]# cd /data/volumes/
[root@nfs volumes]# mkdir v{1,2,3,4,5}
[root@nfs volumes]# ls
index.html  v1  v2  v3  v4  v5
[root@nfs volumes]# echo "<h1>NFS stor 01</h1>" > v1/index.html
[root@nfs volumes]# echo "<h1>NFS stor 02</h1>" > v2/index.html
[root@nfs volumes]# echo "<h1>NFS stor 03</h1>" > v3/index.html
[root@nfs volumes]# echo "<h1>NFS stor 04</h1>" > v4/index.html
[root@nfs volumes]# echo "<h1>NFS stor 05</h1>" > v5/index.html

  修改nfs的配置

[root@nfs volumes]# vim /etc/exports
/data/volumes/v1        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v2        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v3        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v4        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v5        192.168.130.0/24(rw,no_root_squash)

  查看nfs的配置

[root@nfs volumes]# exportfs -arv
exporting 192.168.130.0/24:/data/volumes/v5
exporting 192.168.130.0/24:/data/volumes/v4
exporting 192.168.130.0/24:/data/volumes/v3
exporting 192.168.130.0/24:/data/volumes/v2
exporting 192.168.130.0/24:/data/volumes/v1

  配置生效

[root@nfs volumes]# showmount -e
Export list for nfs:
/data/volumes/v5 192.168.130.0/24
/data/volumes/v4 192.168.130.0/24
/data/volumes/v3 192.168.130.0/24
/data/volumes/v2 192.168.130.0/24
/data/volumes/v1 192.168.130.0/24

2、在master上创建PV

  编写yaml文件,并创建pv。创建5个pv,存储大小各不相同,是否可读也不相同

# vim pv-damo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: nfs
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 15Gi

注:accessModes:支持三种类型
ReadWriteMany 多路读写,卷能被集群多个节点挂载并读写
ReadWriteOnce 单路读写,卷只能被单一集群节点挂载读写
ReadOnlyMany 多路只读,卷能被多个集群节点挂载且只能读
nfs,它支持全部三种。但是ISCI就不支持ReadWriteMany;HostPath就不支持ReadOnlyMany和ReadWriteMany

# kubectl apply -f pv-damo.yaml
persistentvolume/pv001 created
persistentvolume/pv002 created
persistentvolume/pv003 created
persistentvolume/pv004 created
persistentvolume/pv005 created

  查看pv状态

kubectl  get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                      9s
pv002     5Gi        RWO            Retain           Available                                      9s
pv003     5Gi        RWO,RWX        Retain           Available                                      9s
pv004     10Gi       RWO,RWX        Retain           Available                                      9s
pv005     15Gi       RWO,RWX        Retain           Available                                      9s

3、创建PVC,绑定PV

  编写yaml文件,并创建pvc。创建一个pvc,需要6G存储;所以不会匹配pv001、pv002、pv003

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


kubectl apply -f vol-pvc-demo.yaml
persistentvolumeclaim/mypvc created
pod/vol-pvc created

  查询验证:pvc已经绑定到pv004上

# kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc     Bound     pv004     10Gi       RWO,RWX                       24s

# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                            1m
pv002     5Gi        RWO            Retain           Available                                            1m
pv003     5Gi        RWO,RWX        Retain           Available                                            1m
pv004     10Gi       RWO,RWX        Retain           Bound       default/mypvc                            1m
pv005     15Gi       RWO,RWX        Retain           Available                                            1m

  查询业务验证

# kubectl get pods -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP             NODE
vol-pvc   1/1       Running   0          59s       10.244.2.117   node2

# curl 10.244.2.117
<h1>NFS stor 04</h1>

三、动态存储StorageClass

 nfs默认不支持动态存储,使用了第三方的NFS插件 external-storagenfs-client-provisioner

1、流程图

2、创建rbac授权

# cat  rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
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: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

3、创建nfs的nfs-client-provisioner

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 10.10.10.60
            - name: NFS_PATH
              value: /ifs/kubernetes
      volumes:
        - name: nfs-client-root
          nfs:
            server: 10.10.10.60  
            path: /ifs/kubernetes

注:

-value: 10.10.10.60 、server: 10.10.10.60    #换成自己nfs的ip

- name:

NFS_PATH value: /xxx/xxxx   ##nfs共享的目录。

4、创建客户端

kubectl apply -f deployment.yaml

5、创建storage class

kubectl apply -f  class.yaml

reclaimPolicy:有两种策略:Delete、Retain。默认是Delet

fuseim.pri/ifs为上面deployment上创建的PROVISIONER_NAM(在“3、创建nfs的nfs-client-provisioner”)

6、查看 nfs 客户端 和 storage class

客户端
# kubectl  get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-7695c66c6b-56sbw   1/1     Running   0          10m

storage class
# kubectl  get sc
NAME                  PROVISIONER      AGE
managed-nfs-storage   fuseim.pri/ifs   10m

7、创建PVC

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes: # 策略
    - ReadWriteMany
  resources: 
    requests:
      storage: 1Mi # 请求空间大小

创建PersistenetVolumeClaim

kubectl  apply -f test-claim.yaml

查看 pvc

# kubectl  get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
test-claim   Bound    pvc-2febc25a-d2b0-11e9-9623-000c29b3776e   1Mi        RWX            managed-nfs-storage   14s

8、部署测试pod

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: nginx
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc # 绑定pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc #pvc 通过pvc 动态创建pv
      persistentVolumeClaim:
        claimName: test-claim

创建 测试 pod

kubectl  apply -f test-pod.yaml

kubectl  get pod | grep pod
test-pod                                  0/1     Completed   0          81s

kubectl  get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS          REASON   AGE
pvc-e78d0817-d2b0-11e9-9623-000c29b3776e   1Mi        RWX            Delete           Bound    default/test-claim   managed-nfs-storage            22m

 

 

https://github.com/kubernetes-retired/external-storage   github项目地址external-storage

https://www.cnblogs.com/panwenbin-logs/p/12196286.html    实战,分析案例详细

K8S持久化存储-NFS存储卷实战 (qq.com)

https://blog.csdn.net/weixin_30119911/article/details/112337003 实战,tomcat使用storageclass

posted @ 2020-04-30 10:33  凡人半睁眼  阅读(1198)  评论(2编辑  收藏  举报