Proxmox VE 三节点 WireGuard 集群搭建

本文最后更新于31 天前，其中的信息可能已经过时，如有错误请发送邮件到yd-neply@foxmail.com

本文记录一次将三台 Proxmox VE 9 ARM64 主机通过 WireGuard overlay 组成三节点集群的过程。目标是让 Proxmox 的 corosync 集群通信走稳定的私有 WireGuard 网络，同时保留公网 7788 作为日常 SSH 管理入口。

目标

将三台独立 PVE 主机组成一个 Proxmox 集群。
三台机器使用稳定节点名，避免默认 pve 主机名冲突。
corosync 集群通信走 WireGuard overlay。
清理 B/C 上旧容器与旧 NAT 状态，避免加入集群失败。
保留公网 SSH 7788，将临时加入集群用的 SSH 22 收窄到 WireGuard 网段。

最终拓扑

节点	公网入口	集群节点名	WireGuard IP
A	`140.245.xxx.xxx:7788`	`pve-a`	`10.200.0.1`
B	`168.110.xxx.xxx:7788`	`pve-b`	`10.200.0.2`
C	`149.118.xxx.xxx:7788`	`pve-c`	`10.200.0.3`

集群名：pve-cluster

WireGuard 网段：10.200.0.0/24

前置检查

先确认三台机器都没有加入旧集群：

pvecm status

如果还没有集群，通常会看到类似 Cannot initialize CMAP service 或未初始化集群状态。

同时确认三台机器的 hostname。最开始三台都叫 pve，这会导致 Proxmox 集群节点名冲突，所以必须先改名再建集群。

修改主机名

三台分别设置为：

hostnamectl set-hostname pve-a
hostnamectl set-hostname pve-b
hostnamectl set-hostname pve-c

然后修改 /etc/hosts，保证节点名能解析到 WireGuard 地址：

127.0.0.1 localhost
127.0.1.1 pve-a

10.200.0.1 pve-a
10.200.0.2 pve-b
10.200.0.3 pve-c

B/C 上的 127.0.1.1 对应改成自己的节点名。

配置 WireGuard

三台机器使用 wg0，地址分别为：

pve-a: 10.200.0.1/24
pve-b: 10.200.0.2/24
pve-c: 10.200.0.3/24

采用 full mesh：A、B、C 彼此都配置对端 Peer，而不是只让 B/C 连接 A。这样 corosync 在三节点之间的连通性更稳定。

启用 WireGuard：

systemctl enable --now wg-quick@wg0

检查连通性：

ping -c 3 10.200.0.1
ping -c 3 10.200.0.2
ping -c 3 10.200.0.3
wg show

最终确认三台之间的 WireGuard ping 都正常。

在 A 上创建集群

在 pve-a 上执行：

pvecm create pve-cluster --link0 10.200.0.1

创建后检查：

pvecm status

此时集群只有 A 一个节点，但 corosync link 已经绑定到 10.200.0.1。

清理 B/C 旧容器和 NAT 状态

Proxmox 不允许带本地 guest 配置的节点直接加入已有集群。B/C 上存在旧 LXC 配置和 NAT/DNAT 规则，因此先清理。

B 原本有 CT 200 到 207，C 原本有 CT 200。用户确认这些都可以删除后，清理内容包括：

停止并删除旧 LXC。
删除 /etc/pve/nodes/pve/lxc/*.conf 旧配置。
删除 /var/lib/vz/images/<vmid> 旧磁盘数据。
删除 10.10.10.0/24 相关 DNAT/MASQUERADE 规则。

清理后 B/C 已经没有阻止入群的本地 guest 状态。

临时开放 SSH 22 用于 pvecm add

pvecm add 内部会通过 SSH 同步密钥和配置。由于三台机器的公网 SSH 默认在 7788，而 join helper 默认期望 22，所以临时增加：

Port 22
Port 7788

随后重新加载 sshd。

B/C 加入集群

在 B 上执行：

pvecm add 10.200.0.1 --link0 10.200.0.2

在 C 上执行：

pvecm add 10.200.0.1 --link0 10.200.0.3

加入完成后，在 A 上验证：

pvecm status
pvecm nodes

最终状态：

Name: pve-cluster
Nodes: 3
Quorate: Yes

Nodeid  Votes  Name
1       1      pve-a (local)
2       1      pve-b
3       1      pve-c

修复旧节点名 pve 导致的 Web UI 报错

集群建好后，A 的 Web UI 曾经只显示旧节点 pve，点击数据中心里的集群页面时报错：

unknown node 'pve' (500)

原因是三台机器最初都叫 pve。改名后，A 上旧的 /etc/pve/nodes/pve 目录仍残留，里面还有 A 原本的 CT 100/101 配置和 HA 本地状态文件。Web UI 被旧目录误导，继续访问不存在的旧节点名。

处理方式：

将 A 上旧节点目录里的 CT 配置迁到新节点名下：

mv /etc/pve/nodes/pve/lxc/*.conf /etc/pve/nodes/pve-a/lxc/

rm -f /etc/pve/nodes/pve/lrm_status /etc/pve/nodes/pve/lrm_status.tmp.*
rmdir /etc/pve/nodes/pve/lxc \
      /etc/pve/nodes/pve/qemu-server \
      /etc/pve/nodes/pve/openvz \
      /etc/pve/nodes/pve/priv \
      /etc/pve/nodes/pve

重启 PVE Web/API/状态服务：

systemctl restart pvestatd pvedaemon pveproxy

修复后验证：

pvesh get /nodes --output-format json

返回的三个节点均为 online：

pve-a online
pve-b online
pve-c online

旧 /etc/pve/nodes/pve 不再存在。

如果浏览器仍显示旧节点，需要强刷页面或重新登录，因为 Proxmox 前端树可能缓存旧节点名。

收窄 SSH 22

加入集群后，不再需要公网监听 22。最终配置为：

公网继续监听 7788。
22 只绑定各节点 WireGuard 地址，供 Proxmox 集群内部 SSH 使用。

A：

ListenAddress 0.0.0.0:7788
ListenAddress [::]:7788
ListenAddress 10.200.0.1:22

B：

ListenAddress 0.0.0.0:7788
ListenAddress [::]:7788
ListenAddress 10.200.0.2:22

C：

ListenAddress 0.0.0.0:7788
ListenAddress [::]:7788
ListenAddress 10.200.0.3:22

应用前先检查配置：

sshd -t
systemctl reload ssh

验证监听：

ss -ltnp | grep sshd

最终结果：

0.0.0.0:7788
[::]:7788
10.200.0.x:22

最终验证

在 A 上确认集群状态：

pvecm status
pvecm nodes
pvesh get /nodes --output-format json
pvesh get /cluster/resources --output-format json

确认结果：

pve-cluster 三节点存在。
Quorate: Yes。
pve-a、pve-b、pve-c 均 online。
A 上原有 CT 100/101 已归属到 pve-a。
B/C 旧容器和 NAT 状态已清空。
旧节点名 pve 不再出现在节点目录中。
SSH 7788 对外保留，22 仅在 WireGuard IP 上监听。

经验总结

Proxmox 集群前必须先处理 hostname，尤其是云服务器模板默认都叫 pve 的情况。
corosync 的 link 地址建议绑定稳定私网地址，这里使用 WireGuard 10.200.0.0/24。
加入集群前，待加入节点不能保留本地 guest 配置。
pvecm add 默认依赖 SSH 22，非标准 SSH 端口环境要提前处理。
改节点名后，必须检查 /etc/pve/nodes/ 下是否有旧节点目录残留。
Web UI 的 unknown node '<old-name>' (500) 往往不是集群坏了，而是旧节点状态或前端缓存还没清干净。

目标