企业官网建设流程全解析

• 云原生
• 存储
• 高可用
• 容器编排

本指南以 Longhorn v1.6.0 官方发布说明（CHANGELOG/CHANGELOG-1.6.0.md）为主体，结合仓库内的增强设计文档（enhancements/）与 Helm Chart 配置源码（chart/），系统解读该版本的核心特性：V2 数据引擎的成熟化（快照/回滚、备份/恢复、ARM64）、平台无关部署（Talos/OKD）、可配置的快照空间管理、GitOps 友好化、块卷加密、新的节点排空策略以及 Backing Image 备份恢复。读完本文，你将掌握 v1.6.0 的升级前提、关键新设置的配置方法与底层实现原理，并理解每个核心功能的源码级支撑。

版本概览：v1.6.0 的核心主题

Longhorn v1.6.0 是面向稳定性、性能与韧性的重要版本，发布说明将其亮点归纳为六个方向：

• V2 数据引擎新特性：快照与回滚、备份与恢复、V1/V2 数据面分离、ARM64 支持；
• 平台无关部署：正式支持 Talos 与 OKD；
• 空间效率：引入可配置的快照最大数量与最大总大小限制；
• GitOps 友好：与 Flux、Argo CD、Fleet 完成验证；
• 数据保护：支持块设备卷（VolumeMode: Block）加密；
• 节点维护：新增两种节点排空（drain）策略选项；
• Backing Image 管理：支持 Backing Image 的备份与恢复。

需要强调的是，v1.6.0 中 V2 数据引擎仍属于 preview（预览）特性，但核心功能已显著增强，尤其是 V1 与 V2 数据引擎之间的备份/恢复互通，为未来两个引擎之间的卷迁移铺平了道路。

安装与升级前提

v1.6.0 的安装与升级都有明确的 Kubernetes 版本门槛：

确保集群运行 Kubernetes v1.21 或更高版本，再安装 Longhorn v1.6.0。

从 v1.5.x 升级到 v1.6.0 前，同样要求 Kubernetes v1.21 或更高版本。

• 安装：可通过 Rancher、kubectl、Helm 等多种工具安装，部署清单见 deploy/longhorn.yaml，Helm Chart 见 chart/Chart.yaml（对应版本号可在该文件确认）。
• 升级：Longhorn 只允许从受支持的版本升级，官方要求按照受支持的升级路径执行，详见发布说明的 Upgrade 一节。
• 废弃与不兼容项：涉及功能不兼容、废弃与移除的重要变化，请以发布说明的 "Deprecation & Incompatibilities" 与 "Post-Release Known Issues" 两节为准——这两个章节列举了版本演进中需要用户特别关注的风险点。

V2 数据引擎：从预览走向可用

v1.6.0 对 V2 数据引擎（基于 SPDK，即 Storage Performance Development Kit）投入了大量工作。其底层架构在设计文档 enhancements/20230619-spdk-engine.md 中有完整描述：与传统引擎不同，V2 引擎的数据流由 spdk_tgt 接管，磁盘被抽象为 aio bdev + lvstore，快照与卷头文件是 lvstore 内的逻辑卷（lvol），远程副本以 NVMe-oF 子系统形式暴露，引擎后端是 SPDK RAID1 bdev，前端是 NVMe-oF initiator。v1.6.0 在这一架构之上补齐了下列用户可见能力。

卷快照与回滚（Issue #6137）

V2 卷现在支持快照创建与回滚操作，这是 V2 引擎可用性的关键一步。结合设计文档可知，SPDK 引擎服务通过 gRPC 提供SnapshotCreate/SnapshotDelete接口（见 enhancements/20230619-spdk-engine.md），并由 Longhorn Manager 侧的统一控制器编排，使 v2 卷的快照行为与 v1 卷趋同。

卷备份与恢复（Issue #6138）

v1.6.0 实现了V2 卷的备份/恢复，并且支持V1 与 V2 数据引擎之间无缝进行卷备份与恢复操作（UI 备份恢复也同时支持 v1 与 v2 数据引擎，见 Improvements 中的 Issue #6597）。这意味着：你可以从 V1 卷创建备份，再恢复到 V2 卷，反之亦然，为引擎间迁移提供了数据通道。配套改进还包括：

• 支持仅启用 v2 数据引擎时列出备份（Issue #7486）；
• 删除 v2 卷重建快照、删除恢复中的备份、备份损坏等场景下的状态卡死问题修复（Issue #7573、#7575、#7583、#7584）；
• v2 卷恢复过程中删除实例管理器导致卷卡在 detaching 状态的问题修复（Issue #7581）。

V1/V2 数据面分离：独立的实例管理器（Issue #6984、#7015）

v1.6.0 将v1 与 v2 卷的实例管理器（instance manager）分开部署，并允许按需启用/禁用数据引擎，即 "Selective V2 Data Engine Activation"。这一设计可以从 enhancements/20230303-consolidate-instance-managers.md 中找到脉络：Longhorn 曾将 engine/replica 实例管理器合并为单一个体（aio），而 v1.6.0 进一步让 V1/V2 引擎各用各自的实例管理器，避免相互干扰。对应地，chart/values.yaml 中提供了全局开关：

defaultSettings: # 允许启用 V1 数据引擎 v1DataEngine: ~ # 允许启用 V2 数据引擎（基于 SPDK） v2DataEngine: ~ # V2 专属：为 SPDK 目标守护进程启用 hugepages dataEngineHugepageEnabled: ~ # V2 专属：SPDK 目标守护进程的 hugepage 大小（MiB），默认 {"v2":"2048"} dataEngineMemorySize: ~

这些设置同样可以在 chart/templates/default-setting.yaml 中看到被渲染为 Longhorn Setting CR 的逻辑。UI 侧也会根据已启用的数据引擎校验卷创建（Issue #7505）。

ARM64 支持（Issue #6021）

v2 卷正式支持在 ARM64 平台运行，进一步拓展了 V2 引擎的硬件适用面。

其他 V2 相关增强

• 在 v2 卷之上叠加线性 dm 设备（Issue #7357）：通过 device-mapper 暴露逻辑卷实际大小（Issue #5947），并让 UI 显示 v2 卷的实际大小（Issue #7524）；
• 基于 SPDK 的副本重建（Replica rebuild over SPDK）（Issue #5216），并修复首次重建失败后卷永远无法重建成功的问题（Issue #7723）；
• 为 spdk_tgt 增加 2GiB hugepage（Issue #7606），并优雅关闭 spdk_tgt（Issue #7263）；
• spdk_tgt 死亡时自动重建 v2 实例管理器 Pod（Issue #7551）；
• 为 v2 卷新增 guaranteedInstanceManagerCPU 设置（Issue #7361）；
• 修复 v2 卷在spdk_tgt异常时的各种卡死/循环（Issue #7579、#7608）以及读写带宽提升（Issue #5759，见下文性能部分）。

平台无关部署：Talos 与 OKD

v1.6.0 进一步兑现了"在各类环境中可用"的承诺：

• Talos（Issue #3161）：Talos 是一个安全、不可变、极简的 Kubernetes 操作系统。此前 Longhorn 组件安装到 Talos 上存在诸多阻碍，v1.6.0 做了针对性适配，允许在 Talos 上安装全部 Longhorn 组件。
• OKD（OpenShift Origin）（Issue #1831）：由社区成员 @ArthurVardevanyan 贡献，v1.6.0 加入了对 OKD 的支持。Helm Chart 中也相应提供了 OpenShift 相关的 OAuth Proxy 镜像配置（见 chart/values.yaml）。

这些适配使得 Longhorn 在通用 Linux 发行版、容器优化系统（如 SLE Micro）以及 Talos、OKD 上都能运行。

快照空间管理：让快照占用变得可预测

这是 v1.6.0 最具操作价值的特性之一。在此之前，单个卷的默认最大快照数为固定常量250（写死在引擎源码中），用户既无法控制也无法预估快照空间占用；而 v1.6.0 允许用户全局与按卷配置最大快照数量与最大快照总大小，详见设计文档 enhancements/20230905-snapshot-space-management.md。

核心机制

• 新增全局设置snapshot-max-count：类型为整型，合法范围2 到 250，默认值250。最小值取 2 的原因是：在 Longhorn 中所有快照最终可以合并为一个快照，至少需要一个可删除的快照来腾出名额，因此要创建新快照至少需要 2 个名额。
• VolumeSpec 新增两个字段（设计文档 enhancements/20230905-snapshot-space-management.md）：

type VolumeSpec struct { // ... SnapshotMaxCount int `json:"snapshotMaxCount"` SnapshotMaxSize int64 `json:"snapshotMaxSize,string"` }

• 若SnapshotMaxSize为0，表示该卷不设快照大小上限；

• 若SnapshotMaxCount为0，卷的 mutator 会用全局snapshot-max-count设置的值补齐；

• 卷扩容时，若snapshot-max-size小于size * 2，mutator 会将其更新为size * 2——因为一个卷至少可以存在两个快照，快照大小下限为卷大小的两倍。

• 校验规则（validator）：

  • SnapshotMaxCount必须在2到250之间（包含用户快照与系统快照）；
  • 若SnapshotMaxSize非零，其最小值必须等于该卷Size * 2。

• 副本侧实现：Replica 新增snapshotMaxCount/snapshotMaxSize字段，并提供GetSnapshotCountUsage/GetSnapshotSizeUsage统计实际占用（跳过 volume head、backing disk 与被移除的磁盘）；ReplicaServer 的 gRPC proto 新增remain_snapshot_size字段；引擎控制器通过新增的canDoSnapshot函数在创建快照前校验配额；Manager API 新增updateSnapshotMaxCount/updateSnapshotMaxSize两个动作。

配置方式

• 全局默认：在 Longhorn UI 的 Settings 中修改 "Snapshot Maximum Count"，或在 Helm Chart 的defaultSettings中配置对应项（chart/values.yaml 中snapshotDataIntegrity等快照相关设置亦在同一分组）。
• 按卷配置：创建/编辑卷时直接指定该卷的最大快照数与最大快照大小，适合为重要卷预留更多快照空间。

设计文档还给出了可执行的集成测试预期，例如：1G 卷、最大快照数 2、无大小限制时，创建第 1、2 个快照成功、第 3 个失败；删除一个快照后即可再次创建。这套行为也是用户在 v1.6.0 中可以直接验证的。

GitOps 友好：Flux、Argo CD 与 Fleet

v1.6.0 已与主流 GitOps 方案完成验证（Flux：Issue #6343；Argo CD：Issue #6434；Fleet：Issue #6935），关键改动是：

• 移除/改造 Helm 预升级 hook 以支持 Argo CD（Issue #6415）：预升级检查 Job 在 GitOps 场景下容易造成部署漂移或阻塞，因此改为可禁用。对应地，chart/values.yaml 提供了显式开关：

preUpgradeChecker: # 使用 Argo CD 或其他 GitOps 方案安装 Longhorn 时建议关闭 jobEnabled: true # 升级版本检查；关闭该项会同时禁用 jobEnabled upgradeVersionCheck: true

• 此外还修复了 Rancher 无法导入 longhorn 1.5 chart 的 YAML 解析问题（Issue #7496）等 Chart 层面的兼容性问题。

数据保护：块卷加密

v1.6.0 正式支持VolumeMode: Block 的卷加密（Issue #4883），对 Harvester、KubeVirt 等虚拟化场景尤其有用。加密基于 device-mapper（crypt）实现，仓库中提供了完整示例：加密全局 Secret 与 StorageClass 见 examples/crypto/secret-crypto-global.yaml 与 examples/crypto/storageclass-crypto-global.yaml，按卷独立加密的示例见 examples/crypto/storageclass-crypto-per-volume.yaml，块设备卷 + 加密组合示例见 examples/block/crypto/。同时 v1.6.0 修复了 Amazon Linux 2、mTLS 场景下的加密卷挂载失败问题（Issue #5944、#7040），并清理了 RWX 可迁移加密卷的 crypt device mapper 残留（Issue #7678）。

节点维护：新的节点排空策略

v1.6.0 为节点维护引入两个新的node drain policy选项：

• Block For Eviction：在节点被 cordon 之前，自动驱逐（evict）并迁移该节点上的健康副本；
• Block For Eviction If Contains Last Replica：仅当节点包含某卷的最后一个健康副本时才阻止排空，允许在其他情况下自动迁移副本。

这两项由 Issue #2238 落地，核心价值是：在排空节点时自动驱逐并搬迁健康副本，降低卷变为 degraded 的风险。官方建议仅在计划维护期间启用，以最小化数据移动的影响。对应设置在 Helm Chart 中可以直接配置：

defaultSettings: # 定义当包含卷最后一个健康副本的节点被排空时，Longhorn 采取的动作 nodeDrainPolicy: ~ # 节点被 cordon 时，是否自动分离手动挂载的卷 detachManuallyAttachedVolumesWhenCordoned: ~

（见 chart/values.yaml，并由 chart/templates/default-setting.yaml 渲染为node-drain-policy设置。）相关改进还包括：允许kubectl drain停止手动挂载的卷（Issue #6978）、节点排空时自动驱逐副本等。

Backing Image 管理：备份与恢复

v1.6.0 允许创建并恢复 Backing Image 的备份（Issue #4165），可显著简化跨集群的 Backing Image 管理，同样利好 Harvester/KubeVirt 虚拟化场景。设计文档 enhancements/20230807-backingimage-backup-support.md 说明了实现要点：

• 带 Backing Image 的卷备份时，Backing Image自动随卷备份；恢复时也自动恢复，无需在目标集群手工重建 Backing Image；
• 所有 Backing Image 共享备份存储中的同一块池，相同数据块复用，提速且省空间；
• 备份按块（默认 2MB，最后一块可能不足 2MB）上传；恢复时按块映射写回正确偏移；qcow2 格式由于无法探测空洞，全量备份所有块；
• 新增backupbackingimage.longhorn.ioCRD 承载备份状态（Pending/InProgress/Completed 等状态机）；
• 修复了导出自 Backing Image 卷的数据不一致（Issue #6899）、下载服务器错误（Issue #7288）、存储网络下 502 错误（Issue #7236）等问题。

稳定性、性能与其他值得关注的能力

性能

• V2 卷读带宽提升：允许从所有下游副本同时读取，显著提升 v2 卷读带宽（Issue #5759）；
• 补充了 1.5 性能基准数据到官方性能基准 WIKI（Issue #6203）。

关键改进（Improvements 精选）

• 内存与资源：优化资源缓存，解决 longhorn-manager 高内存占用（Issue #6954，对应此前 v1.5 的 20GB+ RAM 问题 #6866）；默认priorityClass防止意外驱逐（Issue #6528，对应设置见 chart/values.yamlpriorityClass: longhorn-critical）；为系统托管 CSI 组件提供资源限制配置（Issue #7325 相关设置项见 chart/values.yaml）；
• RWX 卷：回退到 NFS v4.1（Issue #7741）并支持 NFS v4.2 与自定义挂载选项（Issue #7638）；支持自定义 NFShard/soft与timeo/retrans（Issue #6655）；修复 share-manager 死锁与 RWX 卸载 I/O 错误（Issue #7183、#6829）；
• CSI 与组件升级：CSI 组件升级到最新补丁版本（Issue #7384、#6916）；csi-snapshotter 升级以缓解快速重试 bug（Issue #6506）；支持在 Helm Chart 中为 StorageClass 设置挂载选项（Issue #7351）与日志级别（Issue #3655）；
• 监控可观测性：磁盘状态 Prometheus 指标（Issue #6858）；卷指标增加 PVC 命名空间与名称（Issue #7077、#5297）；快照指标包含大小与类型（系统/用户，Issue #5869）；Helm Chart 支持部署 Prometheus ServiceMonitor（Issue #7041）；
• 数据面与恢复：意外只读的 RWO 卷自动重挂载为读写（Issue #6386）；upgradeVersionCheck决定版本升级强制策略（Issue #7539）；环境检查脚本识别 iscsid.socket（Issue #5380）；default-data-path支持块设备（Issue #7234）。

重点 Bug 修复（Bug Fixes 精选）

• 引擎与实例管理器：引擎进程被杀后卷无法重新挂载（Issue #7751）；崩溃后卷卡在 Unknown 状态（Issue #6699）；实例管理器内存泄漏（Issue #6481）；v2 卷在spdk_tgt异常下的 attach/detach 循环（Issue #7579）；
• 加密与安全：mTLS 下卷无法挂载（Issue #7040）；加密卷挂载失败（Issue #7033、#7045）；加密在 Amazon Linux 2 上不生效（Issue #5944）；
• 备份/恢复：错误备份导致 v2 卷卡死（Issue #7575）；恢复期间删除备份导致卷 faulted（Issue #7584）；备份目标未设置时无法删除 volumesnapshot（Issue #4979）；备份执行遇错仍返回 Completed（Issue #4255）；
• 调度与副本：创建卷时找不到具备默认引擎镜像的节点（Issue #7413）；单节点磁盘亲和性相关修复（Issue #3823 特性落地）；副本调度失败信息增强（Issue #6461）；
• 升级兼容：v1.5.x 引擎卷在 v1.6.0-rc1 下工作异常（Issue #7642）；升级后副本不重建（Issue #7631、#7555）；
• UI：批量删除对话框可读性（Issue #4080）、窗口缩放事件处理（Issue #7036）等。

（完整列表以 CHANGELOG/CHANGELOG-1.6.0.md 的 Bug Fixes 一节为准。）

杂项与工程化

• CRD 演进：将 volume/engine/replica CRD 中的engineImage字段替换为image（Issue #6647、#6685）；移除不必要的 Kubernetes 版本检查（Issue #7601）；最低支持的 Kubernetes 版本上探（Issue #7224）；
• 基础镜像：Longhorn 组件基础镜像更新为 BCI 15.5（Issue #6206）；
• 支持包：support-bundle-kit 升级至 v0.0.33（Issue #7277），并将/var/log/messages纳入 syslog 采集（Issue #6544）；
• 日志：统一日志附带 module/method/function/line 等静态信息（Issue #5509）；修复设置同步失败日志刷屏（Issue #7654）；
• 部署清单 deploy/longhorn.yaml 在此版本中保持与 Chart 同步（对应 Issue #6428 的修复）。

社区与贡献

v1.6.0 由 27 位贡献者共同完成，包括 @derekbit、@yangchiu、@PhanLe1010、@mantissahz、@ejweber、@james-munson、@c3y1huang、@chriscchien、@roger-ryao、@shuo-wu、@ChanYiLin、@smallteeths、@votdev 等，以及社区贡献者 @ArthurVardevanyan（OKD 支持）、@sfackler（mTLS 修复）、@m-ildefons、@antoninferrand 等。完整名单见发布说明末尾的 Contributors 一节。

升级与运维建议

1. 检查版本门槛：升级前确认 Kubernetes ≥ v1.21，且当前 Longhorn 版本在受支持的升级路径内。
2. 关注废弃项：升级前阅读 "Deprecation & Incompatibilities" 与 "Post-Release Known Issues" 两节，尤其是 CRD 字段变更（engineImage→image）与实例管理器行为变化。
3. 按需启用新特性：V2 数据引擎、快照空间管理等均为新增能力，建议先在测试环境验证：启用v2DataEngine设置、为重要卷配置snapshotMaxCount/snapshotMaxSize、评估节点维护期间启用新的 drain policy 的影响。
4. GitOps 场景：使用 Argo CD 等方案时，按需关闭preUpgradeChecker.jobEnabled，避免预升级 hook 阻塞持续交付。
5. 备份 Backing Image：跨集群迁移带 Backing Image 的卷时，可直接依赖 v1.6.0 的自动备份/恢复能力，无需手工重建镜像。

• 云原生
• 存储
• 高可用
• 容器编排