亚马逊AWS官方博客
·
规划 Amazon EKS 从 1.32 升级到 1.35：关键变更识别与逐版本实施路径
内容提要
本文讨论了如何将Amazon EKS从1.32升级到1.35，强调逐版本升级的重要性。升级时需评估自管理和托管组件的风险，识别关键变更，如cgroup v1弃用和containerd升级。建议制定详细的升级路径，确保每个阶段完成必要的准备和验证，以降低风险并确保系统稳定。
关键要点
-
Amazon EKS 不支持跨多个版本直接升级，必须逐版本递进。
-
升级时需评估自管理和托管组件的风险，识别关键变更。
-
cgroup v1 在 Kubernetes 1.35 中被弃用，需确保节点使用 cgroup v2。
-
建议制定详细的升级路径，确保每个阶段完成必要的准备和验证。
-
自管理组件需按风险等级分类，确保高风险组件在升级前完成更新。
-
托管组件会自动更新，但建议提前确认目标版本及其对工作负载的影响。
-
在升级过程中，需特别注意关键风险项，如 containerd 升级和 Ingress NGINX 退役。
-
建议预留 2-3 周时间进行组件升级和测试，确保系统稳定。
延伸解读
逐版本升级的重要性
Amazon EKS 不支持跨多个大版本直接升级，必须逐版本递进。这一策略确保了每个版本的兼容性和稳定性，避免了因一次性升级导致的系统崩溃或功能失效。因此，企业在规划升级时，需充分考虑每个版本的关键变更，确保逐步实施。
自管理组件的风险评估
在升级过程中，自管理组件的版本更新至关重要。许多企业因惯性未及时升级这些组件，导致在升级 Kubernetes 版本时出现兼容性问题。建议企业在升级前进行风险分级评估，确保高风险组件在升级前完成更新，以降低潜在的系统故障风险。
关键变更的关注点
在 EKS 1.32 升级到 1.35 的过程中，cgroup v1 的弃用和 containerd 的升级是两个关键变更。企业需特别关注这些变更对现有工作负载的影响，确保在升级前完成必要的准备和验证，以避免在升级后出现节点无法启动等严重问题。
延伸问答
为什么Amazon EKS不支持跨多个版本直接升级？
Amazon EKS不支持跨多个大版本直接升级，必须逐版本递进，以确保每个版本的兼容性和稳定性。
在升级到EKS 1.35时需要注意哪些关键变更？
需要注意cgroup v1的弃用、containerd的升级、Ingress NGINX的退役等关键变更。
如何评估自管理组件的风险？
自管理组件按风险等级分为高、中、低风险，需根据与目标K8s版本的兼容性进行分类。
升级EKS时，托管组件会如何处理？
托管组件会自动更新到与目标版本兼容的版本，但建议提前确认其对工作负载的影响。
在升级过程中，如何处理cgroup v1的弃用问题？
需确保所有节点使用cgroup v2，如果仍在使用AL2，必须在升级到1.34前迁移到AL2023。
建议预留多长时间进行组件升级和测试？
建议预留2-3周时间进行组件升级和测试，以确保系统稳定。
