kubernetes集群之Volumes配置管理

一、了解Volumes

为了持久化保存容器的数据，可以使用 Kubernetes Volume。

Volume 的生命周期独立于容器，Pod 中的容器可能被销毁和重建，但 Volume 会被保留。

本质上，Kubernetes Volume 是一个目录，这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod，Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型，包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等。

Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说，所有类型的 Volume 都只是一个目录。

二、 emptyDir卷

1. 什么是emptyDir卷

当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，并且只要 Pod 在该节点上运行，卷就一直存在。 就像它的名称表示的那样，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，但是这些容器都可以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除。

2. emptyDir的使用

emptyDir 的使用场景：
缓存空间，例如基于磁盘的归并排序。
为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。

3. emptyDir卷创建

此时访问是403的原因是我们没有在发布目录里面写发布文件

添加发布文件

再次访问：

可以看到文件超过sizeLimit,则一段时间后(1-2分钟)会被kubelet evict(驱逐)掉。之所以不是“立即”被evict,是因为kubelet是定期进行检查的,这里会有一个时间差。

emptydir缺点:

• 不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出,但是这个时间内,其实对node还是有风险的;
• 影响kubernetes调度,因为empty dir并不涉及node的resources,这样会造成Pod“偷偷”使用了node的内存,但是调度器并不知晓;
• 用户不能及时感知到内存不可用

三、 hostPath卷

1. 了解hostPath卷

hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。

当使用这种类型的卷时要小心,因为:

• 具有相同配置(例如从 podTemplate 创建)的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
• 当 Kubernetes 按照计划添加资源感知的调度时,这类调度机制将无法考虑由 hostPath使用的资源。
• 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程,或者修改主机上的文件权限以便容器能够写入 hostPath 卷。

2. 部署hostPath卷

集群中server4被调度工作后，生成/data目录

在server2中调度test卷写入内容：

在server4上查看，写入内容：

四、nfs卷

1. 了解nfs卷

nfs 卷将 NFS (网络文件系统) 挂载到 Pod 中，和emptyDir 卷不同的是nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。

2. nfs卷的部署

现在server1(仓库所在主机)开启nfs


在server2上测试：

在server1上的挂载路径里清除所有信息，重新写入文件：

在server2上部署：
删除之前的test-pod

vim nfs.yaml

在tets-pd里查看共享的文件是否存在：

3. nfs与pv

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。
就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。

PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

有两种PV提供的方式：静态和动态

静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。
动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态

a.安装配置NFS服务：

yum install -y nfs-utils
mkdir -m 777 /nfsdata
vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
systemctl enable --now rpcbind
systemctl enbale --now nfs

b. 创建NFS PV卷

c. pod挂载pvc：



删除时最好也按照执行顺序删除：

d. 创建两个pv卷

4. nfs动态存储

NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。
PV以 $namespace-${pvcName}-$pvName的命名格式提供（在NFS服务器上）PV回收的时候以archieved-${namespace}-$pvcName-${pvName} 的命名格式（在NFS服务器上）

在server1上开启nfs，并且上传镜像：

在server2上：

删除之前的卷及其挂载：

编写pvc文件：

更改挂载路径：

将true改为false：



手动更新：