Skip to content

Commit 5a6d9be

Browse files
author
yangjingjing
committed
init blog
1 parent 2bc714f commit 5a6d9be

File tree

6 files changed

+1485
-7
lines changed

6 files changed

+1485
-7
lines changed

.idea/codeStyles/Project.xml

Lines changed: 13 additions & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

.idea/codeStyles/codeStyleConfig.xml

Lines changed: 5 additions & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

_posts/2015-09-30-C命令行参数.md

Lines changed: 0 additions & 7 deletions
This file was deleted.

_posts/2022-04-11-Kubernetes共享存储.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -209,8 +209,42 @@ Kubernetes支持两种资源的供应模式:静态模式(Static)和动态
209209
## 资源绑定
210210
在用户定义好PVC之后,系统将根据PVC对存储资源的请求(存储空间和访问模式)在已存在的PV中选择一个满足PVC要求的PV,一旦找到,就将该PV与用户定义的PVC进行绑定,用户的应用就可以使用这个PVC了。如果在系统中没有满足PVC要求的PV,PVC则会无限期处于Pending状态,直到等到系统管理员创建了一个符合其要求的PV。PV一旦绑定到某个PVC上,就会被这个PVC独占,不能再与其他PVC进行绑定了。在这种情况下,当PVC申请的存储空间比PV的少时,整个PV的空间就都能够为PVC所用,可能会造成资源的浪费。如果资源供应使用的是动态模式,则系统在为PVC找到合适的StorageClass后,将自动创建一个PV并完成与PVC的绑定。
211211

212+
## 资源使用
213+
Pod使用Volume的定义,将PVC挂载到容器内的某个路径进行使用。Volume的类型为persistentVolumeClaim,在后面的示例中再进行详细说明。在容器应用挂载了一个PVC后,就能被持续独占使用。不过,多个Pod可以挂载同一个PVC,应用程序需要考虑多个实例共同访问一块存储空间的问题。
212214

215+
## 资源释放
216+
当用户对存储资源使用完毕后,用户可以删除PVC,与该PVC绑定的PV将会被标记为“已释放”,但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上,只有在清除之后该PV才能再次使用。
213217

218+
## 资源回收
219+
对于PV,管理员可以设定回收策略,用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收,才能供新的PVC绑定和使用。回收策略详见下节的说明。
214220

221+
下面通过两张图分别对在静态资源供应模式和动态资源供应模式下,PV、PVC、StorageClass及Pod使用PVC的原理进行说明。
215222

223+
## StorageClass详解
224+
StorageClass作为对存储资源的抽象定义,对用户设置的PVC申请屏蔽后端存储的细节,一方面减少了用户对于存储资源细节的关注,另一方面减轻了管理员手工管理PV的工作,由系统自动完成PV的创建和绑定,实现了动态的资源供应。基于StorageClass的动态资源供应模式将逐步成为云平台的标准存储配置模式。
216225

226+
StorageClass的定义主要包括名称、后端存储的提供者(provisioner)和后端存储的相关参数配置。StorageClass一旦被创建出来,则将无法修改。如需更改,则只能删除原StorageClass的定义重建。下例定义了一个名为standard的StorageClass,提供者为aws-ebs,其参数设置了一个type,值为gp2:
227+
```yaml
228+
apiVersion: storage.k8s.io/v1
229+
kind: StorageClass
230+
metadata:
231+
name: standard
232+
provisioner: kubernetes.io/aws-ebs
233+
parameters:
234+
type: gp2
235+
reclaimPolicy: Retain
236+
allowVolumeExpansion: true
237+
mountOptions:
238+
- debug
239+
volumeBindingMode: Immediate
240+
```
241+
242+
## StorageClass的关键配置参数
243+
244+
### 提供者(Provisioner)
245+
描述存储资源的提供者,也可以看作后端存储驱动。目前Kubernetes支持的Provisioner都以“kubernetes.io/”为开头,用户也可以使用自定义的后端存储提供者。为了符合StorageClass的用法,自定义Provisioner需要符合存储卷的开发规范,详见https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-provisioning.md的说明。
246+
247+
### 参数(Parameters)
248+
后端存储资源提供者的参数设置,不同的Provisioner包括不同的参数设置。某些参数可以不显示设定,Provisioner将使用其默认值。
249+
250+
接下来通过几种常见的Provisioner对StorageClass的定义进行详细说明。

0 commit comments

Comments
 (0)