生产环境EKS集群五大支柱：网络、安全、可观测性、成本与备份

1. 为什么生产环境EKS集群不能“照着教程点点点”就完事“生产环境AWS EKS/K8s集群搭建全流程看完这篇直接上手”——这个标题里藏着一个巨大的认知陷阱。很多刚接触云原生的工程师看到“全流程”“直接上手”就以为能像装个Ubuntu桌面一样复制粘贴几条命令、点点控制台按钮集群就稳稳当当地跑起来了。我2019年第一次在客户现场部署EKS时也是这么想的。结果呢集群创建成功了kubectl get nodes返回了3个节点kubectl get svc也看到了kubernetes服务但第二天业务上线第一个API请求就超时监控面板一片红日志里全是Connection refused和i/o timeout。排查了整整36小时最后发现是VPC子网路由表里漏配了一条指向NAT网关的默认路由——而这条路由在AWS官方文档里被埋在“VPC网络设计最佳实践”的第7节附录B里连个加粗都没有。这就是生产环境和测试环境最本质的区别测试环境只验证“能不能跑”生产环境必须回答“能不能扛住、能不能稳住、能不能快速恢复”。EKS本身是个托管服务AWS替你管好了控制平面Control Plane的高可用和安全补丁但这绝不意味着你就能当甩手掌柜。恰恰相反EKS把最关键的“责任共担模型”Shared Responsibility Model划得比任何其他AWS服务都更清晰AWS负责Kubernetes API Server、etcd、Scheduler这些组件的可用性与安全而你必须对网络拓扑、节点配置、安全策略、可观测性、备份恢复、成本治理这五大支柱负全责。这五大支柱任何一个环节出问题轻则服务抖动重则整个业务系统雪崩。举个最典型的例子很多人在创建集群时图省事直接用eksctl的--vpc-private-subnets参数指定两个私有子网却忽略了子网的“可用区分布”要求。AWS要求EKS集群的私有子网必须跨至少两个可用区AZ这是为了确保当某个AZ发生故障时你的工作节点Worker Node不会全部挂掉。但如果你只指定了同一个AZ里的两个子网比如us-east-1a里的subnet-01和subnet-02表面上集群创建成功了describe-cluster返回ACTIVE但一旦那个AZ宕机你的所有Pod瞬间失联而Kubernetes的自我修复机制根本无从下手——因为底层EC2实例已经物理不可达了。这种问题在测试环境里永远暴露不出来只有在真实流量洪峰下才会血淋淋地打脸。再比如“直接上手”这个词它暗示着一种零门槛的幻觉。但现实是一个合格的生产级EKS集群其复杂度远超一个简单的Kubernetes安装包。你需要理解为什么VPC的CIDR块不能和Kubernetes Service CIDR重叠为什么CoreDNS的副本数要根据集群规模动态调整为什么Node Security Group必须严格限制入站规则连SSH端口都不能开放为什么kube-proxy的模式选择iptables vs ipvs会直接影响Service的连接建立延迟这些问题没有一个是eksctl create cluster命令能自动帮你决策的。它们背后是网络工程、操作系统内核、分布式系统原理的深度交织。所以这篇博文不叫“EKS快速入门”而叫“生产环境EKS集群搭建全流程”——流程不是线性的步骤清单而是围绕五大支柱构建的一套防御纵深体系。接下来我会带你一层层拆解每一步都告诉你“为什么必须这么做”而不是“应该怎么做”。2. 核心细节解析生产环境五大支柱的底层逻辑与实操铁律生产环境EKS集群的稳定性不取决于你用了多少酷炫的新特性而取决于你是否在五大支柱上筑起了足够高的墙。这五大支柱不是并列关系而是存在严格的依赖链条网络是地基安全是围墙可观测性是哨兵成本是血液备份是保险。任何一环的缺失或薄弱都会成为整个系统的单点故障。下面我将逐个拆解不仅告诉你该做什么更要讲透背后的“为什么”。2.1 网络支柱VPC与子网设计——不是选填题是必答题很多人把VPC当成一个“容器”只要把集群塞进去就行。这是致命误区。VPC是EKS集群的“呼吸系统”它的设计直接决定了集群的生死存亡。核心逻辑EKS集群的网络通信分为三个层面控制平面Control Plane与工作节点Worker Node之间的通信、工作节点与Pod之间的通信、Pod与外部世界互联网或VPC内其他服务的通信。这三个层面全部依赖于VPC的底层网络能力。实操铁律一CIDR规划的“三不重叠”原则不重叠原则1VPC CIDR与Service CIDR不重叠。Kubernetes Service的ClusterIP默认从10.100.0.0/16分配。如果你的VPC CIDR是10.0.0.0/16那么10.100.0.0/16就完全落在VPC地址空间内。这会导致一个问题当Pod尝试访问一个ClusterIP Service时流量会错误地被VPC路由表导向VPC内部而不是被kube-proxy拦截处理。结果就是Service完全不可用。解决方案为Service CIDR单独规划一个“干净”的网段比如172.20.0.0/16并确保它与你的VPC CIDR如10.0.0.0/16、以及你VPC内所有其他子网如数据库子网10.1.0.0/24都不重叠。不重叠原则2VPC CIDR与Pod CIDR不重叠。Amazon VPC CNI插件默认从VPC子网中为Pod分配IP。如果Pod IP和VPC内其他资源如RDS、ElastiCache的IP重叠就会产生ARP冲突导致网络丢包。因此你必须为Pod预留一个独立的、不与任何现有VPC资源冲突的IP段。通常做法是在VPC CIDR内为Pod专门划分一个大子网如10.0.0.0/16的VPC可划出10.100.0.0/20给Pod使用并在CNI配置中显式指定--pod-cidr。不重叠原则3不同可用区的子网CIDR不重叠。这是新手最容易犯的错。AWS允许你在同一个VPC下为不同AZ创建CIDR重叠的子网比如us-east-1a的10.0.1.0/24和us-east-1b的10.0.1.0/24。这在理论上可行但在EKS场景下是灾难性的。因为CNI插件会为每个节点分配来自其所在子网的IP如果两个AZ的子网CIDR相同CNI会无法区分导致Pod IP分配混乱跨AZ通信失败。铁律每个子网的CIDR必须全局唯一。实操铁律二子网类型与路由的“黄金组合”生产环境必须使用私有子网Private Subnet部署工作节点。公有子网Public Subnet只用于部署负载均衡器ALB/NLB或NAT网关。原因很简单公有子网的EC2实例拥有公网IP直接暴露在互联网上这违背了最小权限原则。即使你关闭了所有安全组端口EC2实例本身的元数据服务http://169.254.169.254也可能被恶意利用。私有子网的路由表必须包含两条关键路由0.0.0.0/0→ 指向NAT网关NAT Gateway。这是工作节点访问互联网如拉取Docker镜像、下载系统更新、上报CloudWatch日志的唯一出口。10.0.0.0/16或你的VPC CIDR→ 本地Local。这是VPC内所有资源EC2、RDS、S3之间通信的基础。提示NAT网关必须部署在公有子网中并且其关联的路由表必须将0.0.0.0/0指向Internet GatewayIGW。这是一个经典的三层路由结构Pod → Worker Node → NAT Gateway → IGW → Internet。任何一层缺失都会导致节点无法联网。2.2 安全支柱IAM与网络策略——看不见的锁链EKS的安全是“纵深防御”的典范。它由两道核心锁链构成身份认证锁链IAM和网络访问锁链NetworkPolicy。这两道锁链一道管“谁可以操作”一道管“谁可以通信”缺一不可。核心逻辑Kubernetes本身是一个强大的API系统但它默认的RBAC基于角色的访问控制只管理集群内部资源。而EKS集群运行在AWS上其底层资源EC2实例、EBS卷、ELB的权限必须由AWS IAM来管控。这就是IRSAIAM Roles for Service Accounts诞生的原因——它让Kubernetes Pod能以最小权限原则安全地调用AWS服务。实操铁律一IRSA是Pod访问AWS服务的唯一正途在EKS之前我们常用的方式是给Worker Node的IAM Role附加一堆权限如AmazonS3FullAccess然后让所有Pod共享这个Role。这就像给每个员工一把公司大门的钥匙无论他是不是保安。IRSA则完全不同它为每个ServiceAccount创建一个独立的IAM Role并通过OIDC Provider进行绑定。这样一个负责上传图片的Pod只能获得S3:PutObject权限一个负责发送短信的Pod只能获得SNS:Publish权限。实现IRSA的关键步骤创建OIDC Provider这是信任的根。eksctl create iamserviceaccount命令会自动为你完成它本质上是在AWS IAM中注册一个OIDC Provider其Issuer URL就是你的EKS集群的OpenID Connect URL形如https://oidc.us-east-1.eks.amazonaws.com/id/ABCD1234567890ABCDEF1234567890AB。创建ServiceAccount并绑定Roleeksctl create iamserviceaccount --name my-app-sa --namespace default --cluster my-cluster --attach-policy-arn arn:aws:iam::123456789012:policy/MyAppS3Policy --approve。这条命令会做三件事在Kubernetes中创建ServiceAccount、在IAM中创建Role、并将Role与OIDC Provider关联。在Pod Spec中引用spec.serviceAccountName: my-app-sa。从此这个Pod内的进程就可以用aws sts get-caller-identity命令看到自己拥有的、精确到具体API操作的权限。注意IRSA的调试非常痛苦。最常见的错误是WebIdentityErr: failed to retrieve credentials。这通常是因为Pod的token文件/var/run/secrets/eks.amazonaws.com/serviceaccount/token没有被正确挂载或者OIDC Provider的thumbprint不匹配。解决方法是先用kubectl exec -it pod -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token | head -n 20确认token存在再用openssl x509 -in your-oidc-cert.pem -fingerprint -noout计算证书指纹与IAM中OIDC Provider的thumbprint对比。实操铁律二NetworkPolicy是Pod间通信的交通警察RBAC管的是“人”用户、ServiceAccount对“资源”Pod、Deployment的操作权限NetworkPolicy管的是“Pod”对“Pod”的网络访问权限。在生产环境默认拒绝所有Default Deny是唯一安全的选择。一个典型的NetworkPolicy示例只允许frontend命名空间下的Pod访问backend命名空间下的api-serviceapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: backend spec: podSelector: matchLabels: app: api-service ingress: - from: - namespaceSelector: matchLabels: name: frontend podSelector: matchLabels: app: web ports: - protocol: TCP port: 8080这条策略的意思是“在backend命名空间里所有标签为appapi-service的Pod只接受来自frontend命名空间、且标签为appweb的Pod对8080端口的TCP访问。” 其他所有访问一律被CNI插件如Calico拦截。提示NetworkPolicy需要CNI插件支持。AWS VPC CNI本身不支持NetworkPolicy你必须额外部署Calico或Cilium。Cilium因其eBPF技术在性能和功能上更胜一筹是生产环境的首选。2.3 可观测性支柱从“黑盒”到“透明玻璃”在Kubernetes的世界里“看不见”就意味着“失控”。一个没有完善可观测性的EKS集群就像一辆没有仪表盘的汽车你只能靠感觉判断它是否在正常行驶。核心逻辑可观测性Observability不是监控Monitoring的简单升级而是从“发生了什么”Metrics到“为什么发生”Traces再到“正在发生什么”Logs的三位一体。三者缺一不可。实操铁律一Metrics采集必须分层不能只看表面基础设施层Infrastructure LayerCloudWatch Metrics。这是AWS提供的“原生”指标如EC2 CPUUtilization、EBS VolumeReadOps。它免费、稳定但粒度粗5分钟聚合且无法深入到容器内部。Kubernetes层K8s LayerPrometheus kube-state-metrics。Prometheus是事实标准它通过/metrics端点主动抓取指标。kube-state-metrics则将Kubernetes API对象如Deployment、Pod、Node的状态转化为Prometheus指标。例如kube_pod_status_phase{phasePending}可以实时反映有多少Pod卡在Pending状态这比单纯看CPU使用率更能揭示调度问题。应用层Application Layer应用自身暴露的指标。一个健康的微服务必须在/actuator/prometheusSpring Boot或/metricsGo端点暴露业务指标如http_requests_total、order_processing_duration_seconds。这才是真正反映业务健康度的“黄金信号”。实操铁律二Logs必须集中化且保留原始上下文kubectl logs是调试利器但绝不能作为生产环境的日志方案。原因有三一是日志随Pod销毁而丢失二是无法跨多个Pod聚合分析三是缺乏结构化查询能力。生产级方案是Fluent BitSidecar或DaemonSet → Kinesis Data Firehose → S3/Opensearch。Fluent Bit轻量、高效作为DaemonSet部署在每个节点上负责收集所有容器的标准输出stdout/stderr。它内置丰富的过滤器Filter可以自动解析JSON日志、添加Kubernetes元数据如Pod名、Namespace、Node名并将日志按namespace或app标签分流到不同的Firehose Delivery Stream。最终日志被持久化到S3低成本、高可靠或实时索引到Opensearch高性能、可搜索。注意日志采集的性能开销必须可控。Fluent Bit的内存占用应限制在100MB以内CPU使用率不应超过0.1核。这需要精细调整其Buffer_Chunk_Size和Buffer_Max_Size参数。一个经验法则Buffer_Chunk_Size设为1MBuffer_Max_Size设为5M可以在性能和可靠性之间取得良好平衡。2.4 成本支柱从“按需付费”到“精打细算”EKS本身不收费但支撑它的EC2、EBS、ELB、数据传输等资源构成了90%以上的成本。一个未经优化的生产集群其月度账单可能比业务收入还高。核心逻辑成本优化不是“砍预算”而是“提升资源利用率”。Kubernetes的核心价值之一就是通过调度算法将不同业务的Pod混部在同一台物理机上从而摊薄硬件成本。实操铁律一节点组Node Group必须按负载特征精细化划分Spot Instance节点组用于无状态、可中断的批处理任务如数据ETL、视频转码。Spot价格通常是On-Demand的1/3到1/5但随时可能被回收。因此必须配合cluster-autoscaler和priorityClassName确保关键业务Pod有更高优先级能在Spot被回收前被驱逐并重新调度到On-Demand节点上。On-Demand节点组用于有状态、不可中断的核心服务如数据库代理、API网关。这类节点必须保证100%的SLA不能容忍任何中断。Graviton节点组使用ARM64架构的c7g、m7g实例。对于Java、Go等语言编写的微服务Graviton实例的性价比通常比同规格x86实例高出40%且功耗更低。迁移成本极低只需重新编译Docker镜像docker build --platform linux/arm64 -t myapp:arm64 .。实操铁律二Horizontal Pod AutoscalerHPA必须基于真实业务指标HPA默认基于CPU和内存使用率进行扩缩容。这在早期很有效但很快就会失效。因为一个健康的微服务其CPU使用率可能常年维持在20%-30%但此时QPS可能已经翻倍响应时间开始飙升。真正的瓶颈往往在I/O或数据库连接池。因此必须将HPA与Prometheus指标集成apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp metrics: - type: Pods pods: metric: name: http_requests_total target: type: AverageValue averageValue: 100这个HPA会监控http_requests_total指标的每秒平均值当它超过100时就触发扩容。这才是与业务增长同步的弹性。2.5 备份支柱从“侥幸心理”到“确定性恢复”“我的集群很稳定不需要备份。”——这是我在客户现场听到的最多、也最危险的一句话。EKS控制平面是AWS托管的但你的etcd数据存储所有Kubernetes对象状态是运行在Worker Node上的。一旦节点磁盘损坏、误删了/var/lib/etcd目录、或者执行了kubectl delete ns --all这样的毁灭性命令没有备份就意味着数据永久丢失。核心逻辑备份的目标不是“恢复集群”而是“恢复业务”。因此备份的对象必须是声明式Declarative的YAML文件而不是命令式Imperative的kubectl apply操作。实操铁律一Velero是唯一经过大规模验证的K8s备份方案Velero通过在集群中部署一个Operator定期将Kubernetes资源Namespace、Deployment、ConfigMap、Secret等的YAML定义以及相关的PVPersistentVolume快照备份到S3或Azure Blob Storage中。它的优势在于应用一致性Velero支持Pre/Post Hooks可以在备份前执行mysqldump在备份后执行mysql restore确保数据库备份与应用状态一致。增量备份基于S3的版本控制Velero可以只备份发生变化的资源大幅减少存储成本和备份时间。跨集群恢复你可以将生产环境的备份一键恢复到开发环境用于故障复现和压力测试。实操铁律二备份策略必须遵循3-2-1原则3份副本Velero备份本身在S3中至少保留3个历史版本。2种介质主备份存S3副备份存Glacier冷存储成本更低。1份异地将备份同步到另一个AWS区域如us-east-1的集群备份同步到us-west-2。这是应对区域性灾难如整个AZ不可用的最后防线。提示Secret资源的备份需要特别小心。Velero默认会备份Secret但其中的敏感信息如数据库密码会以明文形式存储在S3中。解决方案是在Velero安装时启用--use-restic参数让Restic对Secret进行加密备份或者将Secret的值存储在AWS Secrets Manager中然后在Pod中通过IRSA读取这样Velero备份的只是Secret的引用而非明文。3. 实操过程从零开始构建一个生产级EKS集群的完整流水线纸上谈兵终觉浅绝知此事要躬行。下面我将带你走一遍一个真实生产环境EKS集群的构建流水线。这个流水线不是一次性的手工操作而是基于GitOps理念所有配置都代码化Infrastructure as Code并通过CI/CD管道自动化执行。整个过程分为五个阶段环境准备、集群创建、节点组部署、核心插件安装、应用部署。每一个阶段我都会给出可直接执行的命令、详细的参数解释以及我踩过的坑。3.1 阶段一环境准备——一切始于一个干净的AWS账户在动手之前你必须确保你的AWS账户处于一个“可部署”状态。这不是一句空话而是有明确的检查清单。检查清单AWS CLI v2已安装并配置aws --version必须返回aws-cli/2.12.3或更高版本。旧版本的CLI不支持EKS的最新API。配置命令aws configure输入你的Access Key ID和Secret Access Key并设置default region如us-east-1。eksctl已安装eksctl version必须返回0.215.0或更高版本。eksctl是EKS的官方命令行工具它封装了大量底层AWS API调用极大简化了集群创建。安装命令macOSbrew tap weaveworks/tap brew install weaveworks/tap/eksctl。kubectl已安装kubectl version --client必须返回一个与目标Kubernetes版本兼容的客户端版本。EKS 1.35推荐使用kubectl v1.35.x。安装命令curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.35.0/2024-07-12/bin/darwin/arm64/kubectl chmod x kubectl sudo mv kubectl /usr/local/bin/。IAM权限完备执行eksctl命令的IAM用户必须拥有以下最小权限eks:*(所有EKS相关操作)ec2:Describe*(描述VPC、子网、安全组)iam:ListRoles,iam:PassRole(创建和传递IAM Role)cloudformation:CreateStack,cloudformation:DescribeStacks(eksctl内部使用CloudFormation)提示我强烈建议你为EKS部署创建一个专用的IAM用户如eks-deployer并为其附加一个自定义的、权限最小化的策略。不要用Root用户或AdministratorAccess策略这是严重的安全风险。3.2 阶段二集群创建——用eksctl生成一个“骨架”现在让我们创建集群。这里的关键是不要用eksctl create cluster的默认参数而是用一个YAML配置文件来定义一切。这样做的好处是配置可版本化、可复用、可审计。创建一个名为eks-prod-cluster.yaml的文件# eks-prod-cluster.yaml --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: prod-cluster region: us-east-1 version: 1.35 tags: Environment: production Team: platform ManagedBy: eksctl # 网络配置这是整个集群的地基 vpc: # 我们不创建新的VPC而是复用现有的、经过精心设计的VPC id: vpc-0abcdef1234567890 # 私有子网ID必须跨至少两个AZ subnets: private: us-east-1a: { id: subnet-0123456789abcdef0 } us-east-1b: { id: subnet-0123456789abcdef1 } us-east-1c: { id: subnet-0123456789abcdef2 } # 公有子网ID用于部署NAT网关和ALB public: us-east-1a: { id: subnet-0fedcba9876543210 } us-east-1b: { id: subnet-0fedcba9876543211 } us-east-1c: { id: subnet-0fedcba9876543212 } # Kubernetes网络配置避免与VPC CIDR冲突 kubernetesNetworkConfig: serviceIPv4CIDR: 172.20.0.0/16 # 集群角色定义EKS控制平面可以代表你做什么 iam: # 为集群创建一个专用的IAM Role withOIDC: true # 启用OIDC为后续IRSA做准备 # 附加的托管策略 attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy # 自定义策略用于特定需求 # extraAttachPolicyARNs: # - arn:aws:iam::123456789012:policy/ProdClusterExtraPolicy # 加密为etcd中的Secret启用KMS加密 secretsEncryption: keyARN: arn:aws:kms:us-east-1:123456789012:key/abcd1234-5678-90ab-cdef-1234567890ab # 日志开启所有控制平面日志这是故障排查的基石 logging: audit: true authenticator: true controllerManager: true scheduler: true api: true # 其他高级配置 addons: # 禁用默认安装的CoreDNS和kube-proxy我们稍后手动安装最新版 - name: vpc-cni version: 1.15.1 attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy - name: coredns version: 1.11.1 - name: kube-proxy version: 1.35.0执行创建命令eksctl create cluster -f eks-prod-cluster.yaml参数详解与避坑指南--vpc-private-subnets参数在这里被vpc.subnets.private替代更清晰、更安全。serviceIPv4CIDR被显式设置为172.20.0.0/16这是为了避免与VPC的10.0.0.0/16冲突。这是最重要的参数之一漏掉它你的Service将无法工作。withOIDC: true是启用IRSA的前提。没有它你就无法为Pod赋予精细的AWS权限。secretsEncryption.keyARN指向一个你预先创建好的KMS密钥。这确保了etcd中存储的所有Secret如数据库密码都是加密的符合GDPR等合规要求。logging部分开启了所有日志类型。虽然会产生一些费用但这是生产环境的必备项。没有这些日志你将无法诊断控制平面级别的问题。提示eksctl create cluster命令会启动一个CloudFormation堆栈整个过程大约需要15-20分钟。你可以通过eksctl get clusters查看状态。当状态变为ACTIVE时集群就绪了。此时eksctl会自动为你更新~/.kube/config文件让你可以直接使用kubectl。3.3 阶段三节点组部署——为集群注入“肌肉”集群的控制平面Control Plane创建好了但它现在只是一个“大脑”没有“身体”Worker Node来执行任务。我们需要部署节点组。继续编辑eks-prod-cluster.yaml在文件末尾添加节点组配置# ... 上面的配置保持不变 ... # 节点组配置按需、Spot、Graviton三足鼎立 nodeGroups: # On-Demand节点组用于核心服务 - name: on-demand-ng instanceType: m5.xlarge minSize: 2 maxSize: 5 desiredCapacity: 3 volumeSize: 100 # 关键为节点组创建专用的IAM Role iam: withAddonPolicies: # 启用EBS CSI驱动所需的权限 ebs: true # 启用ALB Ingress Controller所需的权限 albIngress: true # 启用Fargate所需的权限虽然我们不用Fargate但留着无害 autoScaler: true # 标签用于后续的Pod亲和性调度 labels: nodegroup: on-demand lifecycle: on-demand # 污点Taint防止非核心Pod被调度到这里 taints: - key: dedicated value: core effect: NoSchedule # Spot节点组用于批处理任务 - name: spot-ng instanceType: c5.2xlarge minSize: 0 maxSize: 10 desiredCapacity: 0 volumeSize: 50 # 使用Spot实例 spot: true # 关键为Spot节点组启用自动伸缩 scalingConfig: minSize: 0 maxSize: 10 desiredCapacity: 0 # 标签 labels: nodegroup: spot lifecycle: spot # 污点确保只有打了对应容忍Toleration的Pod才能调度 taints: - key: lifecycle value: spot effect: NoSchedule # Graviton节点组用于新业务 - name: graviton-ng instanceType: m7g.xlarge minSize: 1 maxSize: 3 desiredCapacity: 1 volumeSize: 100 # ARM64架构 amiFamily: AmazonLinux2_ARM_64 # 标签 labels: nodegroup: graviton architecture: arm64 # 污点 taints: - key: architecture value: arm64 effect: NoSchedule执行节点组创建命令eksctl create nodegroup -f eks-prod-cluster.yaml参数详解与避坑指南minSize: 0对于Spot节点组是必须的。因为Spot实例可能随时被回收节点数可能降到0。cluster-autoscaler会根据负载自动增减。withAddonPolicies是一个便捷的开关它会自动为节点组的IAM Role附加一系列预定义的策略。ebs: true会附加AmazonEBSCSIDriverPolicy这是后续安装EBS CSI驱动所必需的。taints和labels是Kubernetes调度的核心。taints是“排斥”labels是“标识”。一个Pod要想被调度到Spot节点上它必须同时满足1) 有nodeSelector匹配lifecycle: spot2) 有toleration容忍lifecyclespot:NoSchedule。这确保了只有明确声明可以容忍Spot中断的Pod才会被调度过去。提示节点组创建完成后用kubectl get nodes -o wide查看节点列表。你会看到节点名称、状态Ready、角色 、年龄、版本、以及外部IP。此时集群已经具备了执行Pod的能力但还缺少关键的“神经系统”——网络插件。3.4 阶段四核心插件安装——为集群装上“眼睛”和“手脚”一个裸集群Bare Cluster就像一个没有操作系统的服务器它什么也干不了。我们必须安装一系列核心插件让集群具备完整的网络、存储、服务发现能力。插件安装顺序至关重要CNI插件VPC CNI这是第一步也是最重要的一步。它负责Pod的IP地址分配和网络通信。eksctl在创建集群时已经安装了它但我们必须确保它是最新版并且配置正确。CSI驱动EBS CSI Driver为Pod提供持久化存储PersistentVolume。Ingress ControllerALB Ingress Controller将外部HTTP/HTTPS流量路由到集群内的Service。Metrics Server为HPA提供CPU/Memory指标。Prometheus Operator为整个集群提供统一的Metrics采集和告警能力。Step 1: 验证并升级VPC CNI# 查看当前CNI版本 kubectl get daemonset -n kube-system aws-node -o wide # 如果版本过旧如低于1.15.0升级它 eksctl utils update-cni -f eks-prod-cluster.yaml --approve**Step 2: 安装EBS CSI