执行terraform apply后AWS EKS节点变为NotReady问题咨询

算力阿峰

2026-8-27

问题根因

核心是IAM角色权限配置错误，附带存在Terraform配置隐患，和手动创建命名空间没有直接关系：

你把仅给EKS控制平面集群角色用的AmazonEKSClusterPolicy策略错挂到了工作节点组的IAM角色上。这个策略是AWS预留给EKS控制平面本身调用AWS API管理集群资源用的，工作节点完全不需要这个权限。
AWS托管节点组的创建和更新校验逻辑不一致：首次创建节点组时，不会严格校验节点角色是否挂载了多余的控制平面策略，所以初始部署完节点能正常运行；但后续执行terraform apply时，Terraform会调用AWS API全量刷新关联资源状态，EKS托管节点组控制器检测到节点角色带了不属于工作节点的控制平面权限，就会触发异常的节点滚动替换，新拉起的节点因为权限错配，kubelet、CNI插件没法正常和控制平面通信、完不成节点注册，就会全部变成NotReady状态。
你刚好在创建命名空间之后执行terraform apply，只是在这个时间点触发了Terraform的状态刷新，把藏了很久的配置问题引爆了而已，命名空间本身不会修改节点配置。
额外隐患：你把节点组的Kubernetes版本硬编码成了1.20，后续如果升级EKS集群版本，版本不匹配也会触发非预期的节点组滚动更新。

修复步骤

移除错挂的策略
直接删除配置里的aws_iam_role_policy_attachment.amazon_eks_cluster_policy资源块。注意AmazonEKSClusterPolicy只能绑定到aws_eks_cluster资源引用的EKS控制平面角色上，绝对不能挂到工作节点角色上。
收敛节点角色权限
工作节点角色只需要保留3个基础托管策略就能满足正常运行要求：
- AmazonEKSWorkerNodePolicy：节点基础运行权限
- AmazonEKS_CNI_Policy：容器网络插件权限（如果给CNI插件配置了独立的IRSA服务角色，这个策略也可以从节点角色移除，权限配置更安全）
- AmazonEC2ContainerRegistryReadOnly：拉取ECR镜像的只读权限
替换硬编码的版本号
把节点组配置里硬编码的version = "1.20"改成引用集群的实际版本，避免版本不一致触发意外更新：
```
# 把main替换成你自己定义的aws_eks_cluster资源名
version = aws_eks_cluster.main.version
```

（可选）给集群对接的provider加显式依赖
如果你在Terraform里用了kubernetes或者helm provider直接管理集群内资源，一定要给provider加显式依赖，等集群和节点组完全就绪后再执行集群内资源操作，避免提前发起请求触发异常：

provider "kubernetes" {
  host                   = aws_eks_cluster.main.endpoint
  cluster_ca_certificate = base64decode(aws_eks_cluster.main.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", aws_eks_cluster.main.name]
  }
  depends_on = [
    aws_eks_cluster.main,
    aws_eks_node_group.nodes_general
  ]
}

应用修复
先删除当前状态异常的节点组，再执行terraform apply更新所有配置。

验证方法

修复完成后做两步校验即可确认问题解决：

执行terraform plan，确认输出里没有针对节点组、节点IAM角色的非预期变更
手动创建一个测试命名空间，再执行terraform apply，完成后执行kubectl get nodes，确认所有节点状态均为Ready

内容的提问来源于stack exchange，提问作者HulkSmash