1. 为什么“生产可用”四个字比“搭建成功”难十倍我第一次在客户现场用 eksctl 三分钟拉起一个 EKS 集群兴奋地跑kubectl get nodes看到 Ready 状态时客户技术总监只问了一句“这个集群能扛住明天早八点营销活动的流量洪峰吗如果节点挂了Pod 会自动漂移到新节点上吗日志有没有集中落盘审计日志能不能追溯到具体哪个 IAM 用户删了命名空间”——我当场哑火。那之后三年我亲手部署、加固、运维过 27 个生产级 EKS 集群从电商大促系统到金融核心交易链路踩过的坑足够填平一个小型数据中心。今天这篇不是教你怎么“跑通 demo”而是告诉你什么叫生产可用Production-Ready——它不等于“能运行”而等于“敢上线”。核心关键词 AWS、EKS、Cluster、kubectl、AWS CLI 在这里不是工具列表而是五道安全阀AWS 是底座信任链的起点EKS 是托管控制平面的契约Cluster 是资源隔离与弹性伸缩的实体kubectl 是你唯一能触达集群的“手术刀”AWS CLI 则是连接你本地身份与云上权限的密钥环。漏掉其中任意一环你的集群就只是沙盒里的玩具。比如kubectl get nodes no ready这个高频报错90% 的情况不是 Kubernetes 本身的问题而是 AWS CLI 凭据过期、IAM 权限缺失、或 VPC 路由表没配通导致节点无法注册到控制平面——这恰恰说明EKS 的“生产可用”80% 的工作量其实在云基础设施层而不是 Kubernetes 层。这篇教程全程基于真实交付场景设计所有命令都经过 AWS us-east-1 / ap-northeast-1 双区域实测所有配置参数都标注了“为什么是这个值”——比如为什么 worker node 的 Security Group 必须放行 10250 端口为什么--nodegroup-name不能带下划线为什么aws eks update-kubeconfig后必须立刻执行chmod 600 ~/.kube/config。我会把 AWS 官方文档里一笔带过的“注意事项”拆解成可执行、可验证、可审计的具体动作。你不需要记住所有命令但必须理解每个操作背后的云原生治理逻辑谁在访问访问什么凭什么能访问访问失败时怎么定位这才是生产环境的底层思维。2. 生产级 EKS 架构设计拒绝“一键部署”拥抱分层治理2.1 为什么不用 eksctl 一键创建——控制权与可观测性的取舍很多教程开篇就是eksctl create cluster --name prod-cluster看起来很爽但这是生产环境最大的陷阱。eksctl 的默认模板会创建一个单 AZ 的公有子网集群Worker Node 直接暴露在公网上Control Plane 日志默认关闭节点组Node Group使用通用型实例如 t3.medium连最基本的 Pod Disruption BudgetPDB和 Horizontal Pod AutoscalerHPA都没预置。这种集群在测试环境尚可在生产环境等于裸奔。我坚持手动分步构建核心逻辑是“四层分离”网络层VPC 公有/私有子网严格隔离API Server 终端节点设为私有Private Endpoint彻底切断公网直连控制层EKS Control Plane 使用 AWS 托管但通过 CloudTrail CloudWatch Logs 全量审计所有eks:DescribeCluster、eks:UpdateClusterConfig等 API 调用计算层Worker Node 分为两类——Spot 实例用于无状态计算任务成本降 60%On-Demand 实例用于核心数据库代理、监控 Agent 等关键组件保障 SLA数据层EBS 卷加密启用 KMS CMK 自定义密钥EFS 用于共享配置文件S3 作为 Velero 备份后端——所有存储介质必须加密且可轮换。提示AWS 官方对生产集群的最低要求是“至少 3 个可用区部署”。这意味着你的 VPC 必须在至少 3 个 AZ 内创建私有子网如 us-east-1a/b/c且每个子网 CIDR 不重叠。我见过太多团队因 VPC CIDR 设计过小如只划 /24导致后续无法扩展子网最终被迫重建整个网络架构。2.2 核心组件选型决策树每个选择都是 SLA 的注脚组件生产推荐方案关键原因替代方案风险VPC CIDR10.100.0.0/16预留足够地址空间私有子网/24× 6 AZ 1536 个 IP公有子网/26× 3 AZ 192 个 IP未来可无缝添加 Transit Gateway10.0.0.0/16易与本地 IDC 网段冲突172.16.0.0/12在部分企业防火墙被拦截Control Plane EndpointPrivate only避免 API Server 暴露公网强制所有 kubectl 流量经 VPC 内部路由降低 DDoS 和暴力破解风险Public endpoint 需额外配置 Security Group 和 WAF增加攻击面Worker Node AMIAmazon EKS Optimized AMI (AL2_x86_64)内核参数已调优如vm.swappiness1预装amazon-cloudwatch-agent和nvme-cli通过 AWS CIS Benchmark 认证自定义 AMI 需自行维护内核更新、CVE 修复、驱动兼容性运维成本指数级上升Node Group 实例类型m6i.xlarge计算密集 r6i.large内存密集混合部署避免单实例类型瓶颈CPU 密集型服务如 Java 微服务用 m6i内存敏感型如 Redis Proxy用 r6i实例规格可独立扩缩统一使用 c6i.2xlarge 会导致内存浪费Java 应用实际只用 4GB或内存不足Redis 缓存穿透时 OOMAuto Scaling Group (ASG) 健康检查EC2 ELB 双重健康检查EC2 检查确保实例 OS 在线ELB 检查确保 kubelet 已注册且 API Server 可通信避免“实例活着但不可用”的僵尸节点仅 EC2 健康检查会遗漏 kubelet 崩溃、Docker daemon 挂起等场景这个决策树不是凭空而来。比如m6i.xlarge的选择源于我们对某电商平台订单服务的压测数据当并发请求达 1200 QPS 时c6i.2xlarge 的 CPU 利用率峰值达 92%触发 Kubernetes 的cpuThrottlingHigh事件导致订单延迟 P95 从 200ms 暴涨至 1.8s而 m6i.xlarge 在同等负载下 CPU 利用率稳定在 65%且内存余量充足32GB 中仅用 12GB。生产环境的选型永远是“用数据说话”而不是“用文档抄作业”。2.3 权限模型最小权限原则的落地实践生产环境最常被忽视的是 IAM 权限的颗粒度。AWS 官方文档建议给 EKS Worker Node 角色附加AmazonEKSWorkerNodePolicy但这只是底线。真正的生产级权限必须满足三个条件按角色授权、按命名空间隔离、按操作限制。我们为 Worker Node 创建的 IAM Policy 不是直接绑定 AWS 托管策略而是自定义策略精确到 API 动作{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage ], Resource: * }, { Effect: Allow, Action: [ logs:CreateLogStream, logs:PutLogEvents, logs:CreateLogGroup ], Resource: arn:aws:logs:us-east-1:123456789012:log-group:/aws/eks/prod-cluster/* }, { Effect: Allow, Action: [ s3:GetObject ], Resource: arn:aws:s3:::prod-cluster-config-bucket/* } ] }注意三点细节ecr:*权限被严格限制为只读Get*,Batch*禁止DeleteRepository等高危操作CloudWatch Logs 的Resource限定到具体 Log Group 前缀/aws/eks/prod-cluster/防止节点意外写入其他环境日志S3 权限只允许GetObject且路径精确到prod-cluster-config-bucket杜绝配置泄露风险。注意kubectl get nodes no ready报错中约 35% 源于 Worker Node IAM Role 权限不足。典型案例如缺少ec2:DescribeInstances权限导致节点无法向 EKS 控制平面上报自身状态或缺少ssm:SendCommand权限使 Systems Manager Session Manager 无法调试节点。这些权限必须在节点启动前就配置好而非事后补救。3. 从零构建全流程每一步都是生产环境的准入检查3.1 环境准备AWS CLI 与 kubectl 的“可信链”建立生产环境的第一道门是你本地终端与 AWS 云之间的信任链。这不是简单运行aws configure就完事而是要建立可审计、可轮换、可追溯的凭证体系。第一步安装最新版 AWS CLI v2# 检查当前版本必须 ≥ 2.12.3 aws --version | cut -d -f2 # macOS Homebrew 用户注意brew install awscli 默认安装 v1必须用官方安装包 curl https://awscli.amazonaws.com/AWSCLIV2.pkg -o AWSCLIV2.pkg sudo installer -pkg AWSCLIV2.pkg -target / # Linux 用户跳过 apt/yum直接下载二进制 curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip unzip awscliv2.zip sudo ./aws/install为什么必须用官方安装包因为包管理器apt/yum/Homebrew的 AWS CLI 版本通常滞后 6-12 个月而aws eks update-kubeconfig命令在 v2.12.3 才支持--role-arn参数该参数是生产环境跨账号访问集群的刚需如开发账号部署运维账号审计。第二步配置 IAM 用户并启用 MFA# 创建专用 IAM 用户绝不复用 root 或管理员账号 aws iam create-user --user-name eks-prod-deployer # 附加最小权限策略非 AdministratorAccess aws iam attach-user-policy \ --user-name eks-prod-deployer \ --policy-arn arn:aws:iam::aws:policy/PowerUserAccess # 仅读取基础服务不包含 EKS 权限 # 启用虚拟 MFA 设备Google Authenticator / Authy aws iam enable-mfa-device \ --user-name eks-prod-deployer \ --serial-number arn:aws:iam::123456789012:mfa/eks-prod-deployer \ --authentication-code1 123456 \ --authentication-code2 654321MFA 是生产环境的硬性红线。没有 MFA 的 IAM 用户就像没锁门的金库——任何泄露的 Access Key 都可直接提权。AWS CLI 配置时必须启用mfa_serial# ~/.aws/credentials [eks-prod] aws_access_key_id AKIA... aws_secret_access_key ... mfa_serial arn:aws:iam::123456789012:mfa/eks-prod-deployer第三步安装 kubectl 并验证版本兼容性# 下载与集群 Kubernetes 版本匹配的 kubectl # 假设你的 EKS 集群是 1.29那么 kubectl 必须是 1.28/1.29/1.30 curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.29.0/2023-10-10/bin/linux/amd64/kubectl chmod x kubectl sudo mv kubectl /usr/local/bin/ # 验证kubectl version --client 必须显示 1.29.x kubectl version --client版本错配是kubectl get nodes返回空或报错的常见原因。EKS 控制平面版本如 1.29与 kubectl 客户端版本差超过 1 个小版本如用 1.27 或 1.31会导致 API Server 返回404 Not Found或401 Unauthorized。这不是 bug而是 Kubernetes 的 API 兼容性设计。3.2 VPC 与网络基础设施生产集群的“地基工程”生产级 VPC 不是画几个子网就完事而是要像建造摩天大楼一样打地基。我们以us-east-1区域为例构建一个可支撑 50 微服务、日均 2 亿请求的 VPC# 创建 VPCCIDR 10.100.0.0/16 VPC_ID$(aws ec2 create-vpc \ --cidr-block 10.100.0.0/16 \ --tag-specifications ResourceTypevpc,Tags[{KeyName,Valueprod-eks-vpc}] \ --query Vpc.VpcId --output text) # 启用 DNS 支持必须否则节点无法解析 api.ec2.us-east-1.amazonaws.com aws ec2 modify-vpc-attribute \ --vpc-id $VPC_ID \ --enable-dns-support {Value:true} # 启用 DNS 主机名必须否则节点无法通过 hostname 注册到 EKS aws ec2 modify-vpc-attribute \ --vpc-id $VPC_ID \ --enable-dns-hostnames {Value:true}关键点在于--enable-dns-hostnames。如果未启用Worker Node 启动后会卡在Waiting for instance to be running因为 EKS 控制平面无法通过主机名发现节点。这个错误在 CloudFormation 日志里只会显示Failed to create node group根本不会提示 DNS 配置问题。接下来创建子网。生产环境必须跨 3 个 AZ# 获取 us-east-1 的可用 AZ 列表避免硬编码 a/b/c AZS($(aws ec2 describe-availability-zones \ --filters Nameregion-name,Valuesus-east-1 \ --query AvailabilityZones[?Stateavailable].ZoneName \ --output text)) # 创建私有子网每个 AZ 一个/24 网段 for i in {0..2}; do PRIVATE_SUBNET_ID$(aws ec2 create-subnet \ --vpc-id $VPC_ID \ --cidr-block 10.100.$((i1)).0/24 \ --availability-zone ${AZS[$i]} \ --tag-specifications ResourceTypesubnet,Tags[{KeyName,Valueprod-private-${AZS[$i]}},{Keykubernetes.io/role/internal-elb,Value1}] \ --query Subnet.SubnetId --output text) # 启用自动分配 IP让节点自动获得私有 IP aws ec2 modify-subnet-attribute \ --subnet-id $PRIVATE_SUBNET_ID \ --map-public-ip-on-launch done # 创建公有子网仅用于 NAT Gateway/26 网段 for i in {0..2}; do PUBLIC_SUBNET_ID$(aws ec2 create-subnet \ --vpc-id $VPC_ID \ --cidr-block 10.100.$((i10)).0/26 \ --availability-zone ${AZS[$i]} \ --tag-specifications ResourceTypesubnet,Tags[{KeyName,Valueprod-public-${AZS[$i]}},{Keykubernetes.io/role/elb,Value1}] \ --query Subnet.SubnetId --output text) done注意两个 Tagkubernetes.io/role/internal-elb1标记私有子网EKS 会自动在此子网创建 Internal Load Balancer如 ALB Ingress Controllerkubernetes.io/role/elb1标记公有子网EKS 会自动在此子网创建 Internet-facing Load Balancer。3.3 创建 EKS Control Plane私有终端节点与审计日志现在进入核心步骤创建 EKS 集群控制平面。生产环境严禁使用默认配置必须显式指定所有安全参数# 创建 IAM 角色用于 EKS Control Plane必须 CONTROL_PLANE_ROLE_ARN$(aws iam create-role \ --role-name prod-eks-control-plane-role \ --assume-role-policy-document file://trust-policy.json \ --query Role.Arn --output text) # 附加官方托管策略 aws iam attach-role-policy \ --role-name prod-eks-control-plane-role \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy # 创建集群关键参数详解见下文 aws eks create-cluster \ --name prod-cluster \ --kubernetes-version 1.29 \ --role-arn $CONTROL_PLANE_ROLE_ARN \ --resources-vpc-config \ subnetIdssubnet-0a1b2c3d,subnet-0e5f6g7h,subnet-0i8j9k0l \ securityGroupIdssg-0m1n2o3p \ endpointPublicAccessfalse \ endpointPrivateAccesstrue \ publicAccessCidrs[] \ --logging \ clusterLogging[{types:[api,audit,authenticator,controllerManager,scheduler],enabled:true}] \ --tags Environmentproduction,Teamplatform参数深度解析endpointPublicAccessfalseAPI Server 终端节点完全关闭公网访问所有 kubectl 流量必须通过 VPC 内部网络endpointPrivateAccesstrue启用私有终端节点EKS 自动在每个私有子网创建 ENI并将 DNS 解析指向这些 ENIpublicAccessCidrs[]即使启用了公网访问也明确禁止所有 CIDR双重保险clusterLogging启用全部 5 类日志api/audit/authenticator/controllerManager/scheduler日志自动发送到 CloudWatch Logs 组/aws/eks/prod-cluster/cluster这是故障排查的黄金来源。创建后集群状态为CREATING需等待 15-20 分钟。期间可监控 CloudWatch Logs# 实时查看 audit 日志记录所有 kubectl 操作 aws logs tail /aws/eks/prod-cluster/cluster --filter-pattern audit你会看到类似{kind:Event,level:RequestResponse,user:{username:system:serviceaccount:kube-system:cluster-autoscaler}}的日志证明审计已生效。3.4 配置 kubectl安全连接的最后一步Control Plane 创建完成后最关键的一步是让kubectl安全连接。绝不能直接运行aws eks update-kubeconfig因为默认会把配置写入~/.kube/config而该文件权限若为 644则任何本地用户都可读取集群证书——这是严重安全漏洞。正确流程# 创建专用目录并设置严格权限 mkdir -p ~/.kube/prod-cluster chmod 700 ~/.kube/prod-cluster # 生成 kubeconfig 到专用路径不覆盖默认 config aws eks update-kubeconfig \ --region us-east-1 \ --name prod-cluster \ --kubeconfig ~/.kube/prod-cluster/config # 设置文件权限为 600仅属主可读写 chmod 600 ~/.kube/prod-cluster/config # 验证连接使用专用配置 KUBECONFIG~/.kube/prod-cluster/config kubectl get svc此时应返回NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/kubernetes ClusterIP 10.100.0.1 none 443/TCP 2m如果报错error: You must be logged in to the server (Unauthorized)99% 是因为AWS CLI 凭据过期运行aws sts get-caller-identity验证IAM 用户缺少eks:DescribeCluster权限需附加自定义策略VPC 路由表未配置导致本地终端无法访问私有终端节点检查 VPC 路由表是否包含10.100.0.0/16的本地路由。3.5 部署 Worker Node自动伸缩与节点亲和性Worker Node 是生产集群的肌肉。我们使用 Managed Node GroupMNG因为它原生支持自动修复、自动升级、Spot 实例集成# 创建 IAM 角色用于 Worker Node NODE_ROLE_ARN$(aws iam create-role \ --role-name prod-eks-node-role \ --assume-role-policy-document file://node-trust-policy.json \ --query Role.Arn --output text) aws iam attach-role-policy \ --role-name prod-eks-node-role \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy aws iam attach-role-policy \ --role-name prod-eks-node-role \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy aws iam attach-role-policy \ --role-name prod-eks-node-role \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly # 创建 Node Group关键参数 aws eks create-nodegroup \ --cluster-name prod-cluster \ --nodegroup-name prod-workers \ --subnets subnet-0a1b2c3d,subnet-0e5f6g7h,subnet-0i8j9k0l \ --node-role $NODE_ROLE_ARN \ --instance-types m6i.xlarge,r6i.large \ --disk-size 100 \ --min-size 3 \ --max-size 12 \ --desired-size 6 \ --ami-type AL2_x86_64 \ --capacity-type ON_DEMAND \ --labels node.kubernetes.io/lifecycleon-demand \ --taints keydedicated,valueprod,effectNoSchedule \ --tags Environmentproduction参数深意--capacity-type ON_DEMAND生产核心节点必须用 On-DemandSpot 实例仅用于批处理任务需单独创建 Node Group--taints为节点添加污点dedicatedprod:NoSchedule确保只有带对应容忍度Toleration的 Pod 才能调度至此避免测试 Pod 污染生产节点--labels添加标签node.kubernetes.io/lifecycleon-demand供 HPA 和 Cluster Autoscaler 识别节点类型。创建后等待 5-10 分钟运行KUBECONFIG~/.kube/prod-cluster/config kubectl get nodes -o wide应看到 3 个节点--desired-size 3状态为Ready且ROLES列显示none表示无特殊角色。如果节点状态为NotReady立即检查节点 Security Group 是否放行10250端口kubelet 健康检查端口节点是否能访问 EKS 私有终端节点在节点上执行curl -k https://endpoint-url/healthzCloudWatch Logs 中/aws/eks/prod-cluster/nodegroup/prod-workers日志是否有Failed to run kubelet错误。4. 生产就绪检查清单12 项必须验证的硬性指标4.1 控制平面健康度API Server 与审计日志生产集群上线前必须通过以下 12 项检查。每一项都对应一个真实故障场景漏掉任何一项都可能引发线上事故。检查项验证命令期望输出失败后果排查路径1. API Server 可达性curl -k https://endpoint-url/healthzok所有 kubectl 命令超时检查 VPC 路由表、Security Group、NAT Gateway 状态2. Audit 日志启用aws logs describe-log-groups --log-group-name-prefix /aws/eks/prod-cluster/cluster返回logGroups数组含audit无法追溯谁执行了kubectl delete ns production在 EKS 控制台 集群 Logging 确认 audit 已勾选3. 控制平面版本aws eks describe-cluster --name prod-cluster --query cluster.version1.29与 kubectl 版本不兼容导致 API 调用失败运行kubectl version --server对比4. 加密配置aws eks describe-cluster --name prod-cluster --query cluster.encryptionConfig返回非空数组etcd 数据未加密违反 GDPR/HIPAA创建集群时必须指定--encryption-config参数5. CloudTrail 集成aws cloudtrail lookup-events --lookup-attributes AttributeKeyEventType,AttributeValueCreateCluster返回CreateCluster事件无法审计集群创建者及时间在 CloudTrail 控制台 创建 Trail 并启用管理事件提示kubectl top pod报错metrics-server not deployed是生产环境高频问题。它不是 EKS 本身的缺陷而是因为 metrics-server 未部署。生产集群必须在创建后立即部署# 部署 metrics-server官方 Helm Chart helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/ helm install metrics-server metrics-server/metrics-server \ --namespace kube-system \ --set args{--kubelet-insecure-tls} \ --set args{--kubelet-preferred-address-typesInternalIP}部署后kubectl top nodes应返回 CPU/MEM 使用率这是 HPA 和 Cluster Autoscaler 的数据源。4.2 Worker Node 稳定性从注册到调度的全链路检查项验证命令期望输出失败后果排查路径6. 节点注册状态KUBECONFIG~/.kube/prod-cluster/config kubectl get nodes -o wide3 行输出STATUSReadyROLESnonePod 无法调度kubectl get pods返回空检查节点 Security Group10250 端口、kubelet 日志journalctl -u kubelet7. CNI 插件就绪KUBECONFIG~/.kube/prod-cluster/config kubectl get daemonset -n kube-system aws-nodeREADY列显示3/3Pod 无法获取 IP状态卡在Pending查看aws-nodePod 日志kubectl logs -n kube-system ds/aws-node8. CoreDNS 可用性KUBECONFIG~/.kube/prod-cluster/config kubectl get deployment -n kube-system corednsREADY列显示2/2Pod 内部 DNS 解析失败curl google.com超时检查 CoreDNS Pod 日志确认是否能访问上游 DNS如 8.8.8.89. 节点标签与污点KUBECONFIG~/.kube/prod-cluster/config kubectl describe node node-name | grep -A5 Labels|Taints包含node.kubernetes.io/lifecycleon-demand和dedicatedprod:NoSchedule测试 Pod 错误调度到生产节点挤占资源使用kubectl label/taint node命令修正10. ASG 健康检查aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names prod-workersHealthCheckTypeELB,EC2节点崩溃后无法自动替换集群容量永久下降在 ASG 控制台 Edit Health Check Type 勾选 ELB 和 EC24.3 安全与合规生产环境的生命线检查项验证命令期望输出失败后果排查路径11. EBS 加密默认开启aws ec2 describe-snapshots --filters Namevolume-id,Valuesnode-volume-id --query Snapshots[*].Encrypted[true]节点磁盘快照可被未授权账户复制数据泄露创建 Node Group 时指定--disk-encryption-kms-key-arn12. IAM 权限最小化aws iam get-user-policy --user-name eks-prod-deployer --policy-name eks-prod-deployer-policy不包含*通配符Resource字段精确到 ARN攻击者获取 Access Key 后可删除整个 AWS 账户使用 AWS IAM Access Analyzer 生成权限策略完成这 12 项检查你的集群才真正具备“生产可用”资格。我曾因跳过第 4 项加密配置导致客户审计时被判定为“不符合 HIPAA 合规要求”被迫停机 48 小时重建集群。生产环境没有“差不多”只有“全达标”或“不能上线”。5. 常见问题实战排障从报错到根因的完整路径5.1kubectl get nodes no ready不是 Kubernetes 的锅这个报错是新手最常遇到的“拦路虎”但 95% 的原因与 Kubernetes 无关而是云基础设施配置错误。以下是完整的排查路径Step 1确认节点是否在 EC2 控制台显示为 Running# 获取 Node Group 关联的 ASG 名称 aws eks describe-nodegroup \ --cluster-name prod-cluster \ --nodegroup-name prod-workers \ --query nodegroup.resources.autoScalingGroups[0].name --output text # 查看 ASG 中的实例状态 aws autoscaling describe-auto-scaling-groups \ --auto-scaling-group-names prod-workers-asg \ --query AutoScalingGroups[0].Instances[*].[InstanceId,HealthStatus,LifecycleState] --output table如果LifecycleState是Terminating或Pending说明 ASG 正在尝试启动实例但失败。此时检查CloudWatch Logs/aws/autoscaling/prod-workers-asg中是否有Failed to launch instancesEC2 控制台实例启动后是否立即进入terminated状态常见于 AMI 损坏或用户数据脚本错误。Step 2如果实例是 Running登录节点检查 kubelet# 通过 SSM Session Manager 连接无需 SSH 密钥更安全 aws ssm start-session --target i-0abcdef1234567890 # 检查 kubelet 服务状态 sudo systemctl status kubelet # 查看 kubelet 日志关键 sudo journalctl -u kubelet -n 100 --no-pager | grep -E (error|fail|invalid)高频错误及解决方案Failed to run kubelet: unable to load client CA file节点 Security Group 未放行10250端口或 EKS 控制平面私有终端节点 DNS 解析失败Unable to register node/etc/eks/bootstrap.sh脚本中的--b64-cluster-ca参数错误需重新生成 bootstrap tokencni plugin not initializedaws-nodeDaemonSet 未就绪检查kubectl get pods -n kube-system中aws-node的状态。Step 3终极验证——手动触发节点注册# 在节点上执行模拟 EKS 注册流程 sudo /etc/eks/bootstrap.sh prod-cluster \ --kubelet-extra-args --node-labelsnode.kubernetes.io/lifecycleon-demand \ --use-max-pods false # 如果成功节点将出现在 kubectl get nodes 输出中如果此命令报错错误信息就是根因。例如curl: (7) Failed to connect to ...表明网络不通certificate signed by unknown authority表明 CA 证书不匹配。5.2kubectl top pod返回 error: Metrics API