EKS Anywhere 中网络环境变量失效导致Cilium升级失败问题分析

问题背景

在EKS Anywhere v0.22.0版本中，用户报告了一个关于网络配置的问题。当集群运行在需要通过中间服务器访问外部网络的网络环境中时，eksa-controller-manager组件在尝试升级或安装Cilium CNI插件时会失败，错误显示无法连接到ECR仓库。

问题现象

具体表现为两种场景：

1. 从v0.21.7升级到v0.22.0时，eksa-controller-manager无法生成Cilium升级预检清单
2. 全新安装v0.22.0集群时，Cilium安装过程失败

错误信息中都包含类似的连接拒绝提示，表明组件未能通过中间服务器访问ECR仓库，尽管HTTPS_PROXY环境变量已正确配置。

技术分析

深入分析这个问题，我们可以理解到几个关键点：

1. 网络配置机制：在Kubernetes环境中，通常通过Pod的环境变量来配置网络设置。在本案例中，HTTPS_PROXY已正确设置为http://[redacted]:8080，NO_PROXY则配置为私有网络地址段。

2. 组件行为变化：v0.21.7版本可以正常工作，而v0.22.0出现故障，这表明新版本中处理HTTP请求的组件行为发生了变化，可能没有正确继承或使用系统网络设置。

3. Cilium镜像获取流程：EKS Anywhere使用Helm从OCI仓库获取Cilium图表时，需要能够访问公共ECR仓库。当网络设置失效时，这个关键的网络请求会失败。

解决方案

根据用户反馈，该问题在v0.22.2版本中已得到修复。对于遇到类似问题的用户，建议：

1. 直接升级到v0.22.2或更高版本
2. 如果必须使用v0.22.0，可以考虑临时解决方案：
   • 检查并确保所有相关组件都有正确的网络环境变量
   • 验证网络策略是否允许中间服务器连接
   • 考虑将ECR端点添加到NO_PROXY例外列表（如果安全策略允许）

经验总结

这个问题提醒我们在Kubernetes环境中处理网络配置时需要特别注意：

1. 组件升级时要测试网络相关的功能
2. 确保所有需要访问外部网络的组件都能正确继承网络设置
3. 对于容器化应用，明确了解其网络栈如何处理网络配置

网络配置问题在受限网络环境中很常见，理解这类问题的排查思路对运维人员很有价值。通过分析请求失败的具体阶段和组件，可以快速定位问题根源。