如何解决EKS优化加速AMI节点无法加入EKS集群问题

核心问题定位 #

从日志看，kubelet启动失败的根源是环境文件加载失败和start-pre任务执行失败，结合你使用的Amazon EKS AL2023 GPU AMI，大概率是节点初始化脚本（user data）缺失或IAM权限配置不全导致的。

分步排查与修复 #

1. 检查节点IAM角色权限 #

EKS GPU节点必须具备以下核心权限，缺失会导致初始化脚本无法下载必要资源：

• AmazonEKSWorkerNodePolicy：节点与EKS控制平面通信的基础权限
• AmazonEKS_CNI_Policy：CNI网络插件运行权限
• AmazonEC2ContainerRegistryReadOnly：拉取容器镜像权限
• AmazonS3ReadOnlyAccess：下载NVIDIA驱动及相关组件权限

Terraform配置示例：

resource "aws_iam_role" "eks_gpu_node_role" {
  name = "eks-gpu-node-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

# 附加必要托管策略
resource "aws_iam_role_policy_attachment" "eks_worker_policy" {
  role       = aws_iam_role.eks_gpu_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

resource "aws_iam_role_policy_attachment" "eks_cni_policy" {
  role       = aws_iam_role.eks_gpu_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

resource "aws_iam_role_policy_attachment" "ecr_readonly" {
  role       = aws_iam_role.eks_gpu_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
}

resource "aws_iam_role_policy_attachment" "s3_readonly" {
  role       = aws_iam_role.eks_gpu_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

2. 验证节点User Data配置 #

AL2023的EKS节点依赖/etc/eks/bootstrap.sh脚本生成kubelet所需的环境文件（如kubeadm-flags.env、config.yaml），缺失该脚本会直接导致kubelet启动失败。

Terraform启动模板的user data配置示例：

resource "aws_launch_template" "eks_gpu_node_lt" {
  name_prefix   = "eks-gpu-node-lt"
  image_id      = data.aws_ami.eks_gpu_ami.id # 对应amazon-eks-node-al2023-x86_64-nvidia-1.31-*
  instance_type = "g4dn.2xlarge"
  iam_instance_profile {
    name = aws_iam_instance_profile.eks_gpu_node.name
  }

  user_data = base64encode(<<-EOF
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -o xtrace
# 执行EKS节点初始化脚本，添加GPU节点标签
/etc/eks/bootstrap.sh ${var.cluster_name} --kubelet-extra-args "--node-labels=eks.amazonaws.com/nodegroup=${var.nodegroup_name},nvidia.com/gpu.present=true"
--BOUNDARY--
EOF
  )
}

3. 手动修复节点kubelet配置 #

如果已经创建节点，可登录节点手动执行初始化步骤：

1. 检查kubelet环境文件是否存在：

ls -l /var/lib/kubelet/

如果缺少kubeadm-flags.env或config.yaml，执行bootstrap脚本（替换为你的集群名）：

/etc/eks/bootstrap.sh your-cluster-name --kubelet-extra-args "--node-labels=nvidia.com/gpu.present=true"

2. 启用并重启kubelet：

systemctl enable --now kubelet
systemctl restart kubelet

4. 验证NVIDIA驱动与容器运行时状态 #

AL2023 GPU AMI会自动安装NVIDIA驱动，但权限不足可能导致安装失败：

1. 检查驱动状态：

nvidia-smi

如果报错，手动安装驱动：

dnf install -y nvidia-driver

2. 检查containerd的NVIDIA runtime配置：

cat /etc/containerd/config.toml

确认包含以下配置段：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
  runtime_type = "io.containerd.runc.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
    BinaryName = "/usr/bin/nvidia-container-runtime"

缺失则重启containerd并重新执行bootstrap脚本：

systemctl restart containerd
/etc/eks/bootstrap.sh your-cluster-name

5. 检查安全组配置 #

确保节点安全组允许：

• 入站：EKS控制平面的443端口、节点间的10250/30000-32767端口
• 出站：所有TCP/UDP流量（至少允许访问S3、ECR、EKS控制平面）

总结 #

最常见的触发原因是User Data缺失bootstrap初始化脚本或IAM角色权限不全，优先从这两点排查。若问题仍存在，提供journalctl -xeu kubelet.service的完整日志片段，以及Terraform节点组、IAM角色的完整配置，可进一步定位问题。

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