关于k8s中，存储卷的使用

1.  卷的作用

在容器化的环境中，容器的主体操作分为创建和删除。

在容器化的环境中，区别于传统模式，对于服务的修改、配置、修复等操作

在容器化的环境中，尤其针对于k8s的设计理念

主要将其简化为创建和删除

当一个容器对于其服务的运行，没有达到管理员的需求

管理员不把重心放在对于其内部配置文件及参数的修正，把

当前的容器修复好。

而管理员的重心放在直接去旧迎新，

删除原有的容器，运用新的正确的方式，启动新的容器

来实现服务。

有管理员描述，其认为，容器化的服务运行方式，

有点像渣男

行就行，不行就下一个，

这可能是一个比较通俗的理解角度。

探究容器服务管理的理念原理，

客观来讲，

容器的运行，是基于镜像文件

而镜像文件是多个只读层

即，容器为在镜像文件只读层的基础之上运行出的一个读写层

当读写层的配置修改多次之后

再还原

像版本回退

版本回滚

是需要一些对于版本记忆

和记录的工作量

同样可以完成管理员对于容器的服务的管理的正确解决。

从工作量的角度来看，

用正确的配置，在原有的只读层的镜像文件基础上

重新建立一个符合管理员预期的容器

比在原有的经过多次更改的容器中，再更改为正确的配置

工作量要少一些。

那么从管理目标的角度，

能够达到预期的服务在线水平，

即目标

所用的步骤越少

管理效率越高

同时，能够提高容错率

因为，显而易见，操作的步骤越少

修改过的步骤越少

即使服务仍有不完善之处

也更容易定位，到底是哪一步导致的不完善。

像传统的，非容器化的服务部署方式，

修改某一些程序、环境变量，

由于在同一个操作系统环境，

把当前的服务打成预期，

但可能会影响其他的服务，

所需的，环境。

此处，显示出了服务方面对于隔离性的需求

也衬托出虚拟机的存在的优势

虚拟机的主要优势之一

就是提供了隔离性

A虚拟机的环境修改

基本不会影响B虚拟机的服务运行环境

-------------------------------------------------------------------------

那么容器化的优势之一

就是延续了虚拟机在隔离性方面的优势

同时，让服务的运行环境变得更加的轻量级

此处，更加的轻量级

指的是容器化相比虚拟机，更加的轻量级

其区别主要是在于，

同样是隔离性操作

容器不需要自己的操作系统

而虚拟机需要自己的操作系统

此处的操作系统

指的是虚拟操作系统

虽然虚拟机的虚拟操作系统，可以用技术化手段，来实现其部分功能直接调用

真机操作系统，来和硬件交互

剩余部分功能扔需要虚拟操作系统来实现

就是这么一个方式，

既实现了隔离性，又实现了虚拟机的性能接近真机。

我们从虚拟机里面运行的进程的视角来看，

部分进程调用，可以透明化虚拟机，直接访问真机

部分进程调用，要通过虚拟机，来访问真机

核心就在于，

需要通过虚拟机来访问真机的部分。

虚拟机需要这一部分，而这一部分就是虚拟机所谓的“虚拟”

名词。

而容器，就是不需要这个“虚拟”

容器里面运行的进程，是全部、直接，访问真机资源。

常说的话来说，就是容器共享宿主机的内核

它没有操作系统

它没有虚拟化层

它直接就是跑一个进程，这个进程可以直接调用

宿主机的内核，来和硬件交互。

相当于，它就是宿主机上的进程

没有虚拟机，也没有虚拟化层。

所以说，容器既实现了隔离性，又实现了轻量级。

简单来讲，同样硬件资源配置的物理机。

如果能跑5个虚拟机

那么往往就能跑50个容器，甚至更多。

从市场化的角度来讲，

同样的硬件资源支出，

A技术的产出是5

B技术的产出是50

那么B技术就在市场化的发展中

大受欢迎

从做生意的角度来讲

同样的投入，

产出更多的方式更受欢迎。

这个很朴素

也很务实。

这个，也就是docker受欢迎的原因

因为docker就是把容器化容阳春白雪，带到了实际生产环境。

那么docker的价值，简单来讲，就是把5变成了50

所以，

很猛。

那么k8s的价值是什么呢？

当5的时候，管理员们，用传统的对于机器的管理方式

可以去管理，熟练程度和工作的质量，暂不需要应对变化特别大的挑战，

同时会感觉，真好，几个虚拟机，隔离着用，很方便。

确实是一个进步。

但是科技的进步，又走到了容器这一步了，

用传统的管理5的方式，去管理50，甚至更多，

可能就会遇到更多的挑战

没有那么容易了

但是容器化这个技术确实很好。

那么怎么用呢？

怎么管理这个50呢？

k8s的价值，就在于解决这个问题。

它对于容器化的高度自动化管理，

将50,500,5000甚至更多的容器

变成了一个可以范式管理的服务集群，

也就是k8s官方对于其自身的定义，

是一个平台。

在这个平台上，管理50,5000,500000

能够接近于管理5的难易程度

这个也就是k8s技术的市场。

虚拟机将1变成了5，

docker将5变成了50，

k8s将50变成了500000

虚拟机的主要作用在于隔离性

docker的主要作用在于既提供隔离性，又提高同样硬件资源的算力产出

k8s的主要作用在于，docker产生了如此多的既有隔离性，又有算力的容器，对于其的自动化管理

所以，k8s在初步了解的时候，管理员接触到的信息是，容器编排管理工具。

到这，编排管理的重要性就体现出来了

为什么？

因为容器实在是太多了

企业使用容器来运行自己的业务

可以大幅提高投资回报率

return on investment

意思是，在投入的基础上，返还回来多少

比如

企业投入1000元

一年净收益500元（那1000元还是企业的固定资产）

那么投资回报率，就是50%

那么，使用容器化，简单直接的提高投资回报率

这个事情，股东老板们应该是喜欢的

在市场化的竞争中

使用更高效的技术

似乎是一个必需做的事情

早还是晚的问题

考虑问题者的考虑问题的角度问题

从宏观的角度来看，甚至在行业内看，已经是量化的事情

管理员或许能够想到，科学技术就是生产力

------------------------------------------------------------------------------------------------------

那么容器化对于传统方式的改变，

有一个问题，是需要清楚的

容器化的存储怎么办

管理容器，主要是创建和删除

那么数据怎么办？

传统方式，服务修修改改，存储就在那，没有什么好变的

感觉存储看得见摸得着，方式也比较成熟

感觉很踏实。

那么容器动不动就删了，弄个新的

感觉很潇洒

但是旧容器里面的那些数据呢？

新容器里怎么拿过来还是怎么样？

容器说删就删了，

容器里的数据肯定要重视啊。

docker采取的常见的方式之一就是卷绑定，

把宿主机上的目录和容器里面的目录

绑定起来，相互映射。

其实挺实用的

但是容器特别多的时候，怎么搞？

一个个绑定映射吗

这个特别多，指的是上几百，几千，甚至更多。

那么k8s的作用，又显示出来了。

卷绑定这个方式，它也保留

类似于hostPath方式

字面意思就是主机路径

主机路径干嘛？

主机路径和容器绑定

容器里面的数据就可以放到主机的路径上

当然，这里的主机路径有很多种选择方式，

比如目录，文件，socket套接字，块存储，字符设备

目录的方式应用的比较多

通过这种方式，管理员就心中有数，容器里面的数据和主机绑定

比如目录，容器里面某个目录里面存放的东西就在宿主机上的磁盘的一个对应目录

hostPath是持久卷，容器删除了，但是数据还在hostPath的主机路径上

还有一个特征是，不同节点上的hostPath的内容不同

第二种

nfs

nfs可以直接被挂载在容器里面。

容器休息，nfs服务器上的数据是在这个容器umount了，

nfs服务器上的数据，仍然是持久化保存的

第三种

PV/PVC

资料来源，k8s官网。

持久卷 | Kubernetes本文描述 Kubernetes 中的持久卷（Persistent Volumes）。 建议先熟悉卷（volume）、 存储类（StorageClass）和 卷属性类（VolumeAttributesClass）。介绍 存储的管理是一个与计算实例的管理完全不同的问题。 PersistentVolume 子系统为用户和管理员提供了一组 API， 将存储如何制备的细节从其如何被使用中抽象出来。 为了实现这点，我们引入了两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）。同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以挂载为 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod， 请参阅访问模式）。尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源， 常见的情况是针对不同的问题用户需要的是具有不同属性（如，性能）的 PersistentVolume 卷。 集群管理员需要能够提供不同性质的 PersistentVolume， 并且这些 PV 卷之间的差别不仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。 为了满足这类需求，就有了存储类（StorageClass） 资源。参见基于运行示例的详细演练。https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/#persistent-volumes