Longhorn 面试题
30 道题- 分类
- Kubernetes
- 子分类
- csi
- 题目数
- 30 道
1 Longhorn 的架构由哪些核心组件构成?
答案:
Longhorn 采用微服务架构,核心组件包括 Longhorn Manager、Longhorn Engine、Longhorn Instance Manager 和 Longhorn UI。
- Longhorn Manager:以 Deployment 方式运行,负责管理 Longhorn 系统资源(Volume、Replica、Engine、Backup 等 CRD),协调卷的创建、挂载、备份和恢复操作。
- Longhorn Engine:每个卷对应一个 Engine 实例,负责 I/O 处理,包括 Replica 读写分发、Snapshot 管理、数据去重。Engine 是控制面和数据面的核心。
- Longhorn Instance Manager:以 DaemonSet 方式运行在每个节点上,负责管理本地 Replica 实例的生命周期,包括启动、停止、健康检查,以及 Replica 与 Engine 之间的数据通道维护。
- Longhorn UI:Web 管理界面,提供卷管理、备份恢复、节点磁盘管理、系统监控等功能。
| 组件 | 职责 | 部署方式 |
|---|---|---|
| Longhorn Manager | CRD 管理、卷协调、调度 | Deployment(2 副本) |
| Longhorn Engine | 卷 I/O 处理、Replica 分发 | InstanceManager(按卷) |
| Instance Manager | Replica/Engine 进程管理 | DaemonSet(每节点) |
| Longhorn UI | Web 管理界面 | Deployment(可选) |
| BackingImage Manager | 基础镜像管理 | DaemonSet(每节点) |
2 Longhorn Engine 如何处理读写 I/O 请求?
答案:
Longhorn Engine 采用主动-被动(Active-Passive)的 Replica 架构,Engine 是唯一的 I/O 入口。
写入流程:
写入请求 → Engine → 并行写入所有 Replica(同步复制)
→ 每个 Replica 写入本地存储
→ 所有 Replica 返回确认 → Engine 返回写入成功
读取流程:
读取请求 → Engine → 从任意一个 Replica 读取(Round-Robin 负载均衡)
→ 读到的数据返回给上层
关键机制:
- 无锁写入:Engine 通过 IO Serialization 确保写入顺序,Replica 侧无需锁机制
- 写入全部确认:只有所有 Replica 都写入成功才返回成功,保证强一致性
- 故障降级:Replica 故障或超时时自动从 Replica 集合中移除,降级为 degraded 模式
- 重建恢复:故障 Replica 恢复后自动增量重建,通过 Engine 的 Snapshot 差异同步
数据路径优化:
- 使用 SPDK(Storage Performance Development Kit)加速块设备 I/O
- Engine 使用事件驱动模型(类似 Node.js 的事件循环),非阻塞处理 I/O 请求
3 Longhorn 如何实现高可用存储?
答案:
Longhorn 通过多 Replica、Engine 高可用、自动重建和故障转移实现存储高可用。
多 Replica(默认 3 副本):
- 每个卷的数据在多个节点上维护 3 份完整 Replica
- Replica 分布在不同节点的不同磁盘上,故障域隔离
- 任意一个 Replica 故障不影响数据可用性
Engine HA:
- Engine 实例运行在与 Replica 不同的节点上(通过反亲和性保证)
- Engine 故障时,Instance Manager 自动重建 Engine 进程
- 卷的挂载状态通过 Longhorn CRD 持久化,Engine 重建后自动恢复 I/O
自动重建:
# 卷重建策略
replicaAutoBalance: "best-effort" # 自动平衡 Replica 分布
replicaDiskSoftAntiAffinity: "ignore" # 软反亲和性
replicaZoneSoftAntiAffinity: "ignore" # 跨可用区
故障恢复流程:
节点故障 → Longhorn Manager 检测到 Replica 不可达(~30秒超时)
→ 标记 Replica 为 Failed → 自动在其他健康节点新建 Replica
→ 新 Replica 从 Engine 处增量同步数据 → 恢复为 Healthy 状态
SLA(Service Level Agreement,服务等级协议):
| 场景 | RPO(Recovery Point Objective) | RTO(Recovery Time Objective) |
|---|---|---|
| Engine 故障 | 0(无数据丢失) | < 30 秒 |
| 单节点故障 | 0 | < 2 分钟 |
| 文件系统损坏 | 取决于 Snapshot 频率 | 取决于卷大小 |
4 Longhorn 的 Replica 同步机制是怎样的?
答案:
Longhorn 使用基于 Snapshot 的增量同步机制实现 Replica 之间的数据一致性。
同步流程:
- Engine 接收写入请求,将数据写入所有 Healthy Replica
- 默认使用同步复制,所有 Replica 确认后才返回成功
- 写入过程中自动创建增量 Snapshot 记录数据差异
Replica 重建(Rebuilding):
新 Replica 加入 → Engine 创建 Full Snapshot
→ 新 Replica 从 Engine 全量同步数据 → 同步完成后转为 Healthy
→ 后续写入按正常同步路径进行
重建触发条件:
- Replica 所在节点宕机后恢复
- Replica 数据损坏被标记为 Failed
- 手动添加新的 Replica
- Replica 自动平衡迁移
增量重建(Incremental Rebuilding):
- 全量同步后,Engine 只发送自 Full Snapshot 以来的数据变更
- 通过 Snapshot 链(Chain)追踪写入差异
- 极大减少重建时间和网络带宽消耗
同步一致性保障:
| 机制 | 说明 |
|---|---|
| Sync Agent | 每个 Replica 自带的同步代理,管理与 Engine 的数据通道 |
| 写入屏障(Write Barrier) | 重建期间阻止对重建 Replica 的写入 |
| CRC 校验 | 数据块级别校验,检测传输损坏 |
| 重试机制 | 超时和校验失败自动重试 |
5 Longhorn 如何处理节点故障时的数据恢复?
答案:
Longhorn 的处理依赖于 Engine 多 Replica 和 Instance Manager 的健康检测。
故障检测:
- Instance Manager 通过 gRPC 健康检查 Engine 和 Replica 状态(每 5 秒)
- Longhorn Manager 通过 Kubernetes Node 状态监控节点健康
- 默认超时时间 30 秒后标记故障
节点完全宕机:
节点宕机 → Kubernetes Node 状态 NotReady(约40秒)
→ Longhorn Manager 标记该节点上的所有 Replica 为 Unknown
→ 等待约 30 秒(设置 allowRecoveryWhileDetached: true)后标记 Failed
→ 创建新 Replica 在其他节点重建数据
节点恢复(重新加入集群):
节点恢复 → Instance Manager 重新启动
→ 检查本地 Replica 完整性 → 清理过期 Replica
→ Replica 状态从 Failed 转为 Healthy(数据在重建时已恢复)
→ Longhorn Manager 自动平衡删除多余的 Healthy Replica
Engine 故障处理:
Engine 进程崩溃 → Instance Manager 检测到进程退出
→ 自动启动新 Engine 进程(秒级恢复)
→ 新 Engine 加载卷配置和 Replica 映射
→ 恢复 I/O 请求处理
→ 客户端短暂 I/O 挂起后恢复(取决于客户端超时设置)
数据恢复策略:
| 场景 | 操作 |
|---|---|
| 1 个 Replica 故障 | 自动重建,无中断 |
| 2 个 Replica 故障 | 卷降级为 Degraded,只读或出错 |
| Engine 崩溃 | 进程级自动重启 |
| 数据损坏 | 通过 Snapshot 回滚恢复 |
6 Longhorn 的 Backup 和 Snapshot 有什么区别?
答案:
Snapshot 是本地快照,Backup 是远程备份,两者在存储位置、生命周期和用途上有根本区别。
| 维度 | Snapshot(快照) | Backup(备份) |
|---|---|---|
| 存储位置 | 本地(与 Replica 同磁盘) | 远程(S3/NFS/MinIO) |
| 创建速度 | 秒级(差量元数据) | 取决于数据量 |
| 空间占用 | 差量存储(仅变更块) | 压缩后存储 |
| 数据持久性 | 受本地磁盘故障影响 | 独立于集群存储 |
| 用途 | 快速回滚、Replica 重建 | 灾难恢复、集群迁移 |
| 保留策略 | 手动管理 | Recurring Job 自动清理 |
| 依赖关系 | 依赖 Replica 存活 | 独立存在 |
Snapshot 机制:
- 基于 Copy-on-Write(CoW),创建 Snapshot 时只记录元数据指针
- 写入新数据时,原数据块被复制到 Snapshot 中(Redirect-on-Write)
- Snapshot 链:活跃数据 → Snapshot-1 → Snapshot-2 → … → 基础镜像
Backup 机制:
- 从 Snapshot 创建,读取差量数据后上传到远程存储
- 增量备份:仅上传自上次 Backup 以来的变更块
- 支持加密(AES256)和压缩(gzip)
关系示例:
Backup (S3 bucket) ← 基于 Snapshot-3
↑
活跃数据 ─→ Snapshot-1 → Snapshot-2 → Snapshot-3 (本地)
7 Longhorn 如何保障数据一致性?
答案:
Longhorn 从写入确认、数据校验和 I/O 屏障三个层面保障数据一致性。
写入确认:
- 同步复制:Engine 需等待所有 Healthy Replica 写入确认后才返回成功
- 如果任一个 Replica 写入失败,Engine 返回错误并标记该 Replica 为 Error
- 客户端(CSI Driver / iSCSI)收到写入成功即表示所有 Replica 已持久化
数据校验:
- CRC-32C 校验:每个 4KB 数据块在写入时计算校验和
- 定期(默认每 60 秒)进行完整数据校验(Full Checksum Scan)
- Replica 重建时进行块级别 CRC 校验,保证重建数据正确性
I/O 屏障(Barrier):
- 在以下场景设置屏障,暂停写入保证一致性:
- Replica 重建期间
- Snapshot 创建过程中
- Backup 操作时
- 屏障期间新写入进入队列,屏障解除后按序执行
Journal(日志)机制:
- 关键元数据操作记录到 WAL(Write-Ahead Log,预写日志)
- Replica 故障恢复后先回放 WAL 再处理新请求
- 确保元数据操作原子性
8 Longhorn 的 CSI 驱动是如何工作的?
答案:
Longhorn 实现了标准的 CSI(Container Storage Interface)规范,提供持久化存储卷的生命周期管理。
CSI 组件:
| CSI 组件 | 功能 | 部署方式 |
|---|---|---|
| CSI Driver(csi-provisioner) | 处理卷的创建和删除 | Deployment |
| CSI Attacher | 处理卷的挂载和卸载 | Deployment |
| CSI Resizer | 处理卷的扩容 | Deployment |
| CSI Snapshotter | 处理快照的创建和恢复 | Deployment |
| Node Driver Registrar | 注册 CSI Driver 到 kubelet | DaemonSet(每节点) |
| Longhorn CSI Plugin | 实际的 CSI 接口实现 | DaemonSet(每节点) |
工作流程(创建和挂载卷):
1. PVC 创建 → CSI Provisioner 监听到请求
2. CSI Provisioner 调用 Longhorn Manager API 创建 Volume CR
3. Longhorn Manager 调度 Replica 到合适节点
4. Pod 调度 → CSI Attacher 调用 Longhorn 挂载 API
5. Engine 启动 → Replica 连接就绪 → 块设备出现在节点
6. kubelet 对块设备做格式化 → 挂载到 Pod 指定路径
StorageClass 配置:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-fast
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
numberOfReplicas: "3"
staleReplicaTimeout: "30"
fromBackup: ""
fsType: "ext4"
dataLocality: "best-effort"
diskSelector: "ssd,fast"
nodeSelector: "storage-node"
recurringJobs: '[{"name":"snap","task":"snapshot","cron":"*/5 * * * *"}]'
9 Longhorn 的 ReadWriteMany(RWX)是如何实现的?
答案:
Longhorn 通过 NFS Server 和 Share Manager 组件实现 RWX(ReadWriteMany)卷。
RWX 架构:
- Share Manager Pod:每个 RWX 卷对应一个 Share Manager Pod
- Share Manager 内部运行 NFS Server(nfs-ganesha)
- Longhorn 块卷被 Share Manager 挂载为本地块设备
- 多个 Pod 通过 NFS 协议同时访问同一个 RWX 卷
工作流程:
多个 Pod 挂载 PVC(accessModes: ReadWriteMany)
→ kubelet 调用 CSI 驱动 → CSI 检测到 RWX 请求
→ Longhorn Manager 创建 Share Manager Pod
→ Share Manager 挂载 Longhorn 块卷作为本地存储
→ Share Manager 启动 NFS Server 导出该卷
→ 各 Pod 通过 NFS Client 挂载到 Pod 内路径
配置示例:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-data
spec:
accessModes:
- ReadWriteMany
storageClassName: longhorn
resources:
requests:
storage: 10Gi
RWX 性能考量:
- NFS 协议增加额外网络延迟(约 0.1-0.5ms)
- 并发写入时 NFS 的缓存一致性协议影响性能
- 适合读多写少场景(如配置共享、静态内容分发)
- 写密集型场景建议使用 RWO(ReadWriteOnce)
Share Manager 高可用:
- Share Manager 故障时自动重建
- 使用 NFS Grace Period(优雅期)确保客户端连接恢复
- 重建期间 NFS 客户端 I/O 短暂阻塞(默认 90 秒超时)
10 Longhorn 如何处理 Stale Replica?
答案:
Stale Replica(过期副本)是指数据版本落后于 Engine 的 Replica,通常因节点离线导致。
Stale Replica 产生场景:
- 节点宕机或网络隔离期间,Engine 继续写入,该节点上的 Replica 数据版本落后
- 节点恢复后,该 Replica 变为 Stale 状态
处理策略(staleReplicaTimeout):
# StorageClass 参数
parameters:
staleReplicaTimeout: "30" # 默认 30 分钟
- Stale Replica 在
staleReplicaTimeout超时内被视为可用 - 超时后 Replica 被标记为 Failed,触发自动重建
- 超时时间内节点恢复,Replica 自动从 Engine 处同步差异数据
Stale Replica 清理:
# 手动清理 Stale Replica
kubectl -n longhorn-system get replicas | grep stale
kubectl -n longhorn-system delete replica <replica-name>
# 或通过 UI 清理
# Longhorn UI → Node → Replica → Remove
重建触发:
Stale Replica 超时 → Longhorn Manager 标记为 Failed
→ 检查可用节点和磁盘 → 在其他节点创建新 Replica
→ 新 Replica 从 Engine 同步数据 → 转为 Healthy
→ 原 Stale Replica 被清理删除
11 Longhorn 的 Data Locality 策略有哪些?
答案:
Data Locality(数据本地性)控制卷的 Replica 是否与使用该卷的 Pod 运行在同一节点。
策略类型:
| 策略 | 值 | 行为 |
|---|---|---|
| Disabled | disabled | Replica 分布在任意节点,Pod 调度不受影响 |
| Best-effort | best-effort | 优先在 Pod 所在节点放置一个 Replica,不可用时忽略 |
| Strict-local | strict-local | 强制所有 Replica 在 Pod 所在节点,否则 Pod 无法调度 |
配置示例:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-local
provisioner: driver.longhorn.io
parameters:
dataLocality: "strict-local"
numberOfReplicas: "3" # 节点必须有 3 个磁盘
选型考量:
- Disabled:通用场景,数据高可用优先,容忍节点故障
- Best-effort:权衡性能和可用性,降低跨节点 I/O 延迟
- Strict-local:高性能敏感场景(数据库),但牺牲容错能力
性能影响:
数据本地性 vs 读取延迟
Disabled: Engine → 跨节点网络 → Replica(额外 0.1-0.5ms)
Best-effort: Engine → 本地 Replica(0.01-0.05ms)
Strict-local: Engine → 本地 Replica(0.01-0.05ms)
12 Longhorn 如何实现卷的在线扩容?
答案:
Longhorn 支持在不中断 Pod 运行的情况下在线扩展卷大小。
扩容流程:
- 修改 PVC 的存储请求大小
- CSI Resizer 监听到 PVC 变更
- 调用 Longhorn 的 ExpandVolume API
- Longhorn Manager 扩展 Engine 和所有 Replica 的块设备大小
- 文件系统在线扩展(xfs_growfs 或 resize2fs)
配置要求:
# StorageClass 必须允许扩容
allowVolumeExpansion: true
执行示例:
# 修改 PVC 大小
kubectl edit pvc my-data
# spec.resources.requests.storage: 10Gi → 20Gi
# 检查扩容状态
kubectl get volumes.longhorn.io my-data -o yaml
# status.conditions 显示 ExpandInProgress → ExpandCompleted
扩容限制:
- 支持 ext4 和 xfs 文件系统
- 只支持增大,不支持缩小
- 文件系统预留空间(ext4 5%、xfs 通过调整)不影响扩容操作
- 扩容后新空间在 Pod 内立即可见
13 Longhorn 的 Backup Target 支持哪些存储后端?
答案:
Longhorn 的 Backup Target 支持 NFS 和 S3 兼容对象存储两类后端。
NFS:
# Backup Target 配置
backupTarget:
endpoint: nfs://192.168.1.100:/backups/longhorn
credentialSecret: "" # NFS 不需要密钥
S3 Compatible:
# 创建 Secret
apiVersion: v1
kind: Secret
metadata:
name: s3-secret
namespace: longhorn-system
stringData:
AWS_ACCESS_KEY_ID: "minioadmin"
AWS_SECRET_ACCESS_KEY: "minioadmin"
AWS_ENDPOINTS: "https://minio.example.com"
AWS_REGION: "us-east-1"
支持的 S3 实现:
| 后端 | 类型 | 推荐场景 |
|---|---|---|
| AWS S3 | 公有云 | 生产环境 |
| MinIO | 自建 | 私有云 / 开发环境 |
| Ceph RGW | 自建 | 已有 Ceph 环境 |
| Alibaba Cloud OSS | 公有云 | 阿里云 |
| Tencent COS | 公有云 | 腾讯云 |
| Backblaze B2 | 公有云 | 低成本归档 |
Backup Target 检查:
# 通过 Longhorn CLI 检查
kubectl -n longhorn-system exec -it longhorn-manager-xxx -- longhorn-manager backup list
# 或检查卷的 Backup Status
kubectl get volumes.longhorn.io my-volume -o jsonpath='{.status.backupStatus}'
14 Longhorn 如何处理卷的灾备恢复?
答案:
Longhorn 通过 Backup 恢复和 Disaster Recovery Volume(DR Volume)实现灾备。
Backup 恢复(手动):
# 从 Backup 恢复为新的卷
kubectl create -f - <<EOF
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: restored-volume
namespace: longhorn-system
spec:
fromBackup: "s3://bucket-name/backup-bundle/volume-name/?backup=backup-xxx"
numberOfReplicas: 3
size: "10737418240" # 10Gi bytes
EOF
DR Volume(持续同步恢复):
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: dr-volume
namespace: longhorn-system
spec:
fromBackup: "s3://bucket/backup-url"
numberOfReplicas: 3
standby: true # 灾难恢复模式
revisionCounterDisabled: true # 灾备不维护修订计数器
DR Volume 工作流程:
主集群定期 Backup → 灾备集群的 DR Volume 自动检测新 Backup
→ 增量同步 Backup 数据 → DR Volume 保持 Standby 状态
→ 主集群故障 → 激活 DR Volume(standby: false → 读写模式)
→ 应用切换到灾备集群
RPO 控制:
- Backup 频率决定 RPO(如每 5 分钟 Backup → RPO ≤ 5 分钟)
- 增量 Backup 在网络带宽充足时可做到秒级 RPO
15 Longhorn 的 Maintenance Mode 是什么?有什么用?
答案:
Maintenance Mode(维护模式)是 Longhorn 卷的只读模式,用于安全执行磁盘维护、数据检查和快照操作。
进入维护模式:
# 通过 UI 或 API 将卷设为维护模式
kubectl -n longhorn-system edit volume my-volume
# spec.disableFrontend: true # 启用维护模式
维护模式下的操作:
- 安全检查 Replica 数据完整性
- 手动清理或删除过时的 Snapshot
- 在 Replica 级别执行文件系统检查(fsck)
- 备份 Replica 原始数据
- 迁移 Replica 到新的磁盘或节点
维护模式行为:
| 状态 | 读写能力 | Engine 状态 | Replica 访问 |
|---|---|---|---|
| 正常 | 读写 | 活跃 | 全部连接 |
| 维护模式 | 不可用 | 暂停 | 仅不参与 I/O |
| 分离(Detached) | 不可用 | 停止 | 不连接 |
使用场景:
磁盘需要更换或升级 → 将关联的卷设为维护模式
→ 检查数据完整性 → 执行维护操作
→ 退出维护模式 → 恢复正常访问
16 Longhorn 的 Orphaned Replica 自动清理机制是怎样的?
答案:
Orphaned Replica(孤儿副本)是指没有关联卷的残余 Replica 数据,Longhorn 提供了自动发现和清理机制。
Orphan 产生场景:
- 卷被删除但 Replica 清理不完全
- Instance Manager 重启导致 Replica 进程中断
- 磁盘故障后的残余数据
Orphan 检测:
# 查看 Orphaned Replica
kubectl -n longhorn-system get orphans.longhorn.io
# NAME TYPE
# orphan-20240101-abcdef replica
自动清理策略:
# 全局配置
orphan:
autoCleanup: true # 自动清理开关
cleanupIntervalSeconds: 3600 # 清理间隔(秒)
手动清理:
# 删除单个 orphan
kubectl -n longhorn-system delete orphans.longhorn.io orphan-20240101-abcdef
# 批量清理
kubectl -n longhorn-system delete orphans --all
清理流程:
Longhorn Manager 定期扫描各节点磁盘
→ 发现无关联卷的 Replica 数据 → 创建 Orphan CR
→ AutoCleanup 启用 → 验证 Orphan 无需保留 → 删除 Orphan 数据和 CR
→ 释放磁盘空间
17 Longhorn 如何处理磁盘压力(Disk Pressure)?
答案:
Longhorn 通过磁盘压力检测和 Eviction(驱逐)机制处理节点磁盘空间不足的问题。
磁盘压力等级:
| 等级 | 条件 | 行为 |
|---|---|---|
| Normal | 使用率 < 90% | 正常调度 |
| Warning | 使用率 90-95% | 不再调度新 Replica |
| Critical | 使用率 > 95% | 触发 Eviction,迁移所有 Replica |
磁盘监控配置:
# 全局设置
disk:
storageReservedPercentage: 30 # 保留空间百分比
storageOverProvisioningPercentage: 200 # 超分比例
defaultDiskSoftAntiAffinity: false
磁盘驱逐(Eviction):
# 通过 UI 触发磁盘驱逐
# Longhorn UI → Node → Disks → 选择磁盘 → Evacuate
# 或通过 API
kubectl -n longhorn-system get disks.longhorn.io
kubectl -n longhorn-system delete disks.longhorn.io <disk-name>
Eviction 流程:
磁盘 Critical 或手动触发 Eviction
→ Longhorn Manager 标记该磁盘上的 Replica 为 Eviction
→ 检查其他可用节点和磁盘 → 创建新 Replica
→ 数据同步完成后自动清除原 Replica
→ 磁盘压力解除
18 Longhorn 如何与 Prometheus 集成进行监控告警?
答案:
Longhorn 原生暴露 Prometheus 格式的指标,通过 ServiceMonitor 自动接入监控系统。
指标暴露:
# 启用指标
prometheus:
enabled: true
serviceMonitor:
enabled: true
关键指标:
| 指标名称 | 类型 | 说明 |
|---|---|---|
longhorn_volume_status | Gauge | 卷状态(0=Healthy, 1=Degraded, 2=Fault) |
longhorn_volume_capacity_bytes | Gauge | 卷容量 |
longhorn_volume_actual_size_bytes | Gauge | 卷实际占用 |
longhorn_node_status | Gauge | 节点状态 |
longhorn_disk_storage_available_bytes | Gauge | 磁盘可用空间 |
longhorn_backup_volume_last_sync | Gauge | 最后备份时间戳 |
longhorn_volume_replica_count | Gauge | 卷的 Replica 数量 |
告警规则示例:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: longhorn-alerts
namespace: monitoring
spec:
groups:
- name: longhorn
rules:
- alert: VolumeDegraded
expr: longhorn_volume_status{status="degraded"} > 0
for: 5m
annotations:
summary: "卷 XQOPEN $labels.volume XQCLOSE 降级运行"
- alert: DiskSpaceCritical
expr: longhorn_disk_storage_available_bytes / longhorn_disk_storage_maximum_bytes < 0.1
for: 5m
annotations:
summary: "磁盘 XQOPEN $labels.disk XQCLOSE 空间不足 10%"
- alert: BackupFailure
expr: time() - longhorn_backup_volume_last_sync > 3600
for: 10m
annotations:
summary: "备份 XQOPEN $labels.volume XQCLOSE 超过 1 小时未同步"
19 Longhorn 的升级策略和注意事项是什么?
答案:
Longhorn 升级遵循从 Manager 到 Instance Manager 再到 Engine 的升级顺序。
升级流程:
1. 升级 Longhorn Manager(Deployment)
2. 升级 Instance Manager(DaemonSet,逐节点)
3. 升级 Engine Image(自动或手动触发)
4. 升级各卷的 Engine 版本
升级顺序:
# 1. 更新 Helm 仓库
helm repo update
# 2. 升级 Longhorn
helm upgrade longhorn longhorn/longhorn \
--namespace longhorn-system \
--version 1.6.0
# 3. 等待所有 Pod 就绪
kubectl -n longhorn-system rollout status deployment/longhorn-manager
kubectl -n longhorn-system rollout status daemonset/longhorn-csi-plugin
# 4. 卷引擎升级(手动触发)
kubectl -n longhorn-system get engines.longhorn.io
# 检查 image 版本,不是最新则需要更新
kubectl -n longhorn-system edit engines.longhorn.io <engine-name>
# spec.image: longhornio/longhorn-engine:v1.6.0
升级注意事项:
| 注意事项 | 说明 |
|---|---|
| 兼容性检查 | 跨大版本升级需检查 Breaking Changes |
| 卷 I/O 暂停 | 生产环境建议先 drain 节点再升级 |
| Engine 版本 | 所有卷的 Engine 版本应一致 |
| 备份验证 | 升级前做一次完整 Backup |
| 回滚准备 | 保留旧版本 Manager 镜像 |
| RWX 卷 | 升级期间 Share Manager 可能中断 |
20 Longhorn 如何与 Velero 集成实现集群级备份?
答案:
Longhorn 与 Velero 集成时,通过 Velero 的 CSI Snapshot 插件或 Longhorn Backup API 实现集群级别的应用和数据备份。
Velero CSI Snapshot 集成:
# 安装 Velero CSI 插件
velero install \
--provider aws \
--plugins velero/velero-plugin-for-csi:v0.7.0 \
--features EnableCSI
VolumeSnapshotClass 配置:
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: longhorn-snapshot
driver: driver.longhorn.io
deletionPolicy: Delete
备份工作流:
Velero Backup 请求
→ 创建 VolumeSnapshot(调用 CSI Snapshotter)
→ Longhorn 创建 VolumeSnapshot CR → 创建 Snapshot
→ Velero 备份 Pod 资源定义 + VolumeSnapshot 引用
→ 恢复时 VolumeSnapshot → Longhorn 从 Snapshot 创建新卷
直接使用 Longhorn Backup:
# 使用 Longhorn Backup CRD
apiVersion: longhorn.io/v1beta2
kind: Backup
metadata:
name: my-backup
namespace: longhorn-system
spec:
volumeName: "my-volume"
snapshotName: "my-snapshot"
labels:
app: "my-app"
backup-type: "weekly"
21 Longhorn 的 Recurring Job 支持哪些类型?
答案:
Longhorn 支持三种类型的 Recurring Job(定期任务),用于自动化数据保护。
任务类型:
| 类型 | 说明 | 典型配置 |
|---|---|---|
| Snapshot | 创建快照 | 每 5 分钟一次,保留 24 个 |
| Backup | 创建备份到远程 | 每天一次,保留 7 个 |
| Snapshot Backup | 先创建快照再备份 | 快照保留 24h + 备份保留 7d |
| Snapshot Cleanup | 清理过期快照 | 按保留策略执行 |
| Filesystem Trim | 文件系统回收 | 每天一次 |
配置方式(Volume 级别):
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: my-volume
namespace: longhorn-system
spec:
recurringJobs:
- name: snapshot-5m
task: "snapshot"
cron: "*/5 * * * *"
retain: 12
- name: backup-daily
task: "backup"
cron: "0 2 * * *"
retain: 30
- name: backup-weekly
task: "backup"
cron: "0 3 * * 0"
retain: 52
StorageClass 级别:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-autobackup
provisioner: driver.longhorn.io
parameters:
recurringJobs: '[{"name":"snap","task":"snapshot","cron":"*/5 * * * *","retain":12}]'
RecurringJob CRD 全局配置:
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
name: global-snapshot
namespace: longhorn-system
spec:
task: "snapshot"
cron: "0 */6 * * *"
retain: 4
groups:
- default # 应用到所有 default group 的卷
22 Longhorn 如何处理 Engine 和 Replica 之间的网络分区?
答案:
Longhorn 对 Engine 与 Replica 之间的网络分区有专门的检测和恢复机制。
网络分区检测:
- Instance Manager 通过 gRPC keepalive(默认每 10 秒)检测连接状态
- Engine 定期向 Replica 发送健康检查请求
- Replica 的 I/O 超时设置(默认 30 秒)
网络分区处理流程:
网络分区发生
Engine 侧:
→ Replica I/O 超时(30秒)
→ Engine 标记 Replica 为 Faulted(Non-responding)
→ 从 Replica 集合中移除 → 继续在剩余 Healthy Replica 上写入
→ 只有 1 个 Healthy Replica 时,Volume 降级为 Degraded
Replica 侧(被隔离的节点):
→ Replica 检测不到 Engine 的心跳
→ Replica 继续等待并维护本地数据
→ 超时(默认 60 秒)后 Replica 标记自身为 Error
网络恢复后:
→ Engine 发现 Replica 重新可访问
→ 检查 Replica 的 Revision Counter → 判断数据状态
→ 如果 Replica 落后 → 触发增量重建
→ Replica 同步完成后重新加入集合
Revision Counter 机制:
- 每个 Replica 维护一个 Revision Counter
- Engine 每次写入后增加计数器
- 网络分区恢复后比较各 Replica 的 Revision Counter
- 选择最新版本作为重建源
23 Longhorn 如何实现卷的加密?
答案:
Longhorn 支持通过 Linux 内核的 dm-crypt(通过 cryptsetup)实现卷级别的数据加密。
启用加密的 StorageClass:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-encrypted
provisioner: driver.longhorn.io
parameters:
encrypted: "true"
numberOfReplicas: "3"
密钥管理:
- 加密密钥存储在 Kubernetes Secret 中
- 每个加密卷自动生成唯一的 LUKS 密钥
- 密钥绑定到卷的 UID,迁移时密钥不可用
# 加密 Secret 自动创建
apiVersion: v1
kind: Secret
metadata:
name: longhorn-volume-<volume-uid>-passphrase
namespace: longhorn-system
type: Opaque
stringData:
CRYPTO_KEY_VALUE: "<auto-generated-key>"
CRYPTO_KEY_CIPHER: "aes-xts-plain64"
CRYPTO_KEY_HASH: "sha256"
CRYPTO_KEY_SIZE: "256"
CRYPTO_PBKDF: "argon2i"
加密层次:
Pod → 文件系统(ext4/xfs) → dm-crypt(加密设备映射)
→ Longhorn 块设备 → Replica(加密后存储)
注意:
- 加密在 Engine 层下面,即数据在 Replica 上是加密的
- 性能损耗约 5-10%(取决于 CPU AES-NI 支持)
- 必须备份加密密钥,否则密钥丢失数据不可恢复
24 Longhorn 如何管理多个磁盘?
答案:
Longhorn 支持节点上管理多个磁盘,并根据磁盘类型和大小进行调度。
磁盘管理:
# 节点磁盘配置(通过 UI 或 CRD)
apiVersion: longhorn.io/v1beta2
kind: Node
metadata:
name: worker-1
namespace: longhorn-system
spec:
disks:
- path: "/var/lib/longhorn"
allowScheduling: true
storageReserved: 10737418240 # 10GB 保留
tags:
- "ssd"
- "fast"
- path: "/mnt/extra-ssd"
allowScheduling: true
storageReserved: 5368709120 # 5GB 保留
tags:
- "ssd"
- "slow"
- path: "/mnt/hdd-storage"
allowScheduling: false
tags:
- "hdd"
- "cold"
磁盘标签(Disk Tags):
# StorageClass 通过标签选择磁盘
parameters:
diskSelector: "ssd,fast"
存储超分(Over-Provisioning):
# 全局设置
storageOverProvisioningPercentage: 200 # 允许 2 倍超分
storageMinimalAvailablePercentage: 25 # 最少保留 25% 可用空间
磁盘添加/移除:
# 添加新磁盘到节点
# Longhorn UI → Node → worker-1 → Edit Disks → Add Disk
# 或直接修改 Node CRD
# 移除磁盘(需先驱逐数据)
# Node → Disks → 选择磁盘 → Evacuate → 完成后移除
磁盘调度策略:
- 优先选择标签匹配的磁盘
- 在可用空间充足的磁盘上均匀分布 Replica
- 避免同一卷的 Replica 放置在同一节点或磁盘
- 考虑磁盘的 StorageReserved 设置
25 Longhorn 与 Rook/Ceph 的核心差异是什么?
答案:
Longhorn 和 Rook/Ceph 是 Kubernetes 生态中两种主流的持久化存储方案,设计理念有本质区别。
| 对比维度 | Longhorn | Rook/Ceph |
|---|---|---|
| 架构 | 轻量级微服务,每个卷独立 Engine | 分布式 Ceph 集群(MON/OSD/MGR) |
| 安装 | Helm 一键安装,简单 | 需要部署完整的 Ceph 集群 |
| 存储引擎 | 自定义块设备引擎 | RADOS + RBD |
| 数据冗余 | 多 Replica 完全副本 | 副本或 EC(纠删码) |
| RWX | NFS Share Manager | CephFS 原生支持 |
| 性能 | 低延迟,轻量级 | 高吞吐,低延迟(RBD 接近原生) |
| 资源消耗 | 低(每节点 ~1CPU/2GB) | 高(MON 3 副本 + OSD 多进程) |
| 运维复杂度 | 低 | 中高(Ceph 调优复杂) |
| 扩展性 | 单集群 < 100 节点 | 可扩展到数千节点 |
| 成熟度 | 相对较新(CNCF Incubating) | 成熟(CNCF Graduated) |
| 适用规模 | 中小规模(< 50 节点) | 中大规模(< 1000 节点) |
选型建议:
- Longhorn:中小规模集群、简单运维、SSD/NVMe 场景、不需要原生 CephFS
- Rook/Ceph:大规模集群、需要纠删码、需要 CephFS、已有 Ceph 运维经验
- 混合:关键业务用 Rook/Ceph,边缘/开发用 Longhorn
26 Longhorn 如何处理 SPDK(Storage Performance Development Kit)加速?
答案:
Longhorn 支持 SPDK 加速模式,通过用户态 NVMe 驱动绕过内核块设备层,减少 I/O 路径延迟。
SPDK 加速原理:
- 传统模式:写入请求 → 内核 VFS → 文件系统 → 块设备层 → NVMe 驱动
- SPDK 模式:写入请求 → SPDK 用户态 NVMe 驱动(绕过内核)
启用 SPDK:
# Global Settings
spdk:
enable: true
SPDK 加速效果:
| 指标 | 传统模式 | SPDK 模式 |
|---|---|---|
| 单线程 4K 随机写 IOPS | ~30,000 | ~100,000 |
| 4K 随机写延迟 P99 | 200-500μs | 50-100μs |
| CPU 使用率 | 中 | 低(轮询驱动) |
SPDK 前提条件:
- 内核支持 VFIO 和 IOMMU
- 需要大页内存(HugePages)配置
- 支持 NVMe 的 SSD
- 需要在 BIOS 中启用 VT-d/AMD-Vi
27 Longhorn 的 StorageClass 关键参数如何配置?
答案:
Longhorn StorageClass 参数控制卷的行为和性能特性。
常用参数列表:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-performance
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
# 数据冗余
numberOfReplicas: "3" # 副本数(1-3)
replicaAutoBalance: "best-effort" # 自动平衡
# 数据本地性
dataLocality: "best-effort" # 本地性策略
# 磁盘选择
diskSelector: "ssd,nvme" # 磁盘标签
nodeSelector: "storage-node" # 节点标签
# 文件系统
fsType: "ext4" # ext4 / xfs
mkfsParams: "-I 256 -O ^has_journal" # mkfs 参数
# 备份
fromBackup: "" # 从备份恢复
# 快照和备份
staleReplicaTimeout: "30" # 过期副本超时(分钟)
recurringJobs: '[{"name":"snap","task":"snapshot","cron":"*/5 * * * *","retain":12}]'
# 加密
encrypted: "false" # 是否加密
# 迁移设置
migrating: "false"
参数选择指南:
| 场景 | numberOfReplicas | dataLocality | diskSelector |
|---|---|---|---|
| 数据库 | 3 | best-effort | ssd,nvme |
| 文件存储 | 3 | disabled | hdd |
| 开发测试 | 1 | disabled | 无限制 |
| 高性能 | 2 | strict-local | nvme |
28 Longhorn 的 Volume Clone 和 Volume Export 如何操作?
答案:
Longhorn 支持卷的克隆(Clone)和导出(Export),用于数据复制和迁移。
Volume Clone:
# 创建克隆卷
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: cloned-volume
namespace: longhorn-system
spec:
fromVolume: "source-volume" # 源卷
numberOfReplicas: 3
size: "10737418240" # 与源卷大小一致
Clone 实现机制:
# or via Longhorn UI
# Volume → 选择源卷 → Clone → 输入新卷名 → 确认
- Clone 创建时从源卷的最新 Snapshot 生成
- 克隆过程不中断源卷的正常 I/O
- 克隆完成后是一个独立的新卷,与源卷完全隔离
Volume Export:
# 导出卷为原始块设备文件
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
curl -X POST http://localhost:8080/v1/volumes/my-volume?action=snapshotCreate
curl -X POST http://localhost:8080/v1/volumes/my-volume?action=snapshotBackup \
-H "Content-Type: application/json" \
-d '{"name":"export-snap"}'
从 Backup 恢复为新卷:
# UI 操作:Backup → 选择 Backup → Restore as new Volume
# 或 CLI(通过 Longhorn Manager API)
curl -X POST http://localhost:8080/v1/volumes \
-H "Content-Type: application/json" \
-d '{"name":"restored-volume","fromBackup":"s3://bucket/backup-url"}'
29 Longhorn 在生产环境部署的最佳实践有哪些?
答案:
Longhorn 生产环境部署需要从存储规划、节点配置、监控和灾备多维度优化。
节点规划:
- 专用存储节点:建议部署 3 节点以上作为存储节点,标签
node-role: storage - CPU & 内存:存储节点推荐 8C/32GB,Longhorn Manager 预留 2C/4GB
- 磁盘配置:
- 系统盘和数据盘分离
- 数据盘推荐使用独立 SSD/NVMe
- RAID 0(条带化)增加容量,RAID 1 增加可靠性
- 网卡推荐 10Gbps 以上
关键配置:
global:
# 存储配置
defaultSettings:
defaultReplicaCount: "3"
storageOverProvisioningPercentage: "200"
storageMinimalAvailablePercentage: "10"
replicaAutoBalance: "best-effort"
allowVolumeCreationWithDegradedAvailability: "false"
# 调度
replicaNodeSoftAntiAffinity: "ignore"
replicaDiskSoftAntiAffinity: "ignore"
# 快照
snapshotDataIntegrity: "fast-check"
recurringJobs: '[{"name":"snapshot-hourly","task":"snapshot","cron":"0 * * * *","retain":24}]'
# 性能
engineReplicaTimeout: "30"
concurrentAutomaticEngineUpgradePerNodeLimit: "1"
运维 Checklist:
- 配置 Backup Target 并验证恢复流程
- 设置 Prometheus 告警(VolumeDegraded、DiskPressure)
- 定期执行 Snapshot 清理,避免存储空间浪费
- 关键卷配置 Recurring Job 自动备份
- 升级前做完整数据备份验证
- 监控节点 Network、Disk I/O 和 CPU 使用率
容量规划:
可用容量 = (Σ 节点存储容量) × (storageOverProvisioningPercentage / 100)
实际可用 = 可用容量 - (Σ 保留空间)
示例(3 节点,各 1TB SSD,超分 200%,保留 10%):
总容量 = 3TB
超分后 = 6TB
保留空间 = 600GB
建议卷总量 = 5.4TB
30 Longhorn 如何排查 Pod 挂载卷失败的问题?
答案:
Pod 挂载卷失败通常涉及 CSI 驱动、Instance Manager 和卷状态等多层排查。
排查步骤:
1. 检查 Pod 事件:
kubectl describe pod <pod-name>
# Events 部分显示挂载失败原因
2. 检查 PVC/PV 状态:
kubectl get pvc
kubectl get pv
kubectl get volumes.longhorn.io -n longhorn-system
# 确认卷状态是否为 Healthy
3. 检查 CSI Pod 是否正常:
kubectl -n longhorn-system get pods | grep csi
# 确认 csi-provisioner / csi-attacher / csi-plugin 均为 Running
kubectl -n longhorn-system logs daemonset/longhorn-csi-plugin --tail=50
4. 检查 Instance Manager:
kubectl -n longhorn-system get instancemanagers
# 确认 Engine 和 Replica 的实例管理器正常
kubectl -n longhorn-system logs -l app=longhorn-instance-manager --tail=50
5. 查看 Longhorn Manager 日志:
kubectl -n longhorn-system logs deployment/longhorn-manager --tail=100
# 搜索卷相关错误
常见挂载失败原因及解决:
| 错误信息 | 可能原因 | 解决措施 |
|---|---|---|
Failed to mount volume | Engine 未启动 | kubectl describe volume <volume> 查看状态 |
Volume is not Ready | Replica 不足 | 检查节点状态和磁盘空间 |
executable not found | CSI 插件问题 | 重启 longhorn-csi-plugin |
timeout waiting for volume | Instance Manager 死锁 | 重启 Instance Manager Pod |
filesystem not found | 卷未格式化 | 检查 StorageClass 的 fsType 参数 |
no such device | Engine 和 Replica 连接断开 | kubectl get engines.longhorn.io 查看故障 |
# 紧急恢复:如果 Engine 卡死,可尝试强制重新挂载
kubectl -n longhorn-system annotate volume <volume> longhorn.io/force-detach=true
kubectl delete pod <pod-name> # 触发重新挂载