亚马逊AWS官方博客
HAQM EKS 版本升级：控制面和数据面的升级实战
 |
在当今快速发展的云原生环境中，保持 Kubernetes 集群的最新状态是至关重要的。HAQM Elastic Kubernetes Service (EKS) 作为一个受欢迎的托管 Kubernetes 服务，定期发布新版本以提供最新的功能、性能改进和安全补丁。本文将详细介绍如何执行 EKS 集群的就地升级，包括升级前的准备工作、具体的升级步骤、以及升级后的验证和清理工作。
升级前的准备工作和检查清单
在开始升级过程之前，进行充分的准备和检查是确保升级顺利进行的关键。以下是一个详细的准备工作和检查清单：
1. 版本兼容性检查
- 确认目标 EKS 版本：查看 AWS 文档，了解最新的 EKS 版本及其功能。
- 检查应用程序兼容性：确保您的应用程序和使用的 Kubernetes API 与目标版本兼容。
- 检查插件兼容性：确保所有使用的 EKS 插件（如 CoreDNS、kube-proxy）与目标版本兼容。
2. 集群健康检查
- 运行
kubectl get nodes确保所有节点都处于 Ready 状态。 - 使用
kubectl get pods --all-namespaces检查所有 Pod 的状态。 - 检查集群指标，确保 CPU、内存和网络使用正常。
3. 备份关键数据
- 备份 etcd 数据：虽然 EKS 管理 etcd，但建议在升级前进行额外的备份，可以使用开源工具 Velero。
- 备份持久卷数据：如果使用 EBS 卷，考虑创建快照。
4. 更新 AWS CLI 和 kubectl
- 更新 AWS CLI 到最新版本
- 更新 kubectl 以匹配目标 EKS 版本
5. 检查 IAM 权限
- 确保用于升级的 IAM 用户或角色具有必要的权限，包括
eks:UpdateClusterVersion。
6. 规划维护窗口
- 选择一个对业务影响最小的时间窗口进行升级。
- 通知所有相关团队升级计划和可能的影响。
7. 准备回滚计划
- 制定详细的回滚计划，包括如何恢复到之前的版本。
- 确保团队成员熟悉回滚程序。
控制平面升级的具体步骤
控制平面的升级是 EKS 集群升级过程中的第一步，也是最关键的一步。以下是详细的步骤。
检查当前版本
首先，检查当前的 EKS 集群版本：
可以通过 cluster insight 功能检查 api 和 add-on 的兼容性。注意对于第三方的插件如 Istio 之类的需要进一步参考其官方网站检查其兼容性。
 |
启动升级过程
使用 AWS CLI 启动升级过程：
其中，1.XX 是你想升级到的 Kubernetes 版本。
监控升级进度
升级过程可能需要 20-30 分钟。你可以使用以下命令监控升级状态：
update-id 是在启动升级时返回的 ID。
验证控制平面升级
升级完成后，再次检查集群版本以确认升级成功：
升级附加组件
HAQM EKS 不会自动更新附加组件。要更新现有集群的附加组件，必须启动更新。启动更新后，HAQM EKS 会为您更新附加组件。在更新某个附加组件之前，请查看该附加组件的最新文档，您需要确保所有 EKS 插件都已更新到与新版本兼容的版本，对于托管的附加组件，可以按照以下步骤进行升级。更详细的内容可以参考附加组件升级文档。 对于第三方的附加组件，需要通过其官方渠道进一步获取其版本的兼容性说明。
查看附加组件：
升级附加组件：
工作节点升级的方法和注意事项
在控制平面升级完成后，下一步是升级工作节点。这个过程需要更多的注意和规划，因为它可能会影响运行中的工作负载。
托管节点组升级
如果你使用的是 EKS 托管的节点组，升级过程如下。注意托管节点组升级后，整个过程由后台自动控制，无法干预。
检查当前节点组版本：
更新节点组：
监控升级进度：
 |
非托管节点组升级
对于非托管节点，升级过程需要更多的手动操作，也提供了更多的灵活性和操作空间。非托管节点组的升级通过新建节点组的方式提供升级。在此过程中，需要注意的是新节点组的子网、安全组、IAM Role、userdata、标签、污点等需与旧节点组兼容。
- 创建新的 节点组。
- 给旧的节点打上污点。
- 逐步驱逐 pod 到新的节点，注意这一部可以批量操作也可以一个个节点操作，前提是保证业务应用的可用性。
- 同时检查应用的健康性，确保整个迁移顺利完成。
- 完成检查后可以缩容旧的的节点组，可以将节点组下线或者保留。
 |
注意事项
- 确保集群有足够的容量来重新调度 Pod。
- 考虑使用 Pod Disruption Budgets (PDBs) 来保护关键工作负载。
- 密切监控升级过程，准备随时回滚。
升级过程中的监控和故障排除
在升级过程中，持续监控和快速排除故障是确保升级成功的关键。
监控集群健康
- 使用
kubectl get nodes和kubectl get pods --all-namespaces定期检查节点和 Pod 状态。 - 监控关键指标如 CPU 使用率、内存使用率和网络流量。
- 使用 AWS CloudWatch 监控 EKS 控制平面指标。
检查系统组件
确保核心组件正常运行：
特别关注 CoreDNS、kube-proxy 和 aws-node 等关键组件。
检查日志
检查控制平面和工作节点的日志：
- 对于控制平面，查看 CloudWatch Logs。
- 对于工作节点，使用
kubectl logs或直接在节点上查看/var/log/下的日志。
常见问题及解决方法
- 节点未加入集群：检查安全组设置和 IAM 角色。
- Pod 无法调度：检查资源限制和节点亲和性设置。
- 网络问题：验证 CNI 插件配置和 VPC 设置。
升级后的验证和清理工作
升级完成后，进行全面的验证和必要的清理工作是确保集群稳定运行的重要步骤。
验证集群版本
再次检查集群和节点版本：
确保所有组件都已更新到预期版本。
验证工作负载
- 检查所有部署的状态：
kubectl get deployments --all-namespaces - 验证服务可用性：
kubectl get services --all-namespaces - 运行端到端测试确保应用程序功能正常。
清理旧资源
- 如果使用了新的节点组，可以考虑删除旧的节点组。
- 更新任何引用特定 Kubernetes 版本的 CI/CD 管道。
更新文档
- 更新集群文档，记录新版本及其特性。
- 更新任何内部工具或脚本以适应新版本。
性能基准测试
可以在测试验证环境进行性能基准测试，与升级前的性能进行对比，确保没有性能下降。
最佳实践和总结
最佳实践
- 定期升级：保持与 EKS 版本的更新节奏一致，避免跨多个版本的大规模升级。
- 测试环境先行：在生产环境升级之前，先在测试环境中进行升级和验证。
- 自动化：尽可能自动化升级流程，减少因为人工操作导致的错误。
- 文档化：详细记录每次升级的过程、遇到的问题和解决方案。
- 培训：确保团队成员了解升级流程和可能遇到的问题。
总结
EKS 集群的就地升级是一个复杂但必要的过程。通过仔细的规划、准备和执行，可以最小化风险并确保升级的成功。关键步骤包括：
- 充分的准备和检查
- 控制平面的平稳升级
- 附加组件的升级
- 工作节点的升级
- 全程监控和及时排障
- 升级后的全面验证和清理
通过遵循本文提供的步骤和最佳实践，您可以确保 EKS 集群始终运行在最新、最安全、性能最优的版本上，为您的应用程序提供稳定可靠的基础设施。
记住，虽然升级过程可能看起来繁琐，但其带来的好处包括增强的安全性、改进的性能和新功能，远远超过了升级的成本和风险。保持集群更新不仅是技术需求，也是保持竞争力和创新的战略决策。