Kubernetes in Action笔记 - (9) 卷
文章目录
卷
卷是 pod 的一个组成部分,不是独立的 Kubernetes 对象, 不能单独创建或删除。 pod 中的所有容器都可以使用卷, 但必须先将它挂载在每个需要访问它的容器中。
卷类型
主要类型:
- emptyDir:用于存储临时数据的简单空目录。
- hostPath: 用于将目录从工作节点的文件系统挂载到pod中
- gitRepo: 通过检出Git仓库的内容来初始化的卷
- nfs: 挂载到pod中的NFS共享卷
- 用于挂载云服务商提供的特定存储类型。比如,gcePersistentDi sk (Google 高效能型存储磁盘卷)、 awsElasticBlockStore (AmazonWeb 服务弹性块存储卷)、 azureDisk (Microsoft Azure 磁盘卷)
- 用于挂载其他类型的网络存储。比如,cinder、cephfs、iscsi、flocker、glusterfs、quobyte、rbd、flexVolume、vsphere-Volume、photonPersistentDisk 、scaleIO
- configMap、secret、downwardAPI 一一用于将 k8s 部分资源和集群信息公开给 pod 的特殊类型的卷
- persistentVolumeClaim:一种使用预置或者动态配置的持久存储类型
emptyDir
卷从一个空目录开始,运行在 pod 内的应用程序可以写入它需要的任何文件。当删除 pod 时,卷的内容就会丢失。
一个 emptyDir 卷对于在同一个 pod 中运行的容器之间共享文件特别有用。但是它也可以被单个容器用于将数据临时写入磁盘。
下面是个例子
1apiVersion: vl
2kind: Pod
3metadata:
4 name : fortune
5spec:
6 containers:
7 - image: luksa/fortune
8 name: html-generator
9 volumeMounts:
10 - name: html
11 mountPath: /var/html/docs
12 - image: nginx:alpine
13 name: web-server
14 volumeMounts :
15 - name: html
16 mountPath: /usr/share/nginx/html
17 readOnly: true
18 ports:
19 - containerPort: 80
20 protocol: TCP
21 volumes:
22 - name: html
23 emptyDir: {}
medium属性可以指定存储介质。比如内存
1volumes:
2 name: html
3 emptyDir:
4 medium: Memory
使用 Git 仓库作为存储卷
gitRepo 卷基本上也是 一 个 emptyDir 卷,它通过克隆 Git 仓库并在 pod 启动时(但在创建容器之前) 检出特定版本来填充数据
1volumes:
2- name: html
3 gitRepo:
4 repository: https://github.com/luksa/kubia-website-example.git
5 revision: master
6 directory: .
但是它并未与git仓库保持同步,如果git仓库有任何更新,这些更新不会反映到挂载的卷中。可以通过删除并重建pod来获得最新的git代码,或者运行一个附加进程来使卷与 Git 仓库保持同步。
Git 同步进程不应该运行在主容器中,而应该是在另外一个容器: sidecar container。这种容器增加了对 pod 主容器的操作。在Docker Hub中搜索 "git syc", 可以看到很多可以实现git仓库同步的容器镜像
hostPath卷
大多数 pod 应该忽略它们的主机节点, 因此它们不应该访问节点文件系统上的任何文件。但是某些系统级别的 pod(切记, 这些通常由 DaemonSet 管理)确实需要读取节点的文件或使用节点文件系统来访问节点设备。
它是持久性存储,Pod删除时候,hostPath 卷的内容则不会被删除。
如果你正在考虑使用 hostPath 卷作为存储数据库数据的目录, 请重新考虑。因为卷的内容存储在特定节点的文件系统中, 所以当数据库 pod 被重新安排在另一个节点时, 会找不到数据。这解释了为什么对常规 pod 使用 hostPath 卷不是一个好主意, 因为这会使 pod 对预定规划的节点很敏感。
使用持久化卷
当运行在一个 pod 中的应用程序需要将数据保存到磁盘上, 并且即使该 pod 重新调度到另一个节点时也要求具有相同的数据可用,这就必须将其存储在某种类型的网络存储 (NAS) 中。比如 Google Kubernetes Engine的GCE持久磁盘、AWS的awsElasticBlockStore、NFS等等
持久卷和持久卷声明
为了使应用能够正常请求存储资源, 同时避免处理基础设施细节, 引入了两个新的资源, 分别是待久卷和持久卷声明。这样,开发人员不需要知道底层使用的是哪种存储技术, 同理他们也不需要了解应该使用哪些类型的物理服务器来运行pod, 与基础设施相关的交互是集群管理员独有的控制领域。当开发入员需要一定数量的持久化存储来进行应用时, 可以向 k8s 请求,就像在创建 pod 时可以请求 CPU、 内存和其他资源一样。
由集群管理员设置底层存储, 然后通过 Kubernetes API 服务器创建持久卷并注册。在创建持久卷时, 管理员可以指定其大小和所支持的访问模式。当集群用户需要在其 pod 中使用持久 化存储时, 他们首先创建持久卷声明(PersistentVolumeClaim, 简称 PVC) 清单, 指定所需要的最低容量要求和访问模式, 然后用户将待久卷声明清单提交给 Kubernetes API 服务器, Kubernetes 将找到可匹配的持久卷并将其绑定到持久卷声明。持久卷声明可以当作 pod 中的一个卷来使用, 其他用户不能使用相同的持久卷,除非先通过删除持久卷声明绑定来释放。
通过 persistentVolumeReclaimPolicy 属性设置存储卷回收策略:
- Retain: 在持久卷从持久卷声明中释放后仍然能保留它的卷和数据内容。
- Recycle: 删除卷的内容并使卷可用于再次声明,通过这种方式,持久卷可以被不同的持久卷声明和 pod 反复使用
- Delete: 策略删除底层存储
另外,集群管理员也可以创建一个持久卷配置,并定义一个或多个 StorageClass 对象,从而让用户选择他们想要的持久卷类型而不仅仅只是创建持久卷。用户可以在其持久卷声明中引用 StorageClass,而配置程序在配置持久存储时将采用这一点。可以指定默认的StorageClass,未指定StorageClass时就用默认的。
StorageClasses 的好处在于,声明是通过名称引用它们的。因此,只要 StorageClass名称在所有这些名称中相同, PVC 定义便可跨不同集群移植
图书资料: