Amazon VPC CNI插件对EKS Pod Identity的支持演进与实践指南

背景概述

Amazon VPC CNI（Container Network Interface）作为AWS EKS集群中负责Pod网络通信的核心组件，其身份认证机制一直采用IRSA（IAM Roles for Service Accounts）方案。随着EKS Pod Identity这一更先进的认证方式的推出，社区对VPC CNI支持新特性的呼声日益高涨。

技术演进过程

初始支持阶段

在早期版本中，VPC CNI仅支持传统的IRSA认证方式。当用户尝试直接使用Pod Identity时，会遇到典型的"鸡生蛋蛋生鸡"问题：

1. Pod Identity Agent需要先运行才能为VPC CNI提供认证
2. 但VPC CNI未正常运行会导致节点网络不可用
3. 网络不可用又阻止了Pod Identity Agent的调度

关键突破点

社区通过实践发现了两个有效的解决方案：

方案一：容忍度配置增强 通过为Pod Identity Agent添加特定的容忍度配置，使其能够在节点未完全就绪时仍可被调度：

{
  "tolerations": [
    {
      "key": "node.kubernetes.io/not-ready",
      "operator": "Equal",
      "effect": "NoSchedule"
    }
  ]
}

方案二：回退到节点IAM角色 作为临时方案，可以将AmazonEKS_CNI_Policy直接附加到节点IAM角色，但这会降低安全隔离性。

官方解决方案

AWS团队在Pod Identity Agent v1.2.0-eksbuild.1版本中正式加入了必要的容忍度配置，从根本上解决了调度依赖问题。同时，VPC CNI从1.15.5版本开始已集成支持Pod Identity所需的SDK组件。

最佳实践建议

1. 版本选择：确保使用VPC CNI 1.15.5+和Pod Identity Agent v1.2.0+版本组合
2. 升级策略：建议分阶段升级，先保持IRSA配置升级CNI版本，再迁移到纯Pod Identity
3. 故障排查：当遇到CNI Pod卡在就绪检查时，检查AWS_CONTAINER_CREDENTIALS_FULL_URI环境变量是否正常注入

技术原理深入

Pod Identity相比传统IRSA的主要优势在于：

• 消除了对OIDC提供商的依赖
• 简化了权限管理模型
• 提高了认证效率

在实现层面，VPC CNI通过检测环境变量AWS_CONTAINER_CREDENTIALS_FULL_URI自动切换至Pod Identity认证流程，这与标准AWS SDK的行为保持一致。

未来展望

随着Pod Identity的全面推广，预计AWS将进一步优化相关组件的默认配置，包括：

• 更智能的调度策略
• 更完善的文档支持
• 更紧密的版本兼容性管理

运维团队应持续关注官方更新，及时调整集群配置以获得最佳的安全性和可用性体验。