赛博堡垒的数据血脉：部署 Longhorn 分布式块存储

📖 认识赛博存储底座：为什么必须是 Longhorn？

之前我们安装的 Portainer 的 Pod 固定到 master-01 节点 当我们手动搬家到 master-02 时，整个 Pod 直接卡死在了 Pending（挂起）状态，K8s 抛出了无情的报错：“1 node(s) didn’t match PersistentVolume’s node affinity”。

产生这个死锁的根本原因，就是 K3s 默认提供的 local-path 存储。它就像电焊一样，把你的数据（PV）死死焊在了 Master 01 的物理硬盘上。租客（Pod）虽然跑到了隔壁楼，但全部家当还锁在老房子的地板里，导致业务永远无法重启。

在真正的企业级架构中，计算资源随时可能因为节点断电而重新调度，如果要实现“拔电无感漂移”，我们就必须打碎物理硬盘的枷锁，将所有的存储资源池化！ 这就是为什么我们必须请出顶级开源存储项目 —— Longhorn。

📜 官方特性白皮书 (Official Features)

根据 Longhorn 官方文档 的定义，它不仅是一个软件，更是 K8s 内部的“赛博存储大坝”。它能为你提供以下三大核心能力：

🛡️ 高可用的云原生持久化存储 (Highly available persistent storage) 过去，在非云托管的 K8s 集群中添加副本存储极其困难，外部存储阵列又昂贵且无法移植。Longhorn 提供了极其简单的、100% 开源的云原生分布式块存储（Block Storage）。它能把你三台虚拟机里零散的剩余空间整合起来，并且在内部实时进行多副本同步。现在，哪怕 Node 1 瞬间物理粉碎，Node 2 上的 Pod 也能瞬间无损接管。

🗃️ 轻松的增量快照与备份 (Easy incremental snapshots and backups) Longhorn 内置了增量快照和备份功能。配合它自带的高颜值 UI 面板，你可以极其直观地配置定时任务。最关键的是，它可以把备份数据直接推送到集群外部（比如咱们局域网里那台 NAS 提供的 NFS/S3 存储上），让集群数据拥有终极的安全底线。

🌍 跨集群灾难恢复 (Cross-cluster disaster recovery) 传统的存储容灾通常需要耗费数天时间来重新复制整个数据存储。而使用 Longhorn，你可以把粒度控制到极致。如果主集群由于不可抗力彻底瘫痪，你能以明确的 RPO (恢复点目标) 和 RTO (恢复时间目标)，在另一个备用 K8s 集群中极其迅速地将应用重新拉起。

一句话总结它的工作原理 (How Longhorn works)：

Longhorn 会在你的每一个节点上安插一个“存储引擎”容器。当你的 K3s 需要硬盘时，Longhorn 就在底层把多个节点上的物理碎片拼凑成一块极其强韧的“虚拟网络硬盘”，直接插入到 Pod 的底部。

🎬 施工演示录像 (Video Walk-through)

正在嗅探浏览器语言并加载赛博录像...

---

🧱 施工前置准备 (Requirements)

官方安装指南

既然我们的目标是“拔电无感漂移”，那就意味着底层的每一台机器都必须具备独立挂载、解密和读取网络块设备的能力。

由于我们的赛博靶场是清一色的 Ubuntu 22.04+ 虚拟机，这为我们的施工省下了大量的系统兼容性麻烦。根据 Longhorn 官方文档的硬性要求，我们需要在所有 3 台 Master 节点上打牢以下基础。

1. 环境探勘：安装底层存储协议依赖

Longhorn 并不是自己凭空造硬盘，它是通过调度 Linux 内核底层的存储协议来实现卷的挂载的。

请使用终端工具向你的 3 台 Ubuntu 节点同时下发以下安装指令：

sudo apt-get update
sudo apt-get install -y open-iscsi nfs-common cryptsetup dmsetup

💡 包工头硬核原理解析：为什么要装这“四大金刚”？

• 🔌 open-iscsi (核心生命线)：Longhorn 为 Pod 提供虚拟硬盘的底层技术是 iSCSI。Longhorn Engine 会在内部暴露一个 iSCSI Target，而宿主机需要通过 iscsid 守护进程（Initiator）去连接它。没有它，K3s 根本无法把 Longhorn 的盘挂载给容器。
• 🌐 nfs-common (备灾与共享通道)：
  1. 备份需求：Longhorn 未来要把快照推送到你的 NAS 上，必须走 NFSv4 协议。
  2. RWX 支持：如果你未来需要让多个 Pod 同时读写同一个 Longhorn 卷（ReadWriteMany），底层也依赖 NFS 客户端组件。
• 🔐 cryptsetup & dmsetup (加密与映射)：用于支持未来的透明磁盘加密（LUKS2）以及设备映射。

---

🔨 底层环境深度调优

装完软件还不够，为了让集群在经历意外断电、重启后依然稳如泰山，我们必须对内核和系统服务进行深度干预：

第一步：激活 iSCSI 核心生命线 让守护进程开机自启，随时准备接收 Longhorn 的挂载指令。

sudo systemctl enable --now iscsid

第二步：唤醒并固化内核模块 (立下“开机规矩”) 默认情况下，NFS 和加密模块是按需加载的。为了防止宿主机刚开机时，由于加载延迟导致 Longhorn 引擎启动崩溃（CrashLoopBackOff），我们必须把它们死死“钉”在内存里，粮草先行。

# 1. 临时唤醒存储内核模块
sudo modprobe nfs
sudo modprobe dm_crypt

# 2. 写入开机基因（防止以后停电重启又睡死）
echo -e "nfs\ndm_crypt" | sudo tee /etc/modules-load.d/longhorn.conf

第三步：驱逐抢地盘的进程 (消灭底层黄灯) Ubuntu 默认运行着一个叫 multipathd 的多路径守护进程。它是个“热心肠”，看到系统里出现新的裸硬盘就会试图去接管。为了防止它和 Longhorn 引擎抢夺虚拟硬盘的控制权导致严重死锁，必须将其彻底封杀！

# 停止并禁用多路径服务
sudo systemctl stop multipathd
sudo systemctl disable multipathd

---

2. 官方质检工具：执行飞行前检查 (Preflight Check)

Longhorn 官方提供了一个极其贴心的质检工具 longhornctl，专门用来检查集群的底层是否已经满足了所有苛刻的要求。

在你的 Master 01 上执行：

# 下载 AMD64 版本的质检工具 安装你实际版本号和架构下载
curl -sSfL -o longhornctl https://github.com/longhorn/cli/releases/download/v1.11.1/longhornctl-linux-amd64
chmod +x longhornctl

# 创建独立的存储专属园区
kubectl create namespace longhorn-system

# 执行全集群质检
./longhornctl check preflight

🔍 期望的验收结果： 只要关键组件（iscsid, NFS4, open-iscsi 等）都在 info: 列表里显示 installed 或 loaded，且没有红色的 error:，就代表地基质检完美通过！

---

3. 节点物理存储空间盘点与规划

Longhorn 默认会使用宿主机的这个目录来存放虚拟硬盘的数据块： 👉 /var/lib/longhorn

⚠️ 施工警告：确认你的 PVE 硬盘余量 因为是 Ubuntu 虚拟机，这个目录实际上消耗的是你虚拟机系统盘的空间。如果你在 PVE 里给这 3 台虚拟机只分配了极小的硬盘，系统很容易因为写满数据而彻底宕机。建议单节点硬盘配置在 50GB - 100GB 以上。

🔨 核心施工流程 (Installation Steps)

步骤 1：添加官方 Helm 仓库并获取图纸版本号

我们使用 Helm 这把“云原生瑞士军刀”来统筹整个大坝的建设。首先获取官方图纸库并更新本地缓存：

helm repo add longhorn https://charts.longhorn.io
helm repo update

💡 查明并锁定最新大版本号 在真正的赛博工地里，我们绝不能盲目使用默认的 latest 进行部署，否则未来一旦触发跨版本自动更新，极易导致底层大坝崩塌。我们必须查明当前的最新稳定版，并在稍后的安装指令中死死锁住它。

敲下这条命令，列出官方仓库里最新的 5 个版本：

helm search repo longhorn/longhorn -l | head -n 5

(观察输出结果中的 CHART VERSION 列，记下排在第一行的最新版本号。例如咱们本次施工获取到的最新版本是 1.11.1，请把它记好，稍后的浇筑指令中会用到它。)

步骤 2：定制 Longhorn 专属施工图纸 (values.yaml)

官方默认的配置虽然能跑，但为了体现咱们“赛博靶场”的工程鲁棒性，我们需要自己覆写一份图纸。

创建一个名为 longhorn-values.yaml 的文件，填入以下核心配置：

defaultSettings:
  # 默认 3 副本，完美匹配 3 节点集群，实现“宕机任意一台数据绝对不丢”
  defaultReplicaCount: 3
  # 硬盘防爆开关：宿主机硬盘剩余低于 15% 时强制停止写入，防止 Ubuntu 变砖
  storageMinimalAvailablePercentage: 15
  # 关闭自动升级检查，减少内网环境不必要的外部网络请求
  upgradeChecker: false

service:
  ui:
    # 核心联动：召唤咱们部署的 Cilium L2 负载均衡器
    type: LoadBalancer
    # 指定 IP 方式：请更换为你自己网段内规划的可用靓号
    loadBalancerIP: "10.0.10.52"

💡 包工头进阶提示：按需查阅官方全量图纸 上面的配置只是满足咱们靶场高可用和固定 IP 的最核心精简版。Longhorn 拥有极其庞大的参数矩阵，如果你有更复杂的定制需求（例如配置远端 S3 备份目标、节点亲和性、污点容忍等），请务必查阅并参考官方的全量默认图纸： 👉 Longhorn 官方 values.yaml 参考配置 (⚠️ 避坑指南：查阅官方 GitHub 源码时，请务必注意将 URL 分支或 Tag 切换为你实际通过 helm search 查到的安装版本号，防止由于版本跨度导致参数不生效。)

步骤 3：执行 Helm 一键浇筑指令

图纸画好，直接锁定版本号执行安装。Longhorn 是一个极其复杂的系统，指定大版本号（这里使用 1.11.1）可以防止未来误操作跨版本翻车：

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  -f longhorn-values.yaml \
  --version 1.11.1

执行完毕后，系统会在后台拉起几十个组件（包括引擎、控制器、前端面板等）。可以使用以下命令盯紧大坝的合拢进度：

# 监控所有组件的启动状态，按 Ctrl+C 退出
kubectl get pods -n longhorn-system -w

步骤 4：打通 UI 面板入口 (配合 Cilium LB)

等所有的 Pod 都变成 Running 状态后，我们来验证一下 Cilium 是否乖乖听话，把我们刚才在图纸里指定的 VIP（虚拟 IP）发给了 Longhorn 面板。

敲下这条查岗命令：

kubectl get svc -n longhorn-system longhorn-frontend

🎉 竣工验收： 观察终端输出，如果 EXTERNAL-IP 这一列成功显示了 10.0.10.52，那么恭喜你，存储大坝已经全面通水！

直接在浏览器中访问 http://10.0.10.52，你将看到那个极具赛博工业风的 Longhorn 仪表盘。属于你自己的分布式云原生存储池，至此正式落成！