通过 Open Service Broker 在 Kubernetes 上实现动态本地持久卷

Source: Dev.to

共享存储对许多工作负载来说表现良好，但一旦延迟和 I/O 一致性变得重要，本地磁盘就显得非常有吸引力。

Kubernetes 支持本地持久卷（Local PV），但有一个重大限制：本地 PV 必须静态供给。这使得它们在需要按需创建工作负载的动态环境中难以使用。我们在尝试通过 Open Service Broker 接口暴露本地存储时就遇到了这个问题。

为什么静态本地 PV 是个问题

• 必须在工作负载请求之前就已经存在 PV
• 容量规划需要手动进行
• 自动化流水线会出现故障

对于服务代理和自助平台来说，这根本不可接受。用户期望存储能够动态供给。

我们采用的方案

我们没有去对抗 Kubernetes 的设计，而是寻找了变通办法。核心思路是将以下两件事分离：

• 调度决策 – 仍由 Kubernetes 完成
• 磁盘创建 – 在目标节点上完成

供给流程

从宏观上看，我们的工作流如下：

1. 服务代理收到本地存储的请求。
2. 代理提交一个临时的 “dummy” Kubernetes 清单，内容包括：
   • 资源需求
   • 节点亲和性
3. Kubernetes 将工作负载调度到具体节点。
4. 节点确定后，代理：
   • 远程创建本地磁盘
   • 生成对应的 Local PV 对象
5. 真正的工作负载被部署并绑定到该 PV。
6. 当服务被删除时，清理本地磁盘。

这样我们实现了类似动态供给的效果，虽然本地 PV 在底层仍是静态的。

为什么能奏效

• 调度仍由 Kubernetes 决定。
• 磁盘只在需要的节点上创建。
• 没有对未使用容量的预供给。
• 存储生命周期与服务实例绑定。

虽然没有 CSI 驱动那样优雅，但对于本地部署和混合集群来说，这是一种实用的解决方案。

权衡与经验教训

• 需要节点级别的访问权限。
• 清理工作必须谨慎处理。
• 故障路径需要额外关注。

作为回报，我们获得了可预测的性能以及对有状态工作负载更好的开发者体验。

何时适合使用此模式

• 你能够控制集群。
• I/O 性能至关重要。
• 云块存储不可用。
• 服务代理是平台的一部分。

对许多内部平台而言，这已经“足够好”，且远胜于手动管理 PV。

开源实现

我们已将此方案记录并开源，作为更大平台项目的一部分：

👉 https://github.com/laoshanxi/app-mesh/blob/main/docs/source/success/open_service_broker_support_local_pv_for_K8S.md

如果你已经围绕本地 PV 构建了动态存储工作流（或决定不这么做），欢迎分享你的成功经验与教训。