从崩溃到自愈：AWS EKS集群生产级升级与维护实战指南
项目地址: https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero 引言：为什么EKS集群维护让运维工程师彻夜难眠？
你是否曾经历过：
- 集群升级后核心服务突然不可用？
- 节点组扩容失败导致业务中断？
- ALB控制器权限不足引发流量黑洞？
本文将通过day-22/installing-eks.md和day-22/prerequisites.md的实战经验，构建一套完整的EKS集群升级与维护体系，让你从"救火队员"转变为"预防专家"。
读完本文你将掌握：
- 零停机升级EKS控制平面的3种方案
- 节点组滚动更新的自动化脚本实现
- ALB控制器权限问题的快速诊断流程
- 生产环境必备的监控告警配置
一、EKS集群升级前的准备工作
1.1 环境检查清单
在执行任何升级操作前，必须验证以下组件版本兼容性：
| 组件 | 最低版本要求 | 检查命令 |
|---|---|---|
| kubectl | 1.24+ | kubectl version --client |
| eksctl | 0.130.0+ | eksctl version |
| AWS CLI | 2.9.0+ | aws --version |
1.2 基础设施备份策略
# 备份集群配置
eksctl get cluster --name <cluster-name> --region <region> > cluster-backup.yaml
# 备份关键命名空间资源
kubectl -n kube-system get all -o yaml > kube-system-backup.yaml
kubectl -n aws-load-balancer-controller get all -o yaml > alb-controller-backup.yaml
二、EKS控制平面升级实战
2.1 升级方案对比
| 升级方式 | 适用场景 | 停机风险 | 操作复杂度 |
|---|---|---|---|
| 控制台一键升级 | 测试环境 | 中 | 低 |
| eksctl命令行升级 | 生产环境 | 低 | 中 |
| 蓝绿部署升级 | 核心业务 | 极低 | 高 |
2.2 eksctl升级实施步骤
# 检查当前集群版本
eksctl get cluster --name <cluster-name> --region <region>
# 执行控制平面升级
eksctl upgrade cluster --name <cluster-name> --region <region> --version 1.25
# 验证升级结果
kubectl version --short
注意事项：升级过程约需15-30分钟，期间API Server可能会有2-3次短暂中断，建议在业务低峰期执行。
三、节点组维护与更新
3.1 节点组滚动更新
# 创建新节点组
eksctl create nodegroup --cluster <cluster-name> --region <region> \
--name new-nodegroup --node-type t3.large --nodes 3
# 迁移工作负载
kubectl drain <old-node-1> --ignore-daemonsets
kubectl drain <old-node-2> --ignore-daemonsets
# 删除旧节点组
eksctl delete nodegroup --cluster <cluster-name> --region <region> --name old-nodegroup
3.2 自动化节点更新配置
通过day-24/main.tf中的Terraform配置实现节点自动更新：
resource "aws_eks_node_group" "main" {
cluster_name = aws_eks_cluster.main.name
node_group_name = "auto-updating-nodegroup"
node_role_arn = aws_iam_role.eks_node_role.arn
subnet_ids = aws_subnet.private[*].id
scaling_config {
desired_size = 3
max_size = 5
min_size = 2
}
update_config {
max_unavailable_percentage = 25
}
labels = {
Environment = "production"
UpdatePolicy = "auto"
}
}
四、ALB控制器维护与故障排除
4.1 ALB控制器升级流程
day-22/alb-controller-add-on.md提供了完整的升级步骤：
# 更新Helm仓库
helm repo update eks
# 升级ALB控制器
helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=<cluster-name> \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set region=<region> \
--set vpcId=<vpc-id>
4.2 常见权限问题修复
当出现"elasticloadbalancing:DescribeListenerAttributes"权限错误时：
# 下载最新策略文档
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/install/iam_policy.json
# 更新IAM策略
aws iam create-policy-version \
--policy-arn arn:aws:iam::<account-id>:policy/AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json \
--set-as-default
五、监控告警与自愈机制
5.1 关键指标监控配置
推荐监控以下EKS核心指标（参考interview-questions/cloudwatch.md）：
| 指标名称 | 阈值 | 告警级别 |
|---|---|---|
| API Server错误率 | >1% | P1 |
| 节点NotReady状态 | >0 | P0 |
| Pod重启次数 | >5次/小时 | P2 |
| 控制平面延迟 | >1s | P1 |
5.2 自动恢复脚本示例
#!/bin/bash
# 检查异常节点
NON_READY_NODES=$(kubectl get nodes | grep -v "Ready" | grep -v "NAME" | awk '{print $1}')
# 自动驱逐异常节点上的Pod
for NODE in $NON_READY_NODES; do
echo "Processing node: $NODE"
kubectl drain $NODE --ignore-daemonsets --force
aws eks update-nodegroup-config --cluster-name <cluster-name> --nodegroup-name <nodegroup-name> --scaling-config desiredSize=0
sleep 30
aws eks update-nodegroup-config --cluster-name <cluster-name> --nodegroup-name <nodegroup-name> --scaling-config desiredSize=3
done
六、总结与最佳实践
6.1 升级维护检查清单
-
升级前：
- 完成所有资源备份
- 在测试环境验证升级流程
- 通知相关团队准备应急预案
-
升级中：
- 实时监控控制平面状态
- 每完成一步执行健康检查
- 保留故障排查窗口时间
-
升级后：
- 验证所有核心服务可用性
- 检查节点和Pod状态
- 观察24小时监控数据
6.2 进阶学习资源
- EKS官方文档：day-22/installing-eks.md
- 面试题集：interview-questions/eks.md
- Terraform配置示例：day-24/main.tf
通过本文介绍的方法，你可以构建一套稳定可靠的EKS集群维护体系。记住，最好的升级是用户感受不到的升级。收藏本文，下次集群升级前再看一遍，让你的运维工作更从容！
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
