Kube-VIP在Local模式下服务负载均衡问题解析与解决方案

问题背景

在Kubernetes裸金属集群中使用Kube-VIP实现LoadBalancer服务时，当服务配置为externalTrafficPolicy: Local模式时，经常会出现VIP无法正确分配到节点的问题。具体表现为：

1. 新创建的Service的VIP状态持续处于Pending状态
2. 已有Service的VIP不会随Pod迁移而重新分配
3. 仅当Pod运行在控制平面节点时VIP才能正常工作

问题根源分析

经过深入分析，这个问题主要由以下几个因素导致：

1. 节点选择机制：Kube-VIP的DaemonSet默认仅部署在控制平面节点上，导致它只能感知到这些节点上的Pod状态

2. Local模式特性：externalTrafficPolicy: Local要求流量必须直接到达运行Pod的节点，而传统部署方式无法感知工作节点上的Pod

3. 选举机制：当启用servicesElection=true时，VIP分配决策基于节点上的Pod存在情况，但默认配置限制了决策范围

解决方案

方案一：分离控制平面与负载均衡功能

最佳实践是将控制平面的VIP功能与服务负载均衡功能分离部署：

1. 控制平面VIP：部署一个仅处理控制平面流量的Kube-VIP实例

   # 仅处理控制平面流量
   args:
   - manager
   env:
   - name: vip_arp
     value: "true"
   - name: vip_leaderelection
     value: "true"
   

2. 服务负载均衡：部署另一个专门处理服务流量的Kube-VIP实例

   # 专门处理服务流量
   args:
   - manager
   env:
   - name: vip_arp
     value: "true"
   - name: svc_enable
     value: "true"
   - name: svc_election
     value: "true"
   

方案二：全节点部署

如果资源允许，可以在所有节点（包括工作节点）上部署Kube-VIP：

1. 修改DaemonSet的节点选择器，使其在所有节点上运行
2. 确保所有节点都具备ARP响应能力
3. 配置适当的资源限制以避免资源浪费

实现细节

配置示例

完整的服务负载均衡专用配置示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-vip-lb
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kube-vip-lb
  template:
    metadata:
      labels:
        app: kube-vip-lb
    spec:
      containers:
      - name: kube-vip
        image: ghcr.io/kube-vip/kube-vip:v0.7.2
        args: ["manager"]
        env:
        - name: vip_arp
          value: "true"
        - name: svc_enable
          value: "true"
        - name: svc_election
          value: "true"
        securityContext:
          capabilities:
            add: ["NET_ADMIN", "NET_RAW"]

验证步骤

1. 部署上述配置后，创建测试服务：

   apiVersion: v1
   kind: Service
   metadata:
     name: test-service
   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
     selector:
       app: test-app
     ports:
       - port: 80
         targetPort: 8080
   

2. 观察VIP分配情况：

   kubectl get svc test-service -w
   

3. 检查Kube-VIP日志确认分配过程：

   kubectl logs -l app=kube-vip-lb -n kube-system
   

最佳实践建议

1. 资源隔离：将控制平面流量和服务流量完全隔离，避免相互影响

2. 监控配置：为两种VIP功能分别配置监控，使用不同的Prometheus端口

3. 版本管理：保持Kube-VIP版本更新，新版本通常会修复此类问题

4. 测试策略：在非生产环境充分测试Local模式的行为，特别是Pod迁移场景

5. 文档记录：明确记录集群中VIP功能的部署架构，便于后续维护

通过以上方案，可以确保Kube-VIP在Local模式下能够正确识别所有节点上的Pod，并实现VIP的自动分配和迁移，满足生产环境的高可用需求。