わたしの部屋

一、背景与集群拓扑#

节点信息：

• 三节点通过 ZeroTier 组成 /24 的内网，接口名为 ztpp6n6xmz（由网络 ID 决定，这里以 ztpp6n6xmz 为例）。
• PostgreSQL 集群由 Patroni 管理，使用 patronictl list 可查看角色。
• K3s 集群有三个 etcd+control-plane 节点。
• 目标：提供一个统一的 VIP 10.0.0.100，对外暴露以下服务：
  • 5432 端口 → PostgreSQL 写库（自动指向 Leader）
  • 5433 端口 → PostgreSQL 读库（负载均衡到 Replica）
  • 6443 端口 → K3s API Server（四层代理）

二、整体架构#

1
         ┌─────────────────────────────────┐
2
         │  keepalived (VIP 高可用)         │
3
         │  HAProxy  (四层代理 + 健康检查)  │
4
         └──────────┬──────────────────────┘
5
                    │ VIP: 10.0.0.100 (ztpp6n6xmz)
6
         ┌──────────┼──────────┐
7
         ▼          ▼          ▼
8
  10.0.0.10     10.0.0.30    10.0.0.40
9
  (server)      (txy)        (aly)
10
  [Leader]      [Replica]    [Replica]
11
  [K3s CP]      [K3s CP]     [K3s CP]

设计要点：

• Keepalived 通过 VRRP 通告（本实践为单播）管理 VIP，选择一台节点作为 MASTER，其余为 BACKUP。接口故障（如 ztpp6n6xmz down）会立即触发降级，避免等待超时。
• HAProxy 仅在 MASTER 节点上运行，监听 VIP 的三个端口，根据后端健康检查动态路由流量。
• 健康检查直接调用 Patroni REST API（/master、/replica），实现完全自动化的读写分离。

三、基础准备#

1
curl -s https://install.zerotier.com | sudo bash
2
sudo zerotier-cli join <network_id>
3
# 在 ZeroTier Central 管理后台授权节点，并确保它们获得预期的 IP（如 10.0.0.10、10.0.0.30、10.0.0.40）
4
sudo zerotier-cli listnetworks   # 查看接口名称，通常为 zt<网络ID前10位>

1
sudo apt update
2
sudo apt install -y haproxy keepalived
3

4
# 允许绑定非本机 IP（HAProxy 需要监听 VIP）
5
echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
6
sudo sysctl -p
7

8
# 停止并禁用这两个服务，后续由 keepalived 控制 HAProxy 启停
9
sudo systemctl stop haproxy keepalived
10
sudo systemctl disable haproxy keepalived

四、HAProxy 配置：实现读写分离#

文件：/etc/haproxy/haproxy.cfg （三台节点相同）

1
global
2
    log /dev/log local0
3
    maxconn 4096
4
    user haproxy
5
    group haproxy
6
    daemon
7

8
defaults
9
    mode tcp
10
    timeout connect 5s
11
    timeout client 30m
12
    timeout server 30m
13

14
# ---------- PostgreSQL 读写分离 ----------
15
frontend psql_write
16
    bind 10.0.0.100:5432
17
    mode tcp
18
    default_backend pg_write
19

20
frontend psql_read
21
    bind 10.0.0.100:5433
22
    mode tcp
23
    default_backend pg_read
24

25
# ---------- K3s API Server ----------
26
frontend k8s_api
27
    bind 10.0.0.100:6443
28
    mode tcp
29
    default_backend k3s_servers
30

31
# ---------- 后端定义 ----------
32
backend pg_write   # 写库：只有 Patroni Leader 存活
33
    mode tcp
34
    option httpchk GET /master
35
    http-check expect status 200
36
    default-server inter 3s fall 3 rise 2
37
    server pg10 10.0.0.10:5432 check port 8008
38
    server pg30 10.0.0.30:5432 check port 8008
39
    server pg40 10.0.0.40:5432 check port 8008
40

41
backend pg_read    # 读库：所有 Replica（Leader 会自动被 /replica 剔除）
42
    mode tcp
43
    option httpchk GET /replica
44
    http-check expect status 200
45
    default-server inter 3s fall 3 rise 2
46
    server pg10 10.0.0.10:5432 check port 8008
47
    server pg30 10.0.0.30:5432 check port 8008
48
    server pg40 10.0.0.40:5432 check port 8008
49

50
backend k3s_servers
51
    mode tcp
52
    balance roundrobin
53
    option tcp-check
54
    server srv10 10.0.0.10:6443 check
55
    server srv30 10.0.0.30:6443 check
56
    server srv40 10.0.0.40:6443 check

关键机制：

• Patroni 默认在 8008 端口提供 REST API，/master 仅在 Leader 返回 200，/replica 仅在 Replica 返回 200。
• HAProxy 利用 httpchk 动态探测，自动将写请求导向 Leader，读请求分发到所有副本。
• K3s 后端仅使用 TCP 端口检查，保证 API Server 可达。

五、Keepalived 配置：VIP 高可用与 HAProxy 联动#

ZeroTier 是二层虚拟以太网，理论上原生支持多播、可直接使用默认的 VRRP 多播模式。但本实践为稳定起见采用单播 VRRP：通过 unicast_src_ip 指定本机源 IP，unicast_peer 列出对端节点 IP，三个节点间单播互发通告。这样不依赖多播包在 ZeroTier 中的传播，排障更直观。

1
#!/bin/bash
2
# 检查 haproxy 进程是否存活
3
if systemctl is-active --quiet haproxy; then
4
  exit 0
5
else
6
  exit 1
7
fi

1
#!/bin/bash
2
VIP="10.0.0.100"
3
DEV="ztpp6n6xmz"   # 使用 ZeroTier 接口名
4

5
case "$1" in
6
    master)
7
        sleep 1
8
        ip addr show $DEV | grep -q $VIP || exit 1
9
        systemctl start haproxy
10
        # 发送 gratuitous ARP，通知同网段其他节点 VIP 已漂移到本机 MAC
11
        # 避免其他节点 ARP 缓存残留旧 MASTER 的 MAC，导致 ICMP Redirect 或短暂不通
12
        ip neigh flush dev $DEV
13
        arping -c 5 -A -I $DEV $VIP 2>/dev/null || \
14
        arping -c 5 -U -I $DEV $VIP 2>/dev/null || true
15
        logger "keepalived: transition to MASTER, haproxy started, gratuitous ARP sent"
16
        ;;
17
    backup)
18
        systemctl stop haproxy
19
        logger "keepalived: transition to BACKUP, haproxy stopped"
20
        ;;
21
    fault)
22
        systemctl stop haproxy
23
        logger "keepalived: transition to FAULT, haproxy stopped"
24
        ;;
25
    *)
26
        echo "Usage: $0 {master|backup|fault}"
27
        exit 1
28
        ;;
29
esac

1
# 定义健康检查脚本，供 track_script 引用
2
vrrp_script chk_haproxy {
3
    script "/etc/keepalived/chk_haproxy.sh"   # 检查 haproxy 是否存活
4
    interval 2                                # 每 2 秒执行一次
5
    weight -20                                # 失败时优先级减 20，让其他节点更容易抢占
6
    fall 3                                    # 连续失败 3 次才认为故障
7
    rise 2                                    # 连续成功 2 次才恢复健康
8
}
9

10
vrrp_instance VI_PG {
11
    state BACKUP                   # 所有节点都设为 BACKUP，依靠优先级竞选 Master
12
    interface ztpp6n6xmz          # ZeroTier 虚拟网卡接口
13
    virtual_router_id 51           # 同一 VRRP 组必须相同
14
    priority 100                   # 最高优先级，默认成为 Master
15
    advert_int 1                   # 通告间隔（秒）
16
    unicast_src_ip 10.0.0.10       # 本节点发送 VRRP 通告的源 IP
17
    unicast_peer {
18
        10.0.0.30                  # 对端节点 IP
19
        10.0.0.40
20
    }
21
    authentication {
22
        auth_type PASS
23
        auth_pass 51275127         # 所有节点必须一致
24
    }
25
    virtual_ipaddress {
26
        10.0.0.100/32 dev ztpp6n6xmz  # 虚拟 IP，仅 Master 持有
27
    }
28
    track_interface {
29
        ztpp6n6xmz                 # 监控 ZeroTier 接口，若 down 立即降级
30
    }
31
    track_script {
32
        chk_haproxy                # 引用上方健康检查脚本
33
    }
34
    notify "/etc/keepalived/notify.sh"  # 状态变化时调用通知脚本
35
}

六、启动与调优#

1
sudo systemctl start keepalived

1
ip addr show ztpp6n6xmz | grep 10.0.0.100

1
sudo mkdir -p /etc/rancher/k3s
2
cat <<EOF | sudo tee /etc/rancher/k3s/config.yaml
3
tls-san:
4
  - 10.0.0.100
5
EOF
6

7
# 删除动态证书缓存并逐台重启 K3s（注意保持 etcd quorum）
8
sudo rm -f /var/lib/rancher/k3s/server/tls/dynamic-cert.json
9
sudo systemctl restart k3s

七、验证与测试#

1
# 写库测试（应返回 f）
2
psql -h 10.0.0.100 -p 5432 -U postgres -c "select pg_is_in_recovery();"
3

4
# 读库测试（应返回 t）
5
psql -h 10.0.0.100 -p 5433 -U postgres -c "select pg_is_in_recovery();"

1
pg_is_in_recovery
2
-------------------
3
 f
4
(1 row)
5

6
pg_is_in_recovery
7
-------------------
8
 t
9
(1 row)

1
kubectl get nodes --server https://10.0.0.100:6443

八、踩坑记录与最佳实践#

1. ZeroTier 是 VRRP 的理想承载层
   WireGuard 是三层隧道，不支持多播和 ARP 广播，导致 VIP 必须通过单播 VRRP 和额外的路由配置才能工作(sudo wg set)，且客户端解析 VIP 时容易出问题。切换为 ZeroTier 后这些问题缓解；本实践沿用单播 VRRP（unicast_src_ip + unicast_peer），比多播更稳定可控。

2. Keepalived 配置必须完整
   缺少 track_interface 会导致接口 down 时无法立即切换；缺少健康检查脚本或 track_script 引用会使实例进入 FAULT；未配置 notify 指令则通知脚本永远不会执行。三要素缺一不可。

3. 接口名称一致性
   ZeroTier 的接口名称由网络 ID 决定，不同设备上可能不同（如 zt7ufxgkl3），建议在每台机器上确认接口名，并统一写入 keepalived 配置。或者通过 ZeroTier 的 local.conf 固定接口名称。

4. VIP 单点存在是正常现象
   所有 BACKUP 节点不会持有 VIP，这是 VRRP 的正常表现，不必担心。

5. 证书规划
   如果 K3s 部署时未预知 VIP 地址，后期添加 SAN 需重启集群，建议在部署初期就规划好所有可能的访问入口。

6. etcd 依赖 ZeroTier 接口：服务已启动不代表地址已就绪 在把 WSL2 节点 10.0.0.20 加入 Patroni 后，出现了一个容易误判的故障：patronictl list 中没有 pg-20，而 Patroni 本身只显示依赖失败。

   1
   Dependency failed for patroni.service - Patroni for PostgreSQL HA.
   2
   patroni.service: Job patroni.service/start failed with result 'dependency'.

   patroni.service 配置了 Requires=etcd.service，继续检查 etcd 才找到真正的错误：

   1
   creating peer listener failed
   2
   listen tcp 10.0.0.20:3380: bind: cannot assign requested address
   3
   etcd.service: Main process exited, code=exited, status=1/FAILURE

   对照本次启动的 monotonic 日志可以还原竞态过程：

   • 开机约 12.2 秒时，etcd 开始绑定 10.0.0.20:3380；
   • 约 12.4 秒时绑定失败，Patroni 随即因 etcd 依赖失败而停止启动；
   • 约 13.9 秒时，ZeroTier 接口 ztpp6n6xmz 才 Link UP 并获得地址；
   • etcd 原配置为 Restart=on-abnormal，退出码 1 不属于该策略覆盖的异常终止，因此之后没有自动重试。

   这里有两个不同层次的就绪条件：

   1. zerotier-one.service 进入 active；
   2. ZeroTier 完成控制面连接、创建虚拟接口并分配 10.0.0.x。

   After=zerotier-one.service 只能保证第一层，不能保证第二层。最终在所有 etcd 节点上使用 systemd drop-in：既声明强依赖，也在启动前等待本机的 ZeroTier 地址。

   1
   [Unit]
   2
   Requires=zerotier-one.service
   3
   After=zerotier-one.service
   4
   
   5
   [Service]
   6
   ExecStartPre=/bin/sh -c 'for i in $(seq 1 60); do /usr/sbin/ip -4 address show dev ztpp6n6xmz 2>/dev/null | /usr/bin/grep -q "inet 10.0.0.20/" && exit 0; sleep 1; done; echo "Timed out waiting for ZeroTier address 10.0.0.20 on ztpp6n6xmz" >&2; exit 1'
   7
   Restart=on-failure
   8
   RestartSec=3s

   10.0.0.20 应替换为各节点在 /etc/default/etcd 的 ETCD_LISTEN_PEER_URLS 中配置的地址。使用 drop-in 而不是直接编辑 /usr/lib/systemd/system/etcd.service，可以避免软件包升级覆盖修改；systemd 会将 drop-in 合并进原 unit，依赖语义完全相同。

   本集群通过 Ansible 的 servers 组统一发布。由于 etcd 依赖多数派，不能同时重启所有成员，play 必须设置 serial: 1，每次仅处理一台，并确认本地端点恢复健康后再继续下一台：

   1
   ---
   2
   - name: Make etcd wait for the ZeroTier address
   3
     hosts: servers
   4
     become: true
   5
     serial: 1
   6
     tasks:
   7
       - name: Read etcd peer address
   8
         ansible.builtin.shell: |
   9
           set -o pipefail
   10
           sed -n 's|^ETCD_LISTEN_PEER_URLS="http://\([^:]*\):.*|\1|p' /etc/default/etcd
   11
         args:
   12
           executable: /bin/bash
   13
         register: etcd_peer_address
   14
         changed_when: false
   15
         failed_when: not (etcd_peer_address.stdout is match('^[0-9]+(\.[0-9]+){3}$'))
   16
   
   17
       - name: Create etcd systemd drop-in directory
   18
         ansible.builtin.file:
   19
           path: /etc/systemd/system/etcd.service.d
   20
           state: directory
   21
           owner: root
   22
           group: root
   23
           mode: "0755"
   24
   
   25
       - name: Install ZeroTier readiness drop-in
   26
         ansible.builtin.copy:
   27
           dest: /etc/systemd/system/etcd.service.d/zerotier.conf
   28
           owner: root
   29
           group: root
   30
           mode: "0644"
   31
           content: |
   32
             [Unit]
   33
             Requires=zerotier-one.service
   34
             After=zerotier-one.service
   35
   
   36
             [Service]
   37
             ExecStartPre=/bin/sh -c 'for i in $(seq 1 60); do /usr/sbin/ip -4 address show dev ztpp6n6xmz 2>/dev/null | /usr/bin/grep -q "inet {{ etcd_peer_address.stdout }}/" && exit 0; sleep 1; done; echo "Timed out waiting for ZeroTier address {{ etcd_peer_address.stdout }} on ztpp6n6xmz" >&2; exit 1'
   38
             Restart=on-failure
   39
             RestartSec=3s
   40
         register: etcd_dropin
   41
   
   42
       - name: Reload systemd configuration
   43
         ansible.builtin.systemd_service:
   44
           daemon_reload: true
   45
         when: etcd_dropin.changed
   46
   
   47
       - name: Restart etcd
   48
         ansible.builtin.systemd_service:
   49
           name: etcd.service
   50
           state: restarted
   51
           enabled: true
   52
         when: etcd_dropin.changed
   53
   
   54
       - name: Wait for etcd health
   55
         ansible.builtin.uri:
   56
           url: http://127.0.0.1:3379/health
   57
           return_content: true
   58
         register: etcd_health
   59
         retries: 20
   60
         delay: 1
   61
         until:
   62
           - etcd_health.status == 200
   63
           - "'\"health\":\"true\"' in etcd_health.content"

   发布后检查 systemd 合并结果和集群状态：

   1
   systemctl show etcd -p Requires -p After -p Restart -p ExecStartPre
   2
   curl -fsS http://127.0.0.1:3379/health
   3
   sudo patronictl -c /etc/patroni/config.yml list

   最终四台节点的 zerotier-one、etcd、patroni 均为 active，etcd 健康检查全部返回 {"health":"true"}；pg-20 重新以 Replica 身份加入，状态为 streaming，复制延迟为 0 MB。

7. VIP 消失：keepalived 服务被禁用 + notify.sh 残留旧接口名
   现象：集群中三台主机的 keepalived 均已安装配置，但 ip addr show ztpp6n6xmz 上看不到 VIP 10.0.0.100，访问 10.0.0.100:5432（写）、:5433（读）、:6443（K3s API）全部失败。

   排查过程：

   • 三台 systemctl is-active keepalived 均为 inactive，is-enabled 为 disabled —— keepalived 服务根本没运行；
   • 配置文件和脚本（keepalived.conf、chk_haproxy.sh、notify.sh）都完好，权限正确；
   • 启动 keepalived 后 VIP 出现，但 haproxy 未被自动拉起，5432 仍不通。

   根因有三个：

   • keepalived 服务被禁用：历史操作中（如文档”停止并禁用 haproxy keepalived，由 keepalived 控制 HAProxy 启停”的某次执行）把 keepalived 也停用且未再启用，导致 VRRP 从未运行；
   • notify.sh 中 DEV="wg0" 残留：从 WireGuard（接口 wg0）迁移到 ZeroTier（接口 ztpp6n6xmz）后，notify.sh 里的 DEV 没同步更新。进入 MASTER 状态时执行 ip addr show wg0 失败 → exit 1 → 永远不会启动 haproxy；
   • priority 配置与设计不符：实际为 server=100、txy=100（平级）、aly=30，无法保证 server 优先。应改为 server=100、txy=90、aly=80。

   修复步骤：

   1
   # 1. 修正三台 notify.sh 的接口名（wg0 → ztpp6n6xmz）
   2
   sudo sed -i 's/DEV="wg0"/DEV="ztpp6n6xmz"/' /etc/keepalived/notify.sh
   3
   
   4
   # 2. 修正优先级（server=100、txy=90、aly=80）
   5
   #    在 txy 上：sed -i 's/priority 100/priority 90/' /etc/keepalived/keepalived.conf
   6
   #    在 aly 上：sed -i 's/priority 30/priority 80/' /etc/keepalived/keepalived.conf
   7
   
   8
   # 3. 启动并启用三台 keepalived
   9
   sudo systemctl start keepalived
   10
   sudo systemctl enable keepalived
   11
   
   12
   # 4. 解除 chk_haproxy 与 haproxy 绑定的双重死锁
   13
   #    (a) haproxy 监听 VIP，只有持有 VIP 的节点能启动它；
   14
   #    (b) chk_haproxy 检查 haproxy，haproxy 未起则优先级被降低、丢失 MASTER。
   15
   #    因此需先手动在目标 MASTER 节点绑定 VIP 并启动 haproxy，再重启 keepalived：
   16
   sudo ip addr add 10.0.0.100/32 dev ztpp6n6xmz   # 在期望的 MASTER 节点上
   17
   sudo systemctl reset-failed haproxy              # 清除之前 bind 失败累积的 failed 状态
   18
   sudo systemctl start haproxy                     # 现在能绑定 VIP，正常启动
   19
   sudo systemctl restart keepalived                # server(100) 重新竞选并稳定持有 VIP

   验证：

   1
   # MASTER 节点应持有 VIP（应为 server/10.0.0.10）
   2
   ip addr show ztpp6n6xmz | grep 10.0.0.100
   3
   # 三个端口均通
   4
   timeout 3 bash -c "cat < /dev/null > /dev/tcp/10.0.0.100/5432" && echo "5432 通"
   5
   timeout 3 bash -c "cat < /dev/null > /dev/tcp/10.0.0.100/5433" && echo "5433 通"
   6
   timeout 3 bash -c "cat < /dev/null > /dev/tcp/10.0.0.100/6443" && echo "6443 通"

   IMPORTANT

   网络方案变更后必须检查所有引用旧接口名的脚本。从 WireGuard 切换到 ZeroTier 时，notify.sh、keepalived.conf、haproxy.cfg 中的 wg0 都可能残留，逐一替换为 ztpp6n6xmz。

   chk_haproxy、notify、haproxy 绑定 VIP 三者存在循环依赖：haproxy 靠 notify 启动，chk_haproxy 又检查 haproxy，而 haproxy 只监听 VIP（无 VIP 绑定即启动失败）。首次部署时需手动 ip addr add VIP + systemctl start haproxy 打破死锁，此后 keepalived 即可自行管理。

   priority 必须严格递减且不相等：三台节点优先级需各不相同（如 100/90/80），保证明确的竞选顺序；出现平级时，谁先启动/先恢复健康谁就赢得 MASTER，无法保证指定节点优先。

8. VIP 漂移后其他节点 ARP 缓存残留，出现 ICMP Redirect
   现象：VIP 从旧 MASTER 漂移到新 MASTER（如从 txy 到 server）后，新加入集群的节点（如 WSL2 的 10.0.0.20）ping 10.0.0.100 能通，但输出中出现大量：

   1
   64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=32.1 ms
   2
   From 10.0.0.30 icmp_seq=2 Redirect Host(New nexthop: 10.0.0.100)

   原因：notify.sh 的 master 分支只启动了 haproxy，没有发送免费 ARP（gratuitous ARP）。VIP 漂移后，其他节点的 ARP 缓存仍残留旧 MASTER 的 MAC，数据包先发给旧 MASTER，旧 MASTER 回 ICMP Redirect 告知”VIP 同网段，直接发”。ip neigh 中 10.0.0.100 甚至显示 FAILED，直到缓存自然过期（STALE→FAILED→重新解析）才恢复。

   解决：在 notify.sh 的 master 分支加入免费 ARP 通告：

   1
   # 安装 arping（iputils-arping 提供）
   2
   sudo apt install -y iputils-arping
   3
   
   4
   # notify.sh master 分支中加入（见 5.2 完整脚本）：
   5
   ip neigh flush dev $DEV
   6
   arping -c 5 -A -I $DEV $VIP 2>/dev/null || \
   7
   arping -c 5 -U -I $DEV $VIP 2>/dev/null || true

   验证：VIP 漂移后，其他节点 ip neigh 应立即指向新 MASTER 的 MAC（REACHABLE），ping 10.0.0.100 无 ICMP Redirect、0% 丢包。

   IMPORTANT

   VIP 漂移后必须主动通告 ARP。Keepalived 自身在 master 时会发免费 ARP，但 ZeroTier 二层网络 + 单播 VRRP 环境下可能不可靠，建议在 notify.sh 显式 arping 通告，确保所有节点 ARP 缓存即时更新，避免短暂不通或 ICMP Redirect。

9. 系统重启后 keepalived 因 ZeroTier 接口未就绪而启动失败
   现象：主机重启后，三台 keepalived 全部 failed，VIP 消失，日志报：

   1
   Non-existent interface specified in configuration
   2
   pid <PID> exited with permanent error CONFIG. Terminating

   原因：keepalived 依赖 ZeroTier 接口 ztpp6n6xmz 存在才能通过配置校验。但 keepalived 的 systemd unit 只依赖 network-online.target，没有声明对 zerotier-one.service 的依赖。重启时 ZeroTier 尚未把接口创建出来，keepalived 先启动即报接口不存在，随后因 CONFIG 错误退出（status=2/INVALIDARGUMENT）。

   解决：为 keepalived 添加对 zerotier-one 的启动依赖（drop-in 方式，三台节点均需）：

   1
   sudo mkdir -p /etc/systemd/system/keepalived.service.d
   2
   sudo tee /etc/systemd/system/keepalived.service.d/zerotier.conf << 'EOF'
   3
   [Unit]
   4
   After=zerotier-one.service network-online.target
   5
   Wants=zerotier-one.service network-online.target
   6
   Requires=zerotier-one.service
   7
   EOF
   8
   sudo systemctl daemon-reload

   IMPORTANT

   依赖 ZeroTier 接口的服务都需声明启动顺序。与踩坑记录 6（etcd）同理：keepalived、patroni、etcd 等绑定 10.0.0.x 或依赖 ztpp6n6xmz 的服务，都应通过 drop-in 添加 After=zerotier-one.service + Requires=zerotier-one.service，否则重启后可能因接口未就绪而启动失败。

   首启竞态：即使依赖配好，keepalived 首次进入 MASTER 时，chk_haproxy 仍可能在 haproxy 就绪前失败，导致 notify 的 systemctl start haproxy 失败。若 VIP 端口不通，手动 systemctl start haproxy 一次即可，后续 keepalived 自行管理。

九、总结#

通过切换到 ZeroTier 并配合 Keepalived + HAProxy，我们在三节点虚拟二层网络上成功构建了一个更简洁、更稳定的接入层：

• PostgreSQL 读写分离 完全自动化，无需应用修改连接逻辑，跟随 Patroni 角色动态调整。
• K3s API Server 高可用 隐藏了后端节点细节，任意节点宕机不影响 kubectl 访问。
• VIP 高可用 利用 ZeroTier 的二层多播能力，直接使用标准 VRRP，无需单播，配置极简，毫秒级切换。

这套方案轻量、无外部依赖，非常适合中小规模的自建高可用集群。如果后续需要增强读一致性，还可以基于 Patroni 的 /sync 端点添加同步读端口。希望本文能帮助你在类似场景下快速落地。