一、为什么 Kubernetes 需要独立的分布式存储
Kubernetes 原生只负责调度与编排，Pod 本身是临时性的：一旦被驱逐或节点宕机，本地磁盘上的数据就会随之消失。对于 PostgreSQL、Redis、消息队列这类有状态服务，单靠 emptyDir 或节点本地盘完全不可靠。社区早期用 NFS、Ceph 等方案，但配置繁琐、运维门槛高，小团队很难长期维护。Longhorn 由 Rancher（SUSE）开源，把分布式块存储做成了开箱即用的轻量方案：一条 Helm 命令装好，应用只需像使用普通 PVC 一样申明 StorageClass，就能获得跨节点复制、自动故障转移、快照与备份能力。本文基于一个单机多节点的 K8s 环境（可参考 k3s 轻量部署），从零跑通 Longhorn 的部署、挂载、快照与备份全流程。
很多团队在刚接触 K8s 时会把数据库跑在宿主机目录挂载上，短期能跑通，但一旦节点下线、Pod 被重新调度到别的机器，数据就彻底丢失。真正的生产环境必须让存储与计算解耦：存储跟随卷走，而不是跟随节点走。这正是 Longhorn 要解决的核心问题。
二、Longhorn 与其他存储方案怎么选
在引入 Longhorn 之前，先想清楚它和常见方案的定位差异。下面的对比表能帮你快速判断：
| 方案 | 运维复杂度 | 可靠性 | 适用规模 |
|---|---|---|---|
| 节点本地盘 | 最低 | 差（节点挂即丢） | 仅临时数据 |
| NFS | 低 | 中（单点依赖） | 小集群共享读 |
| Ceph | 很高 | 极高 | 大型多租户 |
| Rook(Ceph) | 高 | 高 | 中大型 |
| Longhorn | 低 | 高（多副本） | 中小到中型集群 |
可以看到，Longhorn 处在运维成本与可靠性之间的甜点区：比 Ceph 轻得多，又比 NFS 和本地盘可靠得多。它尤其适合 3 到 50 个节点、需要持久化但有状态服务不多的团队。
三、Longhorn 架构：微引擎加多副本
3.1 每个卷一个微引擎
与传统集中式存储不同，Longhorn 为每一个 Volume 启动一个轻量的存储引擎（engine）副本，运行在专用 Pod 里，只负责本卷的读写与复制。这种去中心化设计让性能随节点水平扩展，单点故障不会拖垮整个集群，也避免了传统存储控制器的性能瓶颈。
3.2 默认三副本，跨节点容错
Longhorn 默认把每个卷的数据切成多个副本（replica），默认 3 份，均匀分散在不同节点。当某个节点宕机，控制器会在存活节点上自动重建缺失副本，应用无感知。副本数可以在 StorageClass 里按业务重要性调整，关键数据可提高到 3 以上。
四、Helm 一键部署 Longhorn
添加官方仓库并安装到独立命名空间。Longhorn 由几个核心组件组成：longhorn-manager 负责编排与 API，longhorn-ui 提供可视化界面，longhorn-csi-plugin 则是 Kubernetes CSI 驱动，让 PVC 能真正挂进 Pod。
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace等待组件就绪：
kubectl -n longhorn-system get pods
# NAME READY
# longhorn-manager-xxxxx 1/1
# longhorn-ui-xxxxx 1/1
# longhorn-csi-plugin-xxxxx 1/1部署完成后，通过 kubectl -n longhorn-system get svc 找到 longhorn-frontend 的 NodePort，或配合 Nginx 反向代理 暴露 UI，即可在浏览器中可视化查看卷、节点与副本状态。
五、创建 PVC 并挂载到应用
声明一个 5Gi 的卷，StorageClass 指定 longhorn：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 5Gi在 Deployment 中引用该声明：
volumes:
- name: data
persistentVolumeClaim:
claimName: mysql-dataPod 调度到任意节点都能挂载到同一份数据，节点漂移不再丢数据。Longhorn 还支持在线扩容：把 PVC 的 storage 改大后，卷会在不中断业务的情况下扩展。对数据库类负载，这正是 PostgreSQL 慢查询优化 之外最该先解决的地基问题。
六、StorageClass 与回收策略
Longhorn 安装后会注册多个 StorageClass，核心区别在回收策略与副本数：
| StorageClass | 回收策略 | 默认副本 | 适用场景 |
|---|---|---|---|
| longhorn | Delete | 3 | 临时测试、可重建数据 |
| longhorn-static | Retain | 3 | 生产关键数据 |
| longhorn-witness | Delete | 1 | 低价值日志 |
生产环境建议显式设置 storageClassName: longhorn-static，或将默认类打上 storageclass.kubernetes.io/is-default-class: "true"，避免误删。Delete 策略在 PVC 删除时会连同底层卷一起清掉，Retain 则会保留卷，方便事故后手动恢复。
七、快照与备份：本地快照 vs 远程备份
Longhorn 提供两层数据保护，二者互补：
| 能力 | 存储位置 | 恢复粒度 | 抗节点故障 |
|---|---|---|---|
| 快照 Snapshot | 集群内副本盘 | 卷级/增量 | 是 |
| 备份 Backup | 外部对象存储 S3 | 卷级 | 是（跨集群） |
创建一份本地快照：
kubectl apply -f - <要把备份落到远端，先在 Longhorn UI 配置 Backup Target 指向 MinIO 对象存储（兼容 S3 协议），之后每次备份都会以增量方式推送到桶里，实现真正的异地容灾。快照适合快速回滚，备份则能在整个集群损毁时从外部恢复。
八、实战：把 PostgreSQL 数据迁移到 Longhorn
假设已有一套跑在 PostgreSQL 上的业务，迁移只需三步：第一，用 pg_dump 导出；第二，建 Longhorn PVC 并挂载到新 Pod；第三，psql 导入。由于 Longhorn 卷跨节点可见，后续节点维护时数据库 Pod 可被调度到任意健康节点而不丢数据，配合 Velero 还能做集群级整机备份，形成快照、卷备份、集群备份三层防护。
九、高可用与故障自愈
当某节点宕机，Longhorn 控制器检测到副本不可达，会立即从剩余健康副本继续服务，并在其他节点重建缺失副本，直到恢复到目标副本数。整个过程对上层应用透明，无需人工介入。需要注意：重建副本会占用网络带宽与磁盘 IO，建议在低峰期或给 Longhorn 配置独立的存储网络，避免影响业务吞吐。
十、运维监控与容量规划
Longhorn 自带 Prometheus 指标（如 longhorn_volume_actual_size、longhorn_node_storage_available），可接入现有监控栈做容量预警；UI 中的节点磁盘压力面板能直观看到各节点剩余空间。经验法则是单节点预留 20% 以上余量，避免副本重建时空间不足导致重建失败。同时建议对 longhorn-manager 做资源 request/limit，防止它和业务的存储 IO 互相争抢。
十一、常见坑与调优
| 问题 | 根因 | 处理 |
|---|---|---|
| 卷一直 attaching | 多控制器争用 | 确认 ReadWriteOnce、单 Pod 挂载 |
| 副本重建卡住 | 节点磁盘满 | 清理空间或扩盘后自动恢复 |
| 备份失败 | S3 凭据错误 | 核对 Backup Target 的 AccessKey |
| 性能偏低 | 默认副本 3 跨网络 | 同可用区节点、启用 stripe |
十二、适用与不适用场景
Longhorn 虽好，但并非万能。它适合：单机到中型集群的有状态服务、需要低成本高可用的团队、希望用 UI 直观管理卷的场景。它不太适合：超大规模（数百节点）的多租户存储、对极端吞吐与低延迟有苛刻要求的场景（这类需求更该上 Ceph 或专业存储阵列）。选型时把业务规模与团队运维能力一起考虑，才能避免后续推倒重来。
十三、小结
Longhorn 用极低的运维成本，为 Kubernetes 补上了持久化、高可用、可备份三块短板。它与 k3s、Velero、MinIO 等组成一套完整的有状态基础设施栈。下一步可结合 GitHub Actions 把备份校验纳入 CI，让数据安全自动化闭环。对于绝大多数中小团队而言，Longhorn 是落地 K8s 持久化存储最省心的一站式答案。
