Longhorn：给 K8s 加分布式块存储（不依赖云）

起因

K8s pod 用 PV：

• 云上：EBS / GCE PD / Azure Disk
• 自托管：hostPath（坏到没救）/ NFS（慢 + 没 snapshot）/ Ceph（运维炸）

需要"PVC 跑 stateful 应用"但又不在云上：

• 边缘 cluster
• 自建机房
• 本地 dev / 小 prod

Longhorn（Rancher / SUSE，CNCF）：K8s-native distributed block storage。
轻量 + 部署简单 + UI 友好。

装

helm install longhorn longhorn/longhorn \
    -n longhorn-system --create-namespace

每 node 自动跑 longhorn-manager pod + 用本地 disk 做 storage。

StorageClass 自动创建：

kubectl get sc
longhorn (default)   driver.longhorn.io   Delete   Immediate

用

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  storageClassName: longhorn
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi

spec:
  containers:
    - volumeMounts:
        - mountPath: /data
          name: data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data

挂载即用。Longhorn 在背后：

• 找有空间的 node 创建 volume
• replica 跨 3 node 同步（默认）
• pod schedule 到任意 node，volume 自动跟随

replica 跨 node

3 replica = 3 个 node 各存一份。
任一 node 挂 → 还有 2 副本，pod 在别 node 重启接着用。

snapshot + backup

# 创建 snapshot
apiVersion: longhorn.io/v1beta2
kind: Snapshot
metadata:
  name: snap-1
  namespace: longhorn-system
spec:
  volume: pvc-xxx

snapshot 是 volume 状态 point-in-time copy（本地，秒级）。

backup 是把 snapshot 上传到 S3 / NFS：

# Longhorn UI 配 S3 backup target
# 或者 CR

apiVersion: longhorn.io/v1beta2
kind: Backup
metadata:
  name: backup-1
spec:
  snapshotName: snap-1

恢复：从 backup 创建新 volume → PVC → pod 挂载。
跨集群迁移：cluster A backup → cluster B restore。

recurring job

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: daily-backup
spec:
  cron: "0 2 * * *"
  task: backup
  retain: 7
  groups: [default]

每天 2:00 自动 snapshot + backup，保留 7 份。

UI

kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
# http://localhost:8080

UI 看 volume / replica 状态 / backup / settings。
比 yaml 直观，运维友好。

性能

3-node cluster + NVMe disk + Longhorn 3 replica：

• random read 4k: ~50k IOPS
• random write 4k: ~15k IOPS
• sequential write: ~600 MB/s

跟单盘比有 30-50% overhead（network + replication）。
跟 EBS gp3 接近。够多数 workload。

与 Ceph (Rook) 对比

中小 cluster + 主要 block storage → Longhorn。
大 scale + 需 object / file → Ceph。

RWX (多 pod 同时读写)

accessModes: [ReadWriteMany]    # RWX

Longhorn RWX 用内置 NFS share volume 之上。
性能比 RWO 弱，但能用。

ReadWriteOncePod (K8s 1.27+) 是更严格 RWO。

与 hostPath

volumes:
  - name: data
    hostPath:
      path: /mnt/data

简单粗暴 但：

• pod schedule 必须在那 node（pin）
• 没备份 / 副本
• 移走 node 数据丢

dev 还行，prod 别用。

与 NFS

NFS provisioner：装个 NFS server + provisioner，PVC 在 NFS 上分 volume。

小数据 / RWX 重 → NFS 简单。
HA / 性能 → Longhorn。

真实 case

某客户私有云 cluster：

• 5 node bare metal
• 每 node 1 TB NVMe
• Longhorn 3 replica
• PG / Redis / app data 全 Longhorn

效果：

• Postgres 跑得跟单盘差 30%（可接受）
• 任一 node down → pod 自动迁移 + volume 跟随
• 每天自动 backup 到 S3
• UI 让 ops 直观看 storage 状态

挑战：

• 网络 IO 飙（replica sync 占带宽）→ 10 GbE 网卡
• node 重启时 replica rebuild 几小时

监控

Prometheus metrics：

• longhorn_volume_actual_size_bytes
• longhorn_volume_state
• longhorn_node_status

Grafana dashboard 官方提供。

alert 关键：

• replica 不足（应 3 实际 < 3）
• volume detached
• node down
• backup 失败

与 cloud volume 对比

在云上没必要 Longhorn（用 EBS）。
自托管 / 混合云 → Longhorn 填补"K8s storage" 空白。

踩过的坑

1. 每 node 一份 replica = 数据膨胀：3 replica 占 3x 空间。
   规划存储 capacity * 3。

2. kernel module：Longhorn 用 iSCSI 协议。某些 minimal OS 没装
   open-iscsi → 启不来。

3. disk fill 90%：默认 reserve 30% 给系统。改 Storage Minimal Available Percentage。

4. node drain 慢：drain 时 volume detach + reattach 慢（几十秒）。
   maintenance window 留时间。

5. backup target 配错：S3 endpoint / credential 错 → 备份失败但
   UI 显示成功初看。定期手 restore 验证。