中的容器可以读取和写入emptyDir卷中的相同文件#xff0c;尽管该卷可以挂载到每…一、emptyDir存储卷

当Pod被分配给节点时首先创建emptyDir卷并且只要该Pod在该节点上运行该卷就会存在。

正如卷的名字所述它最初是空的。

Pod

中的容器可以读取和写入emptyDir卷中的相同文件尽管该卷可以挂载到每个容器中的相同或不同路径上。

当出于任何原因从节点中删除

Pod

emptyDir可实现Pod中的容器之间共享目录数据但是emptyDir卷不能持久化数据会随着Pod生命周期结束而一起删除。

mkdir

80#定义容器挂载内容volumeMounts:#使用的存储卷名称如果跟下面volume字段name值相同则表示使用volume的这个存储卷-

name:

html#在容器内定义挂载存储名称和挂载路径mountPath:

/data/command:

hostPath可以实现持久存储但是在node节点故障时也会导致数据的丢失

把Node节点上的目录/文件挂载到容器中可实现持久化数据存储。

但是存储空间会受到Node节点的单机限制Node节点故障数据就会丢失且Pod不能实现跨节点共享数据

//在

/data/pod/volume1/index.html//在

node02

/data/pod/volume1/index.html//创建

Pod

ikubernetes/myapp:v1#定义容器挂载内容volumeMounts:#使用的存储卷名称如果跟下面volume字段name值相同则表示使用volume的这个存储卷-

name:

/data/pod/volume1#定义类型这表示如果宿主机没有此目录则会自动创建type:

apply

使用nfs服务将共享存储设备空间挂载到容器中可实现持久化数据存储且Pod能实现跨节点共享数据

mkdir

192.168.73.0/24(rw,no_root_squash)systemctl

start

ikubernetes/myapp:v1volumeMounts:-

name:

Volume持久化存储卷。

它是用来描述或者说用来定义一个存储卷的这个通常都是由运维工程师来定义。

PVC

Claim是持久化存储的请求。

它是用来描述希望使用什么样的或者说是满足什么条件的

PVC

PV和PVC之间的相互作用遵循这个生命周期Provisioning配置---

Binding绑定---

Volume并可以通过准入控制StorageProtection1.9及以前版本为PVCProtection

PVC

一个PV创建完后状态会变成Available等待被PVC绑定。

一旦被PVC邦定PV的状态会变成Bound就可以被定义了相应PVC的Pod使用。

Pod使用完后会释放PVPV的状态变成Released。

变成Released的PV会根据定义的回收策略做相应的回收工作。

有三种回收策略Retain、Delete和Recycle。

Retain就是保留现场K8S集群什么也不做等待用户手动去处理PV里的数据处理完后再手动删除PV。

Delete策略K8S会自动删除该PV及里面的数据。

Recycle方式K8S会将PV里的数据删除然后把PV的状态变成Available又可以被新的PVC绑定使用。

4.3

accessModes:定义访问模型有以下三种访问模型以列表的方式存在也就是说可以定义多个访问模式

ReadWriteOnce

#Retain保留当删除与之绑定的PVC时候这个PV被标记为releasedPVC与PV解绑但还没有执行回收策略且之前的数据依然保存在该PV上但是该PV不可用需要手动来处理这些数据并删除该PV。

AWS

#PV和PVC中的spec关键字段要匹配比如存储storage大小、访问模式accessModes、存储类名称storageClassName

kubectl

如图所示我们将选择一台k8s集群之外的服务器作为NFS共享存储服务器并且按照图中的规格

创建pv再由k8s集群创建pv资源和pvc资源最后将其挂载在pod上进行使用

#创建共享目录

192.168.136.0/24(rw,sync,no_root_squash)

/data/vulumes/v2

192.168.73.0/24(rw,sync,no_root_squash)

/data/vulumes/v3

192.168.73.0/24(rw,sync,no_root_squash)

/data/vulumes/v4

192.168.73.0/24(rw,sync,no_root_squash)

/data/vulumes/v5

192.168.73.0/24(rw,sync,no_root_squash)

#发布共享目录

ReadWriteManypersistentVolumeReclaimPolicy:

Recyclenfs:path:

ReadWriteOncepersistentVolumeReclaimPolicy:

Recyclenfs:path:

ReadWriteManypersistentVolumeReclaimPolicy:

Recyclenfs:path:

ReadWriteManypersistentVolumeReclaimPolicy:

Recyclenfs:path:

ReadWriteManypersistentVolumeReclaimPolicy:

Recyclenfs:path:

ReadWriteManyresources:requests:storage:

2Gikubectl

mypdpersistentVolumeClaim:claimName:

myclaimkubectl

上面介绍的PV和PVC模式是需要运维人员先创建好PV然后开发人员定义好PVC进行一对一的Bond但是如果PVC请求成千上万那么就需要创建成千上万的PV对于运维人员来说维护成本很高Kubernetes提供一种自动创建PV的机制叫StorageClass它的作用就是创建PV的模板。

StorageClass

不同的类型可能会映射到不同的服务质量等级或备份策略或是由集群管理员制定的任意策略。

Kubernetes

本身并不清楚各种类代表的什么。

这个类的概念在其他存储系统中有时被称为配置文件。

StorageClass

API

StorageClass。

https://kubernetes.io/zh/docs/concepts/storage/storage-classes/卷插件称为

Provisioner存储分配器NFS

192.168.73.0/24(rw,no_root_squash,sync)systemctl

restart

nfs-client-provisioner-clusterrole

rules:-

nfs-client-provisioner-clusterrolebinding

subjects:

nfs-client-provisionernamespace:

default

nfs-client-provisioner-clusterroleapiGroup:

rbac.authorization.k8s.iokubectl

apply

/etc/kubernetes/manifests/kube-apiserver.yaml

spec:containers:-

--feature-gatesRemoveSelfLinkfalse

#添加这一行-

--advertise-address192.168.73.105

......kubectl

/etc/kubernetes/manifests/kube-apiserver.yaml

kubectl

nfs-client-provisionerstrategy:type:

Recreatetemplate:metadata:labels:app:

nfs-client-provisionerspec:serviceAccountName:

#指定Service

quay.io/external_storage/nfs-client-provisioner:latestimagePullPolicy:

name:

#配置provisioner的Name确保该名称与StorageClass资源中的provisioner名称保持一致-

name:

#这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致

false

#false表示在删除PVC时不会对数据进行打包存档存档文件以archived开头kubectl

apply

volume.beta.kubernetes.io/storage-class:

#另一种SC配置方式

#关联StorageClass对象resources:requests:storage:

1Gi

nfs-pvcpersistentVolumeClaim:claimName:

test-nfs-pvc

根据PVC的配置模板通过引用StorageClass(简称SC)资源调用存储卷插件来动态的方式创建PV

Available可用表示为可用状态此时PV已经被创建出来了但还未被PVC绑定

Bound已绑定表示PV已经与PVC绑定了PV与PVC是一对一的绑定关系此时PVC可以被Pod使用

Failed失败表示PV被自动回收失败

2准备创建PV资源的配置文件定义访问模式(ReadWriteOnce、ReadOnlyMany、ReadWriteMany、ReadWriteMany)、存储空间大小、回收策略Retain、Recycle、Delete、存储设备类型、storageClassName等

3准备创建PVC资源的配置文件定义访问模式(必要条件必须是PV支持的访问模式)、存储空间大小(默认就近选择大于等于指定大小的PV)、storageClassName等来绑定PV

4创建Pod资源挂载PVC存储卷定义卷类型为persistentVolumeClaim并在容器配置中定义存储卷挂载点路径

1准备好存储设备和共享目录

2如果是外置存储卷插件需要先创建serviceaccount账户(Pod使用访问apiserver使用的账户)和RBAC授权(创建角色授予相关资源对象的操作权限再将账户与角色绑定)使得serviceaccount账户具有对PV、PVC、StorageClass等资源的操作权限

3准备创建外置存储插件Pod资源的配置文件定义serviceaccount账户作为Pod的用户并设置相关的环境变量(比如存储插件名称等)

4创建StorageClass资源provisioner要设置为存储插件名称

------------------------以上操作是一劳永逸的之后只需要创建PVC资源引用StorageClass就可以自动调用存储卷插件动态创建PV资源------------------------

5准备创建PVC资源的配置文件定义访问模式、存储空间大小、storageClassName设置为StorageClass资源名称等来动态创建PV资源并绑定PV

6创建Pod资源挂载PVC存储卷定义卷类型为persistentVolumeClaim并在容器配置中定义存储卷挂载点路径