一、 场景痛点：凌晨 3 点的报警电话

做工业物联网（IIoT）的架构师都有过这样的噩梦：

• 现状：为了省成本，你在车间部署了一台工控机作为“全能网关”，跑着 Node-RED 采集数据，还跑着 MySQL 存数据。

• 事故：某天凌晨，这台工控机的电源模块烧了，或者内存条松了。

• 后果：全产线数据中断，MES 系统报错，生产停摆。甲方勒令你 30 分钟内恢复，但你离现场有 200 公里。

传统的“冷备”方案（放一台备用机在旁边，坏了让人手动换线）时效性太差；而传统的“Keepalived + VIP”方案在处理容器化应用时，配置极其繁琐且难以管理状态。

今天，我们用云原生的方式降维打击，教你用 3 台廉价小主机（N100/RK3588 均可）搭建一套自动故障转移的边缘集群。

二、 架构拓扑设计

我们的目标是：只要 3 台机器中还有 2 台活着，服务的 IP 地址（VIP）就永远能 ping 通，业务不中断。

• 计算层：3 x 节点安装 K3s (轻量级 Kubernetes)，组成 HA 集群（Embedded etcd 模式）。

• 网络层：使用 MetalLB（二层模式），它能像云厂商的 LoadBalancer 一样，在局域网内广播一个“虚拟 IP (VIP)”。

• 存储层：使用 Longhorn，将 3 台机器的硬盘组成分布式块存储，确保就算机器炸了，数据在其他节点还有备份。

PLC (Modbus) -> [连接 VIP: 192.168.1.200] -> (MetalLB 自动路由) -> [活跃的 Node-RED 容器] -> [Longhorn 分布式存储]

三、 核心实施步骤 (Copy & Paste)

假设你准备了 3 台 IP 分别为 192.168.1.11, 12, 13 的 Linux 主机。

1. 初始化 K3s HA 集群 (Embedded etcd)

别再用 docker run 了。在第一台机器（Node 1）上执行：

# 安装 Server 节点，初始化集群令牌
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --cluster-init --token my-secret-token" sh -

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --server https://192.168.1.11:6443 --token my-secret-token" sh -

2. 关键配置：部署 MetalLB 实现 VIP 漂移

PLC 和 SCADA 系统通常只认 IP 地址，不认域名。MetalLB 能让 K8s Service 拥有一个局域网 IP。

Step A: 安装 MetalLB

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --server https://192.168.1.11:6443 --token my-secret-token" sh -

创建 metallb-config.yaml，指定一个没被占用的 IP（如 .200）作为 VIP：

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: edge-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.200-192.168.1.200  # 这就是你的“永不宕机 IP”
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: edge-advertisement
  namespace: metallb-system

执行 kubectl apply -f metallb-config.yaml。

当你部署 Node-RED 或 EMQX 时，将 Service 类型设为 LoadBalancer，它就会自动获取到 192.168.1.200 这个 IP。

apiVersion: v1
kind: Service
metadata:
  name: node-red
spec:
  selector:
    app: node-red
  ports:
    - port: 1880
      targetPort: 1880
  type: LoadBalancer  # 魔法发生在这里

四、 踩坑复盘 (Red Flags)

1. “脑裂”风险 (Split Brain)

• 警告：为什么我说必须 3 台机器？因为 etcd 需要“法定人数 (Quorum)”来投票。如果是 2 台机器，一旦断网，两台机器都会认为对方死了，自己是大王，导致数据写入冲突（脑裂）。

• 原则：节点数必须是奇数（3, 5, 7）。

2. 存储性能陷阱

• 现象：如果你使用 Longhorn 做分布式存储，且底层用的是 SD 卡或机械硬盘，I/O 延迟会高到让数据库崩溃。

• 对策：Longhorn 极其依赖磁盘性能。在边缘端做超融合架构，必须使用 NVMe SSD。

3. ARP 欺骗防护

• 现象：某些老旧的工业交换机开启了激进的“ARP 攻击防护”，会把 MetalLB 频繁广播的免费 ARP (Gratuitous ARP) 当作攻击给屏蔽掉，导致 VIP 无法切换。

• 对策：在交换机上针对这 3 个网口关闭 ARP Guard，或者绑定静态 MAC（不推荐）。

五、 关联资源与选型

构建这套高可用架构，硬件成本其实很低。

• 推荐硬件 (x86)：

• Intel N100 小主机 (准系统)：单台约 ¥600。低功耗，性能足以跑 K3s。

  
  

推荐硬件 (ARM)：

• 香橙派 5 Plus (RK3588)：单台约 ¥700。支持 NVMe SSD，是搭建 ARM 集群的神器。

  
  

我们已经把 K3s + MetalLB + Longhorn + Node-RED 的完整部署脚本封装成了 Ansible Playbook。

只要填入 3 个 IP 地址，一键运行，10 分钟内自动拉起高可用集群。