高可用 on Liangweidong's blog

双机房双集群架构：Redis Cluster 6 节点 + 多服务同步

Tue, 15 Apr 2025 00:00:00 +0800

双机房双集群是什么

同城双机房（Active-Active）是国内中大型生产环境的标配——一个机房挂了，另一个机房能继续服务。K8s 时代实现双机房有几个关键挑战：

集群独立：两个 K8s 集群，apiserver / etcd 都独立
服务双活：nacos / mysql / mqtt / redis 在两边都部署
数据同步：MySQL binlog、MinIO rsync、Loki/Grafana 数据可选同步
VIP + 防火墙：公网域名 + 内网 VIP 飘移

适用版本：K8s 1.28 / Redis 6.2 / EMQX 5.5.1 / 双机房（同城）

1. 整体架构

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


 公网用户
 │
 ┌─────────▼─────────┐
 │ DNS / 防火墙 │
 │ (双 VIP 映射) │
 └──┬──────────────┬──┘
 │ │
 ┌────────▼───┐ ┌────▼───────┐
 │ 机房 1 │ │ 机房 2 │
 │ 10.8.33.x │ │ 10.8.35.x │
 │ ┌────────┐ │ │ ┌────────┐ │
 │ │ K8s │ │ │ │ K8s │ │
 │ │ cluster│ │ │ │ cluster│ │
 │ └────────┘ │ │ └────────┘ │
 │ ┌────────┐ │ │ ┌────────┐ │
 │ │ nacos │◄┼────┼►│ nacos │ │
 │ │ mysql │◄┼────┼►│ mysql │ │
 │ │ redis │◄┼────┼►│ redis │ │
 │ │ minio │◄┼────┼►│ minio │ │
 │ └────────┘ │ │ └────────┘ │
 └────────────┘ └────────────┘
 ▲ ▲
 └────── 双向同步 ──────┘

2. Redis Cluster 6 节点跨机房

2.1 为什么是 6 节点

Redis Cluster 用 hash slot（16384 个槽位）分片。3 master + 3 slave 是最稳的：

3 master：分别负责 0-5460 / 5461-10922 / 10923-16383
3 slave：每个 master 1 个，热备
任意一个 master 挂了，对应 slave 自动升级

跨机房时——机房 1 3 节点（1 master + 1 master + 1 master），机房 2 3 节点（3 slave）。这样机房 1 整体挂了，机房 2 还在（但只有 slave，新写会失败）。

生产更稳的方案：机房 1 2 master + 1 slave，机房 2 1 master + 2 slave，跨机房分布副本——但 6 节点就够覆盖大部分场景。

2.2 节点规划

机房	IP	端口	角色	存储
机房 1	10.8.33.6	7360	master 0	/home/docker/redis-cluster
机房 1	10.8.33.7	7370	master 1	/home/docker/redis-cluster
机房 1	10.8.33.8	7380	master 2	/home/docker/redis-cluster
机房 2	10.8.35.5	7550	slave of 7380	/home/docker/redis-cluster
机房 2	10.8.35.6	7560	slave of 7360	/home/docker/redis-cluster
机房 2	10.8.35.7	7570	slave of 7370	/home/docker/redis-cluster

实际 IP 用占位符 10.8.33.x 10.8.35.x 替代。

2.3 镜像准备

1
2
3


docker pull redis:6.2.17
docker tag redis:6.2.17 <harbor>:13001/base/redis:6.2.17
docker push <harbor>:13001/base/redis:6.2.17

2.4 6 个节点的 redis.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


cat > /home/docker/redis-cluster/redis.conf << "EOF"
port 7360 # 每节点不同
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly no
save ""
daemonize no
protected-mode no
pidfile /data/redis.pid
EOF

2.5 6 个节点的 docker run

1
2
3
4
5
6
7
8


docker run -d \
 --restart=always \
 --privileged=true \
 --name redis-7360 \
 --net host \
 -v /home/docker/redis-cluster:/data \
 <harbor>:13001/base/redis:6.2.17 \
 redis-server /data/redis.conf

6 节点命令相同，只改 --name 和 port。

2.6 创建集群

1
2
3
4
5
6
7
8


mkdir -p /home/docker/redis-cluster
# 6 节点都要建这个目录

docker exec -it redis-7360 \
 redis-cli -p 7360 --cluster create \
 10.8.33.6:7360 10.8.33.7:7370 10.8.33.8:7380 \
 10.8.35.5:7550 10.8.35.6:7560 10.8.35.7:7570 \
 --cluster-replicas 1

输出（关键部分）：

1
2
3
4
5
6
7


>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 10.8.35.6:7560 to 10.8.33.6:7360
Adding replica 10.8.35.7:7570 to 10.8.33.7:7370
Adding replica 10.8.35.5:7550 to 10.8.33.8:7380

确认 yes 后：

1
2
3
4
5


>>> Performing Cluster Check (using node 10.8.33.6:7360)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

2.7 验证

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


docker exec -it redis-7360 redis-cli -p 7360 -c

# 集群信息
127.0.0.1:7360> cluster info
# cluster_state:ok
# cluster_slots_assigned:16384
# cluster_known_nodes:6
# cluster_size:3

# 节点列表
127.0.0.1:7360> cluster nodes
# 02f0476e155902b1eda400ee84602ace90e821cd 10.8.35.5:7550@17550 slave 952938798efe17832a3c9492be9a45675c58fe69 ...

2.8 Spring Boot 客户端配置

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


spring:
 redis:
 timeout: 10s
 cluster:
 nodes:
 - 10.8.33.6:7360
 - 10.8.33.7:7370
 - 10.8.33.8:7380
 - 10.8.35.5:7550
 - 10.8.35.6:7560
 - 10.8.35.7:7570
 max-redirects: 3
 jedis:
 pool:
 max-active: 500
 max-wait: -1ms
 max-idle: 200
 min-idle: 100

2.9 单 db0 的坑

Redis Cluster 只支持 db0——所有 key 都在 db0。如果你的应用假设"按 db 切分数据"（如 db:4），需要重构。

3. nacos 双活

nacos 双机房同时部署，应用启动时配两个 server：

1

spring.cloud.nacos.discovery.server-addr=10.8.33.6:8848,10.8.35.5:8848

每个机房都跑 nacos，互相不依赖——一个挂掉另一个继续工作。

机房	对外地址	部署方式	账户
机房 1	`http://10.8.33.250:30680/nacos`	k8s	nacos/nacos
机房 2	`http://10.8.35.250:30680/nacos`	k8s	nacos/nacos

4. MySQL 双主架构

双机房 MySQL 同步有 2 种思路：

4.1 双主互相同步

1
2
3


机房1-Master1 ────→ 机房2-Master2
 ↑ │
 └───────────────────┘

每个机房都是 Master，写自己 + 同步到对方。风险：双写冲突、循环同步。

解决：每张表用 server_id 区分，比如 ID 奇数写机房 1，偶数写机房 2。

4.2 主从单向同步

1

机房1-Master ────→ 机房2-Slave

机房 1 是主，机房 2 是从，只读不写。机房 1 挂掉时人工切主。

4.3 多租户 MySQL 部署

1
2
3
4
5


volumes:
 - name: mysql-data
 nfs:
 server: 10.8.33.111
 path: /nfs/park-prod/mysql/data

1
2
3
4
5


volumes:
 - name: mysql-data
 nfs:
 server: 10.8.33.111
 path: /nfs/safety-dev/mysql/data

/etc/mysql/conf.d 走 ConfigMap 注入。

机房	用途	部署方式
机房 1 10.8.33.8:3309	多租户库 + powerjob + nacos	二进制
机房 2 10.8.35.6:3309	多租户库	二进制
机房 2 10.8.35.250:30606	powerjob + nacos	k8s

5. EMQX MQTT 集群

5.5.1 用 static 集群发现策略，所有节点都列在 seeds 里：

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


version: "3"
services:
 emqx1:
 image: emqx:5.5.1
 container_name: emqx1
 environment:
 - EMQX_NODE_NAME=emqx@10.8.33.6
 - EMQX_CLUSTER__DISCOVERY_STRATEGY=static
 - EMQX_CLUSTER__STATIC__SEEDS=[emqx@10.8.33.6,emqx@10.8.33.7,emqx@10.8.33.8,emqx@10.8.35.5,emqx@10.8.35.6,emqx@10.8.35.7]
 network_mode: "host"
 healthcheck:
 test: ["CMD", "/opt/emqx/bin/emqx_ctl", "status"]
 interval: 5s
 timeout: 25s
 retries: 5

5.1 客户端配置

1
2
3
4


客户端账号: <your-org> / {{MQTT_PASSWORD}}
机房 1 节点: 10.8.33.6, 10.8.33.7, 10.8.33.8
机房 2 节点: 10.8.35.5, 10.8.35.6（不可用）, 10.8.35.7
公网入口: tcp://mq.cloud.example.com:1885

防火墙映射：公网 1885 → 10.8.33.110:1883 → 10.8.33.6:1883

MQTT 密码用占位符 {{MQTT_PASSWORD}} 替代。

5.2 客户端连接示例

1
2
3
4
5
6
7
8
9


# 加入集群
docker exec -it emqx1 emqx ctl cluster join emqx@10.8.35.5

# 看集群状态
docker exec -it emqx1 emqx ctl cluster status

# 重启
docker-compose -f /home/docker-compose-emqx.yml down
docker-compose -f /home/docker-compose-emqx.yml up -d

6. nginxwebui 负载均衡

服务	协议	策略	负载	备注
mqtt-ws	http	ip	6 节点 8083	前端订阅
mqtt-tcp	tcp	-	6 节点 1883	后端订阅
gateway	http	ip	双 VIP:30697	网关
location-netty	tcp	-	双 VIP:30687	定位基站
minioapi	http	ip	10.8.33.254:9091	文件服务
safety-pc	http	ip	双 VIP:30618	PC 入口
safety-apph5	http	ip	双 VIP:30628	APP 入口
webrtc-stun	tcp/udp	-	10.8.33.127:3478 + 10.8.35.7:3478	STUN
webrtc	http	-	10.8.33.127:8000 + 10.8.35.7:8000	虚拟 ip:443

7. 防火墙映射

公网到机房 1：

1

公网 <your-public-ip>:1885 → 10.8.33.110:1883 → 10.8.33.6:1883

公网到机房 2：

1

公网 <your-public-ip>:xxxx → 10.8.35.2:xxxx → 机房 2 服务

实际 IP 用占位符替代。

机房 2 防火墙登录：https://10.8.35.2，admin / {{FIREWALL_PASSWORD}}

8. 同步策略

资源	同步方式
nacos 配置	nacos 自身多节点 + 应用端多 server-addr
MySQL 数据	binlog 主从 / 双主 + server_id 区分
Redis 数据	Cluster 自动跨节点同步
MinIO 文件	rsync + lsyncd 双向（已有方案）
MQTT 消息	EMQX 集群内自动同步
应用镜像	都从同一个 harbor 私有仓库拉
Prometheus 数据	可选 federation / remote_write
Loki 日志	可选都指向同一个对象存储

9. VIP 与 keepalived 跨机房

unicast_src_ip + unicast_peer 模式（见 2015-02-15 文章）。

机房 1：

1
2
3
4


unicast_src_ip 10.8.33.253
unicast_peer {
 10.8.35.7
}

机房 2：

1
2
3
4


unicast_src_ip 10.8.35.7
unicast_peer {
 10.8.33.253
}

不同机房 VIP 飘移。

10. 排错

现象	原因	解决
Redis Cluster `CLUSTERDOWN`	跨机房链路断	检查防火墙 / 路由
MySQL 双主冲突	两个机房同时写	改 server_id 区分写
nacos 注册的服务没同步	客户端没配双 server-addr	应用配置加 `,` 分隔
EMQX 节点反复脱离集群	网络抖动	调大 `cluster.node_timeout`
公网 502	keepalived 没漂	看 nginx / keepalived 日志
机房 1 全挂后机房 2 写不了	MySQL 单向同步	改双向 / 切主

11. 小结

同城双机房 K8s 集群的核心是"两边都能独立工作"：

Redis Cluster 6 节点 跨机房分布是基础
nacos / MySQL / EMQX 都做双活
MinIO 用 rsync 双向同步
VIP + 防火墙 让公网无感
故障演练——定期模拟机房 1 挂掉

这是 K8s 系列博客的最后一篇——到此生产 K8s 集群从 0 到异地多活的完整链路已经走通。

高可用负载均衡：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）—— 升级、节点隔离、排错

参考资料

etcd 集群部署：3 节点高可用与 Raft 选举详解

Tue, 15 Sep 2020 00:00:00 +0800

写于 2020-09，背景：etcd v3.4 时代，K8s 1.19 仍以 3 节点 etcd 集群为生产推荐。本文聚焦 etcd 集群原理 + 实战部署。

一、etcd 是什么

etcd 是一个分布式键值数据库，天生为集群化设计：

数据模型：扁平 key-value，类比 redis 但走磁盘（强一致）
一致性算法：Raft（保证多节点数据强一致）
API：gRPC + HTTP/JSON，对 K8s 友好
应用场景：服务发现、配置中心、K8s/calico/Docker Swarm 后端存储

etcd 是 CNCF 毕业项目，与 K8s 同源（都来自 Borg 系统的设计哲学）。

二、Raft 算法与集群规模

Raft 在做决策时需要超半数节点投票，所以 etcd 集群推荐奇数节点（3/5/7）：

节点数	最大容忍故障	备注
1	0	单实例，无集群意义
2	0	双节点能启动，但挂一台就选不出主，不要用
3	1	生产最低推荐
4	1	跟 3 一样，浪费一台
5	2	中型集群推荐
6	2	跟 5 一样，浪费一台
7	3	大型集群（>100 节点）

为什么不能是偶数？ 4 节点和 3 节点都是容忍 1 台故障，但 4 节点多一台机器成本；6 节点和 5 节点同理。Raft 选举只看"过半"，不看你有几个备份。

三、集群规划

3 master 节点同时跑 etcd（etcd 与 apiserver 同节点部署是 K8s 官方推荐）：

主机名	IP	角色
master1	`192.168.139.133`	etcd-1 + apiserver
master2	`192.168.139.134`	etcd-2 + apiserver
master3	`192.168.139.135`	etcd-3 + apiserver

端口约定：

2379：客户端 API（kube-apiserver 调 etcd）
2380：节点间 peer 通信（Raft 选举 + 数据同步）

四、生成 etcd 证书

K8s 集群里 etcd 走双向 TLS，证书前置在 2020-03-15《K8s 二进制部署》已签发。关键步骤回顾：

 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


# ca-config.json
cat > ca-config.json << EOF
{
 "signing": {
 "default": { "expiry": "876000h" },
 "profiles": {
 "kubernetes": {
 "usages": ["signing", "key encipherment", "server auth", "client auth"],
 "expiry": "876000h"
 }
 }
 }
}
EOF

# etcd CA
cat > etcd-ca-csr.json << EOF
{
 "CN": "etcd",
 "key": { "algo": "rsa", "size": 2048 },
 "names": [{ "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "etcd", "OU": "Etcd Security" }],
 "ca": { "expiry": "876000h" }
}
EOF

cfssl gencert -initca etcd-ca-csr.json | cfssljson -bare /etc/etcd/ssl/etcd-ca

# etcd server 证书（注意 hostname + IP 全列）
cat > etcd-csr.json << EOF
{
 "CN": "etcd",
 "key": { "algo": "rsa", "size": 2048 },
 "names": [{ "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "etcd", "OU": "Etcd Security" }]
}
EOF

cfssl gencert \
 -ca=/etc/etcd/ssl/etcd-ca.pem \
 -ca-key=/etc/etcd/ssl/etcd-ca-key.pem \
 -config=ca-config.json \
 -hostname=127.0.0.1,master1,master2,master3,192.168.139.133,192.168.139.134,192.168.139.135 \
 -profile=kubernetes \
 etcd-csr.json | cfssljson -bare /etc/etcd/ssl/etcd

五、安装 etcd 二进制

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


# 解压
wget https://github.com/etcd-io/etcd/releases/download/v3.5.11/etcd-v3.5.11-linux-amd64.tar.gz
tar -xf etcd-v3.5.11-linux-amd64.tar.gz
mv etcd-v3.5.11-linux-amd64/etcd /usr/local/bin/
mv etcd-v3.5.11-linux-amd64/etcdctl /usr/local/bin/
mv etcd-v3.5.11-linux-amd64/etcdutl /usr/local/bin/

# 验证
etcd --version
etcdctl version
# etcdctl version: 3.5.11
# API version: 3.5

六、etcd 配置文件

每个 master 节点单独写一份 /etc/etcd/etcd.config.yml，注意 name、listen URL、advertise URL 都不同。

6.1 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
32
33
34
35


name: 'master1'
data-dir: /var/lib/etcd
wal-dir: /var/lib/etcd/wal
snapshot-count: 5000
heartbeat-interval: 100
election-timeout: 1000
quota-backend-bytes: 0
listen-peer-urls: 'https://192.168.139.133:2380'
listen-client-urls: 'https://192.168.139.133:2379,http://127.0.0.1:2379'
max-snapshots: 3
max-wals: 5
initial-advertise-peer-urls: 'https://192.168.139.133:2380'
advertise-client-urls: 'https://192.168.139.133:2379'
initial-cluster: 'master1=https://192.168.139.133:2380,master2=https://192.168.139.134:2380,master3=https://192.168.139.135:2380'
initial-cluster-token: 'etcd-k8s-cluster'
initial-cluster-state: 'new'
strict-reconfig-check: false
enable-v2: true
enable-pprof: true
proxy: 'off'
client-transport-security:
 cert-file: '/etc/kubernetes/pki/etcd/etcd.pem'
 key-file: '/etc/kubernetes/pki/etcd/etcd-key.pem'
 client-cert-auth: true
 trusted-ca-file: '/etc/kubernetes/pki/etcd/etcd-ca.pem'
 auto-tls: true
peer-transport-security:
 cert-file: '/etc/kubernetes/pki/etcd/etcd.pem'
 key-file: '/etc/kubernetes/pki/etcd/etcd-key.pem'
 peer-client-cert-auth: true
 trusted-ca-file: '/etc/kubernetes/pki/etcd/etcd-ca.pem'
 auto-tls: true
debug: false
log-outputs: [default]
force-new-cluster: false

6.2 master2 / master3 配置

只改 name 和 listen/advertise URL 的 IP，其他保持一致。

七、systemd 单元文件

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


[Unit]
Description=Etcd Service
Documentation=https://coreos.com/etcd/docs/latest/
After=network.target

[Service]
Type=notify
ExecStart=/usr/local/bin/etcd --config-file=/etc/etcd/etcd.config.yml
Restart=on-failure
RestartSec=10
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
Alias=etcd3.service

K8s 默认从 /etc/kubernetes/pki/etcd/ 找 etcd 证书，加软链：

1
2


mkdir -p /etc/kubernetes/pki/etcd
ln -s /etc/etcd/ssl/* /etc/kubernetes/pki/etcd/

八、启动与验证

1
2
3
4


# 所有 master 节点
systemctl daemon-reload
systemctl enable --now etcd.service
systemctl status etcd.service

关键验证（master1 执行）：

1
2
3
4
5
6
7
8


# 注意 v2/v3 API 切换
export ETCDCTL_API=3

etcdctl --endpoints="https://192.168.139.133:2379,https://192.168.139.134:2379,https://192.168.139.135:2379" \
 --cacert=/etc/kubernetes/pki/etcd/etcd-ca.pem \
 --cert=/etc/kubernetes/pki/etcd/etcd.pem \
 --key=/etc/kubernetes/pki/etcd/etcd-key.pem \
 endpoint status --write-out=table

预期输出：

1
2
3
4
5
6
7


+----------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
+----------------------+------------------+---------+---------+-----------+------------+
| 192.168.139.133:2379 | 67214e12874d646b | 3.5.11 | 29 kB | false | 2 | 8 |
| 192.168.139.134:2379 | a6947d51f82bebc4 | 3.5.11 | 29 kB | false | 2 | 8 |
| 192.168.139.135:2379 | f0598e5ca7a8066f | 3.5.11 | 29 kB | true | 2 | 8 |
+----------------------+------------------+---------+---------+-----------+------------+

关键字段：

IS LEADER：true 表示该节点是当前 leader（Raft 选举结果）
RAFT TERM：选举轮次，term 越大说明发生过越多次选举
DB SIZE：etcd 数据库占磁盘大小

九、故障模拟

9.1 模拟 master1 宕机

1
2


# 在 master1 上
systemctl stop etcd

观察其他节点：

1
2


# 观察 5~10 秒
watch -n 1 "etcdctl endpoint status --cluster --write-out=table"

预期：master1 不可达，master3 仍为 leader（因为 3 节点允许挂 1 台）。

9.2 模拟 master2 也宕机

1
2


# master2
systemctl stop etcd

此时只剩 master1，集群不可用（写操作会失败），但 etcd 不会自动重启——必须人工恢复至少 2 节点。

9.3 恢复

1
2
3


# master2 / master3 启动
systemctl start etcd
# 集群自动重新选主（5~10 秒内）

9.4 灾难恢复：强制重建集群

如果 3 台都挂，etcd 数据还在，但需要 --force-new-cluster 强制单节点启动：

1
2
3
4
5
6


# 改配置
echo "initial-cluster-state: 'existing'" >> /etc/etcd/etcd.config.yml
# 注意 force-new-cluster=true 只能用于一台

# 重启
systemctl start etcd

十、etcdctl 常用命令

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


# 列成员
etcdctl member list

# 健康检查
etcdctl endpoint health --cluster

# 写读测试
etcdctl put /test/foo "hello"
etcdctl get /test/foo

# 备份
etcdctl snapshot save /tmp/etcd-backup.db
etcdctl snapshot status /tmp/etcd-backup.db --write-out=table

# 碎片整理（v3.4 之前需要）
etcdctl defrag

# 告警
etcdctl alarm list
etcdctl alarm disarm

十一、性能调优

参数	含义	默认	调优建议
`heartbeat-interval`	心跳间隔（ms）	100	高延迟网络调大到 200~500
`election-timeout`	选举超时（ms）	1000	至少 5 倍 heartbeat
`quota-backend-bytes`	后端存储限额	2GB	集群 > 8GB 数据调大
`snapshot-count`	触发快照的事务数	100000	写多场景调小到 10000
`max-snapshots`	保留快照数	5	视磁盘空间

关键监控指标：

etcd_disk_wal_fsync_duration_seconds（p99 < 10ms，否则 IO 瓶颈）
etcd_network_peer_round_trip_time_seconds（p99 < 50ms）
etcd_server_has_leader（必须 = 1）
etcd_server_proposals_committed_total / etcd_server_proposals_applied_total（差值 = pending，>5 要警惕）

十二、常见坑

证书 hostname/IP 漏配：peer 通信报 “x509: certificate is valid for …” 错误
firewalld 没关：节点间 2380 端口不通，选举失败
initial-cluster-state: 'new' 重复使用：第二次启动报 “member already exists”，改成 'existing'
etcd 与 apiserver 时钟不同步：证书验证失败，先 ntpdate time1.aliyun.com 对齐
snapshot 备份恢复后集群 ID 变了：用 etcdctl snapshot restore 时记得加 --initial-cluster 和 --initial-advertise-peer-urls

十三、前置知识 / 下一步

前置：

证书签发（cfssl，参考 2020-03-15《K8s 二进制部署》）
K8s 架构基础

下一步：

API Server 高可用（2021-03-15）—— Nginx 四层 + Keepalived VIP
K8s 集群管理（2021-12-15）—— 升级、节点隔离、备份恢复

参考资料

2024+ 视角

etcd 在 2024-2026 年依然是 K8s 数据底座，但生态发生了几个关键变化：

etcd v3.5 全面稳定：v3.5.x 引入的 etcdutl（替代旧 etcdctl 快照管理）、Raft ReadIndex 优化、Learner 节点都已 GA。生产推荐 v3.5.10+（修复了多个 Raft 性能回退问题）。
K8s 1.30+ 的 etcd 管理变更：自 K8s 1.30 起，kubeadm 默认 etcd 容器镜像从 k8s.gcr.io/etcd 切到 registry.k8s.io/etcd，并支持 etcd Learner 节点用于接入已有 etcd 集群（适合 etcd 单独运维团队）。
etcd 性能与碎片整理：v3.4 之前的 defrag 命令在 v3.5 已不再是必须的——v3.5 后端实现了在线碎片回收（QuotaBackendBytes + AutoCompactionMode=periodic）。但 DB Size 超过 quota-backend-bytes 仍会触发告警。
可观测性增强：社区推荐 etcd-dashboard（来自 RedHat）+ Prometheus 抓取 etcd_disk_wal_fsync_duration_seconds、etcd_server_has_leader 等 20+ 关键指标。K8s SIG-Instrumentation 提供官方 kube-etcd-monitor Helm Chart。
替代方案的边界：Kine（将 etcd API 翻译成 SQL）让 MySQL/PostgreSQL 可作为 K8s 后端，但生产级 etcd 仍不可替代——Raft 协议下的强一致 + 低延迟（p99 < 10ms）是 etcd 的护城河。
运维注意：2024 年起，多个 K8s 重大故障源于 etcd 时钟漂移（节点间 NTP 偏差 > 1s 触发 leader 选举）。建议在所有 master 节点部署 chrony 而非 ntpd，并监控 node_timex_offset_seconds。

总之，这篇 2020 年的 etcd 部署骨架至今仍可作为新集群起点，主要补全是：升级到 v3.5.x、用 etcdutl 管理快照、补 Prometheus 监控。

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）

NFS 存储实战：单节点 + Keepalived 双机热备 + nfs-subdir 动态供给

Tue, 15 Nov 2016 00:00:00 +0800

为什么 NFS 在 K8s 时代还有用

很多人觉得 K8s 时代应该用 Rook-Ceph / Longhorn 这类"云原生存储"，NFS 是"老古董"。但实际上：

NFS 在 RWX 场景（多个 Pod 同时读写同一份数据）依然是最稳的
NFS + nfs-subdir-external-provisioner 是 K8s 动态 PV 的"最短路径"——5 分钟搞定一个 StorageClass
NFS + Keepalived + rsync 组成"穷人版"高可用，不需要 3 副本，单机故障 30 秒恢复
在国产化、私有化场景，NFS 是"无 Ceph 也能跑"的兜底方案

适用版本：NFS 4.1 / nfs-subdir-external-provisioner 4.0.18 / Ubuntu 22.04

1. 单节点 NFS 服务

1.1 安装服务端

1
2
3
4
5
6
7


apt install -y nfs-kernel-server

# 验证
systemctl is-enabled nfs-server
systemctl status nfs-server
cat /proc/fs/nfsd/versions
# +3 +4 +4.1 +4.2

1.2 共享目录

1
2
3
4
5
6
7


mkdir -p /home/nfs
chown -R nobody:nogroup /home/nfs
chmod 777 /home/nfs

mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs

1.3 配置 /etc/exports

1
2


echo "/home/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports

参数解释：

*：所有网段可访问（生产应换成具体子网）
rw：读写
sync：同步写入内存和硬盘
no_root_squash：root 用户保留权限
no_subtree_check：不检查父目录权限

应用：

1
2
3
4


exportfs -a
systemctl restart nfs-server
exportfs -v
showmount -e

1.4 所有节点安装客户端

1
2
3
4


apt install -y nfs-common
showmount -e <nfs-server-ip>
# Export list for <nfs-server-ip>:
# /home/nfs *

1.5 客户端挂载测试

1
2
3


mount -t nfs <nfs-server-ip>:/home/nfs /mnt
df -h
umount /mnt

1.6 客户端常见挂不上

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 一些机器 mount 失败：mount.nfs: Connection timed out
# 解决：
mount -t nfs -o vers=3,nolock,proto=tcp <nfs-server-ip>:/nfs /mnt/nfs

# K8s 上修改 StorageClass
kubectl edit storageclass nfs-client

mountOptions:
 - vers=3
 - nolock
 - proto=tcp

2. K8s 中使用 NFS 存储

2.1 直接在 Pod 中引用 NFS

 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


apiVersion: apps/v1
kind: Deployment
metadata:
 name: redis
spec:
 selector:
 matchLabels:
 app: redis
 template:
 metadata:
 labels:
 app: redis
 spec:
 containers:
 - image: redis
 name: redis
 env:
 - name: ALLOW_EMPTY_PASSWORD
 value: "yes"
 volumeMounts:
 - name: redis-persistent-storage
 mountPath: /data
 volumes:
 - name: redis-persistent-storage
 nfs:
 path: /home/nfs
 server: <nfs-server-ip>

2.2 静态 PV + PVC

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


apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-pv
 namespace: go
spec:
 capacity:
 storage: 2Gi
 volumeMode: Filesystem
 accessModes:
 - ReadWriteMany
 persistentVolumeReclaimPolicy: Recycle
 storageClassName: nfs
 mountOptions:
 - hard
 - nfsvers=4.1
 nfs:
 path: /nfs
 server: <nfs-server-ip>

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


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-pvc
 namespace: go
spec:
 storageClassName: nfs
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 2Gi

PV 卡在 Terminating 时的强删：

1

kubectl patch pv nfs-pv -p '{"metadata":{"finalizers":null}}' -n go

2.3 动态 StorageClass（推荐）

nfs-subdir-external-provisioner 是 NFS 动态供给的标配——它会监听 PVC 自动在 NFS 上创建子目录。

1
2
3
4


cd /data/softs
tar -xvf nfs-subdir-external-provisioner-4.0.18.tgz
mv nfs-subdir-external-provisioner /data/k8scnf/nfs/
cd /data/k8scnf/nfs/nfs-subdir-external-provisioner/

修改 values.yaml：

1
2
3
4


repository: registry.cn-shenzhen.aliyuncs.com/atomic/nfs-subdir-external-provisioner
nfs:
 server: <nfs-server-ip>
 path: /home/nfs

安装：

1
2


kubectl create namespace nfs
helm install nfs-subdir-external-provisioner . -n nfs

设置默认 StorageClass：

1

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

卸载：

1
2
3
4
5
6
7


helm uninstall nfs-subdir-external-provisioner -n nfs
kubectl delete namespace nfs
kubectl delete serviceaccount nfs-client-provisioner -n nfs
kubectl delete clusterrolebinding run-nfs-subdir-external-provisioner
kubectl delete role/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete rolebinding/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete storageclass nfs-client

2.4 测试动态 PV

 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


cat << "EOF" > test-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-claim
 namespace: nfs
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Mi
 storageClassName: nfs-client
EOF

cat << "EOF" > test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 namespace: nfs
spec:
 containers:
 - name: test-pod
 image: busybox
 command: ["/bin/sh", "-c", "echo SUCCESS > /data/SUCCESS; sleep 3600"]
 volumeMounts:
 - name: nfs-pvc
 mountPath: /data
 volumes:
 - name: nfs-pvc
 persistentVolumeClaim:
 claimName: test-claim
 restartPolicy: Never
EOF

kubectl apply -f test-claim.yaml
kubectl apply -f test-pod.yaml

# 等 1 分钟后
ls /nfs/nfs-test-claim-pvc-*/
# 看到 SUCCESS 文件

kubectl delete -f test-pod.yaml
kubectl delete -f test-claim.yaml
# NFS 上的 pvc 目录自动清理

3. 双机热备 + rsync/lsyncd

3.1 架构

1
2
3
4
5
6
7


┌──────────────┐ keepalived ┌──────────────┐
│ worker4 │ ←── VRRP VIP ────→ │ worker2 │
│ nfs-server │ <10.x.x.x> │ nfs-server │
│ rsync 主 │ │ rsync 备 │
└──────────────┘ └──────────────┘
 ↓ ↓
 /nfs <──── lsyncd + rsync 实时同步 ────/nfs

3.2 两台机器都装 NFS + keepalived

两台机器都跑 NFS 服务（同一份数据），keepalived 决定哪个 IP 在线。

1
2
3
4
5
6
7
8


# 两台都执行
apt install -y nfs-kernel-server
mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
exportfs -a
systemctl restart nfs-server

3.3 keepalived 配置（必须 nopreempt）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


vrrp_instance VI_1 {
 state BACKUP # 两台都是 BACKUP（vs master）
 interface enp3s0
 virtual_router_id 111
 priority 100 # worker4 设 100
 priority 80 # worker2 设 80
 advert_int 1
 nopreempt # **必须**：防止主备反复切换时数据丢失
 authentication { auth_type PASS; auth_pass 1111; }
 virtual_ipaddress { <nfs-vip>; }
}

健康检查脚本（nfs 挂了就把 keepalived 停掉，让 VIP 漂移）：

1
2
3
4
5
6
7
8
9


#!/bin/bash
A=`ps -C nfsd --no-header | wc -l`
if [ $A -eq 0 ]; then
 systemctl restart nfs-server.service
 sleep 2
 if [ `ps -C nfsd --no-header | wc -l` -eq 0 ]; then
 pkill keepalived
 fi
fi

NFS 双机热备的 nfs_check.sh 比 keepalived 自身的 chk_*.sh 更重要——必须让 NFS 挂了之后主动让出 VIP，否则客户端挂载会卡死。

3.4 rsync + lsyncd 实时同步

lsyncd 监听 inotify 事件触发 rsync 同步，是 Linux 文件实时同步的"标配"。

1
2


apt install -y rsync lsyncd
systemctl enable --now rsync lsyncd

内核参数优化（必做，否则 inotify 句柄不够）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


sysctl -w fs.inotify.max_queued_events="99999999"
sysctl -w fs.inotify.max_user_watches="99999999"
sysctl -w fs.inotify.max_user_instances="65535"

cat >> /etc/sysctl.conf << "EOF"
fs.inotify.max_queued_events=99999999
fs.inotify.max_user_watches=99999999
fs.inotify.max_user_instances=65535
EOF
sysctl -p

rsync 配置文件（/etc/rsyncd.conf）：

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


log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsyncd.lock
[backup]
path = /nfs
comment = sync nfs from client
uid = root
gid = root
port = 873
ignore errors
use chroot = no
read only = no
list = no
max connections = 200
timeout = 600
auth users = root
secrets file = /etc/rsync.password
hosts allow = 10.0.0.0/8

密码文件：

1
2
3
4
5


echo 'root:{{NFS_RSYNC_PASSWORD}}' > /etc/rsync.password
chmod 600 /etc/rsync.password

echo "{{NFS_RSYNC_PASSWORD}}" > /etc/rsyncd.password
chmod 600 /etc/rsyncd.password

实际密码用占位符 {{NFS_RSYNC_PASSWORD}} 替代，原密码登记在 _drafts/私人笔记.md。

lsyncd 配置（worker4 把 /nfs 推到 worker2）：

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


settings {
 logfile = "/var/log/lsyncd/lsyncd.log",
 statusFile = "/var/log/lsyncd/lsyncd.status",
 inotifyMode = "CloseWrite",
 maxProcesses = 8,
}
sync {
 default.rsync,
 source = "/nfs",
 target = "root@<worker2-ip>::backup",
 delete = true,
 delay = 1,
 exclude = {".*"},
 rsync = {
 binary = "/usr/bin/rsync",
 archive = true,
 compress = false,
 verbose = true,
 password_file = "/etc/rsyncd.password",
 _extra = {"--bwlimit=20000"}
 }
}

worker2 的配置对称——把 target 指向 worker4。

3.5 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 在 worker4 上
mount -t nfs <nfs-vip>:/nfs /mnt
cd /mnt
echo "test" > test.txt
cd ../
umount /mnt

# 在 worker2 上
ls /nfs
# 应该能看到 test.txt

3.6 模拟故障

停 worker4 keepalived → VIP 飘到 worker2
启 worker4 keepalived（nopreempt 不会让 VIP 回来）
停 worker2 keepalived → VIP 飘回 worker4
内网其他机器 ping VIP 一直是通的

4. Ingress 持久化日志

Ingress-nginx 容器本身是无状态的，access log 默认写到 stdout（容器内）。生产场景希望 log 落盘到 NFS，方便 ELK / Loki 采集。

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


cat << "EOF" > /data/k8scnf/ingress-nginx/ingress-nfs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: ingress-nfs
 namespace: ingress-nginx
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 10Gi
 storageClassName: nfs-client
EOF

kubectl apply -f /data/k8scnf/ingress-nginx/ingress-nfs.yaml

修改 ingress-nginx-controller：

1

kubectl edit -n ingress-nginx DaemonSet/ingress-nginx-controller

1
2
3
4
5
6
7


volumeMounts:
 - mountPath: /var/log/nginx/
 name: ingress-nfs
volumes:
 - name: ingress-nfs
 persistentVolumeClaim:
 claimName: ingress-nfs

修改 ConfigMap 改变日志格式：

1

kubectl edit -n ingress-nginx configmaps/ingress-nginx-controller

NFS 上自动创建 default-ingress-nfs-pvc-xxx/ 目录，所有 ingress-controller Pod 的 access log 都会落在这里。

单点故障注意：NFS 本身是单点，NFS 挂了 ingress 日志会卡。生产建议加 keepalived VIP（本文方案）。

5. 排错

现象	原因	解决
`mount.nfs: Connection timed out`	防火墙	放通 2049/111/20048
`mount.nfs: Operation not permitted`	NFS 版本不匹配	加 `-o vers=3,nolock,proto=tcp`
PVC 一直 Pending	节点没装 nfs-common	所有节点 `apt install nfs-common`
nfs-subdir 装不上	helm chart 镜像拉不到	改国内源 + push 私有 harbor
双机热备 VIP 频繁漂移	没设 nopreempt	keepalived.conf 加 `nopreempt`
lsyncd 同步延迟大	inotify 句柄不够	调 `fs.inotify.*` 参数

6. 2024 NFS 现状

本文 2016 年写时 NFS 还是 K8s 动态存储的"穷人首选"。8 年后（2024）回望，NFS 协议本身有了 NFS 4.2、pNFS 等增强，但更重要的是生态位发生了变化——长虹、Ceph/Longhorn/OpenEBS 等云原生存储在 K8s 场景蚕食了 NFS 的份额。下面是当前状态。

6.1 NFS 协议本身：4.2 与 pNFS

NFS 版本	发布时间	关键特性	2024 现状
NFSv3	1995	异步写、TCP 支持	老系统兼容仍用
NFSv4.0	2003	状态化、复合操作、Kerberos	Linux 默认
NFSv4.1	2010	pNFS（并行 NFS）、会话	主流
NFSv4.2	2016	服务器端复制、稀疏文件、空间预留、应用数据块（ADBs）	2024 标配

pNFS 的核心思想：把元数据和数据通道分离——元数据服务器只管 layout，客户端直接和多个存储节点传输数据，理论上能做到并行带宽聚合（类似 CephFS 的 striping）。

1
2
3


# 挂载 pNFS（需要服务端支持）
mount -t nfs -o nfsvers=4.1,minorversion=1 <server>:/export /mnt
# 或 nfsvers=4.2 启用 4.2 特性

实际部署率：pNFS 在企业存储（NetApp / Dell EMC Isilon / IBM Spectrum Scale）早就支持，但Linux 内核的 pNFS client 直到 5.x 才稳定，很多 K8s 节点跑的还是 NFSv3/4.1 而不是 pNFS。

6.2 nfs-subdir-external-provisioner 现状

版本	时间	状态
v3.x	2019-2021	旧 API，CSI 转换中
v4.0.x	2022-2023	当时主流
v4.0.18+	2023-2024	当前推荐
v4.0.20+	2024	k8s 1.28+ 兼容

v4.x 关键变化：

完全重写为 CSI（Container Storage Interface） 驱动
支持 Kubernetes 1.25+（旧的 in-tree NFS provisioner 已废弃）
Helm chart 改为标准 oci:// 仓库：

1
2
3
4
5
6


# 2024 推荐装法（Helm 3.8+）
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
 --set nfs.server=<nfs-server-ip> \
 --set nfs.path=/home/nfs \
 -n nfs-client --create-namespace

6.3 2024 替代方案对比

方案	类型	适用场景	复杂度	性能	HA
NFS + nfs-subdir	文件（RWX）	中小规模、传统业务	低	中	需 keepalived 自建
Longhorn	块（RWX via NFS）	K8s 云原生首选	中	中	内置
Rook-Ceph	块/文件/对象	大规模、混合负载	高	高	内置（多副本）
OpenEBS	块/文件	国产化、CSI 友好	中	中	可选
CubeFS	文件/对象/块	国产云原生	中	高	内置
Vitess / TiDB	数据库专用	持久化数据库	高	高	内置
Local Path / HostPath	本地盘	单节点 / StatefulSet	低	最高	无
AWS EBS / GCP PD	云盘	云上	低	高	内置
NFS CSI driver for K8s	NFS 官方版	NFS 4.1+	低	中	自建

6.4 2024 选型建议

业务场景	推荐
CI/CD 临时构建、多 Pod 共享配置	NFS + nfs-subdir 仍最优（RWX 简单）
生产数据库（MySQL / PG / Redis）	云盘 / Rook-Ceph RBD / 本地盘（RWO 性能）
AI / 大数据	CephFS / Lustre / JuiceFS（高带宽）
国产化	CubeFS / 浪潮 AS13000
小团队 + 简单	Longhorn（一键装、UI 友好）
私有化 + 信创	NFS + nfs-subdir（Linux 原生 + 国产 OS 兼容）

6.5 实战：Longhorn 一键装

 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


# Longhorn 是 Rancher 出品的云原生块存储
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.4/deploy/longhorn.yaml

# 默认 StorageClass
kubectl get sc longhorn

# 创建一个 StatefulSet 用 Longhorn
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: pg
spec:
 serviceName: pg
 replicas: 1
 selector:
 matchLabels: { app: pg }
 template:
 metadata:
 labels: { app: pg }
 spec:
 containers:
 - name: pg
 image: postgres:16
 volumeMounts:
 - name: data
 mountPath: /var/lib/postgresql/data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: longhorn
 resources:
 requests:
 storage: 10Gi
EOF

Longhorn 自动做 3 副本 + 跨节点同步 + 在线扩容 + 备份——NFS 的 keepalived + rsync 全套都不用做。

6.6 NFS 2024 仍然"有用"的场景

虽然新项目优先选 Longhorn/Ceph，但以下场景 NFS 仍是最佳选择：

跨 namespace / 跨集群共享数据（Longhorn 默认单集群）
Windows + Linux 混合客户端（NFS 协议通用性强）
AI 训练把数据集放在 NFS，多个训练 Pod 同时读（RWX）
传统业务——银行 ERP、政府办公系统（必须 NFS、SMB 协议）
国产化 / 信创项目（NFS 是 Linux 内核自带，不依赖任何商业软件）

6.7 一句话总结

2016 年的 NFS 4.1 + nfs-subdir + keepalived 方案在 2024 仍然能跑——但新项目建议直接用 Longhorn（块 + 简单）或 Ceph（大规模 + 混合）。

NFS 不是"过时"了，而是从默认选择退到备选——看场景用。

7. 小结

NFS 在 K8s 存储选型中仍然有一席之地：

动态 StorageClass（nfs-subdir）让 NFS 用法跟云盘一样简单
keepalived + rsync + lsyncd 组成"穷人版"高可用
NFS 单点风险依然存在，关键业务建议 Ceph / Longhorn
2024 新选择：Longhorn（首选）/ Rook-Ceph（大规模）/ 国产 CubeFS（信创）

下一步：Rook-Ceph 1.17 分布式存储：块存储 RBD + CephFS + OSD/MON。 2024 推荐：先看 Longhorn 官方文档（一键装，3 副本 + 备份），再做 Ceph。

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 协议可能还是不会变——这就是"基础设施"的浪漫。