AWS EKS集群部署实战从零搭建到生产级Ingress配置第一次接触AWS EKS时我花了整整三天时间才让第一个Pod成功运行。不是文档不够详细而是那些隐藏的坑总在关键时刻给你当头一棒——IAM角色权限不足导致集群创建失败、节点组网络配置错误导致Pod无法通信、Ingress Controller版本不兼容导致服务无法暴露...这些经历让我意识到EKS部署远不止是点击几个按钮那么简单。本文将分享我在多个生产环境中总结出的EKS部署全流程特别聚焦那些官方文档没强调的实战细节和避坑指南。无论你是刚接触Kubernetes的开发者还是需要将现有应用迁移到EKS的架构师这些经验都能帮你节省数十小时的试错时间。1. 环境准备与权限规划在控制台点击创建集群按钮前合理的权限规划能避免后续90%的访问控制问题。AWS的IAM系统虽然强大但EKS所需的权限组合却有其特殊性。1.1 IAM角色关键配置创建EKS集群需要两个核心IAM角色集群角色供EKS服务本身使用# 信任关系配置示例 { Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: { Service: eks.amazonaws.com }, Action: sts:AssumeRole } ] }必须附加的托管策略AmazonEKSClusterPolicy可选AmazonEKSServicePolicy旧版本需要节点角色供Worker节点使用的权限策略常被忽略的三个细节必须包含AmazonEKSWorkerNodePolicy和AmazonEKS_CNI_Policy如果使用ECR需要AmazonEC2ContainerRegistryReadOnly自定义权限时需开放ec2:DescribeInstances等元数据访问权限常见错误节点角色缺少CNI策略会导致Pod网络不通错误表现为kubectl get nodes显示Ready但Pod始终处于Pending状态。1.2 网络架构设计EKS集群的网络性能直接取决于VPC规划。生产环境建议配置项推荐方案典型错误子网分配至少3个AZ各2个子网单AZ部署导致高可用失效CIDR规划Pod IP范围(/16)与Service IP(/18)分离地址空间重叠导致路由冲突安全组规则控制平面与节点组使用不同安全组过度开放6443端口# 检查CIDR冲突的命令示例 aws ec2 describe-vpcs --query Vpcs[*].CidrBlockAssociationSet[*].CidrBlock2. 集群创建与节点组配置2.1 控制平面创建技巧通过控制台创建时这些选项值得特别注意Kubernetes版本选择比当前最新版低1-2个的稳定版本如当前1.28则选1.27Endpoint访问生产环境建议先配置为私有访问再通过VPC Peering或VPN开放日志记录务必启用audit日志后续安全审计时至关重要# 使用eksctl创建集群的优化配置示例 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: production-cluster region: us-west-2 version: 1.27 vpc: cidr: 10.10.0.0/16 managedNodeGroups: - name: ng-1 instanceType: m6i.large desiredCapacity: 3 privateNetworking: true iam: attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy2.2 节点组高级配置节点组的自动伸缩配置需要结合应用特点内存密集型应用kubeletExtraArgs: kube-reserved: cpu250m,memory1Gi system-reserved: cpu250m,memory1Gi eviction-hard: memory.available500MiGPU工作负载选择p3/p4实例系列安装NVIDIA设备插件配置节点标签便于调度血泪教训未配置资源预留会导致系统OOM杀死关键进程表现为随机性的节点NotReady状态。3. 集群访问与组件管理3.1 kubectl访问优化方案当API服务器端点设为私有时有三种安全访问方式跳板机模式ssh -L 6443:API_SERVER_ENDPOINT:443 bastion-hostSession Manager隧道aws ssm start-session --target instance-id \ --document-name AWS-StartPortForwardingSession \ --parameters {portNumber:[443],localPortNumber:[6443]}API网关代理适合CI/CD场景resource aws_apigatewayv2_api eks_api { name eks-api-proxy protocol_type HTTP target vpc-link-arn }3.2 必备插件安装除官方文档提到的VPC CNI、CoreDNS、kube-proxy外这些组件对生产环境至关重要Metrics Server用于HPA自动伸缩kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yamlCluster Autoscaler# 注意替换YOUR_CLUSTER_NAME command: - ./cluster-autoscaler - --cloud-provideraws - --namespacekube-system - --node-group-auto-discoveryasg:tagk8s.io/cluster-autoscaler/enabled,YOUR_CLUSTER_NAME4. Ingress Controller实战配置4.1 ALB Ingress深度配置AWS Load Balancer Controller提供了比传统nginx ingress更强大的功能apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: production-ingress annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/id spec: ingressClassName: alb rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: frontend-service port: number: 80性能优化参数alb.ingress.kubernetes.io/load-balancer-attributes: 开启WAF、启用HTTP/2alb.ingress.kubernetes.io/target-group-attributes: 设置deregistration_delay.timeout_seconds304.2 多Ingress控制器共存当需要同时使用ALB和nginx时为nginx ingress创建单独的IngressClassapiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: nginx-external spec: controller: k8s.io/ingress-nginx在Ingress资源中明确指定ingressClassName: nginx-external通过NodePort或内部ALB暴露nginx控制器5. 监控与运维进阶技巧5.1 关键指标监控体系使用CloudWatch Container Insights需要额外配置# 启用指标收集 kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml必须监控的黄金指标控制平面API服务器延迟、etcd写入延迟数据平面节点CPU饱和度、Pod网络丢包率存储EBS卷队列深度、IOPS利用率5.2 灾难恢复方案针对不同故障级别的应对策略节点故障# 自动驱逐不可用节点 kubectl drain node-name --ignore-daemonsets --delete-emptydir-data控制平面故障定期备份EKS配置特别是aws-auth ConfigMap使用Terraform等IaC工具保存状态区域级故障提前配置多区域集群使用Route53故障转移路由策略在最近一次区域中断事件中我们通过预先配置的跨区域副本将服务切换时间控制在3分钟内。关键点在于使用Cluster API自动同步部署状态全局数据库采用Aurora Global DatabaseCI/CD系统同时部署到所有区域EKS的复杂性在于它既是Kubernetes又是AWS服务。掌握这两者的交互细节才能真正发挥云原生架构的威力。经过十几个生产集群的锤炼我发现最稳定的组合往往是最新稳定版Kubernetes减去一个次版本 经过验证的AWS服务集成方案 适度的保守配置。当遇到诡异问题时不妨先检查IAM权限和网络ACL——这两个地方解决了我们80%的灵异事件。
AWS EKS集群部署避坑指南：从零配置到Ingress Controller实战
AWS EKS集群部署实战从零搭建到生产级Ingress配置第一次接触AWS EKS时我花了整整三天时间才让第一个Pod成功运行。不是文档不够详细而是那些隐藏的坑总在关键时刻给你当头一棒——IAM角色权限不足导致集群创建失败、节点组网络配置错误导致Pod无法通信、Ingress Controller版本不兼容导致服务无法暴露...这些经历让我意识到EKS部署远不止是点击几个按钮那么简单。本文将分享我在多个生产环境中总结出的EKS部署全流程特别聚焦那些官方文档没强调的实战细节和避坑指南。无论你是刚接触Kubernetes的开发者还是需要将现有应用迁移到EKS的架构师这些经验都能帮你节省数十小时的试错时间。1. 环境准备与权限规划在控制台点击创建集群按钮前合理的权限规划能避免后续90%的访问控制问题。AWS的IAM系统虽然强大但EKS所需的权限组合却有其特殊性。1.1 IAM角色关键配置创建EKS集群需要两个核心IAM角色集群角色供EKS服务本身使用# 信任关系配置示例 { Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: { Service: eks.amazonaws.com }, Action: sts:AssumeRole } ] }必须附加的托管策略AmazonEKSClusterPolicy可选AmazonEKSServicePolicy旧版本需要节点角色供Worker节点使用的权限策略常被忽略的三个细节必须包含AmazonEKSWorkerNodePolicy和AmazonEKS_CNI_Policy如果使用ECR需要AmazonEC2ContainerRegistryReadOnly自定义权限时需开放ec2:DescribeInstances等元数据访问权限常见错误节点角色缺少CNI策略会导致Pod网络不通错误表现为kubectl get nodes显示Ready但Pod始终处于Pending状态。1.2 网络架构设计EKS集群的网络性能直接取决于VPC规划。生产环境建议配置项推荐方案典型错误子网分配至少3个AZ各2个子网单AZ部署导致高可用失效CIDR规划Pod IP范围(/16)与Service IP(/18)分离地址空间重叠导致路由冲突安全组规则控制平面与节点组使用不同安全组过度开放6443端口# 检查CIDR冲突的命令示例 aws ec2 describe-vpcs --query Vpcs[*].CidrBlockAssociationSet[*].CidrBlock2. 集群创建与节点组配置2.1 控制平面创建技巧通过控制台创建时这些选项值得特别注意Kubernetes版本选择比当前最新版低1-2个的稳定版本如当前1.28则选1.27Endpoint访问生产环境建议先配置为私有访问再通过VPC Peering或VPN开放日志记录务必启用audit日志后续安全审计时至关重要# 使用eksctl创建集群的优化配置示例 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: production-cluster region: us-west-2 version: 1.27 vpc: cidr: 10.10.0.0/16 managedNodeGroups: - name: ng-1 instanceType: m6i.large desiredCapacity: 3 privateNetworking: true iam: attachPolicyARNs: - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy2.2 节点组高级配置节点组的自动伸缩配置需要结合应用特点内存密集型应用kubeletExtraArgs: kube-reserved: cpu250m,memory1Gi system-reserved: cpu250m,memory1Gi eviction-hard: memory.available500MiGPU工作负载选择p3/p4实例系列安装NVIDIA设备插件配置节点标签便于调度血泪教训未配置资源预留会导致系统OOM杀死关键进程表现为随机性的节点NotReady状态。3. 集群访问与组件管理3.1 kubectl访问优化方案当API服务器端点设为私有时有三种安全访问方式跳板机模式ssh -L 6443:API_SERVER_ENDPOINT:443 bastion-hostSession Manager隧道aws ssm start-session --target instance-id \ --document-name AWS-StartPortForwardingSession \ --parameters {portNumber:[443],localPortNumber:[6443]}API网关代理适合CI/CD场景resource aws_apigatewayv2_api eks_api { name eks-api-proxy protocol_type HTTP target vpc-link-arn }3.2 必备插件安装除官方文档提到的VPC CNI、CoreDNS、kube-proxy外这些组件对生产环境至关重要Metrics Server用于HPA自动伸缩kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yamlCluster Autoscaler# 注意替换YOUR_CLUSTER_NAME command: - ./cluster-autoscaler - --cloud-provideraws - --namespacekube-system - --node-group-auto-discoveryasg:tagk8s.io/cluster-autoscaler/enabled,YOUR_CLUSTER_NAME4. Ingress Controller实战配置4.1 ALB Ingress深度配置AWS Load Balancer Controller提供了比传统nginx ingress更强大的功能apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: production-ingress annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/id spec: ingressClassName: alb rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: frontend-service port: number: 80性能优化参数alb.ingress.kubernetes.io/load-balancer-attributes: 开启WAF、启用HTTP/2alb.ingress.kubernetes.io/target-group-attributes: 设置deregistration_delay.timeout_seconds304.2 多Ingress控制器共存当需要同时使用ALB和nginx时为nginx ingress创建单独的IngressClassapiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: nginx-external spec: controller: k8s.io/ingress-nginx在Ingress资源中明确指定ingressClassName: nginx-external通过NodePort或内部ALB暴露nginx控制器5. 监控与运维进阶技巧5.1 关键指标监控体系使用CloudWatch Container Insights需要额外配置# 启用指标收集 kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml必须监控的黄金指标控制平面API服务器延迟、etcd写入延迟数据平面节点CPU饱和度、Pod网络丢包率存储EBS卷队列深度、IOPS利用率5.2 灾难恢复方案针对不同故障级别的应对策略节点故障# 自动驱逐不可用节点 kubectl drain node-name --ignore-daemonsets --delete-emptydir-data控制平面故障定期备份EKS配置特别是aws-auth ConfigMap使用Terraform等IaC工具保存状态区域级故障提前配置多区域集群使用Route53故障转移路由策略在最近一次区域中断事件中我们通过预先配置的跨区域副本将服务切换时间控制在3分钟内。关键点在于使用Cluster API自动同步部署状态全局数据库采用Aurora Global DatabaseCI/CD系统同时部署到所有区域EKS的复杂性在于它既是Kubernetes又是AWS服务。掌握这两者的交互细节才能真正发挥云原生架构的威力。经过十几个生产集群的锤炼我发现最稳定的组合往往是最新稳定版Kubernetes减去一个次版本 经过验证的AWS服务集成方案 适度的保守配置。当遇到诡异问题时不妨先检查IAM权限和网络ACL——这两个地方解决了我们80%的灵异事件。
