1. 为什么需要Longhorn分布式存储？
在Kubernetes集群中部署有状态应用时，持久化存储一直是运维人员面临的重大挑战。传统解决方案如NFS、iSCSI等存在单点故障风险，而云厂商提供的块存储服务又面临跨可用区访问延迟高、成本昂贵等问题。这正是Longhorn诞生的背景——一个轻量级、云原生的分布式块存储系统。
我曾在生产环境中同时管理过200+个有状态Pod，深刻体会到原生Kubernetes存储方案的局限性。当某个节点宕机时，挂载在该节点上的PVC（持久卷声明）往往无法自动迁移到健康节点，导致服务中断。而Longhorn通过以下机制彻底改变了这种局面：
- 数据分片复制：每个卷的数据被自动切分为多个分片（默认1MB大小），这些分片会被复制到不同节点（默认为3副本），即使单个节点故障也不会影响数据可用性
- 分布式架构：没有中心化的存储控制器，所有节点平等参与数据存储和转发，避免单点瓶颈
- 增量快照：基于写时复制（COW）技术实现秒级快照，对性能影响极小（实测快照操作期间IOPS下降不超过5%）
2. 部署前的关键准备工作
2.1 硬件与系统要求
根据Rancher官方文档和我们的实测数据，建议生产环境满足以下配置：
| 组件 | 最低要求 | 推荐配置 | 说明 |
|---|---|---|---|
| CPU | 2核 | 4核+ | 每个卷副本需要约0.1核常驻CPU |
| 内存 | 4GB | 8GB+ | 每TB存储需约1GB内存缓存 |
| 磁盘 | 100GB | 1TB+ SSD | 必须使用直连磁盘（非网络存储） |
| 网络 | 1Gbps | 10Gbps+ | 节点间同步流量较大 |
重要提示：务必禁用所有节点的swap空间，否则可能导致数据同步异常。可通过
sudo swapoff -a && sudo sed -i '/swap/s/^/#/' /etc/fstab永久禁用。
2.2 Kubernetes集群配置
Longhorn对集群有以下特殊要求：
必须安装open-iscsi：
# Ubuntu/Debian sudo apt-get install open-iscsi # CentOS/RHEL sudo yum install iscsi-initiator-utils内核模块加载检查：
lsmod | grep -E 'iscsi_tcp|libiscsi'推荐配置kubelet参数：
# /var/lib/kubelet/config.yaml cpuManagerPolicy: static topologyManagerPolicy: best-effort
3. 分步部署Longhorn存储系统
3.1 使用Helm安装Operator
我们推荐使用Helm 3进行安装，便于后续升级管理：
helm repo add longhorn https://charts.longhorn.io helm repo update helm install longhorn longhorn/longhorn \ --namespace longhorn-system \ --create-namespace \ --set persistence.defaultClass=true \ --set defaultSettings.replicaCount=3关键参数说明：
persistence.defaultClass=true：设为默认StorageClassdefaultSettings.replicaCount=3：设置默认副本数
3.2 节点标签与调度配置
为优化存储性能，建议为存储节点添加专用标签：
kubectl label nodes <node-name> node.longhorn.io/create-default-disk=true然后配置磁盘选择策略：
# longhorn-disk-config.yaml defaultDataPath: /var/lib/longhorn disks: default-disk: path: /mnt/longhorn allowScheduling: true通过Longhorn UI（默认通过NodePort 30880暴露）应用此配置。
4. 高级配置与性能调优
4.1 网络调优参数
对于高性能场景，建议调整以下参数：
# longhorn-settings.yaml backupTarget: "" backupTargetCredentialSecret: "" createDefaultDiskLabeledNodes: true defaultDataPath: /var/lib/longhorn defaultReplicaCount: 3 guaranteedEngineCPU: "0.25" # 每个引擎预留的CPU核数4.2 存储卷参数详解
创建PVC时可通过annotations进行精细控制：
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mysql-pvc annotations: longhorn.io/replica-count: "3" longhorn.io/storage-class: "longhorn-ssd" spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi5. 生产环境运维实战技巧
5.1 监控与告警配置
集成Prometheus监控的推荐配置：
# values.yaml metrics: enabled: true serviceMonitor: enabled: true additionalLabels: release: prometheus-operator关键监控指标告警规则示例：
volume_actual_size > volume_capacity * 0.8：存储空间即将耗尽volume_robustness != healthy：卷状态异常
5.2 灾难恢复方案
定期快照策略：
apiVersion: longhorn.io/v1beta1 kind: Volume metadata: name: pvc-01 spec: recurringJobs: - name: backup task: "backup" cron: "0 0 * * *" retain: 30跨集群恢复流程：
# 从备份恢复 kubectl apply -f backup-volume.yaml # 挂载到新PVC kubectl create -f restore-pvc.yaml
6. 常见故障排查手册
6.1 卷无法挂载
典型错误现象：
Warning FailedAttachVolume 3m attachdetach-controller AttachVolume.Attach failed for volume "pvc-01" : rpc error: code = Internal desc = Failed to attach volume pvc-01: exit status 32排查步骤：
- 检查iscsid服务状态：
systemctl status iscsid - 验证节点网络连通性：
ping <peer-node-ip> - 检查Longhorn管理器日志：
kubectl logs -n longhorn-system -l app=longhorn-manager
6.2 副本同步失败
性能优化建议：
- 调整同步线程数：
defaultSettings.concurrentReplicaRebuildPerNodeLimit=5 - 启用压缩传输：
defaultSettings.replicaReplenishmentWaitInterval=600
我在实际运维中发现，当集群节点超过50个时，建议将guaranteedEngineCPU提高到0.5核，否则可能出现引擎进程CPU饥饿导致IO延迟飙升的情况。同时，对于数据库类应用，设置disableReplicaRebuild=true可以避免后台重建影响前端性能。
