---

使用阿里云主机ECS，
四台主机信息如下：
server1 — 私网IP:10.0.0.2 ----公网IP: 47.108.54.185 ---- 搭建docker仓库harbor—nfs服务器
server2 — 私网IP:10.0.0.3 ----公网IP: 47.108.144.231 ---- k8s集群主节点
server3 — 私网IP:10.0.0.4 ----公网IP: 47.108.115.206 ---- k8s集群节点
server4 — 私网IP:10.0.0.5 ----公网IP: 47.108.28.42 ---- k8s集群节点

---

volume配置管理

configmap存储集群的配置信息，secret存储集群的隐私信息，volume用于存储应用数据，kubernetes支持的volume有许多中类型。

• 容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet将重新启动容器，- -
• 容器中的文件将会丢失，因为容器会以干净的状态重建。其次，当在一个Pod中运行多个容器时，常常需要在这些容器之间共享文件。-
• Kubernetes抽象出Volume对象来解决这两个问题
• Kubernetes卷具有明确的生命周期，与包裹它的Pod相同。因此，卷比Pod中运行的任何容器的存活周期都长，在容器重新启动时数据也会得到保留。当然，当一个Pod不再存在时，卷也将不再存在。也许更重要的是，Kubernetes可以支持许多类型的卷，Pod也能同时使用任意数量的卷
• 卷不能挂载到其他卷，也不能与其他卷有硬链接。Pod中的每个容器必须独立地指定每个卷的挂载位置。

临时卷

emptyDir

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

默认情况下，emptyDir卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或ssd或网络存储，这取决于环境。也可以使用内存，速度虽然快，但是节点重启时就会被清除，并且写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。

hostPath

hostpath类型的volume直接将主机节点的目录或文件挂载到pod内。如果权限没有控制好，那么在pod内就可以写主机文件，可能会造成安全隐患。另一方面，微服务中的pod不稳定，pod可能被调度迁移到其他节点上。但是原来的节点和新调度到的节点上的数据可能不一样，这就有可能会导致业务出问题。

hostPath一些用法：

• 运行一个需要访问Dokcer引擎内部机制的容器，挂载/var/lib/docker路径（挂载的是主机路径）
• 在容器中运行cAdvisor（google的一个监控应用）时，以hostPath方式挂载/sys
• 允许Pod指定给定的hostPath在运行Pod之前是否应该存在，是否应该建立以及应该以什么方式存在

需要注意：

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

nfs

nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。

永久卷PV

简介

• Persistent Volume（持久卷，简称PV）是集群内，由管理员提供的网络储存的一部分。就像集群中的节点亿元，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和它的Pod互相独立的。PV作为API，捕获了诸如NFS，ISCSI或其他云存储系统的实现细节
• Persistent VolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。和Pod类似，Pod消耗Node资源，PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问模式（可以被映射为一次读写或者多次只读）【用户通过使用pvc来申请使用pv，pvc定义了需要使用的pv的大小、访问的方式等等】

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

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

使用：
Pod 将 PVC 申领当做存储卷来使用。集群会检视 PVC 申领，找到所绑定的卷，并 为 Pod 挂载该卷。对于支持多种访问模式的卷，用户要在 Pod 中以卷的形式使用申领 时指定期望的访问模式。
一旦用户有了申领对象并且该申领已经被绑定，则所绑定的 PV 卷在用户仍然需要它期间 一直属于该用户。用户通过在 Pod 的 volumes 块中包含 persistentVolumeClaim 节区来调度 Pod，访问所申领的 PV 卷。 相关细节可参阅使用申领作为卷。

释放
当用户使用完PV之后，他们可以通过API来删除pvc对象。当pvc被删除后，对应的pv就被认为是“released”了，但是还不能再给另一个pvc使用。前一个pvc的属于还存在于该pv中，必须根据策略来处理掉。

回收
当用户不再使用其存储卷时，他们可以从 API 中将 PVC 对象删除，从而允许 该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群，当其被 从申领中释放时如何处理该数据卷。 目前，数据卷可以被 Retained（保留）、Recycled（回收）或 Deleted（删除）。

静态PV

创建pv

创建pvc

创建pod

动态PV

nfs-client-provisioner源码地址：
https://github.com/kubernetes-retired/external-storage/tree/master/nfs-client

下面的文件编写都是参照GitHub上的

配置授权

配置nfs-client-provisioner

定义nfs存储类

创建pvc

创建测试pod

静态pv指定存储类实现动态pv

指定存储类为默认存储类