绵羊料理1. 为什么需要Keepalived高可用架构
在云原生环境中，服务的高可用性不是可选项而是必选项。我经历过一次线上事故：某台Nginx服务器突然宕机，导致整个电商平台的支付接口不可用，直接损失超过百万。这次惨痛教训让我深刻认识到，单点故障是系统架构中最危险的定时炸弹。
Keepalived正是为解决这类问题而生的轻量级高可用方案。它通过VRRP协议（Virtual Router Redemption Protocol）实现IP地址的自动漂移，当主节点故障时，备节点能在秒级完成接管。相比Kubernetes原生的服务发现机制，Keepalived更适合需要固定VIP（Virtual IP）的场景，比如：
- 传统应用向云原生迁移的过渡阶段
- 数据库、中间件等有状态服务
- 需要与硬件负载均衡器配合的混合架构
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实验环境搭建与核心配置解析
2.1 基础环境准备
这次实验我使用了两台CentOS 7.9虚拟机，配置如下：
| 节点 | IP地址 | 角色 | 配置 |
|---|---|---|---|
| node1 | 192.168.1.10 | Master | 2C4G |
| node2 | 192.168.1.11 | Backup | 2C4G |
| VIP | 192.168.1.100 | - | - |
关键依赖安装：
bash复制# 两节点均需执行
yum install -y keepalived ipvsadm
systemctl enable keepalived
2.2 Keepalived核心配置详解
主节点配置文件（/etc/keepalived/keepalived.conf）：
conf复制global_defs {
router_id LVS_DEVEL # 唯一标识，建议用主机名
}
vrrp_instance VI_1 {
state MASTER # 初始状态
interface eth0 # 监听网卡
virtual_router_id 51 # 组ID，主备必须相同
priority 100 # 优先级(1-254)
advert_int 1 # 心跳间隔(秒)
authentication {
auth_type PASS
auth_pass 1111 # 密码，主备需一致
}
virtual_ipaddress {
192.168.1.100/24 # 虚拟IP
}
}
备节点只需修改两处：
conf复制state BACKUP
priority 90 # 必须低于主节点
关键经验：生产环境中建议配置notify脚本，通过企业微信/钉钉发送状态变更通知，我在/etc/keepalived/notify.sh中实现了这个功能。
3. 高可用测试与故障转移演练
3.1 基础功能验证
启动服务后，通过ip addr命令观察VIP绑定情况：
bash复制# 在主节点执行
ip addr show eth0 | grep 192.168.1.100
# 应看到：inet 192.168.1.100/24 scope global secondary eth0
# 模拟主节点宕机
systemctl stop keepalived
# 观察备节点是否在3秒内接管VIP
3.2 脑裂问题防护实战
在早期实践中，我遇到过因网络分区导致的脑裂问题——两个节点同时声称自己是Master。解决方案是在配置中添加：
conf复制vrrp_script chk_nginx {
script "/usr/bin/killall -0 nginx" # 检查nginx进程是否存在
interval 2 # 检查间隔
weight -20 # 检测失败时降低优先级
}
track_script {
chk_nginx
}
这样当Nginx异常时，节点会自动降权触发切换。实测中这个机制成功拦截了多次因应用层故障导致的假高可用。
4. 生产级优化方案
4.1 多VIP场景配置
实际项目往往需要多个VIP对应不同服务：
conf复制vrrp_instance VI_2 {
state MASTER
interface eth0
virtual_router_id 52 # 必须与VI_1不同
priority 100
virtual_ipaddress {
192.168.1.101/24
}
}
4.2 与Docker/K8s集成
在容器环境中，需要特殊处理网络命名空间：
bash复制# 启动容器时添加参数
docker run --net=host --cap-add=NET_ADMIN ...
K8s中建议通过DaemonSet部署，并配置hostNetwork: true。我整理过一份典型配置模板：
yaml复制apiVersion: apps/v1
kind: DaemonSet
metadata:
name: keepalived
spec:
template:
spec:
hostNetwork: true
containers:
- name: keepalived
image: osixia/keepalived:2.0.20
securityContext:
capabilities:
add: ["NET_ADMIN"]
4.3 监控与日志分析
通过Prometheus监控VRRP状态：
bash复制# 安装exporters
yum install -y keepalived-exporter
# 示例告警规则
- alert: VRRPStateChange
expr: keepalived_vrrp_state != 1
for: 1m
labels:
severity: critical
annotations:
summary: "Keepalived state changed on {{ $labels.instance }}"
日志分析技巧：grep "Transition to MASTER" /var/log/messages 可统计切换次数，我曾在日志中发现因网卡抖动导致的频繁切换，最终通过调整advert_int参数解决。
5. 常见陷阱与排查指南
5.1 防火墙配置误区
最常见的问题是忘记放行VRRP协议（IP协议号112）：
bash复制# 正确做法
firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
firewall-cmd --reload
5.2 虚拟路由ID冲突
当同一局域网存在多套Keepalived集群时，必须确保每个实例的virtual_router_id唯一。有次故障排查6小时，最终发现是因为测试环境复制配置时忘了改这个ID。
5.3 真实案例：MTU不匹配
某次跨云部署中，主备节点虽然能通信但无法切换。tcpdump抓包发现：
code复制16:32:45.123456 IP node1 > node2: VRRPv2-advert 112: vrid 51 prio 100 authtype simple intvl 1
16:32:45.123789 IP node2 > node1: VRRPv2-advert 112: vrid 51 prio 90 authtype simple intvl 1
但节点始终收不到对方通告。最终发现是主节点MTU=1500，备节点因云厂商限制MTU=1450，通过ifconfig eth0 mtu 1450调整后恢复正常。
6. 性能调优实战记录
在百万级并发场景下，默认配置可能出现心跳丢失。通过以下调整实现稳定运行：
- 调整内核参数：
bash复制echo "net.ipv4.conf.all.arp_ignore = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.arp_announce = 2" >> /etc/sysctl.conf
sysctl -p
- 优化Keepalived配置：
conf复制vrrp_instance VI_1 {
...
garp_master_delay 10 # 成为master后延迟发送GARP
garp_master_refresh 60 # 定期刷新GARP
debug 1 # 生产环境建议关闭
}
- 使用优先级动态调整：
conf复制vrrp_script chk_load {
script "/etc/keepalived/check_load.sh"
interval 5
weight 50
}
这个check_load.sh脚本会根据系统负载动态调整优先级，实测将故障转移时间从5秒缩短到2秒内。