AWS Load Balancer Controller在无外网环境下的部署问题解析

问题背景

在Kubernetes集群中使用AWS Load Balancer Controller时，经常会遇到Ingress资源无法正确创建Application Load Balancer的问题。特别是在企业内网环境中，当工作节点位于没有互联网访问权限的子网时，这个问题尤为常见。本文将以一个典型场景为例，深入分析问题原因并提供解决方案。

典型错误现象

当尝试在EKS集群中创建Ingress资源时，虽然所有资源配置看似正确，但ALB并未如期创建。通过查看控制器日志，会发现如下关键错误信息：

NoCredentialProviders: no valid providers in chain

同时，使用kubectl describe命令查看Ingress资源时，事件中会显示"Failed build model"的警告信息。

根本原因分析

这个问题通常与EC2实例元数据服务(IMDS)的配置有关。在AWS环境中，工作节点需要通过IMDS获取临时安全凭证来访问AWS API。当出现以下情况时会导致凭证获取失败：

1. 元数据服务访问限制：默认情况下，IMDS的HTTP PUT响应跳数限制为1，这意味着只有直接访问实例的请求才能获取元数据。在Kubernetes环境下，Pod需要通过节点代理访问IMDS，这需要至少2跳。

2. 网络隔离环境：在严格的内网环境中，如果节点没有配置正确的IMDS访问权限，即使跳数设置正确，也无法获取凭证。

3. 安全令牌要求：现代AWS环境通常要求使用IMDSv2，需要提供安全令牌才能访问元数据服务。

解决方案

要解决这个问题，需要对EC2工作节点的IMDS配置进行调整：

aws ec2 modify-instance-metadata-options \
    --http-put-response-hop-limit 2 \
    --http-tokens required \
    --region <region> \
    --instance-id <instance-id>

这个命令做了三件重要的事情：

1. 将HTTP PUT响应跳数限制设置为2，允许通过代理访问元数据服务
2. 强制要求使用IMDSv2安全令牌
3. 确保配置立即生效

深入技术细节

IMDS跳数限制的工作原理

在Kubernetes环境中，Pod通过节点的kubelet代理访问IMDS。请求的路径是： Pod → Kubelet → IMDS

这需要至少2跳才能完成。如果跳数限制为1，请求会在kubelet处被拦截，导致凭证获取失败。

IMDSv2的安全优势

IMDSv2引入了会话令牌机制，每个请求都需要先获取临时令牌，然后用令牌访问实际元数据。这大大提高了安全性，防止了常见的SSRF攻击。

企业网络环境考量

在严格的内网环境中，还需要确保：

• 安全组规则允许节点访问IMDS(169.254.169.254)
• 网络ACL没有阻断相关流量
• 节点有正确的IAM角色附加

最佳实践建议

1. 统一配置管理：在Terraform或CloudFormation模板中预设IMDS配置，避免手动操作
2. 安全加固：始终使用IMDSv2并设置适当的跳数限制
3. 环境验证：部署前验证节点能否正常获取元数据
4. 监控告警：设置监控以捕获凭证获取失败事件

总结