后台回复【资料包】获取学习资料
容器可以很好地与无状态应用程序一起使用,因为不需要保存数据。Kubernetes 可以快速创建和删除容器,因为容器中的应用程序与其所有依赖项打包在一起。
但是,动态创建和删除容器可能会遇到需要持久存储的有状态应用程序的问题。有状态的容器化应用程序必须对其数据具有一致且可靠的访问权限。这意味着无法轻松动态地创建和删除持久存储。
在 Rancher Online Meetup 中,来自 SUSE 的 David Ko 强调了使用 Kubernetes 时与存储相关的其他挑战:
上述挑战正是 Cloud Native Computing Foundation 的孵化器项目Longhorn 正在寻求解决的问题。
https://longhorn.io/ https://github.com/longhorn/longhorn
Longhorn 是 Kubernetes 的云原生分布式块存储系统,旨在运行在不同类型的物理存储设备、基础设施和架构之上。它最初由 Rancher Labs 开发,并于 2019 年 10 月 11 日被云原生计算基金会接受为孵化器项目。
Longhorn 使 DevOps 团队能够在任何 Kubernetes 环境中管理持久数据卷,同时为云原生存储带来供应商中立和企业级的方法。
在 KubeCon Europe 2020 上,来自 SUSE 的 Sheng Yang 概述了 Longhorn 背后的一些设计原则:
Dashboard
该项目能够:
ReadWriteMany
(RWX) 支持Longhorn 有两层:数据平面和控制平面。Longhorn Engine是对应数据平面的存储控制器。Longhorn Manager对应于控制平面。
Manager pod 作为 Kubernetes DaemonSet,在 Longhorn 集群中的每个节点上运行。它负责在 Kubernetes 集群中创建和管理卷。
Manager 与 Kubernetes API 服务器通信以创建新的 Longhorn 卷客户资源定义 (CRD)。接下来,Longhorn Manager 等待 API 服务器的响应。当看到 Kubernetes API 服务器创建了一个新的 Longhorn 卷 CRD 时,Manager 会创建一个新的卷。
创建新卷时,管理器会在卷所连接的节点上创建一个 Longhorn Engine 实例。然后,它会在每个将放置副本的节点上创建一个副本。
创建副本和引擎的过程只需要几秒钟。这就是 Longhorn attach 和 detach 卷的速度。
Architecture
由于副本的多个数据路径,Longhorn 卷实现了高可用性。如果某个副本或引擎出现问题,Pod 将继续正常运行。引擎和副本是分组的,每个组都有一个包含的数据路径,它们之间不交互。这是 Longhorn 设计的一个优势。
如果一个卷出现故障,则无法影响其他卷、引擎和副本。通过这样做,可以避免为整个集群提供高可用性引擎。相反,我们有专门用于每个卷的小型引擎和副本。
自 2019 年将该项目捐赠给 CNCF 以来,Longhorn 经历了指数级增长。该项目被认为是生产就绪的,并且已经被多个组织使用。例如,健康信息技术公司 Cerner,依靠 Longhorn 进行持久存储和高可用性数据复制。另一个例子是巴西帕拉州的地区选举法院,它使用 Longhorn 作为 Prometheus 和其他工具的存储后端。
在 CNCF 捐赠之后,我们看到了 15 倍的增长。在全球范围内,有 35,000 个运行 Longhorn 的活动节点。该项目不仅被开源社区使用,还被顶级企业使用,这意味着 Longhorn 已经准备好投入生产。
Roadmap
Longhorn v1.2 于 2021 年 9 月发布。从那时起,社区一直致力于在下一个重大更新 v1.3 之前进行增量改进。
对于即将发布的 Longhorn v1.3,我们正在努力增强并更加关注 API 接口。不是每个人都想从 Longhorn UI 升级,所以需要一些集成自动化。
除了 RWX 成熟度之外,v1.3 计划的其他一些功能包括:
Longhorn 目前在 v1.2.4 。任何对该项目感兴趣的人都可以在 GitHub 存储库中跟踪其开发。
- END -
原文: https://www.altoros.com/blog/longhorn-provides-persistent-storage-for-35000-kubernetes-nodes/