2. Longhorn 架构解析：控制平面与数据平面
Longhorn 采用微服务架构，将存储系统的控制逻辑与数据路径完全分离。理解其核心组件——控制平面（Longhorn Manager、API Server）与数据平面（Engine、Replica）以及 CSI Driver 的角色，是进行版本漂移校准与备份恢复的基础。本章将逐一拆解这些组件的职责、交互方式与关键配置。
2.1 控制平面：Longhorn Manager 与 API Server
控制平面负责集群存储资源的编排、调度与状态管理，不参与实际 I/O 路径。
| 组件 | 部署方式 | 核心职责 |
|---|---|---|
| Longhorn Manager | DaemonSet（每个节点一个 Pod） | 管理卷生命周期（创建/删除/挂载/快照）；监控 Replica 健康状态；执行故障转移与重建；与 Kubernetes API Server 交互。 |
| Longhorn API Server | Deployment（通常 2 副本） | 提供 RESTful API 供 UI、CLI 与外部系统调用；封装 Manager 操作；维护卷、节点、备份等资源的状态视图。 |
关键点： Longhorn Manager 是控制平面的“大脑”，它通过监听 Kubernetes 自定义资源（CRD）的变化来驱动实际存储操作。API Server 则是面向用户的“窗口”，所有非 Kubernetes 原生操作（如备份到 S3、创建定时快照）都通过它发起。
2.2 数据平面：Engine 与 Replica
数据平面负责处理实际的读写 I/O 请求，保证数据一致性与高可用。
- Engine：每个卷对应一个 Engine 实例，运行在卷挂载的节点上。它接收来自 CSI Driver 的 I/O 请求，将数据同步写入所有健康的 Replica，并处理故障时的读写降级。
- Replica：每个卷通常有 2-3 个 Replica，分布在不同的节点上。每个 Replica 是一个独立的 Linux 块设备（通过
tgt或nvme_tcp暴露），存储完整的数据副本。
数据写入流程： Engine 收到写请求后，会并行写入所有 Replica，只有所有 Replica 都确认写入成功后，才向客户端返回成功。这种“同步复制”机制保证了数据强一致性，但也意味着写入延迟受最慢 Replica 影响。
2.3 CSI Driver 的角色
CSI (Container Storage Interface) Driver 是 Longhorn 与 Kubernetes 存储生态的桥梁。它实现了标准的 CSI 接口，使得 Kubernetes 无需感知 Longhorn 内部细节即可使用其存储能力。
- Controller Plugin：以 Deployment 形式运行，负责处理卷的创建、删除、快照、扩容等控制面操作。
- Node Plugin：以 DaemonSet 形式运行，负责在 Pod 调度到节点后，执行卷的挂载、格式化、卸载等数据面操作。
版本漂移风险点： CSI Driver 的版本必须与 Longhorn Manager 及 Engine 镜像版本严格匹配。在升级 Longhorn 时，如果 CSI Driver 未同步升级，可能导致 Pod 无法挂载卷或挂载后 I/O 异常。这是版本漂移校准中最常见的故障场景之一。
2.4 组件交互流程总结
一个典型的卷创建与挂载流程如下：
- 用户通过 PVC 声明存储需求，Kubernetes 调度器将 PVC 绑定到 PV。
- CSI Controller Plugin 监听到 PV 绑定事件，调用 Longhorn API Server 创建卷。
- Longhorn Manager 根据调度策略在集群中创建 Engine 和指定数量的 Replica。
- Pod 调度到目标节点后，CSI Node Plugin 调用 Longhorn Manager 将 Engine 挂载到节点。
- Pod 开始通过 Engine 进行 I/O 操作，Engine 将数据同步写入所有 Replica。
版本漂移校准切入点： 在上述流程中，步骤 2（API Server 与 Manager 的通信协议）、步骤 3（Manager 与 Engine/Replica 的镜像版本）、步骤 4（CSI Node Plugin 与 Manager 的 gRPC 接口）均存在版本兼容性约束。任何组件的版本不一致都可能导致流程中断或数据损坏。