生产环境kubernetes高可用核心卡点是负载均衡器的正确配置：haproxy必须用mode tcp透传6443端口，后端加check ssl verify none；健康检查需httpchk /healthz而非仅tcp；keepalived绑定物理网卡、禁用preempt、配置vrrp认证；所有组件server地址必须统一指向vip，否则lb形同虚设。
生产环境的 Kubernetes 高可用，核心卡点不在 kubeadm init 或 CNI 插件，而在于负载均衡器是否真能扛住 apiserver 故障切换——很多集群看似三 master，实则 LB 配置错误导致 VIP 永久指向宕机节点，kubectl 直接超时。
HAProxy 必须用 TCP 模式代理 6443 端口
apiserver 是 HTTPS 服务，但 HAProxy 不能用 mode http，否则会因 TLS 握手失败或证书校验中断连接。必须用四层透传：
-
mode tcp，不解析 HTTP 层，只转发原始 TCP 流 - 后端
server行必须指定check ssl verify none（因为 apiserver 自签证书，HAProxy 默认拒绝） - 健康检查要用
option httpchk GET /healthz+http-check expect status 200，不能只靠 TCP 连通性（apiserver 进程存活但未就绪时，TCP 能通但 API 不可用）
Keepalived 的 VRRP 实例必须绑定物理网卡且禁用抢占
常见错误是把 vrrp_instance VI_1 绑定到 lo 或 Docker 网桥，导致 VIP 无法被外部访问；另外默认 preempt 开启会导致主备频繁漂移：
-
interface eth0（替换成实际内网网卡名，不是ens33或docker0） -
preempt_delay 30（而非preempt），避免网络抖动触发误切换 -
authentication { auth_type PASS; auth_pass 1111 }必须配置，否则多实例间无法同步状态
kubelet 和 kubeadm init 必须指向 VIP，而非单个 master IP
如果初始化时用 kubeadm init --control-plane-endpoint "192.168.1.100:6443"（VIP），但 worker 节点的 /etc/kubernetes/kubelet.conf 里 server 字段仍是 https://192.168.1.11:6443，那 LB 就形同虚设：
- 所有节点的
kubelet.conf、admin.conf、controller-manager.conf中的server值必须统一为https://<vip>:6443</vip> -
kubeadm join命令也必须带--control-plane-endpoint参数，否则新 master 加入后仍直连旧节点 - 验证方式：
curl -k https://<vip>:6443/healthz</vip>返回ok，且ip addr show在 LB 节点上能看到 VIP
云厂商 CLB（如腾讯云）需关闭会话保持和健康检查路径硬编码
用云负载均衡器替代自建 HAProxy+Keepalived 时，最容易忽略两点：
- CLB 默认开启「会话保持」，会导致流量始终打到同一台 master，失去负载意义——必须关闭
- 健康检查路径不能填
/healthz（CLB 多数不支持 HTTPS 后端的自定义 path 探针），应改用 TCP 端口探测（目标端口 6443） - CLB 安全组必须放行 6443 入向，且后端服务器组里的 master 节点要启用「健康检查主动探测」，否则 CLB 会把故障节点持续计入轮询池
真正难的不是写完 HAProxy 配置，而是让所有组件——从 kubelet 到 kubectl，从 etcd 成员发现到 controller-manager 的 leader 选举——都信任并依赖同一个 VIP。任何一处漏掉，高可用就变成纸糊的墙。
