Kubernetes系列学习文章 - 存储实现（九）

宝哥@上云专家 • 2023-01-02 • 云技术社区 • 283 阅读

| 导语数据，是无价的。了解清楚底层的存储实现方式对于数据的使用、保护以及IO性能的优化有很大的帮助。本篇文章从三个大点来讲讲K8S的存储实现机制。

一、存储虚拟化介绍

在虚拟化领域有这么一个故事：一个好的虚拟化解决方案就好像游历一个虚拟现实的主题公园。当游客想象他正在城市上空滑翔时，传感器就会把相应的真实感觉传递给游客，并同时隐藏真实的力学环境。这好比黑客帝国里，虚拟世界里的人完全感受不到我是在虚拟的环境中。

基于上面的故事，存储的虚拟化要解决的是上层的用户对底层硬盘、磁带完全不可知。屏蔽掉底层复杂的物理设备后，把零散的硬件存储资源抽象成一个“存储池”，这个“存储池”能灵活的分配给用户。

那么K8S到底是通过什么机制方式把底层块存储或分布式文件系统做成一份份的volume给到Pod使用呢？接下来我们通过PV、PVC、StorageClass等概念给大家说明。

1. PV

PV是 PersistentVolume 的缩写，Persistent是持续的意思，因此PV可以解释为“持久化的数据卷”。PV是对底层共享存储资源的抽象，它能对接多种类型的存储实现类型，主要有：Ceph、Glusterfs、NFS、vSphereVolume（VMWare存储系统）、Local（本地存储设备）、HostPath（宿主机目录）、iSCSI、FC（光纤存储设备）、AWSElasticBlockStore（AWS弹性块设备）、AzureDisk（微软云Disk）、AzureFile（微软云File）、GCEPersistentDisk（谷歌云永久磁盘）。

PV代表着K8S的存储能力、访问模式、存储类型、回收策略、后端存储类型等机制体现。定义一个PV，我们可以参考下面：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003    //定义PV的名字
spec:
  capacity:
    storage: 5Gi    //定义了PV为5GB
  volumeMode: Filesystem    //定义volume模式类型
  accessModes:
    - ReadWriteOnce    //定义读写权限, 并且只能被单个node挂载
  persistentVolumeReclaimPolicy: Recycle     //定义回收策略
  storageClassName: slow     //定义storageClass名字
  mountOptions:
    - hard   //定义NFS挂载模式，硬挂载
    - nfsvers=4.1   //定义NFS的版本号
  nfs:
    path: /tmp       //定义NFS挂载目录
    server: 172.17.0.2     //定义NFS服务地址

同样的，当我们第一次写PV的YAML可能不清楚到底有哪些关键参数，因此下面整理了PV的关键配置参数，读者可以参考：

类型	参数名	说明
存储能力	Capacity	描述存储设备具备的能力，目前仅支持对存储空间的设置（storage=xx），未来可能加入IOPS、吞吐率等指标的设置。
存储卷模式	Volume Mode	Kubernetes从1.13版本开始引入存储卷类型的设置（volumeMode=xxx），可选项包括Filesystem（文件系统）和Block（块设备），默认值为Filesystem。
访问模式	Access Modes	对PV进行访问模式的设置，用于描述用户的应用对存储资源的访问权限。 ReadWriteOnce（RWO）：读写权限，并且只能被单个Node挂载。 ReadOnlyMany（ROX）：只读权限，允许被多个Node挂载。 ReadWriteMany（RWX）：读写权限，允许被多个Node挂载。这里要注意，不同的存储类型，访问模式是不同的，具体可以参考下面的表
存储类别	Class	PV可以设定其存储的类别，通过storageClassName参数指定一个 StorageClass资源对象的名称（StorageClass会预先创建好，指定一个名字）。具有特定类别的PV只能与请求了该类别的PVC进行绑定。未设定类别的PV则只能与不请求任何类别的PVC进行绑定。
回收策略	Reclaim Policy	通过PV定义中的persistentVolumeReclaimPolicy字段进行设置，可选项如下： Retain 保留：保留数据，需要手工处理。 Recycle 回收空间：简单清除文件的操作（例如执行rm -rf /thevolume/* 命令）。 Delete 删除：与PV相连的后端存储完成Volume的删除操作。目前，只有NFS和HostPath两种类型的存储支持Recycle策略；AWS EBS、GCE PD、Azure Disk和Cinder volumes支持Delete策略。
挂载参数	Mount Options	在将PV挂载到一个Node上时，根据后端存储的特点，可能需要设置额外的挂载参数，可以根据PV定义中的mountOptions字段进行设置。
节点亲和性	Node Affinity	可以设置节点亲和性来限制只能让某些Node访问Volume，可以在PV定义中的nodeAffinity字段进行设置。使用这些Volume的Pod将被调度到满足条件的Node上。

每种存储类型的访问模式是否支持是不同的，不支持的需要看“ depends on the driver” 意思是取决具体的驱动能力。

其次是它们总体的架构层次关系，我们可以看下面的图来理解：

最后是它们的生命周期，这个也需要了解：

K8S里只要掌握了StorageClass、PVC、PV的定义和设置，搞清楚它们之间的内在关系和生命周期，那么K8S存储这块基本就了解了。当然，关于这块的一些性能上的优化，具体还得看底层存储的能力。当前云环境下，底层存储各具特色，各大云厂商有自己的实现机制和性能特色；私有云下，在完善底层硬件性能的同时，通常IAAS层都会采用ceph来做分布式存储，进而再给PAAS层使用。

三、Kubernetes CSI

前面一章我们在学习K8S网络的时候有了解过CNI，那么在存储这一块，K8S也有一套接口管理规范机制，那就是CSI。CSI是“Container Storage Interface” 的缩写，中文意思就是“容器存储接口”。CNI是为了统一网络规范接口的，CSI自然是想统一标准化存储方面的接口，方便管理。

1. 为什么要发展CSI

CSI v1.0版本是在2017年12月发布的。在没有CSI之前，K8S已经提供了功能强大的卷插件机制（In-tree Volume Plugin 和 Out-of-tree Provisioner），但由于In-tree的这种模式代码主要是K8S维护，这意味着插件的代码是Kubernetes核心代码的一部分，并会随核心Kubernetes二进制文件一起发布。此外，第三方插件代码在核心Kubernetes二进制文件中可能会引起可靠性和安全性问题，由于代码的审核和测试又是K8S侧人员做的，对于第三方插件代码因为不熟等原因，有些错误是很难发现的。

没CSI之前的K8S集群

因此，CSI的出现非常有必要。CSI的设计目的是定义一个行业标准，该标准将使第三方存储提供商能够自己实现、维护和部署他们的存储插件。借助CSI，第三方存储提供商而无需接触K8S的核心代码。这为K8S用户提供了更多的存储选项，并使系统更加安全可靠。

2. CSI 架构

CSI目前包括三部分：Identity、Controller、Node

CSI Identity的主要功能是负责认证插件的状态信息。
CSI Controller的主要功能是对存储资源和存储卷进行管理和操作。
CSI Node的主要功能是对Node上的Volume进行管理和操作。

有CSI下的K8S集群

3. CSI新特性

CSI目前已经GA，目前CSI有如下几点功能的改进：

Kubernetes当前与CSI的规范v1.0和v0.3版本兼容（取代CSI v0.2）。
CSI v0.3.0跟v1.0.0之间有重大的变化，Kubernetes v1.13同时支持这两个版本；
随着CSI 1.0 API的发布，K8S不在支持低于和等于v0.3的CSI API的驱动程序，K8S v1.15后会彻底不支持；
CSI v0.2和v0.3之间没有重大变化，因此v0.2驱动程序可以跟K8S v1.10.0+ 集合使用；
CSI v0.1和v0.2之间有重大变化，因此，在使用K8S v1.10.0+ 之前的版本，必须将非常老的CSI 0.1的驱动程序更新为至少兼容0.2。
Kubernetes VolumeAttachment 对象（在storage v1alpha1 group v1.9中引入，并已添加到v1beta1 group v1.10）已添加到storage v1 group v1.13中。
Kubernetes CSIPersistentVolumeSource 卷类型已提升为GA。
kubelet发现新的CSI驱动程序方法：“Kubelet设备插件注册机制”，已在Kubernetes v1.13中GA。