Amazon VPC CNI插件升级故障排查与解决方案

背景介绍

在Kubernetes集群管理过程中，网络插件是核心组件之一。AWS提供的Amazon VPC CNI插件负责为EKS集群中的Pod分配IP地址并管理网络连接。本文记录了一个从EKS 1.30升级到1.31版本时遇到的VPC CNI插件故障案例。

故障现象

在升级生产环境的EKS集群时，发现VPC CNI插件的一个Pod(aws-node-rkjkb)无法达到Ready状态。该Pod的日志显示在"Checking for IPAM connectivity..."阶段停滞不前，而其他节点的CNI Pod则正常运行。

环境信息

• Kubernetes版本：v1.31.9-eks-5d4a308
• CNI插件版本：v1.19.5-eksbuild.3
• 操作系统：Amazon Linux 2023.7.20250512
• 内核版本：6.1.134-152.225.amzn2023.x86_64
• 节点类型：t3.2xlarge和r6i.2xlarge两种规格

排查过程

初步分析

通过对比健康Pod和故障Pod的日志，发现故障Pod在IPAM(IP地址管理)连接检查阶段停滞。IPAM是CNI插件的核心功能，负责与AWS EC2 API通信以分配IP地址。

IAM角色检查

检查分配给CNI插件的IAM角色(AmazonEKSVPCCNIRole_prod)，确认已附加AmazonEKS_CNI_Policy策略。然而，AWS控制台的"Access Advisor"显示该角色在跟踪期内未被访问，这与预期行为不符。

日志收集与分析

使用CNI日志收集工具获取故障节点的详细日志。分析发现ipamd(IPAM守护进程)组件无法调用EC2 API，这表明IAM身份验证存在问题。

根本原因

通过对比开发环境和生产环境的配置差异，最终发现生产环境中CNI插件使用的IAM角色配置存在问题。具体来说，角色中的身份提供商(OIDC)引用不正确，导致CNI插件无法获取有效的AWS凭证来调用EC2 API。

解决方案

修正IAM角色中的身份提供商配置，确保CNI插件能够正确获取访问EC2 API所需的权限。具体步骤包括：

1. 检查并更新IAM角色的信任关系策略
2. 确保OIDC提供商URL与EKS集群匹配
3. 验证服务账户注解中的IAM角色ARN是否正确

经验总结

1. 升级前验证：在进行关键组件升级前，应在非生产环境充分测试验证
2. 配置对比：当生产环境出现问题时，与正常工作的开发环境配置对比是有效的排查手段
3. 权限检查：网络插件问题往往与IAM权限相关，应作为首要排查点
4. 日志分析：CNI插件提供的详细日志是诊断问题的重要依据

预防措施

为避免类似问题再次发生，建议：

1. 建立标准化的升级检查清单
2. 实现基础设施即代码(IaC)，确保环境一致性
3. 定期验证IAM角色的有效性
4. 在升级前备份关键配置

通过这次故障排查，我们不仅解决了具体问题，还加深了对Amazon VPC CNI插件工作原理的理解，特别是其与AWS IAM系统的交互机制。这对于未来管理大规模Kubernetes集群具有重要参考价值。