Kubernetes数据持久化之Storage Class（存储类）及自动创建PV

通过博文Kubernetes的存储之Volume可以了解到Kubernets实现数据持久化的流程为：
搭建NFS底层存储——>创建PV——>创建PVC——>创建pod
最终将pod中的container实现数据的持久化！

从上述流程中，看似没有什么问题，但是仔细研究就会发现：PVC在向PV申请存储空间时，是根据指定PV的名称、访问模式、容量大小来决定具体向哪个PV申请空间的。

打比方说：如果PV的容量是20G，定义的访问模式是WRO（只允许以读写的方式挂载到单个节点），而PVC申请的存储空间为10G，那么一旦这个PVC是向上述的PV申请的空间，也就是说，那么PV有10G的空间被白白浪费了，因为其只允许单个节点挂载。这是一个非常严重的问题。就算不考虑这个问题，我们每次手动去创建PV也是比较麻烦的事情，这是就需要使用一个自动化的方案来替我们创建PV。这个自动化的方案就是——Storage Class（存储类）！

Storage class（存储类）概述

Storage class（存储类）是Kubernetes资源类型的一种，它是由管理员为管理PV更加方便而创建的一个逻辑组，可以按照存储系统的性能高低、综合服务质量、备份策略等分类。不过Kubernetes本身并不知道类别到底是什么，这是一个简单的描述而已！

存储类的好处之一就是支持PV的动态创建，当用户用到持久化存储时，不必再去提前创建PV，而是直接创建PVC就可以了，非常的方便。同时也避免了空间的浪费！

Storage class（存储类）三个重要的概念：
1）Provisioner（供给方、提供者）：提供了存储资源的存储系统。Kubernetes内部多重供给方，这些供给方的名字都以“kubernetes.io”为前缀。并且还可以自定义；
2）Parameters（参数）：存储类使用参数描述要关联到的存储卷，注意不同的供给方参数也不同；
3）ReclaimPlicy：pv的回收策略，可用的值有Delete（默认）和Retain；

下面通过一个nginx基于自动创建PV实现数据持久化的案例进一步的了解Storage Class的具体使用！

1）搭建NFS共享存储

为了方便，就直接在master节点上部署NFS存储了！

[[email protected] ~]# yum -y install nfs-utils rpcbind
[[email protected] ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[[email protected] ~]# systemctl start nfs-server
[[email protected] ~]# systemctl start rpcbind
[[email protected] ~]# showmount -e
Export list for master:
/nfsdata *

2）创建rbac授权

这种自动创建PV的方式涉及到了rbac授权机制，关于rbac授权机制这里先不详细介绍，随后再更新说明。

[[email protected] ~]# vim rbac-rolebind.yaml
kind: Namespace              #创建一个名称空间，名称为xiaojiang-test
apiVersion: v1
metadata:
  name: xiaojiang-test
---
apiVersion: v1                            #创建一个用于认证的服务账号
kind: ServiceAccount
metadata:
  name: nfs-provisioner
  namespace: xiaojiang-test
---
apiVersion: rbac.authorization.k8s.io/v1        #创建群集规则
kind: ClusterRole
metadata:
  name: nfs-provisioner-runner
  namespace: xiaojiang-test
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: ["watch", "create", "update", "patch"]
   -  apiGroups: [""]
      resources: ["services", "endpoints"]
      verbs: ["get","create","list", "watch","update"]
   -  apiGroups: ["extensions"]
      resources: ["podsecuritypolicies"]
      resourceNames: ["nfs-provisioner"]
      verbs: ["use"]
---
kind: ClusterRoleBinding                #将服务认证用户与群集规则进行绑定
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: xiaojiang-test
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
[[email protected] ~]# kubectl apply -f rbac-rolebind.yaml     #执行yaml文件

3）创建nfs-deployment.资源

nfs-deployment的作用：其实它是一个NFS客户端。但它通过K8S的内置的NFS驱动挂载远端的NFS服务器到（容器内）本地目录；然后将自身作为storage provider，关联storage class。

[[email protected] ~]# vim nfs-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: xiaojiang-test
spec:
  replicas: 1                              #指定副本数量为1
  strategy:
    type: Recreate                      #指定策略类型为重置
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccount: nfs-provisioner            #指定rbac yanl文件中创建的认证用户账号
      containers:
        - name: nfs-client-provisioner
          image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner     #使用的镜像
          volumeMounts:
            - name: nfs-client-root
              mountPath:  /persistentvolumes             #指定容器内挂载的目录
          env:
            - name: PROVISIONER_NAME           #容器内的变量用于指定提供存储的名称
              value: lzj-test
            - name: NFS_SERVER                      #容器内的变量用于指定nfs服务的IP地址
              value: 192.168.1.1
            - name: NFS_PATH                       #容器内的变量指定nfs服务器对应的目录
              value: /nfsdata
      volumes:                                                #指定挂载到容器内的nfs的路径及IP
        - name: nfs-client-root
          nfs:
            server: 192.168.1.1
            path: /nfsdata
[[email protected] ~]# kubectl apply -f nfs-deployment.yaml                   #执行yaml文件
[[email protected] ~]# kubectl get pod -n xiaojiang-test
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-7cf975c58b-sc2qc   1/1     Running   0          6s

4）创建SC（Storage Class）

[[email protected] ~]# vim test-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: stateful-nfs
  namespace: xiaojiang-test
provisioner: lzj-test                  #这个要和nfs-client-provisioner的env环境变量中的PROVISIONER_NAME的value值对应。
reclaimPolicy: Retain               #指定回收策略为Retain（手动释放）
[[email protected] ~]# kubectl apply -f test-storageclass.yaml

5）创建PVC

[[email protected] ~]# vim test-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim
  namespace: xiaojiang-test
spec:
  storageClassName: stateful-nfs              #定义存储类的名称，需与SC的名称对应
  accessModes:
    - ReadWriteMany                        #访问模式为RWM
  resources:
    requests:
      storage: 100Mi
[[email protected] ~]# kubectl apply -f test-pvc.yaml
[[email protected] ~]# kubectl get pvc -n xiaojiang-test
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-claim   Bound    pvc-267b880d-5e0a-4e8e-aaff-3af46f21c6eb   100Mi      RWX            stateful-nfs   14s
#保证pvc的状态为Bound，表示关联成功
[[email protected] ~]# ls /nfsdata/             #可以看出用于nfs存储的目录下生成了一个对应的目录
xiaojiang-test-test-claim-pvc-267b880d-5e0a-4e8e-aaff-3af46f21c6eb

至此位置，我们已经实现了根据PVC的申请存储空间去自动创建PV（本地的nfs共享目录下已经生成了一个目录，名字挺长的，是pv+pvc名字定义的目录名），至于这个PVC申请的空间是给哪个pod使用，这已经无所谓了！

6）创建基于nginx镜像的Pod

[[email protected] ~]# vim nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: xiaojiang-test
spec:
  containers:
  - name: myweb
    image: nginx:latest
    volumeMounts:
    - name: myweb-persistent-storage
      mountPath: /usr/share/nginx/html/
  volumes:
  - name: myweb-persistent-storage
    persistentVolumeClaim:
      claimName: test-claim                  #指定使用的PVC名称
[[email protected] ~]# kubectl apply -f nginx-pod.yaml
[[email protected] ~]# kubectl get pod -n xiaojiang-test
NAME                                      READY   STATUS    RESTARTS   AGE
myweb                                     1/1     Running   0          38s
nfs-client-provisioner-7cf975c58b-sc2qc   1/1     Running   0          60m

7）测试验证

[[email protected] ~]# kubectl exec -it myweb -n xiaojiang-test /bin/bash
[email protected]:/# cd /usr/share/nginx/html/
[email protected]:/usr/share/nginx/html# echo "hello world" > index.html
#进入容器插入数据进行测试
[[email protected] ~]# cat /nfsdata/xiaojiang-test-test-claim-pvc-267b880d-5e0a-4e8e-aaff-3af46f21c6eb/index.html
hello world
#本地目录测试没有问题
[[email protected] ~]# kubectl exec -it nfs-client-provisioner-7cf975c58b-sc2qc -n xiaojiang-test /bin/sh
/ # ls nfs-client-provisioner
nfs-client-provisioner                        #自动创建pv的可执行程序
/ # cat /persistentvolumes/xiaojiang-test-test-claim-pvc-267b880d-5e0a-4e8e-aaff-3af46f21c6eb/index.html
hello world
#nfs-client容器对应的目录数据也是存在的

从以上测试就可以看出：nginx容器内的网页目录就、本地的nfs共享目录、nfs-client容器中的目录就全部关联起来了。

————————————本文到此结束，感谢阅读————————————————

原文地址：https://blog.51cto.com/14157628/2470108

时间： 2024-10-08 10:46:50

Kubernetes数据持久化之Storage Class（存储类）及自动创建PV的相关文章

Kubernetes数据持久化之Storage Class（存储类）自动创PV

通过博文Kubernetes的存储之Volume可以了解到Kubernets实现数据持久化的流程为:搭建NFS底层存储-->创建PV-->创建PVC-->创建pod最终将pod中的container实现数据的持久化! 从上述流程中,看似没有什么问题,但是仔细研究就会发现:PVC在向PV申请存储空间时,是根据指定PV的名称.访问模式.容量大小来决定具体向哪个PV申请空间的. 打比方说:如果PV的容量是20G,定义的访问模式是WRO(只允许以读写的方式挂载到单个节点),而PVC申请的存储空间

K8s数据持久化之自动创建PV

在前两篇实现k8s的数据持久化的流程为:搭建nfs底层存储===>创建PV====>创建PVC===>创建pod.最终pod中的container实现数据的持久化. 上述流程中,看似没什么问题,但细想一下,PVC在向PV申请存储空间的时候,是根据指定的pv名称.访问模式.容量大小来决定具体向哪个PV来申请空间的,如果PV的容量为20G,定义的访问模式是WRO(只允许以读写的方式挂载到单个节点),而PVC申请的存储空间为10G,那么一旦这个PVC是向上面的PV申请的空间,也就是说,那个PV

k8s数据持久化之statefulset的数据持久化，并自动创建PV与PVC

一:Statefulset StatefulSet是为了解决有状态服务的问题,对应的Deployment和ReplicaSet是为了无状态服务而设计,其应用场景包括:1.稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现2.稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现3.有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依

Kubernetes数据持久化方案

在开始介绍k8s持久化存储前,我们有必要了解一下k8s的emptydir和hostpath.configmap以及secret的机制和用途. 1.EmptydirEmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,EmptyDir主要作用可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件.如果Pod配置了emptyDir类型Volume, Pod 被分配到Node上时候,会创建emptyDir,只要Pod运行在Node上,emptyDir都会存在(容器挂掉不会导致

IOS开发--数据持久化篇之文件存储(一)

前言:个人觉得开发人员最大的悲哀莫过于懂得使用却不明白其中的原理.在代码之前我觉得还是有必要简单阐述下相关的一些知识点. 因为文章或深或浅总有适合的人群.若有朋友发现了其中不正确的观点还望多多指出,不胜感激. 什么叫数据持久化: 在这里我就不照搬教科书上抽象的概念了.我觉得既然要把东西写出来就让它简单明了. 要搞清楚数据持久化,首先要知道数据持久化是相对于缓存而言的,缓存是在程序运行的过程中保存在内存中,程序一旦运行结束,其内存就会被释放.缓存在内存中的数据也就随之消失. 那么数据持久化就是要解

iOS 数据持久化之使用NSUserDefaults存储数据

原文:http://blog.csdn.net/lxinl/article/details/11770675 OS下可以使用NSUserDefaults.sqlite.CoreData几种常用的方式来存储数据,其中NSUserDefaults用来存储类似用户的配置等这些的数据,后两者用户存储大批量和比较复杂的数据.NSUserDefault的使用比较简单: [cpp] view plaincopy NSUserDefaults *mySettingData = [NSUserDefaults s

Kubernetes数据持久化之Secret与ConfigMap

ConfigMap和Secret是Kubernetes中两种特殊类型的存储卷,ConfigMap这种资源对象主要用于提供配置数据以定制程序行为,不过一些敏感的配置信息,比如像用户名.密码.密钥等通常都是由Secret这种资源对象来进行配置的,他们将相应的配置信息保存于对象中,而后在Pod资源上以存储卷的形式将其挂载并获取相应配置,以实现配置与镜像文件的解耦. 一.Secret资源对象 1) Secret概述 Secret资源对象存储数据的方式是以键值对的方式进行存储的,在Pod资源进行Secre

安卓数据持久化：文件存储、SharedPreferences存储以及数据库存储

Android系统中主要提供了三种方式用于简单的实现数据持久化功能: 文件存储(手机自带的内存).SharedPreferences存储以及数据库存储 当然还可以用sd卡存储 读入写出 下面是疯狂java讲义中的关于IO流的一些补充,回忆一下 1,文件存储 手机自带的内存,只能供当前应用程序访问,其他应用程序访问不了,程序卸载这些数据也会随着消失 原理: 基本是先获取一个文件的输出流,然后把信息write进去,最后关闭流 a,通过上下文类context的openFileOutput()方法获得一

k8s存储数据持久化，emptyDir，hostPath，基于Nfs服务的PV，PVC

在docker和K8S中都存在容器是有生命周期的,因此数据卷可以实现数据持久化. 数据卷解决的主要问题: 1.数据持久性:当我们写入数据时,文件都是暂时性的存在,当容器崩溃后,host就会将这个容器杀死,然后重新从镜像创建容器,数据就会丢失. 2.数据共享:在同一个Pod中运行容器,会存在共享文件的需求. 数据卷的类型: 1.emptyDiremptyDir数据卷类似于docker数据持久化的docker manager volume,该数据卷初分配时,是一个空目录,同一个Pod中的容器可以对该