Kube-VIP中如何保留客户端真实源IP地址

在Kubernetes集群中使用Kube-VIP作为负载均衡器时，许多用户会遇到一个常见问题：后端Pod无法获取到客户端的真实源IP地址，取而代之的是集群内部的IP地址。这个问题不仅影响日志记录，还可能带来安全隐患。本文将深入分析这一现象的原因，并提供完整的解决方案。

问题现象分析

当通过Kube-VIP暴露的服务接收外部请求时，后端Pod的日志中显示的源IP地址通常是集群内部节点的IP（如10.42.x.x），而不是真实的客户端IP。这种现象的根本原因在于Kubernetes服务默认的流量处理机制。

在默认配置下，Kubernetes的Service资源使用"Cluster"模式的externalTrafficPolicy，这意味着：

1. 外部流量首先到达任意一个节点
2. 然后通过kube-proxy转发到实际运行Pod的节点
3. 这个过程中会进行SNAT（源地址转换），导致源IP信息丢失

解决方案：使用Local模式

要保留客户端真实IP，我们需要修改服务的externalTrafficPolicy为"Local"模式。这种模式下：

1. 流量只会被路由到运行有对应服务Pod的节点
2. 不会进行SNAT转换，保留原始源IP
3. 需要Kube-VIP运行在所有可能承载服务Pod的节点上

配置示例：

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

Kube-VIP部署架构调整

为了实现Local模式正常工作，我们需要调整Kube-VIP的部署方式：

1. 分离控制平面和负载均衡功能：

   • 为控制平面VIP使用单独的DaemonSet，仅部署在控制平面节点
   • 为服务负载均衡使用另一个DaemonSet，部署在所有节点

2. 关键配置参数：

   • 控制平面DaemonSet设置cp_enable: "true"和svc_enable: "false"
   • 服务负载均衡DaemonSet设置cp_enable: "false"和svc_enable: "true"
   • 确保svc_election: "true"（注意拼写正确）

3. RBAC权限：

   • 服务负载均衡的ServiceAccount需要足够的权限访问节点和端点资源

实现细节与注意事项

1. Leader选举机制：

   • Kube-VIP为每个服务使用独立的Leader选举
   • 只有运行有对应服务Pod的节点会参与选举
   • 这种设计确保了Local模式的正确工作

2. 健康检查：

   • Local模式下，Kube-VIP会检查节点上是否有服务对应的Pod
   • 如果没有健康Pod，节点不会接收流量

3. 性能考量：

   • Local模式可能导致流量分布不均匀
   • 需要确保服务Pod均匀分布在多个节点上

常见问题排查

1. 服务External-IP显示为Pending：

   • 检查Kube-VIP Pod是否在所有节点运行
   • 验证RBAC权限是否正确配置

2. 部分节点无法接收流量：

   • 确认节点上运行有服务Pod
   • 检查Kube-VIP日志中的选举信息

3. 连接超时或拒绝：

   • 验证externalTrafficPolicy拼写正确
   • 检查网络策略是否允许流量

总结

通过正确配置Kube-VIP和Kubernetes服务的externalTrafficPolicy，我们可以有效保留客户端真实IP地址。关键点在于：

1. 使用Local模式的externalTrafficPolicy
2. 合理部署Kube-VIP组件
3. 确保正确的RBAC权限
4. 理解Leader选举机制

这种配置不仅解决了源IP保留问题，还提供了更符合预期的网络行为，为日志分析、访问控制和安全审计提供了可靠的基础。