持久化存储 StorageClass
上面文章我们创建的pv和pvc都是静态的，简单的来说静态的pv和pvc需要我们手动的创建，这种情况很大程度上并不能满足我们的需求，比如我们有一个应用需要对存储的并发度要求比较高，而另外一个应用对读写速度又要求比较高，特别是对于StatefulSet类型的应用。使用静态PV就很不合时了，这里就需要使用StorageClass
Kubernetes从v1.4版本开始引入了一个新的资源对象StorageClass，用于标记存储资源的特性和性能。到v1.6版本时，StorageClass和动态资源供应的机制得到了完善，实现了存储卷的按需创建，在共享存储的自动化管理进程中能够实现了重要的一步。
通过StorageClass的定义，管理员可以将存储资源定义为某种类别（Class），正如存储设备对于自身的配置描述（Profile），例如 "快速存储" "慢速存储" "有数据冗余" "无数据冗余"等。用户根据StorageClass的描述就能够直观得知各种存储资源的特性，就可以根据应用对存储资源的需求去申请存储资源了。
StorageClass作为对存储资源的抽象定义，对用户设置的PVC申请屏蔽后端的细节，一方面减轻用户对于存储资源细节的关注，另一方面也减轻了管理员手工管理PV的工作，由系统自动完成PV的创建和绑定，实现了动态的资源供应。使用基于StorageClass的动态资源供应模式将逐步成为云平台的标准存储配置模式
StorageClass的定义主要包括名称、后端存储的提供者(Provisioner)和后端存储的相关参数配置。StorageClass一旦被创建出来，将无法修改。如需修改，则只能删除原StorageClass的定义重建。
上面文章我们创建的pv和pvc都是静态的，简单的来说静态的pv和pvc需要我们手动的创建，这种情况很大程度上并不能满足我们的需求，比如我们有一个应用需要对存储的并发度要求比较高，而另外一个应用对读写速度又要求比较高，特别是对于StatefulSet类型的应用。使用静态PV就很不合时了，这里就需要使用StorageClass
创建Provisioner
如果需要使用StorageClass，我们就需要安装对应的自动配置程序，比如我们这里后端采用的是nfs，那么我们就需要使用到一个nfs-client的自动配置程序，我们也叫它Provisioner，这个程序使用我们已经配置好的nfs服务器，来自动创建持久卷，也就是自动帮我们创建PV
自动创建的PV以{namespace}-${pvcname}-${pvname}进行命名到服务器上
当pv被回收后会以archieved-${namespace}-${pvcname}-${pvname}格式存在服务器上
关于安装nfs这里不在介绍，需要的请点击下面的文章进行查看
Kubernetes PV与PVC
新闻联播老司机
首先，我们需要配置nfs-client的Deployment文件
#环境说明
本次nfs服务器地址192.168.0.14
数据存储目录 /data1/k8s-volume
kind: Deployment
apiVersion: apps/v1
metadata:
name: nfs-client-provisioner
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
strategy:
type: Recreate
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: 192.168.0.14 #nfs server 地址
- name: NFS_PATH
value: /data1/k8s-volume #nfs共享目录
volumes:
- name: nfs-client-root
nfs:
server: 192.168.0.14
path: /data1/k8s-volume
接下来我们还需要创建一个serveraccount,用于将nfs-client-provisioner中的ServiceAccount绑定到一个nfs-client-provisioner-runner的ClusterRole。而该ClusterRole声明了一些权限，其中就包括了对persistentvolumes的增删改查，所以我们就可以利用ServiceAccount来自动创建PV
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
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: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
创建storageclass
fuseim.pri/ifs 需要和deployment保持一直
这里我们声明了一个名为managed-nfs-storage的Storageclass对象
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-nfs-storage provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
创建
[root@k8s-01 nfs-client]# kubectl create -f . deployment.apps/nfs-client-provisioner created serviceaccount/nfs-client-provisioner created clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created storageclass.storage.k8s.io/managed-nfs-storage created
这里也可以直接参考nfs-client的官方文档 （里面有不同存储后端的文件）
https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
接下来我们可以查看一下
#Pod状态Running [root@k8s-01 nfs-client]# kubectl get pod NAME READY STATUS RESTARTS AGE nfs-client-provisioner-57cb5b4cfd-lhqpw 1/1 Running 0 61m #serveraccount也已经创建完成。 [root@k8s-01 nfs-client]# kubectl get sc NAME PROVISIONER AGE managed-nfs-storage fuseim.pri/ifs 62m
接下来我们需要创建一个pvc，来引用刚刚创建的storageclass
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #storageclass 名称
spec:
accessModes: #访问模式
- ReadWriteMany
resources:
requests:
storage: 1024Mi #请求数据大小
#查看sc的名称可以使用kubectl get sc
创建完成后我们可以查看一下pvc
[root@k8s-01 nfs-client]# kubectl apply -f nfs-pvc.yaml persistentvolumeclaim/test-claim created #这里可以看到一个名称为test-claim的pvc，自动帮我们创建了一个pv并绑定到当前的pvc上 [root@k8s-01 nfs-client]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-nfs Bound pv1 10Gi RWO 3h4m test-claim Bound pvc-72ecd497-44e0-11ea-b5f6-000c29eeccce 1Gi RWX managed-nfs-storage 37s #这里可以看到自动创建了一个pv [root@k8s-01 nfs-client]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-72ecd497-44e0-11ea-b5f6-000c29eeccce 1Gi RWX Delete Bound default/test-claim managed-nfs-storage 16m
在默认情况下，我们创建一个pvc需要有一个状态为空闲的pv，然后才会绑定到pvc上。使用storageclass之后，我们不需要的手动创建pv，只需要创建一个pvc，storageclass会自动将pv给创建并且关联
除了上面使用annotations参数指定storageclass的方式以外，还可以通过修改yaml或者或者通过patch的方式将storageclass设置为默认的存储。(如找不到指定的storageclass则会使用默认sc进行创建pv)
##1.通过命令的方式进行修改
kubectl patch storageclass course-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
#2.通过修改storageclass方式
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
annotations:
storageclass.kubernetes.io/is-default-class": "true"
provisioner: fuseim.pri/ifs
#提示: 如果我们有一个默认的sc，则不需要在pvc中声明sc的名称
测试
上面我们创建了nfs-client以及storageclass和pvc，现在我们后端存储已经做好了，接下来我们需要创建一个应用进行演示
使用Deployment 引用PVC
这里的Pod类型和Deployment使用方式是一样的，官方默认使用的是Pod这里就不变，修改为Deployment也是一样的格式
kind: Pod
apiVersion: v1
metadata:
name: test-pod #pod的名称
spec:
containers:
- name: test-pod #容器的名称
image: busybox
imagePullPolicy: IfNotPresent
command: #容器执行的命令
- "/bin/sh"
args:
- "-c"
- "touch /mnt/SUCCESS && exit 0 || exit 1"
volumeMounts:
- name: nfs-pvc #容器挂载点名称
mountPath: "/mnt" #容器挂载目录
restartPolicy: "Never"
volumes:
- name: nfs-pvc #这里的名称要和上面容器挂载点的名称匹配
persistentVolumeClaim: #挂载使用pvc
claimName: test-claim #pvc的名称
我们在busybox创建一个SUCCESS的文件，同时将/mnt目录挂载到pvc中
[root@k8s-01 nfs-client]# kubectl apply -f test.yaml
pod/test-pod created
[root@k8s-01 nfs-client]# kubectl get pod|grep test-pod
test-pod 0/1 Completed 0 4m30s
#在nfs存储目录就可以看到这个目录
[root@k8s-01 nfs-client]# ls /data1/k8s/default-test-claim-pvc-72ecd497-44e0-11ea-b5f6-000c29eeccce/
SUCCESS
#前面说过，在storageclass中创建的存储，会以${namespace}-${pvc name}-${pv name}
使用StatefulSet 引用Storageclass
如果我们使用手动指定pvc的方式，当我们pod为多实例的时候，多个pod使用的是一个pvc。但是我们使用statefulset时，storageclass会为我们每一个Pod创建一个pv和pvc
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: storageclass-test
spec:
replicas: 3
serviceName: "nginx" #使用statefulSet需要在配置文件中设置一个service的名称
template:
metadata:
labels:
app: sc-web
spec:
containers:
- name: nginx
images: nginx
ports:
- containerPort: 80
volumeMounts:
- name: nginx-test-pvc #挂载点名称 要和下面的关联
mountPath: /usr/share/nginx/html #容器挂载目录
volumeClaimTemplates: #使用pvc的情况下就直接在下面创建一个volumes就可以，但是这里不使用pvc
- metadata: #这里的格式和我们创建pvc的格式是相同的
name: nginx-test-pvc #pvc名称 要和上面的关联
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #sc的名称
spec:
accessModes: #访问模式
- ReadWriteMany
resources:
requests:
storage: 10Gi #存储空间
接下来我们创建查看pv和pvc并且查看一下nfs挂载目录的文件
[root@k8s-01 nfs-client]# kubectl get pod NAME READY STATUS RESTARTS AGE nfs-client-provisioner-57cb5b4cfd-lhqpw 1/1 Running 0 169m storageclass-test-0 1/1 Running 0 2m38s storageclass-test-1 1/1 Running 0 2m16s storageclass-test-2 1/1 Running 0 2m9s #当Pod状态为Running时，已经帮我们创建好pv和pvc并且相互绑定 [root@k8s-01 nfs-client]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv1 10Gi RWO Recycle Bound default/pvc-nfs 4h33m pvc-72ecd497-44e0-11ea-b5f6-000c29eeccce 1Gi RWX Delete Bound default/test-claim managed-nfs-storage 89m pvc-81272745-44ec-11ea-b5f6-000c29eeccce 10Gi RWX Delete Bound default/nginx-test-pvc-storageclass-test-0 managed-nfs-storage 2m51s pvc-8dfe513e-44ec-11ea-b5f6-000c29eeccce 10Gi RWX Delete Bound default/nginx-test-pvc-storageclass-test-1 managed-nfs-storage 2m42s pvc-91f8193c-44ec-11ea-b5f6-000c29eeccce 10Gi RWX Delete Bound default/nginx-test-pvc-storageclass-test-2 managed-nfs-storage 2m21s [root@k8s-01 nfs-client]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE nginx-test-pvc-storageclass-test-0 Bound pvc-81272745-44ec-11ea-b5f6-000c29eeccce 10Gi RWX managed-nfs-storage 3m16s nginx-test-pvc-storageclass-test-1 Bound pvc-8dfe513e-44ec-11ea-b5f6-000c29eeccce 10Gi RWX managed-nfs-storage 2m54s nginx-test-pvc-storageclass-test-2 Bound pvc-91f8193c-44ec-11ea-b5f6-000c29eeccce 10Gi RWX managed-nfs-storage 2m47s #同时按照storageclass的生成目录规则帮我们在nfs共享存储中创建好目录 [root@k8s-01 nfs-client]# ll /data1/k8s/ 总用量 0 drwxrwxrwx 2 root root 6 2月 1 20:15 default-nginx-test-pvc-storageclass-test-0-pvc-81272745-44ec-11ea-b5f6-000c29eeccce drwxrwxrwx 2 root root 6 2月 1 20:15 default-nginx-test-pvc-storageclass-test-1-pvc-8dfe513e-44ec-11ea-b5f6-000c29eeccce drwxrwxrwx 2 root root 6 2月 1 20:15 default-nginx-test-pvc-storageclass-test-2-pvc-91f8193c-44ec-11ea-b5f6-000c29eeccce
扩展资料
在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：
$(podname).(headless server name) FQDN： $(podname).(headless server name).namespace.svc.cluster.local #Headless Service，名为nginx，用来定义Pod网络标识(DNS domain) 扩展资料http://www.mamicode.com/info-detail-2368542.html
如果不是使用NFS，使用其他如ceph等，依旧可以参考nfs-client的官方文档
https://github.com/kubernetes-incubator/external-storage
相关文章：
- Kubernetes 1.14 二进制集群安装
- Prometheus Operator 持久化存储
- CentOS 7 ETCD集群配置大全
- Kubernetes PV与PVC
