Cilium项目中EKS Pod Identity Agent的MTU问题分析与解决方案

背景介绍

在AWS EKS环境中，用户通常会部署EKS Pod Identity Agent组件。这个代理运行在主机网络命名空间中，并创建一个名为dummy的虚拟网络接口(IP地址为169.254.170.23)，其MTU值默认为1500。这个接口的主要功能是为Pod提供获取AWS IAM权限的能力。

问题描述

在Cilium的网络实现中，我们通常会将这个dummy接口包含在设备列表中，将其视为Pod到主机的通信路径。然而，这会导致MTU自动检测方面的问题：

1. 当EC2实例使用9000 MTU(Jumbo Frame)时，由于dummy接口的MTU仅为1500，Cilium会采用两者中较小的值(1500)作为最终MTU
2. 如果手动将MTU设置为9000，对于使用Karpenter等自动伸缩工具的环境，可能会遇到某些节点实际支持的MTU仅为1500的情况，导致网络问题

技术分析

从网络协议栈的角度来看，dummy接口是一种特殊的虚拟网络设备，主要用于本地通信。实际上，从Pod发出的流量会经过veth对到达主机网络栈，经过路由表查询后直接进入用户空间处理，并不会真正通过dummy接口传输数据。

因此，在Cilium的MTU自动检测机制中考虑dummy接口的MTU值是不必要的，甚至会导致错误的MTU配置。这类似于在计算路径MTU时考虑回环接口(lo)的MTU值一样没有实际意义。

解决方案

针对这一问题，我们提出了两种可能的解决方案：

1. 特定排除方案：修改Cilium的MTU管理代码，在ENI模式下显式排除EKS Pod Identity Agent创建的dummy接口。这种方法针对性强，但可能不够通用。

2. 通用排除方案：在Cilium的MTU自动检测机制中，默认排除所有类型为dummy的接口。这种方法更加通用和健壮，因为：

   • dummy接口本质上只用于本地通信
   • 不会影响实际的数据包传输路径
   • 避免了未来可能出现的类似问题

从技术合理性和长期维护的角度来看，第二种通用排除方案更为合适。它不仅解决了当前EKS环境下的特定问题，还能预防其他类似场景可能带来的MTU配置问题。

实施建议

对于使用Cilium的EKS用户，如果遇到MTU相关问题，可以考虑以下步骤：

1. 检查节点上是否存在dummy类型的接口
2. 确认这些接口是否影响了Cilium的MTU自动检测
3. 根据实际情况选择是否需要在Cilium配置中排除这些接口

对于Cilium开发者，建议在MTU自动检测逻辑中加入对dummy接口的过滤，以提供更加准确和可靠的MTU配置。