{"msg":"操作成功","code":200,"data":{"createBy":"admin","createTime":"2021-10-05 17:53:03","updateBy":"admin","updateTime":"2021-10-05 17:53:03","remark":null,"id":72,"articleTitle":"Kubernetes（十）共享存储PV&PVC","articleUrl":"k8s_pv_and_pvc","articleThumbnail":"https://www.asumimoe.com/imgfiles/20220906/f93daad129a04b8db74eed70cd45263b.png","articleFlag":"0","draftStatus":"1","reprintStatement":"1","articleSummary":"为了能够屏蔽底层存储实现的细节，让用户方便使用，同时让管理员方便管理，Kubernetes从1.0版本就引人PersistentVolume（PV）和PersistentVolumeClaim（PVC）两个资源对象来实现对存储的管理子系统。","articleContent":"## 共享存储机制概述\n\nKubernetes对于有状态的容器应用或者对数据需要持久化的应用，不仅需要将容器内的目录挂载到宿主机的目录或者emptyDir临时存储卷，而且需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建后仍然可以使用之前的数据。不过，存储资源和计算资源(CPU/内存)的管理方式完全不同。为了能够屏蔽底层存储实现的细节，让用户方便使用，同时让管理员方便管理，Kubernetes从1.0版本就引人PersistentVolume（PV）和PersistentVolumeClaim（PVC）两个资源对象来实现对存储的管理子系统。\n\nPV是对底层网络共享存储的抽象，将共享存储定义为一种 “资源”，比如Node也是一种容器应用可以“消费”的资源。PV由管理员创建和配置，它与共享存储的具体实现直接相关，例如GlusterFS、iSCSI、RBD或GCE或AWS公有云提供的共享存储，通过插件式的机制完成与共享存储的对接，以供应用访问和使用。\n\nPVC则是用户对存储资源的一个“申请\"。就像Pod“消费”Node的资源一样，PVC能够“消费”PV资源，PVC可以申请特定的存储空间和访问模式。\n\n使用PVC“申请“到一定的存储空间仍然不能满足应用对存储设备的各种需求。通常应用程序都会对存储设备的特性和性能有不同的要求，包括读写速度、并发性能、数据冗余等更高的要求，Kubernetes 从1.4版本并始引入了一个新的资源对象StorageClass，用于标记存储资源的特性和性能。到1.6版本时，StorageClass和动态资原供应的机制得到了完善，实现了存储卷的按需创建，在共享存储的自动化管理进程中实现了重要的一步。\n\n通过StorageClass的定义，管理员可以将存储资源定义为某种类别（Class），正如存储设备对于自身的配置描述（Profile），例如“快速存储”“慢速存储”“有数据完余”“无数据冗杂”等，用户根据StorageClass的描述就能够直观地得知各种存储资源的特性，就可以根据应用对存储资源的需求去申请存储资源了。\n\nKubernetes从1.9版本开始引人容器存储接口Container Storage Interface（CSI）机制，目标是在Kubernetes和外部存储系统之间建立一套标准的存储管理接口，通过该接口为容器提供存储服务。\n\n## PV（持久卷）\n\n### 介绍\n\nPV作为存储资源，主要包括存储能力、访问模式、存储类型、回收策略、后端存储类型等关键信息的配置。\n\n```yaml\napiVersion: v1\nkind: PersistentVolume\nmetadata:\n  name: mypv\nspec:\n  capacity:\n    storage: 3Gi # 存储空间设置为3Gb\n  accessModes:\n    - ReadWriteMany\n  persistentVolumeReclaimPolicy: Recycle\n  storageClassName: slow\n  nfs:\n    path: /nfsshare\n    server: 192.168.52.211\n```\n\nKubernetes支持的PV类型有很多，以下只是其中一部分：\n\n-  AWSElasticBlockStore：AWS公有云提供的ElasticBlockStore\n-  AzureFile：Azure公有云提供的Flie\n-  AzureDisk：Azure公有云提供的Disk\n-  FC (Fibre Channel)：光纤存储设备\n-  Flexvolume：插件式存储机制\n-  Flocker：开源共享存储系统\n-  NFS：开源共享存储系统\n-  iSCSI：iSCSI存储设备\n-  RBD (Ceph Block Device)：Ceph块存储\n-  CephFS：开源共享存储系统\n-  Cinder (OpenStack block storage)\n-  Glusterfs：开源共享存储系统\n-  VsphereVolume：VMware提供的存储系统\n-  HostPath：宿主机目录\n\n### 关键配置参数\n\n1. 存储能力（Capacity）\n\n   描述存储设备具备的能力，目前仅支持对存储空间的设置。\n\n2. 存储卷模式（Volume Mode）\n\n   可选项包括Fliesystem（文件系统）和Block（块设备），默认值为Filesystem。\n\n3. 访问模式\n\n   对PV进行访问模式的设置，用于描述用于的应用对存储资源的访问权限。\n\n   - ReadWriteOnce：表示具有读写权限，但是只能被一个node挂载一次；\n   - ReadOnlyMany：表示具有只读权限，可以被多个node多次挂载；\n   - ReadWriteMany：表示具有读写权限，可以被多个node多次挂载。\n\n4. 存储类别（Class）\n\n   PV可以设定其存储的类别，通过`storageClassName`参数指定一个`StorageClass`资源对象的名称。具有特定类别的PV只能与请求了该类别的PVC进行绑定。未设定类别的PV则只能与不请求任何类别的PVC进行绑定。\n\n5. 回收策略（Reclaim Policy）\n\n   通过PV定义中的`persistentVolumeReclaimPolicy`字段进行设置，可选项如下：\n\n   - Retain：保留数据，需要手工处理。\n   - Delete：删除，与PV相连的后端存储完成Volume的删除操作。\n   - Recycle：回收空间，清除PV中的所有数据。\n\n   目前，只有NFS和HostPath支持Recycle策略；AWS EBS、GCE PD、 Azure Disk和Cinder volume支持Delete策略。\n\n### 生命周期\n\n某个PV的生命周期可能处于以下四个阶段中的一个：\n\n- Available（可用）：表示可用状态，还未被任何PVC绑定\n- Bound（已绑定）：表示PVC已经被PVC绑定\n- Released（已释放）：PVC被删除，但是资源还未被集群回收\n- Failed（失败）： 表示该PV的自动回收失败\n\n## PVC（持久卷声明）\n\nPVC作为用户对存储资源的需求申请，主要包括存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。\n\n```yaml\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: mypvc1\nspec:\n  accessModes:\n    - ReadWriteMany\n  storageClassName: slow\n  resources:\n    requests:\n      storage: 1Gi\n```\n\n创建PVC并使用。\n\n```shell\nkubectl get pvc\nNAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE\nmypvc1   Bound    mypv     1Gi        RWX                           19s\n\nkubectl get pv\nNAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM      STORAGECLASS   REASON   AGE\nmypv   3Gi        RWX            Retain           Bound    default/mypvc1                     17h\n```\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: nginx-pvc\nspec:\n  containers:\n  - name: nginx\n    image: nginx\n    imagePullPolicy: IfNotPresent\n    volumeMounts:\n    - name: pvc-test\n      mountPath: /usr/share/nginx/html\n  volumes:\n  - name: pvc-test\n    persistentVolumeClaim:\n      claimName: mypvc1\n```\n\n### 配置参数\n\n1. 资源请求resources\n\n   描述对存储资源的请求，目前只支持`request.storage`的设置，即存储空间大小。\n\n2. 访问模式accessModes\n\n   PVC也可以设置访问模式，用于描述用户应用对存储资源的访问权限。其三种访问模式的设置与PV设置相同。\n\n3. PV选择条件selector\n\n   通过对Label Selector的设置，可使PVC对于系统中已存在的各种PV进行筛选。\n\n4. 存储类别Class\n\n   PVC在定义时可以设定需要的后端存储类别（通过`storageClassName`指定），只有设置了该Class的PV才能被系统选出并与该PVC绑定。\n\n**注意：**\n\n​\t\tPVC受限于Namespace。Pod在引用PVC的时候同样受Namespace限制。\n\n​\t\t当Selector与Class都设置时，系统将选择两台条件同时满足的PV与之匹配。\n\n## PV与PVC生命周期\n\n### 资源供应\n\nKubernetes支持两种资源的供应模式：静态模式和动态模式：\n\n- 静态模式（Static）：集群管理员手工创建PV，在定义PV时需要将后端存储的特性进行设置。\n- 动态模式（Dynamic）：集群管理员无须手工创建PV，而是通过StorageClass的设置对后端存储进行描述，标记为某种类型。此时要求PVC对存储的类型进行声明，系统将自动完成PV的创建及PVC的绑定。PVC可以声明Class为“”，说明该PVC禁止使用动态模式。\n\n### 资源绑定\n\n在用户定义好PVC后，系统将根据PVC对资源的请求在已存在的PV中选择一个满足PVC要求的PV，一旦找到，就将该PV与用户定义的PVC进行绑定，用户就可以使用这个PVC了。如果在系统中没有满足的PV，PVC则会无限期处于Pending状态，直到系统管理员创建了一个满足要求的PV。\n\nPV一旦绑定到PVC上就会被这个PVC独占。不能再与其他PVC进行绑定。在这种情况下，当PVC申请的存储空间比PV少时，整个PV的空间就都能够被PV占用，可能会造成资源的浪费。如果资源供应使用的是动态模式，则不会有浪费的情况产生。\n\n### 资源使用\n\nPod使用Volume的定义，将PVC挂载到容器的某个路径进行使用。在容器应用挂载了一个PVC之后，就能被持续独自占用。不过，多个Pod可以挂载到同一个PVC，应用程序需要考虑多个实例共同访问同一块存储空间的问题。、\n\n### 资源释放\n\n当用户对存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将被标记为“已释放”，但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上，只有清除后该PV才能再次使用。\n\n### 资源回收\n\n对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用。\n\n回收策略可以看上面的PV设置。使用retain虽然删除pod后的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 PV。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。","categoryId":10,"viewCount":1715,"categoryName":"Kubernetes","author":"球接子","authorAvatar":null,"tagIds":[16],"tagNames":["Kubernetes"]}}