Amazon VPC CNI K8s中ENIConfig配置失效问题分析与解决方案

问题背景

在Kubernetes集群中使用Amazon VPC CNI插件时，当从v1.12.6版本升级到v1.16.0后，部分Pod会被错误地分配到trunk接口而非预期的ENI接口。这导致Pod无法获取ENIConfig中定义的正确安全组配置，从而引发网络连通性问题。

问题现象

用户报告在升级后出现以下异常情况：

1. 部分Pod被分配到trunk接口(aws-k8s-trunk-eni)而非常规ENI接口
2. 这些Pod获取的是默认安全组而非ENIConfig中指定的安全组
3. 问题主要出现在节点刚启动时被调度的Pod上

技术分析

环境配置

用户环境具有以下特点：

• Kubernetes版本：v1.27.9-eks-5e0fdde
• 操作系统：Amazon Linux 2
• 内核版本：5.10.205-195.807.amzn2.x86_64
• 启用了自定义网络配置(AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true)
• 启用了Pod安全组(ENABLE_POD_ENI=true)
• 启用了前缀委托(ENABLE_PREFIX_DELEGATION=true)
• 使用Calico进行网络策略管理

根本原因

经过深入分析，发现问题由以下几个因素共同导致：

1. 功能启用顺序变化：在v1.16.x版本中，IPAMD启用功能的顺序从v1.15.5的"先自定义网络后Pod安全组"变为"先Pod安全组后自定义网络"，这导致VPC资源控制器在创建trunk ENI时未能正确应用ENIConfig配置。

2. trunk ENI安全组不可变：当前实现中，trunk ENI的安全组在创建后无法修改。如果ENIConfig发生变化，现有节点上的trunk ENI安全组不会自动更新。

3. 小规格实例限制：对于仅支持2个ENI的小规格实例(如r7a.medium)，当同时启用自定义网络和Pod安全组时，系统无法同时满足trunk ENI和常规ENI的需求，导致网络配置异常。

解决方案

AWS团队已经针对此问题提出了以下解决方案：

1. 代码修复：

   • 恢复IPAMD中功能启用的顺序，确保先启用自定义网络再启用Pod安全组
   • 禁止将IP地址或前缀分配给trunk ENI或EFA ENI
   • 添加集成测试防止回归

2. 版本计划：

   • 修复已合并到主分支
   • 将在v1.16.4版本中发布(计划于3月初发布)

3. 临时解决方案：

   • 回退到v1.15.5版本
   • 确保在更改网络配置后完全终止节点(不仅仅是drain)，以便VPC资源控制器重建内部状态

最佳实践建议

1. 配置变更后的节点处理：

   • 当修改ENIConfig或相关网络配置时，必须完全终止受影响的节点
   • 简单的drain操作不足以使配置生效，因为trunk ENI不会被自动分离

2. 实例类型选择：

   • 避免在仅支持2个ENI的小规格实例上同时启用自定义网络和Pod安全组
   • 考虑使用支持3个以上ENI的实例类型以获得更稳定的网络行为

3. 监控与验证：

   • 升级后检查Pod分配到的ENI类型和安全组
   • 验证跨版本的功能一致性，特别是网络策略和安全组配置

总结

Amazon VPC CNI K8s插件在v1.16.x版本中由于功能启用顺序变化导致的ENIConfig配置失效问题，影响了Pod网络和安全组的正确分配。AWS团队已定位问题原因并提供了修复方案，将在下一版本中发布。在此期间，用户可采取回退版本或遵循特定操作流程来确保网络配置正确应用。

对于生产环境，建议在升级前充分测试网络配置，特别是同时使用自定义网络和Pod安全组的场景，并关注AWS官方发布说明以获取最新修复信息。