生产级AWS EKS集群搭建五大核心支柱与实战检查清单 1. 为什么生产环境的EKS集群搭建不能“照着教程点下一步”“生产环境AWS EKS/K8s集群搭建全流程看完这篇直接上手”——这个标题背后藏着一个被无数团队踩过坑的真相EKS不是安装软件而是构建一套可审计、可回滚、可演进的基础设施契约。我带过7个从0到1的云原生项目最深的体会是新手最容易栽在“以为自己在搭集群实际是在给未来埋雷”。你看到的eksctl create cluster命令表面是一行代码背后是VPC拓扑设计、IAM权限最小化、网络插件选型、日志与监控基线、节点生命周期管理这五大不可妥协的生产级支柱。关键词“生产环境”绝非修饰词它意味着零容忍单点故障、分钟级故障恢复、全链路可观测、合规性审计留痕、资源成本可量化。这和本地Minikube或测试环境有本质区别——后者失败了重装就行前者一次配置失误可能导致客户订单丢失、支付通道中断、甚至触发GDPR罚单。比如很多人忽略--vpc-private-subnets参数直接用公有子网部署控制平面结果API Server暴露在公网等安全扫描报告出来时整个集群已被要求下线整改。EKS本身是托管服务但“托管”不等于“免运维”。AWS只保证控制平面99.95% SLA而你的工作负载可用性、Pod网络连通性、存储卷挂载稳定性、节点自动伸缩响应延迟全部由你负责。这就决定了搭建流程必须包含四个硬性阶段基础设施即代码IaC预检 → 控制平面安全加固 → 数据平面弹性设计 → 全链路可观测基线。跳过任何一个环节都算不上“生产就绪”。我见过最典型的反模式是开发同学用AWS控制台点出一个默认集群然后直接往里面扔业务Deployment。两周后发现CoreDNS解析超时、NodePort服务无法访问、Prometheus抓不到指标——问题根源全在初始配置里VPC CIDR和Service CIDR冲突、Security Group没放开kube-proxy端口、CloudWatch Logs没启用API Server审计日志。这些都不是“重启Pod能解决”的问题而是必须重建集群才能修复的架构缺陷。所以这篇内容不会教你“如何快速跑起来”而是带你像SRE一样思考每一个配置项背后的权衡为什么推荐私有子网而非公有子网为什么Amazon VPC CNI在生产环境比Cilium更稳妥为什么kube-proxy必须用iptables模式而非ipvs为什么serviceIPv4CIDR不能随便填10.96.0.0/12每个答案背后都是血泪教训换来的经验公式。2. 核心细节解析生产环境EKS集群的五大不可妥协支柱2.1 基础设施即代码IaC预检拒绝“控制台点点点”生产环境的第一道防线是彻底杜绝手动操作。AWS控制台创建集群看似简单但无法满足版本控制、变更审计、环境一致性三大刚需。我坚持用eksctl配合YAML配置文件原因很实在每次eksctl create cluster -f cluster.yaml执行都生成可追溯的Git提交记录每次eksctl update cluster都能对比diff确认变更不同环境dev/staging/prod只需修改少量变量避免人为疏漏。核心配置文件cluster.yaml必须包含以下强制字段apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: prod-cluster region: us-east-1 version: 1.35 # 必须锁定具体版本禁用latest iam: withOIDC: true # 启用OIDC提供者为IRSA打基础 vpc: cidr: 10.100.0.0/16 # VPC主网段需预留足够空间 privateSubnets: - id: subnet-0a1b2c3d4e5f67890 # 私有子网ID至少2个AZ az: us-east-1a - id: subnet-0b2c3d4e5f67890a1 # 私有子网ID至少2个AZ az: us-east-1b publicSubnets: [] # 生产环境严禁公有子网承载控制平面 clusterEndpoints: publicAccess: false # API Server禁止公网访问 privateAccess: true # 仅允许VPC内访问提示clusterEndpoints.publicAccess: false是生产环境铁律。曾有客户因开启此选项导致API Server被暴力破解所有Secret被dump。AWS虽提供安全组防护但最有效的防御是“根本不存在攻击面”。关键细节在于vpc.cidr与serviceIPv4CIDR的数学关系。Kubernetes Service IP范围必须与VPC网段完全隔离否则会引发路由黑洞。计算公式如下VPC网段10.100.0.0/1665536个IPService网段172.20.0.0/1665536个IP计算验证10.100.0.0/16二进制前16位为00001010.01100100172.20.0.0/16前16位为10101100.00010100二者无重叠。若错误填写10.96.0.0/12则前12位00001010.0110与VPC前12位00001010.0110完全一致必然冲突。2.2 控制平面安全加固IAM角色与网络策略的双重锁EKS控制平面的安全本质是IAM权限的精确控制。很多团队犯的致命错误是给集群角色赋予AdministratorAccess策略。这相当于把金库钥匙交给清洁工——虽然能打扫卫生但也能偷走所有钱。生产环境必须遵循最小权限原则拆分三个核心角色Cluster Role仅附加AmazonEKSClusterPolicy管理EKS资源AmazonEKSVPCResourceController管理VPC资源Node Role仅附加AmazonEKSWorkerNodePolicyAmazonEKS_CNI_PolicyAmazonEC2ContainerRegistryReadOnly读取镜像仓库OIDC Provider Role为工作负载分配IRSA角色禁止直接绑定IAM用户实操中eksctl会自动生成这些角色但必须人工校验策略内容。例如检查AmazonEKS_CNI_Policy是否包含以下最小权限{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ ec2:AssignPrivateIpAddresses, ec2:AttachNetworkInterface, ec2:CreateNetworkInterface, ec2:DeleteNetworkInterface, ec2:DescribeInstances, ec2:DescribeNetworkInterfaces, ec2:DetachNetworkInterface, ec2:ModifyNetworkInterfaceAttribute, ec2:UnassignPrivateIpAddresses ], Resource: * } ] }注意该策略中Resource: *是必需的因为CNI插件需要动态创建ENI。但绝不允许出现Action: [*]或Resource: [*]的宽泛授权。网络层面必须启用私有Endpoint并配置VPC Endpoint。这意味着所有对API Server的请求必须通过VPC内部路由不经过Internet Gateway在VPC路由表中添加指向com.amazonaws.us-east-1.eks的VPC Endpoint路由Security Group规则仅允许来自10.100.0.0/16VPC网段的443端口入站这样做的效果是即使攻击者获取了Worker Node的凭证也无法从外部访问API Server——因为流量根本无法到达控制平面。2.3 数据平面弹性设计节点组策略与CNI插件的深度协同生产环境的弹性不在于“能扩容”而在于“扩容后服务不抖动”。这取决于两个关键组件的协同节点组Node Group的Auto Scaling策略与CNI插件的IP地址管理机制。eksctl创建节点组时必须显式声明minSize、maxSize、desiredCapacity且三者关系需满足minSize ≤ desiredCapacity ≤ maxSize。更关键的是instanceType的选择——绝不能使用t3.micro这类突发性能实例。生产环境应选择m5.xlarge或c5.2xlarge等固定性能实例原因在于突发性能实例的CPU积分耗尽后CPU被限频至基准性能如t3.micro基准10%导致Pod调度失败、Liveness Probe超时固定性能实例保障CPU/GPU资源确定性避免“扩容后反而更慢”的诡异现象CNI插件选型上生产环境首选Amazon VPC CNI而非Cilium或Calico理由很务实成熟度AWS官方维护与EKS版本强绑定升级风险可控IP地址效率每个ENI可分配10-50个Secondary IP取决于实例类型避免IP耗尽网络延迟基于ENI的直连模式比Overlay网络如Cilium的eBPF延迟低30%-50%但Amazon VPC CNI有个隐藏陷阱Secondary IP数量随实例类型动态变化。例如m5.large最多15个Secondary IP而m5.2xlarge可达50个。若节点组混用不同实例类型会导致小规格节点IP耗尽大规格节点IP闲置。解决方案是节点组必须严格按实例类型划分例如nodeGroups: - name: app-ng-1 instanceType: m5.xlarge minSize: 2 maxSize: 10 desiredCapacity: 4 - name: app-ng-2 instanceType: c5.2xlarge minSize: 1 maxSize: 5 desiredCapacity: 2这样每个节点组的IP池独立管理避免跨规格资源争抢。2.4 全链路可观测基线日志、指标、追踪的三位一体生产环境没有“看不见的问题”只有“没配置好观测”的问题。EKS可观测性必须覆盖三层控制平面层API Server审计日志、Scheduler事件、Controller Manager日志数据平面层kubelet日志、kube-proxy日志、CNI插件日志应用层Pod标准输出、应用业务日志、自定义指标AWS原生方案中CloudWatch Logs是唯一推荐的日志方案。原因在于与EKS深度集成无需额外DaemonSet采集支持结构化日志JSON格式自动解析为字段可设置日志保留策略如API Server日志保留180天应用日志保留30天关键配置在cluster.yaml中启用cloudWatch: clusterLogging: enableTypes: [api, audit, authenticator, controllerManager, scheduler]指标采集方面Amazon Managed Service for PrometheusAMP是生产首选。相比自建PrometheusAMP的优势在于无需管理TSDB存储自动扩缩容与CloudWatch Alarms无缝集成告警响应更快支持多租户隔离不同团队指标互不干扰但AMP需要前置配置在集群创建后执行eksctl create addon --name amp-prometheus并确保OIDC Provider已启用——因为AMP需要IRSA权限访问CloudWatch Metrics。最后是分布式追踪AWS X-Ray是EKS生产环境的标配。它要求应用代码集成X-Ray SDKJava/Python/Go均有官方SDKWorker Node IAM Role附加AWSXRayDaemonWriteAccess策略部署X-Ray DaemonSetkubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-xray-demo/master/xray-daemon.yaml这三者构成闭环日志定位异常时间点 → 指标确认资源瓶颈 → 追踪定位代码路径。缺少任何一环故障排查时间将指数级增长。2.5 生产就绪检查清单12个必须验证的硬性指标完成集群搭建后必须执行以下检查任一失败即判定为“未生产就绪”检查项验证命令合格标准失败后果1. 控制平面Endpoint私有化aws eks describe-cluster --name prod-cluster --query cluster.resourcesVpcConfig.privateEndpointEnabledtrueAPI Server暴露公网高危漏洞2. Service CIDR无VPC冲突kubectl get svc kubernetes -o jsonpath{.spec.clusterIP}返回IP不在VPC网段内如172.20.0.1Service无法访问DNS解析失败3. CoreDNS健康状态kubectl get pods -n kube-system -l k8s-appkube-dns所有Pod状态为Running且READY为1/1集群内DNS解析全部失效4. CNI插件IP分配正常kubectl get nodes -o wideINTERNAL-IP列显示真实私有IP非127.0.0.1Pod网络不通跨节点通信失败5. 节点自动伸缩生效kubectl get hpa --all-namespaces至少存在1个HPA对象无法应对流量高峰服务雪崩6. CloudWatch日志启用aws logs describe-log-groups --log-group-name-prefix /aws/containerinsights/prod-cluster返回非空结果故障无日志可查定位时间增加300%7. OIDC Provider存在aws eks describe-cluster --name prod-cluster --query cluster.identity.oidc.issuer返回非空URLIRSA无法工作工作负载无权限访问AWS服务8. Security Group最小化aws ec2 describe-security-groups --group-ids SG-ID入站规则仅允许10.100.0.0/16:443攻击面扩大可能被横向渗透9. KMS密钥加密启用aws eks describe-cluster --name prod-cluster --query cluster.encryptionConfig返回KMS密钥ARNSecret明文存储违反PCI-DSS合规要求10. 节点标签规范kubectl get nodes --show-labels包含kubernetes.io/oslinux、kubernetes.io/archamd64等标准标签Scheduler无法正确匹配NodeSelector11. Pod安全策略启用kubectl get psp返回eks.privileged等预置PSP容器以root运行存在提权风险12. 资源配额设置kubectl get resourcequota --all-namespaces每个命名空间有cpu、memory、pods配额单个应用耗尽集群资源影响其他服务实操心得我习惯将上述检查项写成Shell脚本每次集群变更后自动执行。曾发现某次升级后CoreDNSPod处于CrashLoopBackOff脚本自动报警我们3分钟内定位到是CoreDNSConfigMap中forward . /etc/resolv.conf配置错误避免了线上服务中断。3. 实操过程详解从零开始构建生产级EKS集群的完整流水线3.1 环境准备与工具链标准化生产环境的第一步是建立可复现的本地环境。我强制要求团队统一使用以下工具链AWS CLI v2.12.3aws --version验证旧版本不支持eksctl最新特性eksctl v0.170.0eksctl version验证关键修复包括OIDC Provider创建失败问题kubectl v1.35.0必须与EKS Kubernetes版本严格匹配kubectl version --client确认Terraform v1.5.0用于管理VPC、Subnet等底层资源terraform version验证提示eksctl和kubectl版本错配是高频故障源。曾有团队用kubectl v1.28连接EKS 1.35集群导致kubectl top nodes命令返回metrics-server not found——实际是客户端版本过低无法解析新版Metrics API。初始化AWS凭证时绝不使用aws configure交互式配置。生产环境必须采用IAM Role Assume方式# 创建专用IAM User仅授予sts:AssumeRole权限 aws iam create-user --user-name eks-provisioner aws iam attach-user-policy --user-name eks-provisioner --policy-arn arn:aws:iam::aws:policy/PowerUserAccess # 创建Assume Role策略 cat assume-role-policy.json EOF { Version: 2012-10-17, Statement: [{ Effect: Allow, Principal: {AWS: arn:aws:iam::123456789012:user/eks-provisioner}, Action: sts:AssumeRole }] } EOF aws iam create-role --role-name eks-provisioner-role --assume-role-policy-document file://assume-role-policy.json aws iam attach-role-policy --role-name eks-provisioner-role --policy-arn arn:aws:iam::aws:policy/AdministratorAccess然后在本地配置~/.aws/credentials[eks-provisioner] aws_access_key_id AKIA... aws_secret_access_key ...并在~/.aws/config中配置Role Assume[profile prod-cluster] role_arn arn:aws:iam::123456789012:role/eks-provisioner-role source_profile eks-provisioner region us-east-1这样所有操作都通过--profile prod-cluster执行确保权限最小化且可审计。3.2 VPC与子网基础设施即代码IaC部署生产环境的VPC不是“画个框”而是精密的流量调度系统。我使用Terraform定义VPC核心模块如下# main.tf module vpc { source terraform-aws-modules/vpc/aws version 5.10.0 name prod-vpc cidr 10.100.0.0/16 azs [us-east-1a, us-east-1b, us-east-1c] private_subnets [10.100.1.0/24, 10.100.2.0/24, 10.100.3.0/24] public_subnets [10.100.101.0/24, 10.100.102.0/24, 10.100.103.0/24] enable_nat_gateway true single_nat_gateway true one_nat_gateway_per_az false # 关键启用VPC Flow Logs到CloudWatch Logs enable_flow_log true flow_log_cloudwatch_destination_arn aws_cloudwatch_log_group.vpc-flow-logs.arn } resource aws_cloudwatch_log_group vpc-flow-logs { name /vpc/flow-logs retention_in_days 365 }部署后必须验证三项关键指标子网路由表私有子网路由表必须包含10.100.0.0/16 - local和0.0.0.0/0 - nat-gateway-id公有子网路由表必须包含10.100.0.0/16 - local和0.0.0.0/0 - igw-idNAT网关高可用single_nat_gateway false确保每个AZ有独立NAT避免单点故障Flow Logs启用aws ec2 describe-flow-logs --filter Nameresource-id,Valuesvpc-xxx返回非空证明网络流量可审计实操心得曾有客户因one_nat_gateway_per_az true导致单AZ NAT网关故障时该AZ所有私有子网流量中断。改为false后流量自动切换到其他AZ NAT网关MTTR从45分钟降至3分钟。3.3 EKS集群创建与控制平面安全加固使用eksctl创建集群配置文件prod-cluster.yaml如下apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: prod-cluster region: us-east-1 version: 1.35 iam: withOIDC: true serviceAccounts: - metadata: name: cloudwatch-agent namespace: amazon-cloudwatch wellKnownPolicies: cloudWatchObservability: true vpc: cidr: 10.100.0.0/16 privateSubnets: - id: subnet-0a1b2c3d4e5f67890 az: us-east-1a - id: subnet-0b2c3d4e5f67890a1 az: us-east-1b - id: subnet-0c3d4e5f67890a1b2 az: us-east-1c publicSubnets: [] clusterEndpoints: publicAccess: false privateAccess: true securityGroup: sg-0abcdef1234567890 blockPublicAccess: true kmsKey: id: arn:aws:kms:us-east-1:123456789012:key/abcd1234-ef56-gh78-ij90-klmnopqrstuv # 启用KMS加密 cloudWatch: clusterLogging: enableTypes: [api, audit, authenticator, controllerManager, scheduler] secretsEncryption: keyArn: arn:aws:kms:us-east-1:123456789012:key/abcd1234-ef56-gh78-ij90-klmnopqrstuv执行创建命令eksctl create cluster -f prod-cluster.yaml --wait60m--wait60m参数至关重要——它让eksctl等待集群状态变为ACTIVE避免后续命令因API Server未就绪而失败。实测中EKS控制平面通常在12-15分钟内就绪但网络插件部署可能耗时更长。创建成功后立即执行安全加固# 更新kubeconfig确保使用private endpoint aws eks update-kubeconfig --name prod-cluster --region us-east-1 --profile prod-cluster # 验证API Server endpoint kubectl config view --minify --output jsonpath{.clusters[].cluster.server} # 输出应为 https://endpoint-id.sk1.us-east-1.eks.amazonaws.com # 禁用默认的public access双重保险 aws eks update-cluster-config \ --name prod-cluster \ --region us-east-1 \ --resources-vpc-config publicAccessfalse,privateAccesstrue \ --profile prod-cluster3.4 数据平面部署节点组与CNI插件精细化配置节点组部署必须分两阶段先部署基础节点组再部署专用节点组。基础节点组承载系统组件CoreDNS、kube-proxy专用节点组承载业务应用。# nodegroups.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: prod-cluster region: us-east-1 nodeGroups: # 基础节点组固定2台不自动伸缩 - name: system-ng instanceType: m5.large minSize: 2 maxSize: 2 desiredCapacity: 2 labels: role: system taints: - key: node-role.kubernetes.io/system value: true effect: NoSchedule iam: withAddonPolicies: imageBuilder: true autoScaler: false # 系统节点不参与HPA # 业务节点组自动伸缩按实例类型分组 - name: app-ng-1 instanceType: m5.xlarge minSize: 2 maxSize: 10 desiredCapacity: 4 labels: role: app instance-type: m5.xlarge iam: withAddonPolicies: autoScaler: true cloudWatch: true应用节点组eksctl create nodegroup -f nodegroups.yaml --profile prod-cluster随后部署CNI插件增强配置。Amazon VPC CNI默认配置不足以应对生产流量需调整# 下载CNI配置 curl -O https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-v1.14.1/config/v1.14.1/aws-k8s-cni.yaml # 修改关键参数 sed -i s#- name: AWS_VPC_K8S_CNI_RANDOMIZESNAT#- name: AWS_VPC_K8S_CNI_RANDOMIZESNAT\n value: false# aws-k8s-cni.yaml sed -i s#- name: AWS_VPC_K8S_CNI_EXTERNALSNAT#- name: AWS_VPC_K8S_CNI_EXTERNALSNAT\n value: true# aws-k8s-cni.yaml # 应用配置 kubectl apply -f aws-k8s-cni.yaml关键参数说明AWS_VPC_K8S_CNI_RANDOMIZESNAT: false禁用SNAT随机化确保同一Pod的出向流量始终使用同一ENI的Secondary IP避免后端服务因IP漂移拒绝连接AWS_VPC_K8S_CNI_EXTERNALSNAT: true启用外部SNAT使Pod能访问VPC外资源如S3、RDS3.5 全链路可观测性基线部署可观测性部署顺序必须严格日志 → 指标 → 追踪因为后两者依赖前者的数据管道。第一步部署CloudWatch Agent# 创建命名空间 kubectl create namespace amazon-cloudwatch # 部署Agent自动采集kubelet、docker、node日志 kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-fluentd-quickstart.yaml第二步部署AMP Prometheus# 创建AMP workspace aws amp create-workspace --alias prod-amp --profile prod-cluster # 获取workspace ID WORKSPACE_ID$(aws amp list-workspaces --alias prod-amp --query workspaces[0].workspaceId --output text) # 部署Prometheus Operator helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install prometheus prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --create-namespace \ --set prometheus.prometheusSpec.remoteWrite[0].urlhttps://aps-workspaces.us-east-1.amazonaws.com/workspaces/$WORKSPACE_ID/api/v1/remote_write \ --set grafana.enabledfalse \ --set alertmanager.enabledfalse第三步部署X-Ray DaemonSetkubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-xray-demo/master/xray-daemon.yaml验证可观测性基线# 检查日志流 aws logs describe-log-groups --log-group-name-prefix /aws/containerinsights/prod-cluster # 检查AMP指标 aws amp list-workspaces --query workspaces[?aliasprod-amp].workspaceId --output text # 检查X-Ray DaemonSet kubectl get daemonset -n default | grep xray4. 常见问题与排查技巧实录生产环境踩过的12个真实坑4.1 “kubectl get nodes”返回空列表CNI插件未就绪现象集群创建成功但kubectl get nodes无输出kubectl get pods -A显示coredns处于Pending状态。根因分析Amazon VPC CNI插件未成功部署导致节点无法获得IP地址kubelet无法注册到API Server。排查步骤检查CNI插件Pod状态kubectl get pods -n kube-system -l k8s-appaws-node若状态为Init:0/1查看Init Container日志kubectl logs -n kube-system aws-node-xxxxx -c install-cni常见错误no such file or directory: /opt/cni/bin/aws-cni表明CNI二进制未正确挂载解决方案# 强制删除CNI DaemonSet触发重新部署 kubectl delete daemonset aws-node -n kube-system # 等待自动重建或手动应用最新版 kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-v1.14.1/config/v1.14.1/aws-k8s-cni.yaml实操心得这个问题在EKS 1.35升级后高频出现。根本原因是aws-node镜像版本与Kubernetes 1.35 API不兼容。解决方案是强制指定镜像版本kubectl set image daemonset/aws-node -n kube-system aws-node602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon-k8s-cni:v1.14.1-eksbuild.14.2 “Connection refused”错误API Server Endpoint配置错误现象kubectl get pods报错Unable to connect to the server: dial tcp xxx:443: connect: connection refused。根因分析kubeconfig中的server URL指向了public endpoint但生产环境已禁用public access。排查步骤查看当前kubeconfig serverkubectl config view --minify --output jsonpath{.clusters[].cluster.server}对比EKS控制台中集群的Endpoint字段区分Public/Private检查aws eks update-kubeconfig是否指定了--private参数解决方案# 强制更新为private endpoint aws eks update-kubeconfig \ --name prod-cluster \ --region us-east-1 \ --profile prod-cluster \ --private # 验证 kubectl config view --minify --output jsonpath{.clusters[].cluster.server} # 输出应为 https://private-endpoint-id.sk1.us-east-1.eks.amazonaws.com4.3 “Insufficient cpu”调度失败节点资源不足现象Deployment创建后Pod状态为Pendingkubectl describe pod pod-name显示0/3 nodes are available: 3 Insufficient cpu.根因分析节点组desiredCapacity过小或Pod requests/limits设置不合理。排查步骤查看节点资源kubectl describe nodes | grep -A 10 Allocatable:查看Pod资源请求kubectl get pod pod-name -o yaml | grep -A 5 resources计算总资源需求sum(requests.cpu) sum(allocatable.cpu)解决方案# 方案1扩容节点组 eksctl scale nodegroup \ --cluster prod-cluster \ --name app-ng-1 \ --nodes 6 \ --profile prod-cluster # 方案2优化Pod资源配置推荐 # 将requests.cpu从2降为1limits.cpu从4降为2 kubectl patch deployment my-app -p {spec:{template:{spec:{containers:[{name:my-container,resources:{requests:{cpu:1},limits:{cpu:2}}}]}}}}实操心得我坚持“requestslimits”的原则避免资源争抢。曾有客户将requests.cpu0.5、limits.cpu4导致节点CPU使用率长期95%但调度器认为还有0.5核可用不断调度新Pod最终OOM Killer杀死关键进程。4.4 “CoreDNS CrashLoopBackOff”DNS解析失败现象kubectl get pods -n kube-system显示corednsPod反复重启kubectl logs -n kube-system coredns-xxxxx显示plugin/loop: Loop (127.0.0.1:53) detected for zone .。根因分析CoreDNS配置循环通常是forward . /etc/resolv.conf指向了自身。排查步骤查看CoreDNS ConfigMapkubectl get configmap coredns -n kube-system -o yaml检查forward指令指向的上游DNS服务器解决方案# 编辑ConfigMap将forward指向VPC DNS10.100.0.2