目录
内容
三者的概念
PV全称叫做Persistent Volume,持久化存储卷。它是用来描述或者说用来定义一个存储卷的,这个通常都是有运维或者数据存储工程师来定义。
PVC是用来描述希望使用什么样的或者说是满足什么条件的存储,它的全称是Persistent Volume Claim,也就是持久化存储声明。开发人员使用这个来描述该容器需要一个什么存储。
StorageClass(SC)
PV是运维人员来创建的,开发操作PVC,可是大规模集群中可能会有很多PV,如果这些PV都需要运维手动来处理这也是一件很繁琐的事情,所以就有了动态供给概念,也就是Dynamic Provisioning。而我们上面的创建的PV都是静态供给方式,也就是Static Provisioning。而动态供给的关键就是StorageClass,它的作用就是创建PV模板。
三者的关系
我们拿云同步和本地存储来作比喻。
-
PV只是定义存储卷的。我们将它比作云同步软件,我们得手动安装某个云同步软件
-
PVC是定义存储卷的订单。我们将它比作我们决定这台手机上用什么同步软件,就专指这样一个决定。
-
Deployment中则会存在volumes和它自身相关的volumeMounts, Deployment就好像是某台手机。
apiVersion: apps/v1 kind: Deployment metadata: name: tomcat-deploy spec: replicas: 1 selector: matchLabels: appname: myapp template: metadata: name: myapp labels: appname: myapp spec: containers: - name: myapp image: tomcat:8.5.38-jre8 ports: - name: http containerPort: 8080 protocol: TCP volumeMounts: - name: tomcatedata mountPath : "/data" volumes: - name: tomcatedata persistentVolumeClaim: claimName: nfs-pvc001
- volumes 记录了这台手机将使用什么云同步软件
- volumeMounts 就是这台手机本地的记录内容(即便换了新手机,云同步软件上还会有之前的历史记录,我们依旧可以同步并继续)
-
StorageClass(SC)
则是更加高级了。它高级在哪里呢? 如果用程序来说,我们应该可以把它看做是一个高阶函数。它会定义PV和PVC的匹配逻辑,一旦我们说想要使用某种同步软件, 则会在SC中去查找匹配,如果匹配中了其中某种已经注册的软件,则会自动为我们进行安装(而不需要我们再去应用市场找软件,手动安装软件),方便我们使用。
聊聊实际应用
就这个话题我就仅以一名前端开发在实际项目应用中的流程做个简短高效的描述把。
首先前面我们介绍了PV,PVC, SC三者的概念和关系,相信大家大致有了一些认识了。 那实际项目中我们该如何进行呢? 通常步骤是:
- 定义存储类型 ( 你可以有两个选择,创建PV或SC )
这里面会涉及让选择各种不同的存储介质,例如nfs, amasonS3, 物理机目录等等。
- 创建PV
- 创建StorageClass
-
定义“需求关系”-PVC ( 确定了订单号,后续deployment中用; 订单号中指定了存储类型 )
-
deployment中定义这个挂载, 注意两个关键定义点
-
volumes
volumes: - name: v-serverA #volume的名称 persistentVolumeClaim: claimName: pvc-serverA # pvc的名称
-
volumeMounts
volumeMounts: - mountPath: /usr/local/app/tmp #本地文件路径 name: v-serverA #volume的名称
-
0 条评论