基于 Kubernetes 的云平台存储容器化实践

本文由 dbaplus 社群授权转载。

今天分享的主题是 OPPO 云存储的上云之路。

分布式存储介绍

存储相比于其他组件，更底层，所以有必要做一个简单的科普。

1、对象存储

主要是对整个文件进行操作，提供了对整个文件进行增删查改的能力。不支持对对象内容进行增量修改，如七牛的对象存储，AWS S3，阿里 OSS，呈现给我们调用方式是 http api。

2、分布式文件系统

文件存储实现了文件的 POSIX 接口，由于整个文件系统不依赖操作系统，常用于实现共享文件系统，常见的比如说 ceph fs，gluster fs 呈现给我们的使用方式是文件系统。

3、分布式块存储

提供裸块的能力交由物理机使用，协议是 SCSI，iSCSI，文件系统层由操作系统提供。呈现给我们的使用方式是裸盘，不带任何文件系统，需要格式化后使用，或者使用块 API。

云平台存储基本架构

目前块存储主要是三个组件，gateway、storage、 cluster manager。

• gateway 主要是解析 iscsi 协议，把块请求解析发送到 storage 进行处理；

• storage 则是对块的读写操作进行处理，管理磁盘数据

• cluster manager 为元数据中心，保存节点的状态，对整个集群的健康状态做仲裁

云原生存储

现在 Kubernetes 的趋势愈演愈烈，Kubernetes 逐渐成为云原生时代的基础设施，为了给上云的程序提供服务，云原生也随之出现，目前世面上已经有 OpenEBS Portworx 和 Rook 等产品。

云原生存储不仅要为上云的服务提供服务，自身也利用云的特性增强自身的功能，依赖 Kubernetes 的特性，我们可以轻运维，轻部署，利用容器隔离的能力，减少异常进程之前的相互影响，提高整体资源的利用率。

Kubernetes 与 CSI

Kubernetes 作为未来云上的操作系统，把存储整个生命周期和管理抽象成三种资源。

1、StorageClass

抽象了管理存储相关的配置，主要是 provisioner、parameters、reclaimPolicy 这三个配置。

• provisioner: 表示某一种存储资源

• parameters: 相当于自定义配置，自定义一些存储属性

• reclaimPolicy：设置 volume 释放后，pv 的动作，Delete or Retain

通过声明不同 stroageclass 可以管理多种类型的存储比如说 ceph，glusterfs 等等。

2、PersistentVolume

表示一段已分配的存储，可以是文件系统，也可以是裸块，云存储的云盘或者文件系统映射到 Kubernetes 就是一个 PersistentVolume。

3、PersistentVolumeClaim

用户存储的请求，可以请求特定的容量大小和访问模式（例如，可以以读/写一次或指向多次模式挂载）。

抽象出 PersistentVolumeClaim 把存储和管理分离，通过 PersistentVolumeClaim 我们可以控制访问存储的权限，存储的容量和类型。

下图是 Kubernetes 使用存储的一个方式：

这里衍生下 Kubernetes 的一些设计理念，Kubernetes 使用声明式的 API，通过 YAML 声明请求，并保存到 etcd，这样做的好处是把整个请求记录下来，对于问题的回溯也比较方便，不用自己去记录日志提炼请求。

另外 Kubernetes 还提供了对于各种资源的 watch Api，各种资源的 crud 都可以通过 watch api 实时的拿到对应的 YAML，这样的设计的好处是让 Kubernetes 拥有非常好的扩展性，通过实现 controller 去 watch 各种资源的变化情况，定义该资源的 crud 行为。

4、Container Storage Interface

提供一个将任意块或者文件存储系统对接到给容器编排系统（COs）上的接口标准，如 Kubernetes。

把存储从创建到销毁整个生命周期抽象成一组标准接口，Kubernetes 通过对接 CSI，实现对存储整个生命周期的管理。

下图就是 CSI 定义的存储卷的生命周期：

5、Kubernetes 中对接 CSI

上文说道 Kubernetes 对存储的抽象是 StorageClass，PersistentVolume ，PersistentVolumeClaim 等资源 CSI 则是提供一组标准接口。所以需要引入一层把 Kubernetes 中的资源行为转为 CSI 接口的程序，Kubernetes 提供了多个 sidecar 屏蔽这个过程。

这里简单科普下 sidecar，一般来说，引入 sdk 实现某些功能，在编译的时候把 sdk 代码编译进去，更新 sdk 要重新发布，和工程耦合的比较紧密，sidecar 则是把 sdk 实现的功能通过在 pod 运行一个独立的容器实现，通过 sidecar 们提供 rpc 接口进行交互，可以作为被调用方，也可以是把服务包装起来增强服务功能，增加这样子的好处是解耦，让更新 sidecar 容器的版本更简单。

通过引入以下 sidecar，我们可以只专注于实现 CSI 定义的接口。

• external-attacher：辅助触发 ControllerPublishVolume

• external-provisioner：辅助触发 Controller 相关接口

• node-driver-registar：辅助注册 csi 插件到 kubelet

• external-resizer：辅助实现 volume 扩容

• external-snappshotter：辅助实现 volume 快照

• livenessprobe：转换 csi prob 到 k8s 的 liveness

6、Kubernetes 和 CSI 的架构

从官网给的图我们就可以直白的看到粉红色框的 sidecar 们相当于一层胶水，把 Kubernetes 和 csi 链接起来。

1）PV 与调度

至此我们已经讲完了 Kubernetes 和 CSI 与 K8S 怎么交互的，接下来讲下 PV 与调度的关系。

在调度阶段，PV 的 affinity 会影响 Pod 的调度，所以有调度需求的可以通过 PV 的 affinity 控制。

2）NodeStatgeVolume 与 NodePublishVolume

之前查阅资料的时候发现这两个接口的说明讲的比较少。

NodeStatgeVolume 的接口是把远端的云盘挂到物理机上面。NodePublishVolume 的接口是把 NodeStatgeVolume 之后的盘挂进容器里面。Kubernetes 在 NodeStatgeVolume 阶段会给每个 PV 生成一个全局挂载点，如下图：

通过判断这个挂载点是否挂载可以方式 PV 重复挂载导致出错。接下来 NodePublishVolume 把 NodeStatgeVolume 的的挂载点挂载的自己 Pod 文件夹下，最终这个 Pod 的挂载点会被挂载进容器里面。

存储容器化

存储作为基础组件，直接和本地盘打交道，所以我们一个要解决的事情就是如果 Kubernetes 管理本地盘。

kubernetes 管理本地盘

通过官方提供的 local-static-provisioner 自动生成 LocalPersistentVolume 管理磁盘。

LocalPersistentVolume 是 Kubernetes 提供的一种管理本地盘的资源。

1、使用 Statefulset 管理存储容器

通过 statefulset 管理有状态的存储服务， 为每个 pod 分配一个单独的磁盘可以使用 volumeClaimTemplates 给每个 pod 生成唯一的 pvc，具体规则$claimNmae-${podName}，事先准备好 PVC 和 PV，通过 Statefulset 我们就可以把我们的存储托管到云上了。另外借助 daemonset，可以把我们 gateway 模块部署到每一个 node 上面。处理云存储的请求。

2、存储容器化的收益

1）降低运维成本

基于 Kubernetes 和 statfulset 获得了滚动更新，灰度更新，健康检查，快速扩容等功能，只需要一组 yaml 文件就可以快速搭建一个集群，相比于传统写 ansible 脚本部署的方式复杂度大大降低。

2）降低开发运维成本

由于 Kubernetes 把存储抽象成 StorageClass PersistentVolume PersistentVolumeClaim。我们可以通过他们管理我们的存储资源，基于 Kubernetes lable 的过滤功能，可以实现简单的关系查询，通过 PVC 与 PV 管理存储资源，减少管理端的开发。定位问题也能通过 POD 信息快速定位到问题机器和问题云盘。而且接入 Kubernetes 生态上的 prometheus 后，监控告警也能快速开发。

3）隔离性增强

docker 限制 cpu memory 使用，减少进程之间资源互相干扰，进一步提升资源利用率。

作者介绍：

蔡逸煌，OPPO 云平台高级后端工程师

主要从事云平台开发工作，擅长 K8S、容器网络、存储等领域

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787753&idx=2&sn=3ca5aa589e5cfa33c1fe51742b58f572&chksm=f3f97a3cc48ef32ae01f249fcf087df78b4b9b691982ad36d4ea3554358efaf856b6926011ab&scene=27#wechat_redirect