集群存储架构

集群存储架构速查表

1. 核心技术选型：Local Path Provisioner

你使用的是 Rancher 开发的 Local Path Provisioner。它不像 Ceph 或 NFS 那样需要复杂的网络协议，而是直接利用宿主机的硬盘。

• 存储驱动 (CSI): local-path
• 管理工具: Kubernetes StorageClass
• 物理位置: 默认在 node-2（以及 node-1）的 /opt/local-path-provisioner/ 目录下。

---

2. 存储运作逻辑（你是怎么实现“自动化”的）

你刚才安装 Jenkins 时，并没有手动去分硬盘，而是通过以下链路实现的：

1. 声明 (PVC): Jenkins 发出申请：“我需要 10Gi 空间，请找 local-path 要。”
2. 调度 (Provisioner): local-path 插件监听到申请，自动在 node-2 的硬盘上创建了一个专属文件夹。
3. 绑定 (PV): 系统自动生成一个 PersistentVolume，并把文件夹“挂载”进 Jenkins 的 Pod。
4. 持久化: 哪怕你删掉 Jenkins 的 Pod，只要不删 PVC，你的插件和配置都稳稳地躺在 node-2 的硬盘里。

---

3. 当前已承载的资产

你可以通过 kubectl get pvc -A 看到你现在的“家产”：

应用名称	存储占用	存储状态	物理节点	存放内容
Jenkins	10Gi	Bound	node-2	插件、Pipeline 脚本、用户凭据
(已清理)	70Gi+	-	-	刚才删除 GitLab 释放出的巨大空间

---

为什么这个存储架构适合 OpenClaw？

梓涵，你在面试或写博客时可以这样描述你的思考：

• 低延迟 (Low Latency): 因为是本地磁盘 I/O，Python 脚本读取日志文件的速度远高于网络存储，这对 AIOps 实时预警 至关重要。
• 资源精益 (FinOps): 零额外内存占用。相比部署一套 Ceph 需要额外消耗 3-5GB 内存，local-path 几乎不占资源。
• 高可靠性: 配合 K8s 的 StatefulSet，确保了 Jenkins 这种有状态应用的**“数据粘性”**。

---

运维小贴士（记在你的开发笔记里）

如果你想看看 Jenkins 的数据到底长啥样，可以直接去 node-2 执行：

ls -lh /opt/local-path-provisioner/

你会看到一串以 pvc-xxx 命名的文件夹，那里面就是 Jenkins 的灵魂。

---