DeepFlow项目中multus CNI环境下NodeNIC采集异常问题分析

问题背景

在Kubernetes环境中使用multus CNI配合whereabouts IPAM插件时，DeepFlow Agent对节点网卡(Node NIC)的流量采集出现了异常现象。具体表现为Node NIC的tap_side被错误标记为"Rest"，而预期应为"ClientNode"或"ServerNode"。

环境配置

该环境采用以下技术栈：

• Kubernetes网络方案：multus CNI + whereabouts IPAM
• 网络拓扑：Pod间通过HTTP1协议通信
• 报文路径：Client Pod → Client Pod NIC → br0 → Client Node NIC → 外部网络 → Server Node NIC → br0 → Server Pod NIC → Server Pod

问题现象

在流量采集过程中，观察到以下异常：

1. Pod NIC采集正常：

   • tap_side正确标记为Client/Server
   • directions字段显示正确的流量方向

2. Node NIC采集异常：

   • tap_side被标记为Rest
   • directions字段显示为[None, None]
   • is_l2_end和is_l3_end标志位设置不正确

根本原因分析

经过深入排查，发现问题源于以下因素：

1. 资源标识混乱：DeepFlow控制器数据库中出现了重复的Kubernetes集群domain记录，导致Agent无法正确识别节点网卡所属的集群。

2. MAC地址匹配异常：Node NIC的MAC地址与报文中实际MAC不匹配，尽管已设置ignore_l2_end和ignore_mac参数，但仍影响了后续处理流程。

3. 集群ID不一致：Agent配置的pod_cluster_id与资源实际的pod_cluster_id不一致，导致资源关联错误。

解决方案

1. 清理重复domain：

   • 使用deepflow-ctl domain list检查当前环境中的云平台情况
   • 删除重复的Kubernetes集群domain记录

2. 统一集群标识：

   • 确保Agent配置中的kubernetes-cluster-id与实际集群ID一致
   • 验证deepflow-agent的values.yaml配置

3. 配置优化：

   • 确认flow_log.processors.conntrack.flow_generation配置正确
   • 检查cloud_traffic_ignore_mac和ignore_l2_end参数设置

验证结果

实施上述解决方案后：

1. Node NIC的tap_side正确显示为ClientNode/ServerNode
2. directions字段正确反映流量方向
3. 端到端流量追踪功能恢复正常

经验总结

在DeepFlow部署过程中，特别是使用复杂CNI插件时，需要注意：

1. 确保Kubernetes集群标识的唯一性和一致性
2. 对于非标准网络拓扑，需要仔细验证流量采集点的配置
3. 定期检查控制器数据库中的资源记录，避免重复或冲突
4. 充分利用deepflow-ctl工具进行配置验证和问题排查

该案例展示了DeepFlow在复杂CNI环境下的适应能力，同时也提醒我们在部署时需要关注集群元数据的一致性管理。