Kubernetes学习之路（十九）存储卷资源
_____egon新书来袭请看：https://egonlin.com/book.html
一 数据持久化介绍
我们知道，Pod是由容器组成的，而容器宕机或停止之后，数据就随之丢了，那么这也就意味着我们在做Kubernetes集群的时候就不得不考虑存储的问题，而存储卷就是为了Pod保存数据而生的。存储卷的类型有很多，我们常用到一般有以下几种：
1、emptyDir（临时目录）:Pod删除，数据也会被清除，这种存储成为emptyDir，用于数据的临时存储。
2、hostPath(宿主机目录映射)
3、本地的SAN(iSCSI,FC)、NAS(nfs,cifs,http)存储
4、分布式存储（glusterfs，rbd，cephfs）
5、云存储（EBS，Azure Disk）
查看k8s支持的存储类型
[root@master01 ~]# kubectl explain pod.spec.volumes
二 PV与PVC
2.1 PV与PVC
提到存储就不得不说K8S中的PV和PVC了，pv和pvc是kubernetes抽象出来的一种存储资源，具体解释如下
- PV：PersistentVolume，持久化卷
- PVC：PersistentVolumeClaim，存储卷创建申请
PV说白了就是一层存储的抽象，底层的存储可以是本地磁盘，也可以是网络磁盘比如NFS、Ceph之类，既然有了PV那为什么又要搞一个PVC呢？
PVC其实在Pod和PV之前又增加了一层抽象，这样做的目的在于将Pod的存储行为于具体的存储设备解耦，试想一下，假设哪天NFS网络存储的IP地址变化了，如果没有PVC，就需要每个Pod都改一下IP的声明，那得多累，有PVC来屏蔽这些细节之后只用改PV即可！
pv有pvc的绑定与生命周期
PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索赔检查。 #1、PV和PVC之间的相互作用遵循这个生命周期： Provisioning（配置）---> Binding（绑定）--->Using（使用）---> Releasing（释放） ---> Recycling（回收） Provisioning #2、这里有两种PV的提供方式:静态或者动态 静态-->直接固定存储空间： 集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可用于消费。 动态-->通过存储类进行动态创建存储空间： 当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试动态地为 PVC 配置卷。此配置基于 StorageClasses：PVC 必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。 #3、Binding 在动态配置的情况下，用户创建或已经创建了具有特定数量的存储请求和特定访问模式的PersistentVolumeClaim。 主机中的控制回路监视新的PVC，找到匹配的PV（如果可能），并将 PVC 和 PV 绑定在一起。 如果为新的PVC动态配置PV，则循环将始终将该PV绑定到PVC。 否则，用户总是至少得到他们要求的内容，但是卷可能超出了要求。 一旦绑定，PersistentVolumeClaim绑定是排他的，不管用于绑定它们的模式。 如果匹配的卷不存在，PVC将保持无限期。 随着匹配卷变得可用，PVC将被绑定。 例如，提供许多50Gi PV的集群将不匹配要求100Gi的PVC。 当集群中添加100Gi PV时，可以绑定PVC。 #4、Using Pod使用PVC作为卷。 集群检查声明以找到绑定的卷并挂载该卷的卷。 对于支持多种访问模式的卷，用户在将其声明用作pod中的卷时指定所需的模式。 一旦用户有声明并且该声明被绑定，绑定的PV属于用户，只要他们需要它。 用户通过在其Pod的卷块中包含PersistentVolumeClaim来安排Pods并访问其声明的PV。 #5、Releasing 当用户完成卷时，他们可以从允许资源回收的API中删除PVC对象。 当声明被删除时，卷被认为是“释放的”，但是它还不能用于另一个声明。 以前的索赔人的数据仍然保留在必须根据政策处理的卷上. #6、Reclaiming PersistentVolume的回收策略告诉集群在释放其声明后，该卷应该如何处理。 目前，卷可以是保留，回收或删除。 保留可以手动回收资源。 对于那些支持它的卷插件，删除将从Kubernetes中删除PersistentVolume对象，以及删除外部基础架构（如AWS EBS，GCE PD，Azure Disk或Cinder卷）中关联的存储资产。 动态配置的卷始终被删除 Recycling 如果受适当的卷插件支持，回收将对卷执行基本的擦除（rm -rf / thevolume / *），并使其再次可用于新的声明。
如此，便可以极大地解开了耦合，管理分工明确
总结：
k8s要使用存储卷，需要2步：
1、在pod定义volume，并指明关联到哪个存储设备
2、在容器使用volume mount进行挂载
二 emptyDir存储卷
emptyDir ： 是pod调度到节点上时创建的一个空目录，当pod被删除时，emptyDir中的数据也随即被删除，emptyDir长用于容器间共享文件，或者用于创建临时目录。
注：emptyDir不能够用来做数据持久化
[root@master01 ~]# cat emptydir_demo.yaml kind: Deployment apiVersion: apps/v1 metadata: name: emptydir spec: selector: matchLabels: app: emptydir template: metadata: labels: app: emptydir spec: containers: - name: nginx image: nginx volumeMounts: # 在容器内定义挂载存储名称和挂载路径 - mountPath: /usr/share/nginx/html/ name: test-emptydir - name: busybox image: busybox:latest volumeMounts: - mountPath: /egon_data name: test-emptydir command: ['/bin/sh','-c','while true;do echo $(date) >> /egon_data/index.html;sleep 1;done'] volumes: # 定义存储卷 - name: test-emptydir # 定义存储卷名称 emptyDir: {} # 定义存储卷类型
应用
[root@master01 ~]# kubectl apply -f emptydir_demo.yaml deployment.apps/emptydir created [root@master01 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE emptydir-6b6d9b8fbb-pjwpv 2/2 Running 0 52s [root@master01 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES emptydir-6b6d9b8fbb-pjwpv 2/2 Running 0 54s 10.2.43.177 10.1.1.104 <none> <none>
验证：
在上面，我们定义了2个容器，其中一个容器是输入日期到index.html中，然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。如下访问验证:
跑到一台安装有kubelet的节点上，访问pod ip：10.2.43.177
[root@node01 ~]# curl 10.2.43.177 Wed Sep 1 05:15:47 UTC 2021 Wed Sep 1 05:15:49 UTC 2021 Wed Sep 1 05:15:50 UTC 2021 Wed Sep 1 05:15:51 UTC 2021 Wed Sep 1 05:15:52 UTC 2021 Wed Sep 1 05:15:53 UTC 2021
三 hostPath
本地存储即对应K8S中的hostPath， hostPath类似于docker -v参数，将宿主主机中的文件挂载pod中，但是hostPath比docker -v参数更强大，（Pod调度到哪个节点，则直接挂载到当前节点上），
所以说，hostPath可以实现持久存储，但是在node节点故障时，也会导致数据的丢失
========创建PV：首先声明一个PV.yaml，内容如下，声明的本地存储路径为/data/hostpath
apiVersion: v1 kind: PersistentVolume metadata: name: my-pv labels: type: local spec: capacity: storage: 1Gi accessModes: - ReadWriteMany hostPath: # 声明本地存储 path: /data/hostpath
kubectl apply -f PV.yaml创建之
kubectl apply -f PV.yaml
通过kubectl get pv查看
[root@master01 ~]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE my-pv 1Gi RWX Retain Available manual 39s
可以看到创建成功，并且状态是Available，说明还没有被PVC绑定，注意声明的hostPath并不是只有Master节点才有，所有的节点都有！
- Capacity（存储能力）：一般来说，一个 PV 对象都要指定一个存储能力，通过 PV 的 capacity 属性来设置的，目前只支持存储空间的设置，就是我们这里的 storage=1Gi，不过未来可能会加入 IOPS、吞吐量等指标的配置。
- AccessModes（访问模式）：用来对 PV 进行访问模式的设置，用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
- ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
- ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
- ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
可以指定列表：accessModes: ["ReadWriteMany","ReadWriteOnce"]
========创建PVC：再声明一个PVC.yaml，内容如下
这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。定义PVC申请的大小为1Gi，此时PVC会自动去匹配多路读写且大小为1Gi的PV，匹配成功获取PVC的状态即为Bound
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
kubectl apply -f PVC.yaml创建之
kubectl apply -f PVC.yaml
通过kubectl get pvc查看
persistentvolumeclaim/my-pvc created [root@master01 ~]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-pvc Bound my-pv 1Gi RWX manual 13s [root@master01 ~]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE my-pv 1Gi RWX Retain Bound default/my-pvc manual 3m36s [root@master01 ~]#
可以看到PV的状态变成了Bound，说明PV被PVC绑定了（注意：创建 PVC 之后，Kubernetes 就会去查找满足我们声明要求的 PV，如果满足要求就会将 PV 和 PVC 绑定在一起，目前 PV 和 PVC 之间是一对一绑定的关系，也就是说一个 PV 只能被一个 PVC 绑定）
========最后通过如下web-test.yaml声明创建deploy
apiVersion: apps/v1 kind: Deployment metadata: labels: app: web-test name: web-test spec: replicas: 1 selector: matchLabels: app: web-test strategy: {} template: metadata: labels: app: web-test spec: containers: - image: nginx:1.14 name: nginx # 挂载到容器内 volumeMounts: - name: wwwroot mountPath: /usr/share/nginx/html # PVC声明 volumes: - name: wwwroot persistentVolumeClaim: claimName: my-pvc status: {}
应用
kubectl apply -f web-test.yaml
此声明将Pod内的/usr/share/nginx/html绑定到主机的/data/hostpath（通过PV声明的），如果此时访问一下nginx会报403 Forbidden错误，因为主机内的/data/hostpath/index.html并没有，先创建一个（注意：Pod在哪个节点上就在哪个节点上创建）
========创建本地路径：（注意：Pod在哪个节点上就在哪个节点上创建）
# 创建文件夹 mkdir -p /data/hostpath # 写入index.html cat > /data/hostpath/index.html <<EOF Hello egon EOF
验证
[root@master01 ~]# kubectl get deploy,pods -o wide | grep web-test deployment.apps/web-test 1/1 1 1 2m11s nginx nginx:1.14 app=web-test pod/web-test-88bc96645-8mrgd 1/1 Running 0 2m11s 10.2.73.23 10.1.1.103 <none> <none> # 然后验证 [root@node02 ~]# curl 10.2.73.23 Hello egon [root@node02 ~]#
四 网络存储
一般来讲，不会通过本地存储来持久化数据，因为Pod的调度不是固定的，一般会通过网络的方式来存储数据，比如NFS，
nfs使的我们可以挂在已经存在的共享到的我们的Pod中，和emptyDir不同的是，emptyDir会被删除当我们的Pod被删除的时候，但是nfs不会被删除，仅仅是解除挂在状态而已，这就意味着NFS能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间相互传递.并且，nfs可以同时被多个pod挂在并进行读写
这里我们新增加一台虚拟机（192.168.108.100）来充当NFS服务器，安装NFS命令如下（本例中，我们在mananger节点安装nfs）
# 服务端软件安装 yum install -y nfs-utils rpcbind # 安装nfs-utils和rpcbind两个包 # 客户端软件安装(在所有node节点安装) yum install -y nfs-utils # 创建共享目录 mkdir -p /data/nfs # 配置共享目录 cat > /etc/exports <<EOF /data/nfs *(rw,no_root_squash) EOF # 启动nfs服务 systemctl start nfs systemctl enable nfs # 查看服务是否启动成功 ps aux | grep nfs
如果有如下回显，说明启动成功
root 75267 0.0 0.0 0 0 ? S< 08:44 0:00 [nfsd4_callbacks] root 75273 0.0 0.0 0 0 ? S 08:44 0:00 [nfsd]
接下来就是改PV，只需要改动挂载类型即可，如下
[root@master01 ~]# cat PV.yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-pv labels: type: remote # 改为remote spec: capacity: storage: 1Gi accessModes: - ReadWriteMany nfs: #声明nfs存储 path: /data/nfs server: 10.1.1.106
PVC和web.yaml都不用改，然后应用
# 先删除，否则会提示重名 kubectl delete -f web-test.yaml kubectl apply -f PV.yaml kubectl apply -f PVC.yaml kubectl apply -f web-test.yaml
在NFS服务端写入文件
[root@manager ~]# echo "hello big egon" > /data/nfs/a.txt
然后进行测试
[root@node01 ~]# curl 10.2.73.25/a.txt hello big egon
五 Storage Class
先清理一下之前的实验环境
[root@master01 ~]# kubectl delete -f web-test.yaml deployment.apps "web-test" deleted [root@master01 ~]# kubectl delete -f PVC.yaml persistentvolumeclaim "my-pvc" deleted [root@master01 ~]# kubectl delete -f PV.yaml persistentvolume "my-pv" deleted
5.1 什么是StorageClass
Kubernetes提供了一套可以自动创建PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.
我们可以创建不同种类StorageClass，如图：金存储类、银存储类、铜存储类等，此时用户便无需关系存储后端了
StorageClass对象会定义下面两部分内容:
1,PV的属性.比如,存储类型,Volume的大小等.
2,创建这种PV需要用到的存储插件
有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.
但是其实使用起来是一件很简单的事情,你只需要根据自己的需求,编写YAML文件即可,然后使用kubectl create命令执行即可
完整图解如下
5.2 为什么需要StorageClass
在pod中定义一个存储卷（该存储卷类型为PVC），定义的时候直接指定大小，pvc必须根据自己的定义去找到相对应的pv才可以建立关系
而问题的关键是，在pvc申请存储空间时，未必就有现成的pv符合pvc申请的需求，上面nfs在做pvc可以成功的因素是因为我们做了指定的需求处理
而且，在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求
还有，不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。
5.3 StorageClass运行原理及部署流程
要使用 StorageClass，我们就得安装对应的自动配置程序，比如我们这里存储后端使用的是 nfs，那么我们就需要使用到一个 nfs-client 的自动配置程序，我们也叫它 Provisioner，这个程序使用我们已经配置好的 nfs 服务器，来自动创建持久卷，也就是自动帮我们创建 PV。
1.自动创建的 PV 以${namespace}-${pvcName}-${pvName}这样的命名格式创建在 NFS 服务器上的共享数据目录中
2.而当这个 PV 被回收后会以archieved-${namespace}-${pvcName}-${pvName}这样的命名格式存在 NFS 服务器上。
1.原理及部署流程说明
详细的运作流程可以参考下图:
搭建StorageClass+NFS,大致有以下几个步骤:
1.创建一个可用的NFS Server 2.创建Service Account.这是用来管控NFS provisioner在k8s集群中运行的权限 3.创建StorageClass.负责建立PVC并调用NFS provisioner进行预定的工作,并让PV与PVC建立管理 4.创建NFS provisioner.有两个功能,一个是在NFS共享目录下创建挂载点(volume),另一个则是建了PV并将PV与NFS的挂载点建立关联
步骤1：略，我们已经安装好了
[root@manager ~]# cat /etc/exports /data/nfs *(rw,no_root_squash)
步骤2：使用以下文档配置account及相关权限，rbac.yaml: 唯一需要修改的地方只有namespace,根据实际情况定义
apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default #根据实际环境设定namespace,下面类同 --- 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: ["create", "update", "patch"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: run-nfs-client-provisioner subjects: - kind: ServiceAccount name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default roleRef: kind: ClusterRole name: nfs-client-provisioner-runner apiGroup: rbac.authorization.k8s.io --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: leader-locking-nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default rules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: leader-locking-nfs-client-provisioner subjects: - kind: ServiceAccount name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default roleRef: kind: Role name: leader-locking-nfs-client-provisioner apiGroup: rbac.authorization.k8s.io
步骤3：创建NFS资源的StorageClass，nfs-StorageClass.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-nfs-storage provisioner: egon-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致 parameters: archiveOnDelete: "false"
步骤4：创建NFS provisioner，nfs-provisioner.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nfs-client-provisioner labels: app: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default #与RBAC文件中的namespace保持一致 spec: replicas: 1 selector: matchLabels: app: nfs-client-provisioner strategy: type: Recreate selector: matchLabels: app: nfs-client-provisioner 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: egon-nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致 - name: NFS_SERVER value: 10.1.1.106 #NFS Server IP地址 - name: NFS_PATH value: /data/nfs #NFS服务共享出来的挂载卷，去nfs服务端查看cat /etc/exports获取 volumes: - name: nfs-client-root nfs: server: 10.1.1.106 #NFS Server IP地址 path: /data/nfs #NFS 挂载卷
步骤5：应用
[root@master01 ~]# kubectl apply -f rbac.yaml [root@master01 ~]# kubectl apply -f nfs-StorageClass.yaml [root@master01 ~]# kubectl apply -f nfs-provisioner.yaml
=================>测试使用<=================
1、创建pvc文件指定需要的存储空间大小，无需创建pv，文件名test-claim.yaml
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-claim-xxx annotations: volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #与nfs-StorageClass.yaml metadata.name保持一致 spec: accessModes: - ReadWriteMany resources: requests: storage: 10Mi # 指定需要的空间大小
2、确保PVC状态为Boud
[root@master01 ~]# kubectl apply -f test-claim.yaml persistentvolumeclaim/test-claim-xxx created
# 这期间还没有立即创建好 [root@master01 ~]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-claim-xxx Pending managed-nfs-storage 5s [root@master01 ~]# kubectl get pv No resources found in default namespace. [root@master01 ~]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-claim-xxx Pending managed-nfs-storage 12s
# 过一会就创建好了，并且自动创建出了pv [root@master01 ~]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-claim-xxx Bound pvc-bc28e56d-e10f-405e-8b3b-e27b8ef0195a 10Mi RWX managed-nfs-storage 13s [root@master01 ~]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-bc28e56d-e10f-405e-8b3b-e27b8ef0195a 10Mi RWX Delete Bound default/test-claim-xxx managed-nfs-storage 2s
3、创建控制器，应用上面的pvc
[root@master01 ~]# cat web-test.yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: web-test name: web-test spec: replicas: 1 selector: matchLabels: app: web-test strategy: {} template: metadata: labels: app: web-test spec: containers: - image: nginx:1.14 name: nginx volumeMounts: - name: wwwroot mountPath: /usr/share/nginx/html volumes: - name: wwwroot persistentVolumeClaim: claimName: test-claim-xxx # 与pvc名保持一致 status: {} [root@master01 ~]#
应用
[root@master01 ~]# kubectl apply -f web-test.yaml [root@master01 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nfs-client-provisioner-6578dc77d9-pjxnq 1/1 Running 0 16m 10.2.60.122 10.1.1.105 <none> <none> web-test-56bd8bdcbf-4fd2d 1/1 Running 0 4m58s 10.2.43.178 10.1.1.104 <none> <none>
4、去nfs主机里操作挂载点
[root@manager ~]# ll /data/nfs/ 总用量 0 drwxrwxrwx 2 root root 6 9月 1 16:17 default-test-claim-xxx-pvc-bc28e56d-e10f-405e-8b3b-e27b8ef0195a [root@manager ~]# echo 'egon111' > /data/nfs/default-test-claim-xxx-pvc-bc28e56d-e10f-405e-8b3b-e27b8ef0195a/index.html
5、去任意一台安装有kubelet的主机访问
[root@node03 ~]# curl 10.2.43.178 egon111 [root@node03 ~]#
六、关于StorageClass回收策略对数据的影响
1.第一种配置
archiveOnDelete: "false" reclaimPolicy: Delete #默认没有配置,默认值为Delete
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 3.删除PVC后,PV被删除且NFS Server对应数据被删除
2.第二种配置
archiveOnDelete: "false" reclaimPolicy: Retain
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留 4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
3.第三种配置
archiveOnDelete: "ture" reclaimPolicy: Retain
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留 4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
4.第四种配置
archiveOnDelete: "ture" reclaimPolicy: Delete
结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用 3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留 4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
总结:除以第一种配置外,其他三种配置在PV/PVC被删除后数据依然保留
七、常见问题
1.如何设置默认的StorageClass
我们可以用 kubectl patch 命令来更新：
[root@master01 ~]# kubectl get sc #查看当前sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage egon-nfs-storage Delete Immediate false 47m [root@master01 ~]# kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' #设置managed-nfs-storage为默认后端存储 storageclass.storage.k8s.io/managed-nfs-storage patched [root@master01 ~]# kubectl get sc #再次查看,注意是否有default标识 NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage (default) egon-nfs-storage Delete Immediate false 47m [root@master01 ~]# kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' #取消默认存储后端 storageclass.storage.k8s.io/managed-nfs-storage patched [root@master01 ~]# kubectl get sc #再次查看,注意是否有default标识 NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage egon-nfs-storage Delete Immediate false 48m
YAML文件
[root@master01 ~]# cat nfs-StorageClass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-nfs-storage annotations: "storageclass.kubernetes.io/is-default-class": "true" #添加此注释 provisioner: egon-nfs-storage #or choose another name, must match deployment's env PROVISIONER_NAME' parameters: archiveOnDelete: "false"
2.如何使用默认的StorageClass
如果集群有一个默认的StorageClass能够满足我们的需求，那么剩下所有需要做的就是创建PersistentVolumeClaim(PVC)，剩下的都有默认的动态配置搞定，包括无需去指定storageClassName：
[root@master01 ~]# cat test-claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-claim-xxx # 注释掉这两行即可 #annotations: # volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" spec: accessModes: - ReadWriteMany resources: requests: storage: 10Mi # 指定需要的空间大小
3.修改默回收策略(默认为Delete)
[root@master01 ~]# cat nfs-StorageClass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-nfs-storage annotations: provisioner: egon-nfs-storage #or choose another name, must match deployment's env PROVISIONER_NAME' parameters: archiveOnDelete: "true" #暂时不清楚该值对回收策略产生什么影响 reclaimPolicy: Retain #只有NFS 和hostPth支持两种回收策略
4.能过删除/关闭默认的StorageClass
不能删除默认的StorageClass，因为它是作为集群的add-on安装的，如果它被删除，会被重新安装。 当然，可以停掉默认的StorageClass行为，通过删除annotation：storageclass.beta.kubernetes.io/is-default-class,或者设置为false。 如果没有StorageClass对象标记默认的annotation，那么PersistentVolumeClaim对象（在不指定StorageClass情况下）将不自动触发动态配置。相反，它们将回到绑定可用的*PersistentVolume(PV)*的状态。
5.当删除PersistentVolumeClaim(PVC)会发生什么
如果一个卷是动态配置的卷，则默认的回收策略为“删除”。这意味着，在默认的情况下，当PVC被删除时，基础的PV和对应的存储也会被删除。如果需要保留存储在卷上的数据，则必须在PV被设置之后将回收策略从delete更改为retain。
