持久化存储 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
如果需要使用StorageClass,我们就需要安装对应的自动配置程序,比如我们这里后端采用的是nfs,那么我们就需要使用到一个nfs-client的自动配置程序,我们也叫它Provisioner,这个程序使用我们已经配置好的nfs服务器,来自动创建持久卷,也就是自动帮我们创建PV
自动创建的PV以
{namespace}-${pvcname}-${pvname}
进行命名到服务器上
当pv被回收后会以
archieved-${namespace}-${pvcname}-${pvname}
格式存在服务器上
关于安装nfs这里不在介绍,需要的请点击下面的文章进行查看
在Kubernetes中,因为deployment默认使用的是hostpath,当我们pod重启或删除pod后数据会丢失。这时候我们就需要一个持久化存储来解决这个问题。 本次介绍的是kubernetes pv与pvc,同时使用nfs作为后端存储进行演示。 当然kubernetes pv 支持不同的volume,为了环境快速构建学习本次以NFS为主
首先,我们需要配置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,现在我们后端存储已经做好了,接下来我们需要创建一个应用进行演示
这里的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}
如果我们使用手动指定pvc的方式,当我们pod为多实例的时候,多个pod使用的是一个pvc。但是我们使用statefulset时,storageclass会为我们每一个Pod创建一个pv和pvc
apiVersion: apps/v1beta1
kind: StatefulSetyaml
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