1. Kubernetes高可用集群架构解析在传统单Master节点Kubernetes架构中API Server作为整个集群的中枢神经系统一旦发生故障将导致整个集群失联。我们采用KeepalivedHaproxy方案实现双活冗余其核心设计理念可类比机场塔台系统即使主塔台因故停用备用塔台也能立即接管航空管制职能。典型三节点拓扑中两个负载均衡节点LB1/LB2运行Keepalived竞选VIP获胜节点通过Haproxy将流量分发到三个Master节点的6443端口。这种设计带来三个关键优势任一Master节点故障时剩余节点仍可维持集群操作当主LB节点宕机VIP在秒级自动迁移至备用LBHaproxy的健康检查机制自动屏蔽异常Master节点2. 基础环境准备与组件选型2.1 硬件资源配置建议节点类型CPU内存磁盘网络要求负载均衡节点2核4GB50GB系统盘千兆网卡x2心跳线专用Master节点4核8GB100GB千兆网卡Worker节点按需按需按需千兆网卡关键提示生产环境务必为LB节点配置独立心跳网络使用第二块网卡避免与业务流量竞争带宽导致脑裂问题。2.2 关键组件版本匹配Kubernetes: 1.24.x较新版本已移除dockershim需注意容器运行时选择Haproxy: 2.4.x支持动态配置加载Keepalived: 2.2.x稳定版VRRP实现OS: Rocky Linux 9.x兼容RHEL生态且无订阅限制3. Keepalived深度配置实战3.1 VRRP协议配置精要# /etc/keepalived/keepalived.conf 主节点配置 vrrp_instance VI_1 { state MASTER interface eth0 # 监听网卡 virtual_router_id 51 # 集群唯一ID priority 100 # 选举权重 advert_int 1 # 心跳间隔 authentication { auth_type PASS auth_pass 5a1d-789x # 集群通信密码 } virtual_ipaddress { 192.168.1.100/24 dev eth0 # 对外VIP } }关键参数解析virtual_router_id必须全集群一致范围1-255priority主节点建议100备节点90差值建议≥10advert_int生产环境建议调至3秒避免网络抖动误切换3.2 脑裂防护机制通过添加以下脚本检测实现双保险vrrp_script chk_haproxy { script killall -0 haproxy # 轻量级进程检查 interval 2 # 检测频率 weight -20 # 失败时降权值 }4. Haproxy四层负载均衡配置4.1 核心配置模板# /etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 5000 user haproxy group haproxy defaults mode tcp timeout connect 5s timeout client 50s timeout server 50s frontend k8s-api bind *:6443 default_backend k8s-masters backend k8s-masters balance roundrobin option tcp-check server master1 192.168.1.101:6443 check fall 3 rise 2 server master2 192.168.1.102:6443 check fall 3 rise 2 server master3 192.168.1.103:6443 check fall 3 rise 24.2 健康检查优化策略tcp-check基础端口检测消耗资源少但无法感知API Server假死进阶方案添加HTTP健康检查端点option httpchk GET /healthz http-check expect status 2005. 系统调优与排错指南5.1 内核参数调优# /etc/sysctl.d/k8s.conf net.ipv4.ip_nonlocal_bind1 # 允许绑定非本地IP net.ipv4.ip_forward1 # 启用IP转发 net.ipv4.vs.conn_reuse_mode0 # 防止TIME-WAIT问题 net.netfilter.nf_conntrack_max1000000 # 增大连接跟踪表5.2 常见故障排查VIP无法访问tcpdump -i eth0 vrrp # 检查VRRP通告报文 ip addr show eth0 # 确认VIP绑定状态Haproxy流量不均echo show stat | socat /var/run/haproxy/admin.sock stdio # 查看实时流量分布API Server间歇性超时ss -spt | grep 6443 # 检查连接状态统计 dmesg | grep dropped # 检查内核丢包记录6. 生产环境验证方案6.1 故障转移测试流程模拟主LB宕机systemctl stop keepalived # 在主LB执行观察VIP迁移watch -n 1 ip a # 在备LB查看VIP获取验证集群功能kubectl get nodes --request-timeout3s # 检查API响应6.2 性能压测指标使用kube-bench工具验证配置合规性docker run --rm --pidhost -v /etc:/etc:ro \ -v /var:/var:ro -t aquasec/kube-bench:latest master建议达到的SLA指标故障转移时间 5秒API请求P99延迟 500ms最大并发连接数 5000 
长河君 · 2026/11/3 15:02:03 · 阅读 1.2k Kubernetes高可用集群架构与Keepalived+Haproxy实战
1. Kubernetes高可用集群架构解析在传统单Master节点Kubernetes架构中API Server作为整个集群的中枢神经系统一旦发生故障将导致整个集群失联。我们采用KeepalivedHaproxy方案实现双活冗余其核心设计理念可类比机场塔台系统即使主塔台因故停用备用塔台也能立即接管航空管制职能。典型三节点拓扑中两个负载均衡节点LB1/LB2运行Keepalived竞选VIP获胜节点通过Haproxy将流量分发到三个Master节点的6443端口。这种设计带来三个关键优势任一Master节点故障时剩余节点仍可维持集群操作当主LB节点宕机VIP在秒级自动迁移至备用LBHaproxy的健康检查机制自动屏蔽异常Master节点2. 基础环境准备与组件选型2.1 硬件资源配置建议节点类型CPU内存磁盘网络要求负载均衡节点2核4GB50GB系统盘千兆网卡x2心跳线专用Master节点4核8GB100GB千兆网卡Worker节点按需按需按需千兆网卡关键提示生产环境务必为LB节点配置独立心跳网络使用第二块网卡避免与业务流量竞争带宽导致脑裂问题。2.2 关键组件版本匹配Kubernetes: 1.24.x较新版本已移除dockershim需注意容器运行时选择Haproxy: 2.4.x支持动态配置加载Keepalived: 2.2.x稳定版VRRP实现OS: Rocky Linux 9.x兼容RHEL生态且无订阅限制3. Keepalived深度配置实战3.1 VRRP协议配置精要# /etc/keepalived/keepalived.conf 主节点配置 vrrp_instance VI_1 { state MASTER interface eth0 # 监听网卡 virtual_router_id 51 # 集群唯一ID priority 100 # 选举权重 advert_int 1 # 心跳间隔 authentication { auth_type PASS auth_pass 5a1d-789x # 集群通信密码 } virtual_ipaddress { 192.168.1.100/24 dev eth0 # 对外VIP } }关键参数解析virtual_router_id必须全集群一致范围1-255priority主节点建议100备节点90差值建议≥10advert_int生产环境建议调至3秒避免网络抖动误切换3.2 脑裂防护机制通过添加以下脚本检测实现双保险vrrp_script chk_haproxy { script killall -0 haproxy # 轻量级进程检查 interval 2 # 检测频率 weight -20 # 失败时降权值 }4. Haproxy四层负载均衡配置4.1 核心配置模板# /etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 5000 user haproxy group haproxy defaults mode tcp timeout connect 5s timeout client 50s timeout server 50s frontend k8s-api bind *:6443 default_backend k8s-masters backend k8s-masters balance roundrobin option tcp-check server master1 192.168.1.101:6443 check fall 3 rise 2 server master2 192.168.1.102:6443 check fall 3 rise 2 server master3 192.168.1.103:6443 check fall 3 rise 24.2 健康检查优化策略tcp-check基础端口检测消耗资源少但无法感知API Server假死进阶方案添加HTTP健康检查端点option httpchk GET /healthz http-check expect status 2005. 系统调优与排错指南5.1 内核参数调优# /etc/sysctl.d/k8s.conf net.ipv4.ip_nonlocal_bind1 # 允许绑定非本地IP net.ipv4.ip_forward1 # 启用IP转发 net.ipv4.vs.conn_reuse_mode0 # 防止TIME-WAIT问题 net.netfilter.nf_conntrack_max1000000 # 增大连接跟踪表5.2 常见故障排查VIP无法访问tcpdump -i eth0 vrrp # 检查VRRP通告报文 ip addr show eth0 # 确认VIP绑定状态Haproxy流量不均echo show stat | socat /var/run/haproxy/admin.sock stdio # 查看实时流量分布API Server间歇性超时ss -spt | grep 6443 # 检查连接状态统计 dmesg | grep dropped # 检查内核丢包记录6. 生产环境验证方案6.1 故障转移测试流程模拟主LB宕机systemctl stop keepalived # 在主LB执行观察VIP迁移watch -n 1 ip a # 在备LB查看VIP获取验证集群功能kubectl get nodes --request-timeout3s # 检查API响应6.2 性能压测指标使用kube-bench工具验证配置合规性docker run --rm --pidhost -v /etc:/etc:ro \ -v /var:/var:ro -t aquasec/kube-bench:latest master建议达到的SLA指标故障转移时间 5秒API请求P99延迟 500ms最大并发连接数 5000