编者按： 云原生背景下，本地存储相比分布式存储，在易用性、可维护性、IO 性能上都更胜一筹，但使用本地存储任然有诸多问题。那么 open-local 会带来什么不一样的体验呢？来看看作者怎么说。本文整理自[龙蜥大讲堂第 30 期]精彩分享视频回放已上传至龙蜥官网（首页-动态-视频），欢迎查看！
云原生背景下，有状态应用需要借助一套存储方案进行数据持久化保存。本地存储相比分布式存储，在易用性、可维护性、IO 性能上都更胜一筹，但使用本地存储作为目前低成本交付 Kubernetes 集群，依然存在许多问题：
- 本地存储管理能力有限： 使用本地存储需要一定的人力成本，如通过为节点打标来限制 Pod 调度、人工管理不同机型的磁盘、人工通过 Hostpath 方式挂载指定磁盘到容器等；同时还有一些现场交付问题，如绑定了错误的宿主机路径使得故障无法及时发现，这些都严重影响了 K8s 交付效率以及应用运行时稳定性。
- 本地存储空间隔离能力缺失： 应用挂载不适当的宿主机目录（如挂载到宿主机根路径）导致宿主机故障，如因应用数据写满磁盘导致容器运行时无响应、触发 Pod 驱逐等问题。
- K8s 原生本地存储能力有限。 通过 Hostpath 无法做到节点保持，使得 Pod 漂移后应用数据丢失；而使用半自动静态 Local PV 可保证节点保持，但是无法实现全自动，仍然需要为人为参与（如创建文件夹路径，为节点打标等）；无法使用一些高级存储能力（例如快照）。
针对以上问题， open-local 应用而生，接下来一起来看看 open-local 都有哪些性能？
open-local 介绍
开源地址：
https://github.com/alibaba/open-local
open-local 是阿里巴巴开源的一款本地存储管理系统。通过 open-local，在 Kubernetes 上使用本地存储就像使用集中式存储一样简单。
**目前 open-local 支持以下存储特性：**本地存储池管理、存储卷动态分配、存储调度算法扩展、存储卷扩容、存储卷快照、存储卷监控、存储卷 IO 限流、原生块设备及临时卷。
1、use case
- 应用本身已支持多副本高可用，希望使用本地盘以提高存储资源利用率，提高数据读写性能，如 HBase、MinIO 等。
- 应用期望数据卷具备容量隔离能力，避免出现诸如日志打满系统盘的情况。
- 应用需要大量本地存储并依赖节点保持，如 etcd、zookeeper、Elasticsearch 等。
- 集群本地磁盘数量众多，希望通过调度器实现有状态应用的自动化部署。
- 通过存储快照能力为数据库类应用备份瞬时数据等。
2、架构
┌─────────────────────────────────────────────────────────────────────────────┐
│ Master │
│ ┌───┬───┐ ┌────────────────┐ │
│ │Pod│PVC│ │ API-Server │ │
│ └───┴┬──┘ └────────────────┘ │
│ │ bound ▲ │
│ ▼ │ watch │
│ ┌────┐ ┌───────┴────────┐ │
│ │ PV │ │ Kube-Scheduler │ │
│ └────┘ ┌─┴────────────────┴─┐ │
│ ▲ │ open-local │ │
│ │ │ scheduler-extender │ │
│ │ ┌────►└────────────────────┘◄───┐ │
│ ┌──────────────────┐ │ │ ▲ │ │
│ │ NodeLocalStorage │ │create│ │ │ callback │
│ │ InitConfig │ ┌┴──────┴─────┐ ┌──────┴───────┐ ┌────┴────────┐ │
│ └──────────────────┘ │ External │ │ External │ │ External │ │
│ ▲ │ Provisioner │ │ Resizer │ │ Snapshotter │ │
│ │ watch ├─────────────┤ ├──────────────┤ ├─────────────┤ │
│ ┌─────┴──────┐ ├─────────────┴──┴──────────────┴──┴─────────────┤GRPC│
│ │ open-local │ │ open-local │ │
│ │ controller │ │ CSI ControllerServer │ │
│ └─────┬──────┘ └────────────────────────────────────────────────┘ │
│ │ create │
└──────────┼──────────────────────────────────────────────────────────────────┘
│
┌──────────┼──────────────────────────────────────────────────────────────────┐
│ Worker │ │
│ │ │
│ ▼ ┌───────────┐ │
│ ┌──────────────────┐ │ Kubelet │ │
│ │ NodeLocalStorage │ └─────┬─────┘ │
│ └──────────────────┘ │ GRPC Shared Disks │
│ ▲ ▼ ┌───┐ ┌───┐ │
│ │ ┌────────────────┐ │sdb│ │sdc│ │
│ │ │ open-local │ create volume └───┘ └───┘ │
│ │ │ CSI NodeServer ├───────────────► VolumeGroup │
│ │ └────────────────┘ │
│ │ │
│ │ Exclusive Disks │
│ │ ┌─────────────┐ ┌───┐ │
│ │ update │ open-local │ init device │sdd│ │
│ └────────────────┤ agent ├────────────────► └───┘ │
│ └─────────────┘ Block Device │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.1 open-local 包含四个组件：
1）scheduler-extender： 作为 Kube-Scheduler 的扩展组件，通过 Extender 方式实现，新增本地存储调度算法。
2）CSI 插件： 按照 CSI(Container Storage Interface) 标准实现本地磁盘管理能力，包含创建/删除/扩容存储卷、创建/删除快照、暴露存储卷 metrics 等能力。
3）agent： 运行在集群中的每个节点，根据配置清单初始化存储设备，并通过上报集群中本地存储设备信息以供 Scheduler-Extender 决策调度。
4）controller： 获取集群存储初始化配置，并向运行在各个节点的 Agent 下发详细的资源配置清单。
2.2 open-local 包含两个 CRD
1） NodeLocalStorage： open-local 通过 NodeLocalStorage 资源上报每个节点上的存储设备信息，该资源由 controller 创建，由每个节点的 agent 组件更新其 status。该 CRD 属于全局范围的资源。
2）NodeLocalStorageInitConfig： open-local controller 可通过 NodeLocalStorageInitConfig 资源创建每个 NodeLocalStorage 资源。NodeLocalStorageInitConfig 资源中包含全局默认节点配置和特定节点配置，若节点的 node label 满足表达式则使用特定节点配置，否则使用默认配置。
如何在 ack-distro 中使用 open-local
1、初始化配置
前置条件：
环境中已经安装 lvm 工具
ack-distro 部署时会默认安装 open-local。
编辑 NodeLocalStorageInitConfig 资源，进行存储初始化配置。
#kubectl edit nlsc open-local
使用 open-local 要求环境中有 VG（VolumeGroup），若用户环境中已存在 VG 且有剩余空间，则可以配置在白名单；若环境中没有 VG，用户需提供一个块设备名称供 open-local 创建 VG。
apiVersion: csi.aliyun.com/v1alpha1
kind: NodeLocalStorageInitConfig
metadata:
name: open-local
spec:
globalConfig:
listConfig:
vgs:
include:
- open-local-pool-[0-9]+
- your-vg-name
resourceToBeInited:
vgs:
- devices:
- /dev/vdc
name: open-local-pool-0
NodeLocalStorageInitConfig 资源编辑完毕后，controller 和 agent 会更新所有节点的 NodeLocalStorage 资源。
2、存储卷动态供应
open-local 默认在集群中部署了一些存储类模板，我们以 open-local-lvm、open-local-lvm-xfs 和 open-local-lvm-io-throttling 举例：
# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
open-local-lvm local.csi.aliyun.com Delete WaitForFirstConsumer true 8d
open-local-lvm-xfs local.csi.aliyun.com Delete WaitForFirstConsumer true 6h56m
open-local-lvm-io-throttling local.csi.aliyun.com Delete WaitForFirstConsumer true
创建一个 Statefulset，该 Statefulset 使用 open-local-lvm 存储类模板。此时创建的存储卷文件系统为 ext4。若用户指定 open-local-lvm-xfs 存储模板，则存储卷文件系统为 xfs。
# kubectl apply -f https:**//raw.githubusercontent.com/alibaba/open-local/main/example/lvm/sts-nginx.yaml**
检查 Pod/PVC/PV 状态，可看到存储卷创建成功：
NAME READY STATUS RESTARTS AGE
nginx-lvm-0 1/1 Running 0 3m5s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
html-nginx-lvm-0 Bound local-52f1bab4-d39b-4cde-abad-6c5963b47761 5Gi RWO open-local-lvm 104s
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS AGE
local-52f1bab4-d39b-4cde-abad-6c5963b47761 5Gi RWO Delete Bound default/html-nginx-lvm-0 open-local-lvm 2m4s
kubectl describe pvc html-nginx-lvm-0
3、存储卷扩容
编辑对应 PVC 的 spec.resources.requests.storage 字段，将 PVC 声明的存储大小从 5Gi 扩容到 20 Gi。
# kubectl patch pvc html-nginx-lvm-0 -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
检查 PVC/PV 状态：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEhtml-nginx-lvm-0 Bound local-52f1bab4-d39b-4cde-abad-6c5963b47761 20Gi RWO open-local-lvm 7h4mNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGElocal-52f1bab4-d39b-4cde-abad-6c5963b47761 20Gi RWO Delete Bound default/html-nginx-lvm-0 open-local-lvm 7h4m
4、存储卷快照
open-local 有如下快照类：
# kubectl get volumesnapshotclassNAME DRIVER DELETIONPOLICY AGEopen-local-lvm local.csi.aliyun.com Delete 20m
创建 VolumeSnapshot 资源：
# kubectl apply -f https:volumesnapshot.snapshot.storage.k8s.io/new-snapshot-test created# kubectl get volumesnapshotNAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGEnew-snapshot-test true html-nginx-lvm-0 1863 open-local-lvm snapcontent-815def28-8979-408e-86de-1e408033de65 19s 19s# kubectl get volumesnapshotcontentNAME READYTOUSE RESTORESIZE DELETIONPOLICY DRIVER VOLUMESNAPSHOTCLASS VOLUMESNAPSHOT AGEsnapcontent-815def28-8979-408e-86de-1e408033de65 true 1863 Delete local.csi.aliyun.com open-local-lvm new-snapshot-test 48s
创建一个新 Pod，该 Pod 对应的存储卷数据与之前快照点时刻的数据一致：
service/nginx-lvm-snap createdstatefulset.apps/nginx-lvm-snap createdNAME READY STATUS RESTARTS AGEnginx-lvm-snap-0 1/1 Running 0 46sNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEhtml-nginx-lvm-snap-0 Bound local-1c69455d-c50b-422d-a5c0-2eb5c7d0d21b 4Gi RWO open-local-lvm 2m11s
5、原生块设备
open-local 支持创建的存储卷将以块设备形式挂载在容器中（本例中块设备在容器 /dev/sdd 路径）:
# kubectl apply -f https:
检查 Pod/PVC/PV 状态：
NAME READY STATUS RESTARTS AGEnginx-lvm-block-0 1/1 Running 0 25sNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEhtml-nginx-lvm-block-0 Bound local-b048c19a-fe0b-455d-9f25-b23fdef03d8c 5Gi RWO open-local-lvm 36sName: html-nginx-lvm-block-0Namespace: defaultStorageClass: open-local-lvm...Access Modes: RWOVolumeMode: Block # 以块设备形式挂载入容器Mounted By: nginx-lvm-block-0...
6、IO 限流
open-local 支持为 PV 设置 IO 限流，支持 IO 限流的存储类模板如下：
apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: open-local-lvm-io-throttlingprovisioner: local.csi.aliyun.comparameters: csi.storage.k8s.io/fstype: ext4 volumeType: "LVM" bps: "1048576" iops: "1024" reclaimPolicy: DeletevolumeBindingMode: WaitForFirstConsumerallowVolumeExpansion: true
创建一个 Statefulset，该 Statefulset 使用 open-local-lvm-io-throttling 存储类模板。
# kubectl apply -f https:
Pod 处于 Running 状态后，进入 Pod 容器中：
# kubectl exec -it test-io-throttling-0 sh
此时存储卷是以原生块设备挂载在 /dev/sdd 上，执行 fio 命令：
# fio -name=test -filename=/dev/sdd -ioengine=psync -direct=1 -iodepth=1 -thread -bs=16k -rw=readwrite -numjobs=32 -size=1G -runtime=60 -time_based -group_reporting
结果如下所示，可见读写吞吐量限制在 1024KiB/s 上下：
......
Run status group 0 (all jobs): READ: bw=1024KiB/s (1049kB/s), 1024KiB/s-1024KiB/s (1049kB/s-1049kB/s), io=60.4MiB (63.3MB), run=60406-60406msec WRITE: bw=993KiB/s (1017kB/s), 993KiB/s-993KiB/s (1017kB/s-1017kB/s), io=58.6MiB (61.4MB), run=60406-60406msec
Disk stats (read/write): dm-1: ios=3869/3749, merge=0/0, ticks=4848/17833, in_queue=22681, util=6.68%, aggrios=3112/3221, aggrmerge=774/631, aggrticks=3921/13598, aggrin_queue=17396, aggrutil=6.75% vdb: ios=3112/3221, merge=774/631, ticks=3921/13598, in_queue=17396, util=6.75%
7、临时卷
open-local 支持为 Pod 创建临时卷，其中临时卷生命周期与 Pod 一致，即 Pod 删除后临时卷也随之删除。此处可理解为 open-local 版本的 emptydir。
结果如下：
Name: file-serverNamespace: default......Containers: file-server: ...... Mounts: /srv from webroot (rw) /var/run/secrets/kubernetes.io/serviceaccount from default-token-dns4c (ro)Volumes: webroot: # 此为 CSI 临时卷 Type: CSI (a Container Storage Interface (CSI) volume source) Driver: local.csi.aliyun.com FSType: ReadOnly: false VolumeAttributes: size=2Gi vgName=open-local-pool-0 default-token-dns4c: Type: Secret (a volume populated by a Secret) SecretName: default-token-dns4c Optional: false
8、监控大盘
open-local 自带了监控大盘，用户可通过 Grafana 查看集群本地存储信息，包含存储设备和存储卷信息。
总而言之，借助 open-local ，在运维方面可减少人力成本，提高集群运行时的稳定性；功能方面，将本地存储的优势最大化，使用户不仅能体验到本地盘的高性能，同时各种高级存储特性丰富了应用场景，让广大开发者体验云原生带来的红利，实现应用上云尤其是有状态应用云原生部署关键一步。
0
/6 
工商网监
湘ICP备2023018690号
1005
评论
淘帖
361
2
