k0s项目中控制平面负载均衡(CPLB)的Keepalived配置问题分析与解决方案

问题背景

在k0s项目的控制平面负载均衡(CPLB)功能中，使用Keepalived实现高可用时存在一个关键配置问题。该问题会导致TCP连接在多个控制平面节点之间形成无限循环，最终引发"No route to host"错误。这种现象在默认的Round-Robin负载均衡算法下尤为明显。

技术原理分析

Keepalived工作模式

Keepalived通过VRRP协议实现虚拟IP的漂移，同时利用Linux虚拟服务器(LVS)功能实现负载均衡。在k0s的CPLB实现中，所有控制平面节点都配置了相同的virtual_server段，这导致了问题的产生。

问题发生机制

1. 当客户端请求到达MASTER节点的虚拟IP(10.1.0.10)时，LVS会根据负载均衡算法选择一个后端节点
2. 如果选择了BACKUP节点，请求会被转发到该节点
3. 由于DR(Direct Routing)模式保持目标IP不变，BACKUP节点的LVS会再次进行负载均衡
4. 在Round-Robin算法下，可能再次选择MASTER节点，形成循环
5. 这种循环会持续直到IP包的TTL耗尽

问题复现与诊断

通过以下命令可以观察到问题现象：

# 检查各节点IP配置
for i in 10.1.0.{2..4}; do echo $i; ssh $i -- ip -4 --oneline addr show | grep -e enp6s18 -e dummyvip0; done

# 检查各节点LVS状态
for i in 10.1.0.{2..4}; do echo $i; ssh $i -- ipvsadm -L -n; done

在问题发生时，可以观察到：

• TCP连接在多个节点间跳转
• ipvsadm显示ActiveConn计数异常分布
• 最终产生"icmp time exceeded in-transit"错误

临时解决方案

目前可行的临时解决方案是将负载均衡算法从默认的Round-Robin(rr)改为Source Hash(sh)：

controlPlaneLoadBalancing:
  enabled: true
  type: Keepalived
  keepalived:
    vrrpInstances:
    - virtualIPs: ["10.1.0.10/24"]
      authPass: CPLB
    virtualServers:
    - ipAddress: "10.1.0.10"
      lbAlgo: sh

Source Hash算法通过对源IP进行哈希计算确定目标节点，可以避免循环问题，因为：

• 同一源IP的请求总是被分配到同一后端节点
• 即使请求被转发，二次负载均衡结果与首次一致
• 避免了Round-Robin算法可能导致的交替选择

根本解决方案建议

从架构角度，建议的完整解决方案应包括：

1. 将virtual_server配置分离为独立文件
2. 利用Keepalived的notify_master和notify_backup机制
3. 通过脚本动态管理配置加载：
   • MASTER节点启用virtual_server配置
   • BACKUP节点禁用virtual_server配置
4. 实现配置变更时的优雅重载机制
5. 添加防重载循环的保护逻辑

生产环境注意事项

目前CPLB功能尚处于beta阶段，在生产环境中使用时需注意：

1. 即使采用临时解决方案，仍可能出现控制平面节点崩溃问题
2. 配置变更操作(k0sctl apply)可能导致节点不可恢复
3. 建议在关键生产环境考虑使用外部负载均衡方案(如HAProxy)替代CPLB
4. 密切监控LVS连接状态和节点健康状态

未来改进方向

k0s团队已意识到此问题，并计划：

1. 引入用户空间负载均衡器作为替代方案
2. 完善Keepalived配置的健壮性
3. 增加更全面的测试覆盖
4. 优化配置变更的处理流程

对于需要高可用控制平面的用户，建议关注k0s的后续版本更新，待功能稳定后再在生产环境部署CPLB方案。