Keepalived on Liangweidong's blog

高可用负载均衡：Nginx + Keepalived 编译与 VIP 漂移

Thu, 15 Feb 2024 00:00:00 +0800

为什么需要 Nginx + Keepalived

K8s 1.28 集群 3 个 master 上的 kube-apiserver 监听 6443 端口，但是：

worker 节点上的 kubelet 不会写死某个 master IP——它们需要一个虚拟入口
kubectl 客户端也希望只配置一个 server 地址
多个 master 之间的负载需要均衡

业界主流方案是 Nginx 4 层 stream 反代 + Keepalived VIP 漂移：

Nginx 用 stream 块做 TCP 4 层反代（不是 7 层 HTTP），把 10443 端口收到的请求分发到 3 个 master 的 6443
Keepalived 用 VRRP 协议做 VIP 漂移（抢占模式必须 nopreempt），3 个 master 只有一个是 MASTER，2 个 BACKUP

适用版本：nginx 1.24.0 / keepalived 2.2.8 / Ubuntu 22.04 部署位置：master1、master2（只在 2 台上部署，master3 上可装可不装，但 stream 配置要一样）

1. 编译安装 Nginx

1.1 编译依赖

1

apt install -y make g++ openssl libssl-dev libpcre3 libpcre3-dev zlib1g-dev libgd-dev

1.2 编译配置

关键参数：--with-stream（4 层反代）、--with-stream_ssl_module（TLS 透传）、--with-http_ssl_module（7 层 HTTPS）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cd /data/softs
tar xf nginx-1.24.0.tar.gz && cd nginx-1.24.0

./configure \
 --prefix=/usr/local/nginx \
 --with-http_ssl_module \
 --with-http_stub_status_module \
 --with-pcre \
 --with-http_gzip_static_module \
 --with-stream \
 --with-stream_ssl_module

make && make install

如果还要支持 --with-stream_ssl_preread_module（按 SNI 分流），需要二次编译：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


./configure \
 --prefix=/usr/local/nginx \
 --with-http_ssl_module \
 --with-http_stub_status_module \
 --with-pcre \
 --with-http_gzip_static_module \
 --with-stream \
 --with-stream_ssl_module \
 --with-stream_ssl_preread_module

make
# 备份旧的
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx_bak
# 替换
cp objs/nginx /usr/local/nginx/sbin/

1.3 解决 libpcre.so.1 not found

1
2
3
4


# 查依赖
ldd $(which /usr/local/nginx/sbin/nginx)
# libpcre.so.1 => not found
# 解决：编译时加 --with-pcre=../pcre-xxx 源码路径，或安装 libpcre3-dev

2. Nginx 配置

2.1 主配置 nginx.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


worker_processes 1;
events {
 worker_connections 1024;
}
http {
 include mime.types;
 default_type application/octet-stream;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 sendfile on;
 keepalive_timeout 65;
 autoindex on;
 gzip on;
 gzip_buffers 32 4K;
 gzip_comp_level 6;
 gzip_min_length 1k;
 gzip_types application/javascript text/css text/xml;
 gzip_disable "MSIE [1-6]\.";
 gzip_http_version 1.1;
 gzip_vary on;

 client_body_buffer_size 1024k;
 client_max_body_size 2048m;
 client_header_buffer_size 128k;
 large_client_header_buffers 4 128k;

 proxy_buffer_size 256k;
 proxy_buffering on;
 proxy_buffers 64 128k;
 proxy_busy_buffers_size 512k;

 fastcgi_buffers 6 512k;
 fastcgi_buffer_size 512k;
 fastcgi_busy_buffers_size 512k;
 fastcgi_temp_file_write_size 512k;
 fastcgi_intercept_errors on;

 include conf.d/*.conf;
}
stream {
 log_format proxy '[$time_local] $protocol status:$status, bytes client:$bytes_sent/$bytes_received $session_time, '
 'client: $remote_addr, upstream:"$upstream_addr", '
 'bytes upstream:$upstream_bytes_sent $upstream_bytes_received $upstream_connect_time';
 include stream/*.conf;
}

2.2 stream 反代 kube-apiserver

stream/stream.conf：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


upstream k8sapiserver {
 hash $remote_addr consistent;
 server <master1-ip>:6443 max_fails=3 fail_timeout=30s;
 server <master2-ip>:6443 max_fails=3 fail_timeout=30s;
 server <master3-ip>:6443 max_fails=3 fail_timeout=30s;
}
server {
 error_log logs/10443_error.log;
 access_log logs/10443_access.log proxy;
 listen 10443;
 proxy_connect_timeout 1s;
 proxy_pass k8sapiserver;
}

2.3 测试页 conf.d/default.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


server {
 listen 10088;
 server_name localhost;
 error_log logs/10088_error.log;
 access_log logs/10088_access.log;

 location / {
 root html;
 index index.html index.htm;
 }
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }
}

2.4 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


[Unit]
Description=kube-apiserver nginx proxy
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx
ExecReload=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx -s reload
PrivateTmp=true
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4
5
6
7
8
9


systemctl daemon-reload
systemctl enable --now nginx.service
systemctl status nginx.service
journalctl -f -u nginx.service

# 验证（区分两台机器的页面）
sed -i "s#Welcome to nginx#Welcome to nginx master1#g" /usr/local/nginx/html/index.html
curl <master1-ip>:10088
curl <master2-ip>:10088

3. Keepalived 编译与配置

3.1 编译安装

1
2
3
4
5
6
7
8


cd /data/softs
tar xf keepalived-2.2.8.tar.gz && cd keepalived-2.2.8

./configure --prefix=/usr/local/keepalived
make && make install
cd .. && rm -rf keepalived-2.2.8

mkdir -p /usr/local/keepalived/conf

3.2 健康检查脚本

check_nginx.sh：每 2 秒检查一次 nginx，挂了先重启；重启失败就让 keepalived 主动降权让 VIP 漂走。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


cat << "EOF" > /usr/local/keepalived/conf/check_nginx.sh
#!/bin/bash
url="http://127.0.0.1:10088"
code=`curl -s -o /dev/null -w %{http_code} $url`
if [ $code -ne 200 ]; then
 /usr/bin/systemctl start nginx
 sleep 2
 code=`curl -s -o /dev/null -w %{http_code} $url`
 if [ $code -ne 200 ]; then
 /usr/bin/systemctl stop keepalived
 fi
fi
EOF

chmod +x /usr/local/keepalived/conf/check_nginx.sh

必须：脚本用 HTTP 200 判断，不能用 ps -C nginx——多 worker 进程下 ps 不可靠。

3.3 keepalived.conf（master1）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


global_defs {
 router_id LVS_DEVEL
 vrrp_skip_check_adv_addr
 vrrp_garp_interval 0
 vrrp_gna_interval 0
}
vrrp_script check_nginx {
 script "/usr/local/keepalived/conf/check_nginx.sh"
 interval 2
 weight -2
}
vrrp_instance VI_1 {
 state MASTER
 interface eno1 # 网卡名按机器实际改
 mcast_src_ip <master1-ip>
 virtual_router_id 51
 priority 100
 advert_int 2
 nopreempt # **关键**：不抢占，主恢复后 VIP 不会自动抢回
 authentication {
 auth_type PASS
 auth_pass K8SHA_KA_AUTH
 }
 virtual_ipaddress {
 <vip-internal>
 <vip-public>
 }
 track_script {
 check_nginx
 }
}

3.4 keepalived.conf（master2）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


global_defs { router_id LVS_DEVEL ... }
vrrp_script check_nginx { script ".../check_nginx.sh"; interval 2; weight -2; }
vrrp_instance VI_1 {
 state BACKUP # BACKUP 角色
 interface eno1
 mcast_src_ip <master2-ip>
 virtual_router_id 51 # 必须和 master1 一致
 priority 80 # 比 MASTER 低
 advert_int 2
 nopreempt
 authentication { auth_type PASS; auth_pass K8SHA_KA_AUTH; }
 virtual_ipaddress { <vip-internal> <vip-public> }
 track_script { check_nginx; }
}

3.5 keepalived.conf（master3，可选）

1
2
3
4


state BACKUP
priority 60
virtual_router_id 51
... (其余同 master2)

3.6 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[Unit]
Description=VRRP High Availability Monitor
After=network-online.target syslog.target
Wants=network-online.target
Documentation=https://keepalived.org/manpage.html

[Service]
Type=forking
KillMode=process
ExecStart=/usr/local/keepalived/sbin/keepalived -D -f /usr/local/keepalived/conf/keepalived.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4
5


systemctl daemon-reload
systemctl enable --now keepalived
systemctl restart keepalived
systemctl status keepalived
journalctl -f -u keepalived

打包已安装的 keepalived 用于其他节点：

1
2
3


cd /usr/local
tar -zcvf keepalived.tar.gz keepalived
scp keepalived.tar.gz master2:/usr/local/

4. 跨机房 VIP（Unicast 模式）

如果两个机房之间是 L3 路由（不是同 L2），VRRP 多播会被丢，需要切到单播模式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


vrrp_instance VI_1 {
 state MASTER
 interface eno1
 virtual_router_id 51
 priority 100
 advert_int 1
 unicast_src_ip <this-node-ip>
 unicast_peer {
 <peer-node-ip> # 另一机房的对端 IP
 }
 authentication { auth_type PASS; auth_pass 1111; }
 virtual_ipaddress { <vip-cross-dc> }
}

unicast_src_ip + unicast_peer 显式指定对端，绕过 VRRP 多播。

5. 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 验证 VIP
curl <vip-internal>:10088

# 停 master1 模拟故障
ssh master1 "systemctl stop keepalived"
# VIP 应该在 1-3 秒内漂到 master2

# 启动 master1 keepalived
ssh master1 "systemctl start keepalived"
# 因为 nopreempt，VIP 不会回到 master1，仍在 master2 上

6. 常见问题

6.1 ping 不通 VIP

ARP 缓存未刷新。在 client 上：

1
2


# 清理 ARP 缓存
arp -n | awk '/^[1-9]/{print "arp -d " $1}' | sh

或等 30 秒（ARP 默认老化时间）。

6.2 不同网段 ping 不通

防火墙或路由限制。检查 iptables -L -n 与 ip route。

6.3 VIP 漂移后不能自动启动

健康检查脚本没成功。先手动跑：

1

bash /usr/local/keepalived/conf/check_nginx.sh

6.4 master3 也想加 VIP 漂移

把 master3 也装 nginx + keepalived，配置 state BACKUP + priority 60 即可。

7. 小结

Nginx stream 4 层 + Keepalived VIP 是 K8s 1.20+ 时代最稳的 apiserver HA 方案。几个关键点：

nginx 必须 --with-stream 编译
keepalived 必须 nopreempt（否则主备反复切换时丢包）
健康检查用 HTTP 200 不用 ps
跨机房用 unicast_src_ip + unicast_peer 替代多播

下一步：etcd 3.5 集群二进制部署与 TLS 证书签发。

K8s API Server 高可用：Nginx 四层 + Keepalived VIP 漂移

Mon, 15 Mar 2021 00:00:00 +0800

写于 2021-03，背景：K8s 1.21 GA 阶段，二进制高可用部署仍然是国内大厂主流。本文用编译版 Nginx 1.24 + Keepalived 2.2 实现 API Server 的统一入口 VIP 漂移。

一、为什么需要 VIP

3 master 集群时，apiserver 监听在 3 个不同 IP:6443：

1
2
3


master1 → 192.168.139.133:6443
master2 → 192.168.139.134:6443
master3 → 192.168.139.135:6443

但 kubectl 只能配 1 个 --server：

1
2


kubectl --server=https://192.168.139.133:6443 get nodes
# 如果 master1 挂了？

解决思路：在 master 节点前再加一层"虚拟 IP"，3 个 master 通过 VRRP 协议竞选 VIP，VIP 永远在 1 个能用的 master 上。

1
2
3
4
5


kubectl → VIP:6443 (192.168.139.150)
 ↓ VRRP
 ┌────┴────┬────────┐
 master1 master2 master3
 :6443 :6443 :6443

二、方案选型

方案	优点	缺点
Nginx + Keepalived	成熟稳定，二层/四层都能做	需要编译
HAProxy + Keepalived	性能比 Nginx 高	配置稍复杂
Envoy + Keepalived	支持高级路由	太重
公有云 SLB	零运维	绑定云厂商

本文选 Nginx stream + Keepalived——最常见、配置清晰。

三、集群规划

主机名	IP	角色
master1	192.168.139.133	nginx + keepalived MASTER
master2	192.168.139.134	nginx + keepalived BACKUP
master3	192.168.139.135	nginx + keepalived BACKUP
VIP	192.168.139.150	漂移地址

端口约定：

apiserver：6443
nginx stream 监听：8443（外部访问 VIP:8443 → 内部 apiserver 6443）
keepalived VRRP：协议号 112

四、编译 Nginx（master1 + master2）

只在两台装 nginx + keepalived 即可（master3 不需要，节省资源）。如果所有 3 台都装，keepalived 仍能正常选举。

4.1 装编译依赖

1

apt install -y make g++ openssl libssl-dev libpcre3 libpcre3-dev zlib1g-dev libgd-dev

4.2 编译 Nginx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cd /k8s/softs
tar xf nginx-1.24.0.tar.gz && cd nginx-1.24.0

./configure \
 --prefix=/usr/local/nginx \
 --with-http_ssl_module \
 --with-http_stub_status_module \
 --with-pcre \
 --with-http_gzip_static_module \
 --with-stream \
 --with-stream_ssl_module

make -j$(nproc) && make install

关键参数：**--with-stream**（TCP 四层代理），**--with-stream_ssl_module**（与 apiserver HTTPS 通信）

4.3 Nginx 主配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


cat > /usr/local/nginx/conf/nginx.conf << 'EOF'
worker_processes 1;
events {
 worker_connections 1024;
}
http {
 include mime.types;
 default_type application/octet-stream;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 sendfile on;
 keepalive_timeout 65;
 autoindex on;
 gzip on;
 gzip_buffers 32 4K;
 gzip_comp_level 6;
 gzip_min_length 1k;
 gzip_types application/javascript text/css text/xml;
 gzip_disable "MSIE [1-6]\.";
 gzip_http_version 1.1;
 gzip_vary on;

 client_body_buffer_size 1024k;
 client_max_body_size 2048m;

 client_header_buffer_size 128k;
 large_client_header_buffers 4 128k;

 proxy_buffer_size 256k;
 proxy_buffering on;
 proxy_buffers 64 128k;
 proxy_busy_buffers_size 512k;

 include conf.d/*.conf;
}

stream {
 log_format proxy '[$time_local] $protocol status:$status, '
 'client: $remote_addr, upstream:"$upstream_addr", '
 'bytes: $bytes_sent/$bytes_received '
 'time: $session_time/$upstream_connect_time';

 include stream/*.conf;
}
EOF

mkdir -p /usr/local/nginx/conf/{conf.d,stream}

4.4 stream 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


cat > /usr/local/nginx/conf/stream/stream.conf << 'EOF'
upstream k8sapiserver {
 hash $remote_addr consistent;
 server 192.168.139.133:6443 max_fails=3 fail_timeout=30s;
 server 192.168.139.134:6443 max_fails=3 fail_timeout=30s;
 server 192.168.139.135:6443 max_fails=3 fail_timeout=30s;
}

server {
 error_log logs/8443_error.log;
 access_log logs/8443_access.log proxy;
 listen 8443;
 proxy_connect_timeout 1s;
 proxy_pass k8sapiserver;
}
EOF

关键参数：

hash $remote_addr consistent：同一客户端始终连同一后端（会话保持）
max_fails=3 fail_timeout=30s：3 次失败标记 down，30 秒后重试
proxy_connect_timeout 1s：连不上后端立即失败，让 keepalived 切主

五、systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


[Unit]
Description=kube-apiserver nginx proxy
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx
ExecReload=/bin/kill -s HUP $MAINPID
PrivateTmp=true
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4


systemctl daemon-reload
systemctl enable --now kube-nginx
systemctl status kube-nginx
curl 192.168.139.133:8443 # 不报错即可

六、Keepalived 配置

6.1 编译 Keepalived（master1 + master2）

1
2
3
4
5


cd /k8s/softs
tar xf keepalived-2.2.8.tar.gz && cd keepalived-2.2.8
./configure --prefix=/usr/local/keepalived
make -j$(nproc) && make install
mkdir -p /usr/local/keepalived/conf

6.2 健康检查脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


cat > /usr/local/keepalived/conf/check_nginx.sh << 'EOF'
#!/bin/bash
A=$(ps -C nginx --no-header | wc -l)
if [ $A -eq 0 ]; then
 /usr/bin/systemctl start kube-nginx
 sleep 2
 if [ $(ps -C nginx --no-header | wc -l) -eq 0 ]; then
 /usr/bin/systemctl stop kube-keepalived
 fi
fi
EOF
chmod +x /usr/local/keepalived/conf/check_nginx.sh

逻辑：nginx 挂了 → 尝试重启 → 启不来就停 keepalived，让 VIP 漂到其他节点。

6.3 master1 配置（priority 100 = MASTER）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


cat > /usr/local/keepalived/conf/kube-keepalived.conf << 'EOF'
global_defs {
 router_id LVS_DEVEL
}
vrrp_script check_nginx {
 script "/usr/local/keepalived/conf/check_nginx.sh"
 interval 5
 weight -5
 fall 2
 rise 1
}
vrrp_instance VI_1 {
 state MASTER
 interface ens33
 mcast_src_ip 192.168.139.133
 virtual_router_id 51
 priority 100
 nopreempt
 advert_int 2
 authentication {
 auth_type PASS
 auth_pass K8SHA_KA_AUTH
 }
 virtual_ipaddress {
 192.168.139.150
 }
 track_script {
 check_nginx
 }
}
EOF

6.4 master2 配置（priority 90 = BACKUP）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


cat > /usr/local/keepalived/conf/kube-keepalived.conf << 'EOF'
global_defs {
 router_id LVS_DEVEL
}
vrrp_script check_nginx {
 script "/usr/local/keepalived/conf/check_nginx.sh"
 interval 5
 weight -5
 fall 2
 rise 1
}
vrrp_instance VI_1 {
 state BACKUP
 interface ens33
 mcast_src_ip 192.168.139.134
 virtual_router_id 51
 priority 90
 nopreempt
 advert_int 2
 authentication {
 auth_type PASS
 auth_pass K8SHA_KA_AUTH
 }
 virtual_ipaddress {
 192.168.139.150
 }
 track_script {
 check_nginx
 }
}
EOF

关键参数：

virtual_router_id 51：同一集群必须一致（不同集群必须不同！）
priority 100 > 90：数字大 = 高优先级
nopreempt：原 master 恢复后不抢回 VIP（避免脑裂）
track_script：nginx 挂了直接降 priority 5，触发 VIP 漂移
auth_pass K8SHA_KA_AUTH：明文 VRRP 认证，生产请用 16 位随机字符串

6.5 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[Unit]
Description=VRRP High Availability Monitor
After=network-online.target syslog.target
Wants=network-online.target
Documentation=https://keepalived.org/manpage.html

[Service]
Type=forking
KillMode=process
ExecStart=/usr/local/keepalived/sbin/keepalived -D -f /usr/local/keepalived/conf/kube-keepalived.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4


systemctl daemon-reload
systemctl enable --now kube-keepalived
systemctl status kube-keepalived
journalctl -f -u kube-keepalived

七、验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# master1 上看 VIP 是否绑定
ip addr show ens33
# inet 192.168.139.133/24 ...
# inet 192.168.139.150/32 ... ← 看到这行说明 VIP 成功

# 验证 VIP 可访问 apiserver
curl -k https://192.168.139.150:8443/version
# {
# "major": "1",
# "gitVersion": "v1.28.5",
# ...
# }

配置 kubectl 使用 VIP：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


mkdir -p ~/.kube
cat > ~/.kube/config << EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
 server: https://192.168.139.150:8443
 certificate-authority-data: <base64 编码的 ca.pem>
 name: kubernetes
contexts:
- context:
 cluster: kubernetes
 user: kubernetes-admin
 name: default
current-context: default
users:
- name: kubernetes-admin
 user:
 client-certificate-data: <base64 编码的 admin.pem>
 client-key-data: <base64 编码的 admin-key.pem>
EOF

kubectl get nodes

八、故障演练

8.1 模拟 master1 整机宕机

1
2


# 在 master1 上
shutdown -h now

观察 master2：

1
2
3
4
5
6
7


# master2 上
ip addr show ens33
# inet 192.168.139.134/24 ...
# inet 192.168.139.150/32 ... ← VIP 漂到 master2

# 验证 VIP 仍可访问
curl -k https://192.168.139.150:8443/version

预期 5~10 秒后 VIP 漂到 master2，kubectl 无感。

8.2 模拟 master1 nginx 进程挂

1
2


# 在 master1 上
pkill nginx

观察：

check_nginx.sh 检测到 nginx 死 → 尝试 systemctl start kube-nginx
如果能起来：keepalived 继续，VIP 不漂
如果起不来（概率低）：脚本 systemctl stop kube-keepalived，VIP 强制漂走

8.3 恢复 master1

1
2


# master1
systemctl start kube-apiserver kube-nginx kube-keepalived

由于 nopreempt，VIP 不会抢回（继续在 master2）。这是有意设计——避免脑裂。

九、生产环境加固

关闭 mcast_src_ip 改 unicast（云环境 VRRP multicast 被禁用）：

1
2
3
4
5
6
7


vrrp_instance VI_1 {
 ...
 unicast_src_ip 192.168.139.133
 unicast_peer {
 192.168.139.134
 }
}

认证密码用随机 16 位：
1

openssl rand -base64 12
keepalived 配 3 台而不是 2 台：3 节点可以容忍 1 节点挂，2 节点只容忍 0 节点挂（脑裂风险大）。
监控 VIP：把 192.168.139.150 加入 Prometheus blackbox_exporter 监控。
DNS 解析：把 kubernetes-api.example.com 解析到 VIP，kubectl 用域名而不是 IP。

十、常见坑

virtual_router_id 不一致：3 节点 VRRP 选举失败
多播被防火墙挡：VRRP 协议号 112，iptables 默认会拦
nopreempt 没配：master1 恢复时把 VIP 抢回，可能导致短暂脑裂
check_nginx.sh 权限不足：keepalived 跑不了脚本，nginx 挂 VIP 不漂
VIP 绑定到错的 interface：interface ens33 配错网卡，VIP 上不去

十一、前置知识 / 下一步

前置：

nginx 编译与配置
keepalived VRRP 原理
kube-apiserver systemd 单元（参考 2020-12-15《K8s Master 三大组件》）

下一步：

K8s 集群插件（2021-09-15）—— CNI / CoreDNS / Metrics / Dashboard
K8s 集群管理（2021-12-15）—— 升级、节点隔离、排错

参考资料

HAProxy + Keepalived 高可用实战：Nginx 主备双机 + VIP 漂移

Thu, 15 Dec 2016 00:00:00 +0800

背景

单点故障是生产环境的头号杀手——一台 Nginx 挂了，整个网站就 502。

HA（High Availability） = 多台机器 + 故障自动切换，业内有两大经典方案：

方案	代表	适用
LVS + Keepalived	章文嵩博士	四层负载、性能极致
HAProxy + Keepalived	Willy Tarreau	四/七层、配置友好、社区活跃
Nginx + Keepalived	1.x / plus	七层、配置最简单

本篇方案：Nginx + Keepalived + HAProxy（可选用），经典"主备双机 + VIP 漂移"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


[客户端] ──> [VIP: 192.168.50.130]
 │ 
 │ ARP 通告 / VRRP 协议
 │
 ┌───────┴───────┐
 │ │
 [主节点 Master] [备节点 Backup]
 Keepalived Keepalived
 Nginx :80 Nginx :80 (standby)
 priority=100 priority=90
 │
 └─> [后端真实服务器池] (tomcat / gunicorn / ...)

故障切换流程：

主节点 Keepalived 心跳正常 → VIP 留在主节点
主节点 Nginx 挂了 → nginx_check.sh 检测失败
Keepalived 把自己的 priority 减 20
备节点 priority 100 > 主节点 80 → VIP 漂移到备节点
备节点 Nginx 接管服务（前提：备节点 Nginx 配置和数据一致）

一、HAProxy vs Nginx vs LVS

1.1 三者对比

维度	LVS	HAProxy	Nginx
工作层	四层（IP）	四/七层	七层（HTTP）
性能	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
功能	仅转发	丰富（健康检查、会话保持、统计）	反代、缓存、限流
配置复杂度	复杂（需要 ipvsadm）	中等	简单
社区	中国主导	法国/欧洲主导	俄罗斯主导
HA 角色	DR 模式性能最强	七层更智能	最简单

选型建议：

追求性能（十万 QPS 以上）：LVS
追求灵活（健康检查细、会话保持复杂）：HAProxy
追求简单（七层反代、HTTP 处理）：Nginx

1.2 为什么本篇选 Nginx + Keepalived

Nginx 已经是"事实标准"的反代，用 Nginx 做 HA 比 HAProxy 更省机器（HAProxy 当主、备各一台 + Nginx 后端，又多两层）。Keepalived 提供 VIP 漂移，简单可靠。

如果业务量大（单 VIP 扛不住 5w+ QPS），应该做"LVS DR + 多 Nginx"或"HAProxy + 多 Nginx"，不要在单 Nginx 上死磕。

二、安装

2.1 Keepalived 2.2.x

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Ubuntu
apt show keepalived
sudo apt install keepalived -y

# CentOS
yum install keepalived -y

# 验证
keepalived -v
# Keepalived v2.2.4 (08/21,2021)

systemd 管理：

1
2
3


systemctl enable keepalived
systemctl start keepalived
systemctl status keepalived

2.2 HAProxy 2.4.x（可选）

如果需要 HAProxy 做四层负载 + Nginx 后端：

1
2
3
4
5
6
7


# Ubuntu
apt show haproxy
sudo apt install haproxy -y

# 验证
haproxy -v
# HAProxy version 2.4.22-0ubuntu0.22.04.2 2023/08/14

systemd 管理：

1
2
3


systemctl enable haproxy
systemctl start haproxy
systemctl status haproxy

卸载：

1

sudo apt purge haproxy -y

三、HAProxy 配置（可选）

配置文件：/etc/haproxy/haproxy.cfg

3.1 最小可用配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


global
 log /dev/log local0
 log /dev/log local1 notice
 chroot /var/lib/haproxy
 stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
 stats timeout 30s
 user haproxy
 group haproxy
 daemon

 # Default SSL material locations
 ca-base /etc/ssl/certs
 crt-base /etc/ssl/private

 # Mozilla Intermediate
 ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
 ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
 log global
 mode http
 option httplog
 option dontlognull
 timeout connect 5000
 timeout client 50000
 timeout server 50000
 errorfile 400 /etc/haproxy/errors/400.http
 errorfile 403 /etc/haproxy/errors/403.http
 errorfile 408 /etc/haproxy/errors/408.http
 errorfile 500 /etc/haproxy/errors/500.http
 errorfile 502 /etc/haproxy/errors/502.http
 errorfile 503 /etc/haproxy/errors/503.http
 errorfile 504 /etc/haproxy/errors/504.http

3.2 反代后端

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Web 负载
frontend http-in
 bind *:80
 default_backend web-pool

backend web-pool
 balance roundrobin
 option httpchk GET /
 server web1 10.0.1.10:8080 check
 server web2 10.0.1.11:8080 check
 server web3 10.0.1.12:8080 check

# 统计页面
listen stats
 bind *:9000
 stats enable
 stats uri /stats
 stats auth admin:yourpassword

热加载（不中断）：

1
2


haproxy -c -f /etc/haproxy/haproxy.cfg # 验证
systemctl reload haproxy # 重新加载

四、Keepalived 配置（Nginx 主备）

4.1 关键概念

概念	含义
VRRP	Virtual Router Redundancy Protocol，虚拟路由冗余协议
VIP	Virtual IP，对外服务的 IP（飘在主节点网卡上）
priority	优先级（0-254），主高备低
nopreempt	不抢占模式（备升主后，原主恢复不再抢回）
advert_int	VRRP 通告间隔（秒），默认 1
virtual_router_id	VRRP 实例 ID（同组必须相同）
authentication	简单密码认证（防止误抢）
unicast_src_ip / unicast_peer	单播模式（云环境默认，组播被禁用）

4.2 主节点（Master）/etc/keepalived/keepalived.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


! Configuration File for keepalived
global_defs {
 # 标识本节点的字符串，通常为 hostname
 # hostnamectl set-hostname nginx-master1 设置
 router_id nginx-master1
}

# Nginx 健康检查脚本
vrrp_script chk_nginx {
 script "/etc/keepalived/nginx_check.sh"
 interval 2 # 每 2 秒检查一次
 weight -20 # 失败一次 priority -20
 fall 3 # 连续失败 3 次才算挂
 rise 2 # 连续成功 2 次才恢复
}

# 虚拟路由实例
vrrp_instance VI_1 {
 state MASTER # 主节点
 interface eth0 # 绑 VIP 的网卡（云主机可能是 eth1 / ens5）
 virtual_router_id 51 # 虚拟路由 ID（0-255），同组必须一致
 mcast_src_ip 192.168.50.133 # 本机真实 IP
 priority 100 # 主节点优先级（0-254）
 nopreempt # 不抢占（备升主后，原主恢复不再抢）
 advert_int 1 # 通告间隔 1 秒

 # 认证（两边必须一致）
 authentication {
 auth_type PASS
 auth_pass 1111
 }

 # 健康检查
 track_script {
 chk_nginx
 }

 # 虚拟 IP（对外服务的 IP）
 virtual_ipaddress {
 192.168.50.130/24 dev eth0
 }
}

4.3 备节点（Backup）/etc/keepalived/keepalived.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


! Configuration File for keepalived
global_defs {
 router_id nginx-backup1
}

vrrp_script chk_nginx {
 script "/etc/keepalived/nginx_check.sh"
 interval 2
 weight -20
 fall 3
 rise 2
}

vrrp_instance VI_1 {
 state BACKUP # 备节点
 interface eth0
 virtual_router_id 51 # 必须与主一致
 mcast_src_ip 192.168.50.134 # 备机真实 IP
 priority 90 # 备节点优先级（< 主）
 nopreempt
 advert_int 1

 authentication {
 auth_type PASS
 auth_pass 1111
 }

 track_script {
 chk_nginx
 }

 virtual_ipaddress {
 192.168.50.130/24 dev eth0
 }
}

4.4 健康检查脚本 /etc/keepalived/nginx_check.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


#!/bin/bash
# 检测 Nginx 是否存活，不存活就停止 keepalived，触发 VIP 漂移

A=$(ps -C nginx --no-heading | wc -l)
if [ "${A}" -eq 0 ]; then
 # 尝试启动 nginx
 systemctl start nginx
 sleep 2
 # 再查一次
 A=$(ps -C nginx --no-heading | wc -l)
 if [ "${A}" -eq 0 ]; then
 # 启动失败，停掉 keepalived，VIP 漂移到备
 systemctl stop keepalived
 fi
fi

权限与运行：

1

chmod +x /etc/keepalived/nginx_check.sh

4.5 启动

1
2


systemctl enable --now keepalived
systemctl status keepalived

查看 VIP 状态（主节点应有 VIP，备节点没有）：

1
2
3


ip addr show eth0
# 主节点：inet 192.168.50.130/24 ...（VIP 在）
# 备节点：没有 192.168.50.130

查看 VRRP 状态：

1
2
3


tail -f /var/log/syslog | grep -i vrrp
# VRRP_Instance(VI_1) Transition to MASTER STATE
# VRRP_Instance(VI_1) Entering MASTER STATE

五、故障切换演练

5.1 模拟主节点 Nginx 挂掉

1
2
3
4
5


# 在主节点
systemctl stop nginx
# 等 6 秒（fall=3 × interval=2）
# Keepalived 检测到 nginx 挂了，stop keepalived
# VIP 漂移到备节点

观察：

1
2
3
4
5
6
7


# 主节点
ip addr show eth0
# VIP 消失

# 备节点
ip addr show eth0
# VIP 出现 192.168.50.130

客户端视角：从浏览器访问 http://192.168.50.130，整个过程大概 6-10 秒有 502 错误，然后恢复。

5.2 主节点恢复（nopreempt 模式）

1
2
3
4


# 在原主节点
systemctl start nginx
# 启动 nginx，但 keepalived 还没启动
# 此时备节点继续服务（因为 nopreempt）

nopreempt 的意义：

不用 nopreempt → 原主恢复后会"抢回" VIP，两次切换造成额外中断
用 nopreempt → 原主恢复后保持 BACKUP，VIP 留在备，只在下次主挂时才回切

生产建议：用 nopreempt。避免"来回切换"的抖动。

5.3 强制回切（如果需要）

临时：手动在备节点 systemctl stop keepalived，VIP 漂回主。

永久：用 preempt_delay（Keepalived 1.3+）：

1
2
3
4
5
6


vrrp_instance VI_1 {
 state BACKUP
 priority 90
 preempt_delay 300 # 备升主后，5 分钟内原主恢复不回切
 ...
}

六、单播模式（云环境必看）

传统 VRRP 用组播（224.0.0.18），但云主机（阿里云、AWS、华为云）通常禁止组播。必须改单播：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


vrrp_instance VI_1 {
 state MASTER
 interface eth0
 virtual_router_id 51

 # 关闭组播
 # mcast_src_ip 192.168.50.133 ← 注释掉

 # 开启单播
 unicast_src_ip 192.168.50.133 # 本机真实 IP
 unicast_peer {
 192.168.50.134 # 对端真实 IP
 }

 priority 100
 ...
}

两个节点都要配（主备互换 unicast_src_ip 和 unicast_peer）。

七、Nginx + Keepalived 完整架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


 [客户端]
 │
 ↓
 [VIP 192.168.50.130]
 │
 ┌───────────────────────┴───────────────────────┐
 │ │ │
 [主 Nginx] [备 Nginx] [后端集群]
 10.0.1.10 10.0.1.11 10.0.1.20-30
 Keepalived MASTER Keepalived BACKUP Tomcat/...
 priority 100 priority 90
 │ │
 nginx -t / reload nginx -t / reload
 │ │
 /etc/nginx/conf.d/ /etc/nginx/conf.d/ ← rsync 同步
 ↓ ↓
 [共享后端 pool]

主备配置一致（用 rsync/ansible 同步）：

1
2
3


# 在主节点
rsync -avz /etc/nginx/ 10.0.1.11:/etc/nginx/
rsync -avz /var/www/ 10.0.1.11:/var/www/

自动化：用 lsyncd（inotify + rsync）实时同步，或用 etcd/consul 配置中心。

八、Keepalived 邮件告警（可选）

Keepalived 自带邮件提醒，需要 sendmail/postfix：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


global_defs {
 notification_email {
 admin@example.com
 }
 notification_email_from keepalived@example.com
 smtp_server 127.0.0.1
 smtp_connect_timeout 30
 router_id nginx-master1
}

vrrp_instance VI_1 {
 state MASTER
 smtp_alert # 启用邮件告警
 ...
}

建议用第三方监控代替（Zabbix/Prometheus），邮件告警延迟高、易被忽略。

九、常见问题

9.1 VIP 不漂移

症状：主 nginx 挂了，备节点 VIP 一直不来。

排查：

1
2
3
4
5
6
7


# 看 keepalived 日志
journalctl -u keepalived -f
# 或
tail -f /var/log/syslog | grep -i keepalived

# 看 VRRP 通信
tcpdump -i eth0 vrrp

常见原因：

virtual_router_id 不一致
auth_pass 不一致
防火墙没放 VRRP 协议（云环境）：
1

iptables -I INPUT -p vrrp -j ACCEPT
组播在云环境被禁用 → 改 unicast

9.2 脑裂（split-brain）

症状：主备同时持有 VIP，客户端有时连到主有时连到备。

原因：

主备之间通信中断（如防火墙、心跳网络故障）
两边都以为对方挂了

对策：

双心跳线：两条物理/逻辑链路
iptables 阻断：主检测到脑裂时自己 iptables drop VRRP 报文，主动让出 VIP
云环境：用云厂商的 HAVIP（高可用虚拟 IP）+ API 切换

9.3 VIP 配置后 ping 不通

1
2
3
4
5
6
7
8


# 看 VIP 是不是在网卡上
ip addr show eth0

# 看本地能否 ping 通
ping 192.168.50.130

# 看路由
ip route get 192.168.50.130

云环境特殊：AWS/阿里云 HAVIP 需要显式启用 ARP 响应。

9.4 keepalived 启动失败

1
2
3


# 详细日志
keepalived -D -f /etc/keepalived/keepalived.conf
# 看具体错误

十、卸载

1
2
3
4
5
6
7


systemctl stop keepalived
systemctl disable keepalived
apt remove keepalived -y
rm -rf /etc/keepalived

# 清理 VIP
ip addr del 192.168.50.130/24 dev eth0

小结

HAProxy + Keepalived 是"主备双机 + VIP 漂移"的经典方案：

Keepalived 提供 VIP 漂移（VRRP 协议）
Nginx 健康检查脚本触发 failover
nopreempt 模式避免来回切换
云环境用 unicast（组播被禁用）
主备配置必须一致（rsync/ansible 同步）

生产部署三原则：

必须双心跳线（防止脑裂）
必须 rsync 配置（主备一致）
必须 nopreempt（避免抖动）

替代方案：

云原生：ALB/NLB + 多 AZ
K8s：Service + Ingress Controller
更激进：双活（active-active），两边同时服务

下一步：

上 K8s，用 K8s Service + Ingress 替代 VIP
用 Pacemaker + Corosync 做更复杂的 HA 集群
商业方案：F5 BIG-IP、Citrix ADC

2024 视角：Keepalived 在云原生时代"角色变化"

2016 那篇是基于"自己买物理机 / 私有云"的 HA 方案。2024 视角下，Keepalived 角色已经变化——在云上变成"边缘 / 混合云"工具，K8s / 微服务已经走另一套方案。

一、Keepalived 2.2 → 2.3（2024 现状）

2024 主流版本：Keepalived 2.2.7+（2023-12 起进入 2.3 系列开发）。
新特性：
- vrrp_unicast_peer 增强：单播模式支持多 peer
- vrrp_startup_delay：开机延迟（避免启动时误切换）
- vrrp_priority_increment：动态调整 priority
- Python bindings（实验性）：动态控制 keepalived

1
2
3
4


# 2024 装
apt install keepalived
keepalived -v
# Keepalived v2.2.7 (10/18,2023)

二、云上的"VIP 漂移"由云厂商接管

2016 那篇自建 VIP 在云上经常失效（云厂商禁止组播 / 不允许私设 IP）。
2024 云上 VIP 漂移由云厂商原生提供：
- AWS：Secondary IP + ENI（高可用虚拟 IP）
- 阿里云：HAVIP（高可用虚拟 IP）+ API
- Azure：Load Balancer + Floating IP
- 华为云：HA VIP（2023 起提供）

1
2
3
4
5


# AWS CLI 把 Secondary IP 漂到备机
aws ec2 assign-private-ip-addresses \
 --network-interface-id eni-xxx \
 --private-ip-addresses 10.0.1.100 \
 --allow-reassignment

结论：云上不需要 Keepalived——直接用云厂商的 HA 方案。
Keepalived 仍有价值的场景：
- 私有数据中心（自建机房）
- 边缘节点（IoT / 工厂）
- 混合云（部分在云、部分本地）

三、K8s 时代的"VIP 替代"

2016 那篇 HA 思路是"VIP 漂移到备机"。
K8s 时代：Service + Endpoints + kube-proxy 自动做"虚拟 IP 漂移"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# K8s Service（自动实现 VIP 漂移）
apiVersion: v1
kind: Service
metadata:
 name: nginx-ha
spec:
 selector:
 app: nginx
 ports:
 - port: 80
 targetPort: 80
 type: ClusterIP
# K8s 自动分配 VIP（如 10.96.100.50）
# kube-proxy iptables / ipvs 自动 load balance

优势：无需 Keepalived、K8s 自动处理故障切换、漂移时间 < 1 秒。

四、HAProxy 2.4 → 3.0+ 的变化

HAProxy 3.0（2024-04 发布 LTS）：
- HTTP/3（QUIC） 完整支持
- Runtime API 增强（动态改配置）
- Threads 模型（多线程 LB）
- 新的 nbthread / thread-group 指令

1
2
3
4


# HAProxy 3.0 启用多线程
global
 nbthread 4
 cpu-map auto:1-4 0-3

2024 HAProxy 仍是四/七层 LB 主流，但 Envoy / APISIX 正在分食市场。

五、Envoy / APISIX 的"现代 VIP 替代"

Envoy（CNCF毕业项目，2024 仍是云原生服务网格标准代理）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Envoy Listener（替代 VIP）
static_resources:
 listeners:
 - name: main
 address:
 socket_address:
 address: 0.0.0.0
 port_value: 80
 filter_chains:
 - filters:
 - name: envoy.filters.network.http_connection_manager
 config:
 stat_prefix: ingress_http
 route_config:
 virtual_hosts:
 - name: backend
 domains: ["*"]
 routes:
 - match: { prefix: "/" }
 route: { cluster: backend_cluster }

APISIX（国产 Apache 项目，2024 大量企业用）：
- 动态路由（不重启热更）
- 多协议（HTTP/gRPC/WebSocket/MQTT）
- 内置 Dashboard（可视化配置）

六、`keepalived + HAProxy` 的"现代双活"写法

2016 那篇给的是主备（一主一备）。
2024 趋势：双活（两边同时服务）—— Keepalived 可以实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 主节点 keepalived.conf
vrrp_instance VI_1 {
 state BACKUP
 interface eth0
 virtual_router_id 51
 priority 100
 nopreempt
 
 # 两边都启用 nginx
 notify_master "/etc/keepalived/scripts/start_local_lb.sh"
 notify_backup "/etc/keepalived/scripts/keep_local_lb.sh"
}

两边都跑 nginx / HAProxy，但通过 DNS 智能解析 + 全局负载均衡分配流量。

七、Keepalived 的"健康检查"增强

2016 那篇给的 nginx_check.sh 是"脚本检测 nginx 进程"。
2024 现代写法：用 vrrp_track + vrrp_script + HTTP 检查：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


vrrp_script chk_nginx {
 script "curl -sf http://127.0.0.1/health || exit 1"
 interval 2
 weight -20
 fall 3
 rise 2
 timeout 5
}

vrrp_script chk_disk {
 script "df -h / | awk 'NR==2 {print $5}' | grep -E '^[8-9][0-9]%' && exit 1"
 interval 30
 weight -10
}

track_script 多个 script 同时跟踪。

八、IPv6 VIP

2024 趋势：IPv6 的 VIP 部署：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


vrrp_instance VI_1 {
 state MASTER
 interface eth0
 virtual_router_id 51
 priority 100
 
 virtual_ipaddress {
 192.168.50.130/24 dev eth0
 2001:db8::130/64 dev eth0
 }
}

IPv6 默认不依赖 ARP / 组播——使用 NDP（Neighbor Discovery Protocol）。

源文档：os/linux/第三方tools/dev/高可用/高可用.md（HAProxy/Keepalived 安装、主备配置、nginx_check.sh）

Nginx + Keepalived 双机热备与 VRRP 原理

Mon, 15 Dec 2014 00:00:00 +0800

本文写于 2014 年 12 月——彼时 Nginx 反代 + Keepalived 是中小公司做"高可用"的标配，比上硬件 F5 便宜，比 DNS 切换快。

一、为什么需要双机热备

单点 Nginx 一旦宕机，整个网站瞬间 503。在没有云 SLB 的年代，IDC 机房做"对外服务的入口高可用"几乎只有两条路：

硬件 F5 / A10 负载均衡：贵，动辄几十万
软件 VRRP 协议 + 两台 Nginx：Nginx 本身免费，Keepalived 同样免费

Nginx + Keepalived 方案的核心是虚拟 IP（VIP）漂移：两台机器共享一个 VIP，正常情况下 VIP 在主节点，一旦主节点 Nginx 挂了，VIP 自动漂到备节点，对外几乎无感。

二、Keepalived 工作原理

Keepalived 是基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议） 实现的高可用服务软件，主要功能是真机故障隔离 + 负载均衡器间失败切换，防止单点故障。

VRRP 协议保证：当主机的下一跳路由器出现故障时，由另一台路由器代替故障路由器工作，从而保持网络通信的连续性和可靠性。

关键点：VRRP 虚拟出来的是"路由"——本质是一组路由器（物理机）共享一个虚拟 IP，对外只暴露 VIP，内部选举谁持有 VIP。

三、Nginx + Keepalived 双机热备部署

3.1 拓扑结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 ┌──────────────┐
 │ VIP │ <- 对外服务的虚拟 IP（如 192.168.6.100）
 │ 192.168.6.100│
 └──────┬───────┘
 │ VRRP 心跳
 ┌───────┴───────┐
 │ │
┌──────┴──────┐ ┌─────┴───────┐
│ Master │ │ Backup │
│ 192.168.6.29│ │192.168.6.30 │
│ Nginx+Keep │ │ Nginx+Keep │
└─────────────┘ └─────────────┘

3.2 安装 Keepalived

两台机器都装：

1

yum install keepalived -y

3.3 配置 keepalived.conf

主节点（/etc/keepalived/keepalived.conf）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


vrrp_script check_nginx {
 script "/usr/local/src/check_nginx.sh"
 interval 2 # 每 2 秒检查一次
 weight -20 # 失败时优先级减 20
 fall 3 # 连续 3 次失败才认为真挂了
 rise 2 # 连续 2 次成功才认为恢复
}

vrrp_instance VI_1 {
 state MASTER # 本机初始状态
 interface eth0 # 绑定的网卡
 virtual_router_id 51
 priority 100 # 主节点优先级（备节点配 90）
 advert_int 1 # VRRP 通告间隔（秒）
 authentication {
 auth_type PASS
 auth_pass 1111
 }
 virtual_ipaddress {
 192.168.6.100/24 # VIP
 }
 track_script {
 check_nginx
 }
}

备节点唯一区别：state BACKUP + priority 90。

3.4 健康检查脚本

Keepalived 不仅能检查自己心跳，更强大的是通过脚本检查 Nginx 是否活着——/usr/local/src/check_nginx.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


#!/bin/bash
# Nginx 健康检查：HTTP 200 才算健康
A=`ps -C nginx --no-header | wc -l`
if [ $A -eq 0 ]; then
 # Nginx 挂了，尝试拉起
 /usr/local/nginx/sbin/nginx
 sleep 2
 if [ `ps -C nginx --no-header | wc -l` -eq 0 ]; then
 # 拉起失败，关闭 Keepalived，让 VIP 漂到备机
 killall keepalived
 fi
fi

加执行权限：chmod +x /usr/local/src/check_nginx.sh。

3.5 启动

1
2


nginx # 先启动 Nginx
systemctl start keepalived # 再启动 Keepalived

查看 VIP 是否在主节点：ip addr show eth0，应能看到 inet 192.168.6.100/24 出现在主节点。

四、模拟故障测试

1
2
3
4
5
6
7


# 1. 在主节点停掉 Nginx
nginx -s stop

# 2. 检查脚本会拉起 Nginx（如果起不来，则杀掉 Keepalived）
# 3. 观察 VIP 漂移到备节点
ip addr show eth0
# 备节点上应出现 192.168.6.100

五、VRRP 选举细节

优先级（priority）：数值越大越优先成为 Master，Master 范围 1-254（0 和 255 有特殊用途）
不抢占模式（nopreempt）：默认是抢占的（备机升级为主机后，原主机恢复会再抢回 VIP），但实际生产中建议配不抢占——避免抖动
认证（authentication）：PASS 认证要求主备密码一致，否则收不到通告
virtual_router_id：同一 VRRP 实例内必须相同，不同实例必须不同

六、Nginx + Keepalived 的局限

VIP 漂移有秒级延迟：默认 advert_int 1 + 脚本 interval 2 + fall 3，最坏 5-6 秒才完成漂移
脑裂问题：主备之间心跳断了但都还活着，会出现两个 VIP 抢同一资源——解法：① 双心跳线（串口线 + 网线）；② 监控脚本探测对端
单点配置不统一：两台机器的 Nginx 配置必须同步——解法：用 rsync + inotify 自动同步，或上配置中心（Nacos/Consul）

七、后续演进

随着云时代到来，这套方案在 2017 年后逐渐被替代：

云厂商 SLB（阿里云 SLB / AWS ELB）：开箱即用，自带高可用
LVS + Keepalived：Nginx 退到 7 层，LVS 在 4 层做入口，更稳
Nginx + UPScript + Consul：服务发现 + 健康检查 + 动态 upstream，比静态 VIP 更灵活

但理解 VRRP 原理是面试高频题——它不仅能解释 Keepalived，也能解释 LVS、HAProxy、Cisco HSRP、华为 VRRP，本质都是同一个协议家族。

八、面试常问

Q：Keepalived 和 Heartbeat 有什么区别？ A：都是高可用集群管理软件，但 Keepalived 基于 VRRP 协议工作在网络层，主要做 IP 漂移；Heartbeat 更老，做资源接管和消息心跳。Keepalived 配置简单 + 自带健康检查脚本，是现在的事实标准。

Q：脑裂怎么解？ A：三招——① 双心跳线（网线 + 串口）物理防脑裂；② 监控脚本（监控对端 VIP 是否存在）；③ 业务层幂等设计兜底（即使双写也保证最终一致）。

Q：Nginx + Keepalived 和 LVS + Keepalived 怎么选？ A：LVS 工作在 4 层（传输层），性能更高（百万级并发），但配置复杂；Nginx 工作在 7 层（应用层），可以做按 URL / Header 灰度，但性能低一档（10 万级并发）。实际生产两者经常配合：LVS 做入口 → Nginx 7 层分流 → 后端应用。

九、小结

核心思想：VRRP 协议 + 共享 VIP + 健康检查 + 自动漂移
部署关键：两台机器 + 同样 Nginx 配置 + 同样 Keepalived 配置（priority 不同）
健康检查脚本：让 Keepalived 不只检查自己，更检查 Nginx 进程
演进方向：云 SLB / LVS 4 层 / Consul 服务发现

十、2024+ 视角：10 年后回望，VRRP 仍不过时

本文写于 2014 年 12 月。10 年后的 2024-2026，Nginx + Keepalived 这套方案依然没死——只是从"主力"变成"基础设施"。

10.1 Keepalived 10 年未变：协议层的"长寿"

2014 年的 Keepalived 配置和 2024 年的 Keepalived 配置核心语法几乎一样——这是协议层（VRRP RFC 5798）稳定的胜利。

2024-2026 行业里 Keepalived 仍在用的场景：

传统行业（银行 / 政企 / 制造）—— 上 K8s 太重，传统 IDC 还在用 Keepalived
私有云 / 混合云—— 自建机房 + 公有云的混合架构，Keepalived 比云 SLB 更灵活
数据库双主 / 主备—— MySQL / PostgreSQL 高可用方案里 Keepalived 仍是标配
国产化替代—— 信创场景（国产化软硬件替代）里，Keepalived 是少数没被卡脖子的 HA 方案

关键认知：VRRP 协议"够简单、够稳定"是 10 年长寿的根本——AI 时代到来时，最朴素的技术反而最难被淘汰。

10.2 云原生时代的 HA 演进

2014 年我们用 Keepalived 做"主备 + VIP 漂移"。2024-2026 主流 HA 方案：

场景	2014 主流	2024+ 主流
公有云入口	Nginx + Keepalived	阿里云 SLB / AWS ALB / Cloudflare
私有云入口	Nginx + Keepalived	Nginx Ingress + K8s Service
数据库高可用	MySQL + Keepalived + VIP	MHA / Orchestrator / Patroni / Galera
Redis 高可用	Redis Sentinel + Keepalived	Redis Sentinel + Cluster + K8s Operator
消息队列 HA	RabbitMQ + Keepalived	RabbitMQ Cluster + K8s Operator
全局负载	DNS 轮询 + F5	DNS + 全球 Anycast（Cloudflare / AWS Global Accelerator）

关键变化：Keepalived 的角色从"主备入口"变成"K8s / 数据库内部"—— 它没有消失，只是下沉了。

10.3 K8s 时代的 VIP 替代方案

2014 年的"VIP 漂移"在 K8s 时代有了新解法：

K8s Service (ClusterIP)：内部自动负载均衡 + 健康检查——VIP 概念被抽象
MetalLB（2024-2026 稳定）：K8s 集群内的"LoadBalancer"实现——给 bare-metal 集群提供 VIP 能力
Ingress-Nginx + ExternalDNS：把 K8s 服务暴露到公网，VIP 概念被 DNS 替代
Cilium + BGP：基于 eBPF 的网络方案，VIP 通过 BGP 协议声明

1
2
3
4
5
6
7
8
9


# MetalLB 2024 主流配置（替代 Keepalived 在 K8s 中的角色）
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
 name: production
 namespace: metallb-system
spec:
 addresses:
 - 192.168.6.100-192.168.6.110 # VIP 池

2024 主流选择：新项目直接上 K8s + MetalLB；老项目继续 Keepalived 不动——两者并不冲突。

10.4 现代 HA 方案的"5 个特性"对比

方案	自动漂移	健康检查	跨地域	与服务发现集成	复杂度
Nginx + Keepalived	✅	✅（脚本）	❌	❌	低
HAProxy + Keepalived	✅	✅（内置）	❌	❌	低
LVS + Keepalived	✅	✅	❌	❌	中
K8s Service + MetalLB	✅	✅	弱	✅（K8s 原生）	中
云 SLB（阿里/AWS）	✅	✅	✅	✅	极低
Istio / Service Mesh	✅	✅	✅	✅	高
Cloudflare Load Balancer	✅	✅	✅	✅	极低

2024+ 选型经验：小团队用云 SLB / Cloudflare；中等规模 K8s + MetalLB；大规模 Istio / Linkerd；政企 / 信创 Keepalived + 国密 SSL。

10.5 面试题补充（2024+ 视角）

Q：Keepalived 的 VRRP 协议在 IPv6 时代还有用吗？ A：有用。VRRPv3（RFC 5798） 同时支持 IPv4 和 IPv6，2024+ 国产化 IPv6 改造里 Keepalived 仍是首选 HA 方案。

Q：脑裂问题在 K8s 时代怎么解决？ A：K8s 通过 etcd + Raft 协议避免脑裂——集群状态写入 etcd，多数节点同意才算"主"。这是分布式系统层面的"反脑裂"。

Q：为什么云厂商几乎不用 Keepalived？ A：云厂商用底层网络设备的 Anycast + ECMP 实现 LB，Keepalived 是"用户态方案"，在大规模下性能 / 可观测性都比不上硬件方案。但对中小企业，Keepalived 仍然是性价比最高的选择。

Q：Nginx + Keepalived 在 AI 时代还能用吗？ A：能。 AI 服务的入口（推理 API 网关）本质上还是 HTTP，Nginx + Keepalived 一样能跑。区别是 Nginx 需要装 ngx_http_auth_request_module 之类的模块对接 AI 鉴权。

10.6 个人总结：10 年技术演进的"启示"

写这篇文章时我刚毕业 1 年，Keepalived 是我接触的第一个"高可用"方案。10 年后再看：

协议层的稳定性 > 框架的时髦度——VRRP 10 年没变，Spring Cloud / Dubbo 换了 3 套
“够用"比"更好"更重要——Keepalived 不是最优解，但 10 年后仍是"够用” 的方案
云时代不等于"传统方案已死"——Keepalived 仍在政企 / 信创 / 数据库 HA 场景下活得很好
架构选型要"看 10 年"——2014 年选 Keepalived 的项目，2024 年大多还在用

2024+ 给后辈的建议：

面试要会 VRRP 原理——它是 Keepalived / LVS / HSRP 的共同基础

生产要懂 K8s Service——新项目都用这个

架构要懂 BGP / Anycast——云时代的 HA 底层

传统行业要会用 Keepalived——政企 / 银行 / 信创仍是主力

10 年后，VRRP 协议可能还是不会变——这就是"基础设施"的浪漫。