2万字长文:Kubernetes云原生开源分布式存储( 三 )


这个方案如何实现呢?CAS提出如下方案:

  • 每个volume都由一个轻量级的Controller来管理 , 这个Controller可以是一个单独的Pod 。
  • 这个Controller与使用该volume的应用Pod在同一个Node(sidecar模式) 。
  • 不同的Volume的数据使用多个独立的Controller Pod进行管理 。

2万字长文:Kubernetes云原生开源分布式存储文章插图
CAS
由于Pod是通过Kubernetes编排与调度的 , 因此毫无疑问通过这种形式其实就实现了Kubernetes编排和调度存储: )
Kubernetes毕竟是目前主流趋势 , 通过Kubernetes编排和管理存储也必然是一种发展趋势 , 目前OpenEBS就是CAS的一种开源实现 , 商业存储如PortWorx、StorageOS也是基于CAS模式的 。
更多关于CAS的可以参考CNCF官宣文章 Container Attached Storage: A Primer [4]。
2 简单好用的Longhorn2.1 Longhorn简介Longhorn [5] 在我之前的文章 轻量级Kubernetes k3s初探 已经简单介绍过 , 最初由Rancher公司开发并贡献给社区 , 专门针对Kubernetes设计开发的云原生分布式块存储系统 , 因此和Kubernetes契合度很高 , 主要体现在两个方面 , 一是它本身就直接运行在Kubernetes平台上 , 通过容器和微服务的形式运行;其二是能很好的与PV/PVC结合 。
与其他分布式存储系统最大的不同点是 , Longhorn并没有设计一个非常复杂的控制器来管理海量的volume数据卷 , 而是将控制器拆分成一个个非常轻量级的微控制器 , 这些微控制器能够通过Kubernetes、Mesos等平台进行编排与调度 。
每个微控制器只管理一个volume , 换句话说 , 一个volume一个控制器 , 每个volume都有自己的控制器 , 这种基于微服务的设计使每个volume相对独立 , 控制器升级时可以先选择一部分卷进行操作 , 如果升级出现问题 , 可以快速选择回滚到旧版本 , 升级过程中只可能会影响正在升级的volume , 而不会导致其他volume IO中断 。
Longhorn的实现和CAS的设计理念基本是一致的 , 相比Ceph来说会简单很多 , 而又具备分布式块存储系统的一些基本功能:
  • 支持多副本 , 不存在单点故障;
  • 支持增量快照;
  • 支持备份到其他外部存储系统中 , 比如S3;
  • 精简配置(thin provisioning);
  • ...
我觉得Longhorn还有一个特别好的功能是内置了一个Web UI , 通过UI能够很方便的管理Node、Volume以及Backup , 不得不说 Longhorn真是麻雀虽小五脏俱全。
根据官方的说法 , Longhorn并不是为了取代其他分布式块存储系统 , 而是为了设计一个更简单的适合容器环境的块存储系统 , 其他分布式存储有的一些高级功能Longhorn并没有实现 , 比如去重(deduplication)、压缩、分块、多路径等 。
Longhorn存储管理机制比较简单 , 当在Longhorn中Node节点增加物理存储时 , 其本质就是把Node对应的路径通过HostPath挂载到Pod中 , 我们可以查看该路径的目录结构 , 在 replicas 目录中一个volume一个子目录 , 文件内容如下:
# find replicas/int32bit-volume-3-ab6717d6/replicas/int32bit-volume-3-ab6717d6/replicas/int32bit-volume-3-ab6717d6/volume.metareplicas/int32bit-volume-3-ab6717d6/volume-head-000.imgreplicas/int32bit-volume-3-ab6717d6/revision.counterreplicas/int32bit-volume-3-ab6717d6/volume-head-000.img.meta其中 int32bibt-volume-3 是volume名称 ,ab6717d6 对应副本名称 , 子目录中包含一些volume的metadata以及img文件 , 而img文件其实就是一个raw格式文件:
# qemu-img info volume-head-000.imgimage: volume-head-000.imgfile format: rawvirtual size: 20G (21474836480 bytes)disk size: 383Mraw格式其实就是Linux Sparse稀疏文件 , 由于单个文件大小受文件系统和分区限制 , 因此Longhorn volume会受单个磁盘的大小和性能的限制 , 不过我觉得Kubernetes Pod其实也很少需要用到特别大的volume 。
更多关于Longhorn的技术实现原理可以参考官宣文章 Announcing Longhorn: an open source project for microservices-based distributed block storage [6]。
2.2 Longhorn部署Longhorn部署也非常简单 , 只需要一个 kubectl apply 命令:
kubectl apply -f 创建完后就可以通过Service或者Ingress访问它的UI了:
2万字长文:Kubernetes云原生开源分布式存储文章插图
longhorn webui
在Node页面可以管理节点以及物理存储 , Volume页面可以管理所有的volumes , Backup可以查看备份等 。
volume详情页面可以查看volume的挂载情况、副本位置、对应的PV/PVC以及快照链等:
2万字长文:Kubernetes云原生开源分布式存储文章插图
longhorn volume