1. 为什么K8S高可用集群需要负载均衡VIP

想象一下你正在运营一个电商平台，双十一期间突然有一台服务器宕机，所有用户请求都卡死在这台机器上，这绝对是运维人员的噩梦。Kubernetes高可用集群的核心目标就是避免这种单点故障，而HAProxy+Keepalived的组合就像给系统装上了"双引擎"和"自动切换开关"。

在实际生产环境中，Kubernetes的API Server承担着集群大脑的角色。传统部署方式中，如果直接指定某个Master节点的IP作为访问入口，当这个节点故障时，整个集群就会失去控制平面。我曾在项目初期犯过这个错误，结果一次普通的硬件维护导致整个业务停摆半小时。

VIP（虚拟IP）技术相当于给多台服务器分配一个共用的"门牌号"。当主服务器正常时，所有流量都走这个门牌号进入主服务器；当检测到主服务器故障时，这个门牌号会自动指向备用的服务器。Keepalived就是这个"门牌管理员"，而HAProxy则是"智能接待员"，它能够根据服务器负载情况合理分配流量。

这里有个常见误区：既然Keepalived能管理VIP，为什么还要HAProxy？其实它们各司其职。Keepalived只负责VIP的故障转移，而HAProxy实现的是真正的流量分发。就好比Keepalived确保大门永远能打开，HAProxy则决定客人应该被引导到哪个服务窗口。

2. 生产环境架构设计与准备

2.1 硬件资源配置建议

在我的多个项目实施经验中，合理的硬件规划能避免后期很多麻烦。对于三节点生产集群，建议采用如下配置：

组件	最低配置	推荐配置
服务器数量	3台物理机或独立VM	3台物理机
CPU	4核	8核及以上
内存	8GB	16GB及以上
网络	1Gbps	双网卡绑定（bonding）
存储	100GB系统盘	SSD+RAID配置

特别提醒：一定要确保所有节点的时间同步！我曾经遇到因为时间不同步导致证书验证失败的诡异问题，建议配置chronyd服务：

# 所有节点执行
yum install -y chrony
systemctl enable chronyd --now
chronyc sources

2.2 网络拓扑规划

典型的部署架构如下图所示（注：此处应为文字描述）：

• 前端：VIP地址（如192.168.80.100）对外提供服务
• 中间层：3台负载均衡服务器，部署HAProxy+Keepalived
• 后端：多个K8S Master节点（通常也是3台）

关键的网络隔离建议：

• 管理网络与业务网络分离
• 为Keepalived配置独立的VLAN或子网
• 确保ICMP协议和VRRP协议（协议号112）不被防火墙拦截

3. HAProxy深度配置解析

3.1 四层负载均衡核心配置

HAProxy的配置文件就像交响乐的总谱，每个参数都影响最终性能。这是经过多个生产环境验证的优化配置模板：

global
    log /dev/log local0 info
    chroot /var/lib/haproxy
    pidfile /var/run/haproxy.pid
    maxconn 10000
    user haproxy
    group haproxy
    daemon
    stats socket /var/lib/haproxy/stats level admin expose-fd listeners

defaults
    mode tcp
    log global
    option tcplog
    option dontlognull
    timeout connect 5s
    timeout client 50s
    timeout server 50s
    retries 3

frontend kube-apiserver
    bind *:6443
    default_backend kube-apiserver

backend kube-apiserver
    balance roundrobin
    option tcp-check
    server k8s-master1 192.168.80.81:6443 check fall 2 rise 3 inter 2000
    server k8s-master2 192.168.80.82:6443 check fall 2 rise 3 inter 2000
    server k8s-master3 192.168.80.83:6443 check fall 2 rise 3 inter 2000

listen stats
    bind *:8888
    mode http
    stats enable
    stats hide-version
    stats uri /stats
    stats auth admin:YourStrongPassword

几个关键参数解释：

• maxconn 10000：根据服务器内存调整，每个连接约占用1KB内存
• balance roundrobin：最简单的轮询算法，生产环境也可考虑leastconn
• fall 2 rise 3：连续2次检查失败标记为DOWN，3次成功恢复

3.2 健康检查机制优化

默认的TCP检查可能不够精准，我们可以增强检查逻辑：

backend kube-apiserver
    option httpchk GET /healthz
    http-check expect status 200
    server k8s-master1 192.168.80.81:6443 check port 8080

这里有个坑要注意：/healthz端点需要配置匿名访问，否则检查会失败。修改API Server配置：

# 在/etcd/kubernetes/manifests/kube-apiserver.yaml添加
- --anonymous-auth=true

4. Keepalived高可用实战

4.1 VRRP协议深度解析

Keepalived基于VRRP协议工作，可以理解为"服务器选举机制"。配置文件中几个关键参数：

vrrp_instance VI_1 {
    state MASTER       # 初始状态
    interface eth0     # 监听的网卡
    virtual_router_id 51  # 集群内唯一ID
    priority 100       # 选举权重(100-1)
    advert_int 1       # 心跳间隔(秒)
    authentication {
        auth_type PASS
        auth_pass yourpassword
    }
    virtual_ipaddress {
        192.168.80.100/24 dev eth0
    }
}

实际部署时踩过的坑：

• virtual_router_id必须在同一网段内唯一
• 不同节点的priority要有明显梯度（如100/90/80）
• 生产环境建议使用更复杂的auth_pass

4.2 智能故障检测脚本

单纯检测端口可能不够，这个脚本会检查HAProxy进程和端口：

#!/bin/bash
if ! pidof haproxy >/dev/null; then
    exit 1
fi

if ! netstat -tuln | grep -q ':9443'; then
    exit 1
fi

# 检查API Server实际响应
if ! curl -k https://localhost:6443/healthz &>/dev/null; then
    exit 1
fi

exit 0

记得给脚本执行权限并测试：

chmod +x /etc/keepalived/check_script.sh
/etc/keepalived/check_script.sh && echo "Healthy" || echo "Unhealthy"

5. 集群验证与故障演练

5.1 基础功能测试

部署完成后，建议按以下步骤验证：

1. VIP可达性测试：

   ping 192.168.80.100
   curl -k https://192.168.80.100:6443/healthz
   

2. 负载均衡检查：

   for i in {1..10}; do 
     curl -k https://192.168.80.100:6443/version | grep gitVersion
   done
   

3. HAProxy监控界面： 访问http://VIP:8888/stats，应该看到所有后端都是UP状态

5.2 模拟故障场景

真正的考验在于故障恢复能力，建议进行以下测试：

1. 主节点HAProxy服务停止：

   systemctl stop haproxy
   # 观察VIP是否漂移到备用节点
   

2. 断开主节点网络：

   ifdown eth0
   # 观察日志 /var/log/messages
   

3. 模拟脑裂场景（危险操作）： 同时停止所有节点的Keepalived，然后逐个启动观察选举过程

记录每个场景的恢复时间，生产环境RTO（恢复时间目标）应控制在30秒内。

6. 高级调优与生产经验

6.1 性能优化参数

经过多次压测验证的调优参数：

global
    tune.ssl.default-dh-param 2048
    tune.bufsize 32768
    tune.maxrewrite 1024

defaults
    timeout http-keep-alive 300s
    timeout tunnel 1h
    option http-keep-alive
    option http-server-close

对于超大集群，可以考虑：

• 启用多线程：nbthread 4
• 调整内核参数：

  echo "net.ipv4.tcp_max_syn_backlog = 10240" >> /etc/sysctl.conf
  echo "net.core.somaxconn = 10240" >> /etc/sysctl.conf
  sysctl -p
  

6.2 安全加固建议

生产环境必须考虑的安全措施：

1. 访问控制：

   frontend kube-apiserver
       bind *:6443
       acl allowed_ips src 10.0.0.0/8 192.168.0.0/16
       tcp-request connection reject if !allowed_ips
   

2. 证书认证：

   backend kube-apiserver
       server k8s-master1 192.168.80.81:6443 check ssl verify required ca-file /etc/ssl/ca.pem
   

3. 日志审计：

   global
       log 10.0.0.100:514 local0 notice
   

在最近一次安全扫描中，我们发现默认配置的HAProxy存在HTTP请求走私漏洞，必须更新到2.4+版本并添加配置：

http-reuse never