Karpenter AWS Provider 中 AL2023 节点池就绪状态问题解析

问题背景

在使用 Karpenter AWS Provider 管理 Kubernetes 节点时，用户尝试从 Amazon Linux 2 (AL2) 迁移到 Amazon Linux 2023 (AL2023) 时遇到了节点池就绪状态异常的问题。具体表现为 NodePool 和 EC2NodeClass 资源的状态持续显示为 Ready=False，导致节点无法正常创建。

核心问题分析

集群 CIDR 检测失败

根据错误日志显示，系统无法检测到集群 CIDR 地址范围。在 AL2023 系统中，Karpenter 需要明确知道集群的 CIDR 范围才能正常工作。这与 AL2 的行为有所不同，是 AL2023 引入的一个新要求。

用户数据配置的局限性

用户最初尝试通过在 userData 中配置 NodeConfig 来指定集群 CIDR：

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    cidr: xx.yyy.0.0/16

然而，这种方式存在局限性。Karpenter 控制器会优先使用从 EKS API 获取的集群信息，这些发现的值会覆盖用户数据中定义的任何字段。

根本原因

经过深入分析，问题的主要原因是 Karpenter 控制器缺乏必要的 IAM 权限来调用 eks:DescribeCluster API。这个 API 调用对于自动检测集群 CIDR 和其他关键配置信息至关重要。

解决方案

1. 确保正确的 IAM 权限

确保 Karpenter 控制器的 IAM 角色包含以下权限：

{
  "Effect": "Allow",
  "Action": "eks:DescribeCluster",
  "Resource": "arn:aws:eks:region:account-id:cluster/cluster-name"
}

这是最推荐的解决方案，因为它允许 Karpenter 自动发现所有必要的集群配置。

2. 验证权限边界

如果组织使用了 IAM 权限边界，需要确保边界策略也包含了上述 EKS 描述权限。这是许多用户容易忽略的一个配置点。

3. 备选方案：显式配置集群 CIDR

如果由于某些原因无法授予 EKS 描述权限，可以在 Karpenter 配置中显式指定集群 CIDR。这需要通过修改 Karpenter 的部署配置来实现，而不是在用户数据中设置。

最佳实践建议

1. 权限审核：在升级或迁移节点操作系统时，始终审核 Karpenter 控制器的 IAM 权限，确保包含所有必要的 EKS API 权限。

2. 测试环境验证：在生产环境迁移前，先在测试环境中验证 AL2023 的兼容性。

3. 监控就绪状态：部署后密切监控 NodePool 和 EC2NodeClass 的就绪状态，及时发现类似问题。

4. 文档参考：在进行重大变更前，仔细阅读对应版本的 Karpenter 文档，特别是关于新操作系统支持的说明。

总结

AL2023 作为新一代 Amazon Linux 发行版，在安全性和管理上有诸多改进，但也带来了新的配置要求。通过确保正确的 IAM 权限配置，可以解决大多数与集群 CIDR 检测相关的问题。这个问题也提醒我们，在基础设施即代码的环境中，权限管理是确保组件正常工作的关键因素之一。