AWS Load Balancer Controller 与 Karpenter v1.0 的 IMDS 访问问题解析

背景介绍

在 Kubernetes 生态系统中，AWS Load Balancer Controller 是一个重要的组件，用于管理 AWS 环境中的负载均衡资源。当与 Karpenter（AWS 的节点自动伸缩工具）v1.0 版本结合使用时，用户可能会遇到一些与实例元数据服务（IMDS）访问相关的问题。

问题本质

Karpenter v1.0 版本引入了一个重要的安全变更：默认将 EC2 节点的 spec.metadataOptions.httpPutResponseHopLimit 参数值从 2 降为 1。这一变更影响了 Pod 访问实例元数据服务（IMDS）的能力，因为：

1. 当 hop limit 设置为 1 时，只有节点本身可以访问 IMDS
2. Pod 无法通过节点代理访问 IMDS，因为这会增加 hop 计数
3. AWS Load Balancer Controller 需要访问 AWS 元数据来获取区域和 VPC ID 等信息

解决方案分析

对于使用 AWS VPC CNI 的用户，有以下几种解决方案：

方案一：恢复 Karpenter 的原有行为

可以通过在 EC2NodeClass 资源中显式设置 httpPutResponseHopLimit 参数为 2：

apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  metadataOptions:
    httpPutResponseHopLimit: 2

这种方法简单直接，但可能降低安全性，因为 Pod 可以直接访问 IMDS。

方案二：为 AWS Load Balancer Controller 配置 hostNetwork

在 Helm chart 中启用 hostNetwork 模式：

hostNetwork:
  enabled: true

这种方法的缺点是 Pod 会共享节点的网络命名空间，可能带来安全隐患。

方案三：显式配置区域和 VPC ID

这是最推荐的解决方案，因为它既保持了 Karpenter 的安全默认值，又不需要启用 hostNetwork：

clusterName: my-cluster
region: us-west-2
vpcId: vpc-12345678

从 AWS Load Balancer Controller v2.9.0 开始，还可以通过 VPC 标签来识别 VPC ID，这提供了更大的灵活性。

技术细节深入

IRSA 与 Pod 身份

在 EKS 环境中，使用 IAM Roles for Service Accounts (IRSA) 时，Kubernetes 会自动注入以下环境变量到 Pod 中：

• AWS_STS_REGIONAL_ENDPOINTS
• AWS_DEFAULT_REGION/AWS_REGION
• AWS_ROLE_ARN
• AWS_WEB_IDENTITY_TOKEN_FILE

这意味着即使无法访问 IMDS，Pod 仍然可以获得必要的 AWS 凭证和区域信息。但是，VPC ID 仍然需要通过其他方式获取。

VPC ID 发现机制

AWS Load Balancer Controller 获取 VPC ID 的优先级如下：

1. 通过显式配置的 vpcId 参数
2. 通过 VPC 标签（从 v2.9.0 开始支持）
3. 通过 EC2 实例元数据服务（IMDS）

最佳实践建议

1. 保持 Karpenter 的安全默认值（hopLimit=1）
2. 为 AWS Load Balancer Controller 显式配置 region 和 vpcId
3. 考虑使用 VPC 标签来识别 VPC，特别是在多环境部署时
4. 避免使用 hostNetwork 模式，除非有特殊需求
5. 确保使用最新版本的 AWS Load Balancer Controller（至少 v2.9.2）

总结

Karpenter v1.0 的安全改进虽然带来了一些兼容性挑战，但通过合理的配置完全可以解决。理解 AWS Load Balancer Controller 获取 AWS 元数据的各种机制，有助于做出最安全、最可靠的部署决策。在安全性优先的现代云原生环境中，显式配置敏感信息往往比依赖自动发现机制更为可取。