Kubernetes 存储入门-EW帮帮网

一:Volume 的概念

对于大多数的项目而言，数据文件的存储是非常常见的需求，比如存储用户上传的头像、文件以及数据库的数据。在 Kubernetes 中，由于应用的部署具有高度的可扩展性和编排能力(不像传统架构部署在固定的位置)，因此把数据存放在容器中是非常不可取的，这样也无法保障数据的安全。

我们应该把有状态的应用变成无状态的应用，意思是指把数据从应用中剥离出来，把产生的数据文件或者缓存的信息都放在云端，比如常用的 NFS(生产环境中不建议使用，因为存在单点故障，推荐使用分布式的存储或者公有云的 NAS 服务)、ceph、GlusterFs、Minio等。

在传统的架构中，如果要使用这些存储，需要提前在宿主机挂载，然后程序才能访问，在实际使用时。经常碰到新加节点忘记挂载存储导致的一系列问题。而 Kubernetes 在设计之初就考虑了这些问题，并抽象出 Volume 的概念用于解决数据存储的问题。

在容器中的磁盘文件是短暂的，当容器崩溃时，Kubect1 会重新启动容器，但是容器运行时产生的数据文件都会丢失，之后容器会以干净的状态启动。另外，当一个 Pod 运行多个容器时，各个容器可能需要共享一些文件，诸如此类的需求都可以使用 Volume 解决。

Docker 也有卷的概念，但是在 Docker 中,卷只是磁盘上或另一个容器中的目录，其生命周期不受管理。虽然 Docker 已经提供了卷驱动程序，但是功能非常有限，例如从 Docker1.7版本开始，每个容器只允许一个卷驱动程序，并且无法将一些特殊的参数传递给后端存储。

另一方面，Kubernetes 卷具有明确的生命周期，与使用他的 Pod 相同，因此在 Kubernetes 中的卷可以比 Pod 中运行的任何容器的生命周期都长,并且可以在容器重启或者销毁之后保留数据。Kubernetes支持多种类型的卷，并且 Pod 可以同时使用任意数量的卷。

从本质上讲，和虚拟机或者物理机一样，卷被挂载后，在容器中也只是一个目录，可能包含一些数据,Pod 中的容器也可以对其进行增删改查操作，使用方式和裸机挂载几乎没有区别。要使用卷也非常简单,和其他参数类似，Pod 只需要通过.spec.volumes 字段指定为 Pod 提供的卷，然后在容器中配置块，使用.spec.containers.volumeMounts字段指定卷的挂载目录即可。

二:Volume 的类型

在传统架构中，企业内可能有自己的存储平台，比如NFS、Ceph、GlusterFs、Minio 等。如果所在的环境在公有云，也可以使用公有云提供的 NAS、对象存储等。在 Kubernetes 中，Volume 也支持配置这些存储，用于挂载到 Pod 中实现数据的持久化。Kubernetes Volume 支持的卷的类型有很多。

以下为常见的卷:

CephFs
GlusterFS
ISCSI
Cinder
NFS
RBD
HostPath

当然也支持一些 Kubernetes 独有的类型:

ConfigMap:用于存储配置文件
Secret:用于存储敏感数据
EmptyDir:用于一个 Pod 内多个容器的数据共享
PersistentVolumeClaim:对PersistentVolume的申请

三:通过 emptyDir 共享数据

emptyDir 是一个特殊的 Volume 类型，与上述 Volume 不同的是，如果删除 Pod，EmptyDir 卷中的数据也将被删除，所以一般 emptyDir 用于 Pod 中不同容器共享数据，比如一个 Pod 存在两个容器A和容器 B，容器A需要使用容器B产生的数据，此时可以采用 emptyDir 共享数据，类似的使用如 Filebeat收集容器内程序产生的日志。

使用 emptyDir 卷时，直接指定 emptyDir 为{}即可

1:编写 emptyDir 的 Deployment 文件

2:部署该 Deployment

3:查看部署结果

4:登录 Pod 中的第一个容器

5:登录第 Pod 中的第二个容器查看/mnt 下的文件

6:删除此 Pod

四:使用 HostPath 挂载宿主机文件

HostPath 卷可以将节点上的文件或目录挂载到 Pod 上，用于实现 Pod 和宿主机之间的数据共享，常用的示例有挂载宿主机的时区至 Pod，或者将Pod 的日志文件挂载到宿主机等。

1:编写 Deployment 文件，实现 HostPath 挂载

以下为使用 HostPath 卷的示例，实现将主机的/etc/localtime 文件挂载到 Pod 的/etc/localtime

2:创建此 Pod

3:查看创建结果

4:测试挂载情况

在配置 HostPath 时，有一个 type 参数，用于表达不同的挂载类型，HostPath 卷常用的类型有:

type 为空字符串:默认选项，在挂载 HostPath 卷之前不会有任何检查
Directoryorcreate:如果给定的path 不存在任何东西，那么将根据需要创建一个权限为0755 的空目录，和kubelet 具有相同的组和权限
Directory:目录必须存在于给定的路径下
FileorCreate:如果给定的路径不存在任何内容，则会根据需要创建一个空文件，权限设置为 0644，和 kubelet 具有相同的组和所有权
File:文件，必须存在于给定的路径中
Socket:UNIX套接字，必须存在于给定的路径中
CharDevice:字符设备，必须存在于给定的路径中
BlockDevice:块设备，必须存在于给定的路径中

5:删除

五:挂载 NFS 至容器

1:安装 NFS

在所有的 Kubernetes 节点都要安装

2:设置共享目录(在 NFS 服务器上)

3 开启 nfs(在 NFS 服务器上)

4:编写 Deployment 文件，挂载 NFS

5:部署此 Pod

6:查看部署结果

7:登录容器查看挂载结果

六:PersistentVolume(PV，持久卷)

虽然 volume 已经可以接入大部分存储后端，但是实际使用时还有诸多的问题。比如:

当某个数据卷不再被挂载使用时，里面的数据如何处理?
如果想要实现只读挂载，要如何处理?
如果想要只能有一个 Pod 挂载，要如何处理?

如上所述，对于很多复杂的需求，volume 可能难以实现，并且无法对存储的生命周期进行管理。另一个很大的问题是，在企业内使用 kubernetes 的不仅仅是 kubernetes 管理员，可能还有开发人员、测试人员以及初学 kubernetes 的技术人员，对于 kubernetes 的 volume 或者相关存储平台的配置参数并不了解，所以无法自行完成存储的配置。

为此，kubernetes 引入了两个新的 API 资源:PersistentVolume(持久卷，简称 PV)和PersistentVolumeclaim(持久卷声明，简称PVC)。

PV 是 kubernetes 管理员设置的存储，PVC 是对 PV 的请求，标识需要什么类型的 PV。他们同样是集群中的一类资源，但其生命周期比较独立，管理员可以单独对 PV 进行增删改査，不受 Pod 的影响，生命周期可能比挂载它的其他资源还要长。如果一个kubernetes 集群的使用者并非只有 kubernetes 管理员,那么可以通过提前创建 PV,用以解决对存储概念不是很了解的技术人员对存储的需求。和单独配置 volume类似，PV 也可以使用 NFS、GFS、CEPH 等常见的存储后端，并且可以提供更为高级的配置，比如访问模式、空间大小以及回收策略等。目前 PV的提供方式有两种:静态或动态。静态 PV 由管理员提前创建，动态PV 无需提前创建。

1:Pv 回收策略

当用户使用完卷时，可以从 API 中删除 PVC对象，从而允许回收资源。回收策略会告诉 PV 如何处理改卷。目前回收策略可以设置为Retain、Recycle 和 Delete。静态 PV默认的为 Retain，动态 PV 默认为 Delete.

Retain:保留，该策略允许手动回收资源,当删除 PVC时,PV仍然存在,PV 中的数据也存在。volume被视为已释放，管理员可以手动回收卷。
Recycle:回收，如果 volume 插件支持，Recycle 策略会对卷执行rm -rf 清理该 PV，卷中的数据已经没了,但卷还在,使其可用于下一个新的 PVC,但是本策略将会被弃用,目前只有 NFS 和 HostPath支持该策略。
Delete:删除，如果 volume 插件支持，删除 PVC 时会同时删除 PV，PV 中的数据自然也就没了。动态卷默认为 Delete，目前支持 Delete 的存储后端包括 AWS EBS、GCE PD、Azure Disk、openstackCinder 等。

2:Pv访问策略

在实际使用 PV 时，可能针对不同的应用会有不同的访问策略，比如某类 Pod 可以读写，某类 Pod 只能读，或者需要配置是否可以被多个不同的 Pod 同时读写等,此时可以使用 PV的访问策略进行简单控制,目前支持的访问策略如下:

Readwrite0nce:单路可读可写，可以被单节点以读写模式挂载，命令行中可以被缩写橙
RWO。ReadonlyMany:多路只读，可以被多节点以只读模式挂载，命令行中可以被缩写为 ROX。
ReadwriteMany:多路可读可写，可以被多个节点以读写模式挂载，命令行中可以被缩写为 RWX。
Readwrite0ncePod:单节点只读(1.22+)，只能被一个 Pod 以读写的模式挂载，命令行中可以被缩写为 RWOP。

虽然 PV 在创建时可以指定不同的访问策略，但是也要后端的存储支持才行。比如一般情况下，大部分块存储是不支持 ReadwriteMany 的。

在企业内，可能存储很多不同类型的存储，比如 NFS、Ceph、GlusterFs 等，针对不同类型的后端存储具有不同的配置方式,这也是对集群管理员的一种挑战,因为集群管理员需要对每种存储都要有所了解。

3:Pv 的配置方式

(1)静态配置

静态配置是手动创建 PV 并定义其属性,例如容量、访问模式、存储后端等。在这种情况下,Kubernetes管理员负责管理和配置 PV，然后应用程序可以使用这些PV。静态配置通常用于一些固定的存储后端，如NFS.

(2)动态配置

动态配置允许 Kubernetes 集群根据 PVC的需求自动创建 PV，在这种情况下，管理员只需为存储后端配置 storageclass，然后应用程序就可以通过 PVC请求存储。Kubernetes 将自动创建与 PVC 匹配的PV，并将其绑定到 PVC上。这种方法使得存储管理更加灵活和可扩展，允许管理员在集群中动态添加、删除、和管理存储资源

4:基于HostPath的PV

可以创建一个基于 HostPath 的 PV，和配置 NFS 的 PV 类似，只需要配置 hostPath 字段即可，其它配置基本一致。

(1)在所有 node 节点创建主机目录

(2)编辑hostpath 的 yaml 文件

4:基于 NFS 的 PV

(1)提前安装好 nfs 服务

(2)创建一个基于 NFS 的PV

PV 目前没有 NameSpace 隔离，不需要指定命名空间，在任意命名空间下创建的PV 均可以在其他Namespace 使用

创建 PV:

査看 PV 创建结果:

七:PersistentVolumeclaim(PVc，持久卷声明)

当 kubernetes 管理员提前创建好了PV，我们又应该如何使用它呢?这里介绍 kubernetes 的另一个概念 PersistentVolumeclaim(简称PVC)。PVC 是其他技术人员在 kubernetes 上对存储的申请，他可以标明一个程序需要用到什么样的后端存储、多大的空间以及什么访问模式进行挂载。这一点和 Pod 的 0os 配置类似，Pod 消耗节点资源，PVC消耗 PV 资源，Pod 可以请求特定级别的资源(CPU 和内存)，PVC可以请求特定的大小和访问模式的PV。例如申请一个大小为 5G且只能被一个 Pod 只读访问的存储。

在实际使用时，虽然用户通过 PVC获取存储支持，但是用户可能需要具有不同性质的PV 来解决不同的问题，比如使用 SSD 硬盘来提高性能。所以集群管理员需要根据不同的存储后端来提供各种PV，而不仅仅是大小和访问模式的区别，并且无须让用户了解这些卷的具体实现方式和存储类型，打扫了存储的解耦，降低了存储使用的复杂度。

接下来我们来看看如何让 PVC 和前面创建的 PV 绑定。PVC和 PV 进行绑定的前提条件是一些参数必须匹配，比如 accessModes、storageclassName、volumeMode 都需要相同,并且 PVC 的 storage 需要小于等于 PV 的 storage 配置。

1:PVC 的创建

(1)为 hostpath 类型的 PV 创建PVC

(2)为 NFS 类型的 PV 创建 PVC

2:PVC 的使用

上述创建了 PV，并使用PVC与其绑定，现在还差一步就能让程序使用这块存储，那就是将 PVC 挂载到 Pod。和之前的挂载方式类似，PVC的挂载也是通过 volumes 字段进行配置的，只不过之前需要根据不同的存储后端填写很多复杂的参数’而使用 PVC进行挂载时,只填写 PVC的名字即可，不需要再关心任何的存储细节，这样即使不是 Kubemetes 管理员，不懂存储的其他技术人员想要使用存储，也可以非常简单地进行配置和使用。比如我们将之前创建的 hostPath 类型的 PVC 挂载到 Pod 中，可以看到只需要配置-个 PersistentVolumeclaim 类型的 volumes，claimName 配置为 PVC 的名称即可:

Kubernetes 存储入门