规划 Amazon EKS 从 1.32 升级到 1.35：关键变更识别与逐版本实施路径¶

Ch11.107 规划 Amazon EKS 从 1.32 升级到 1.35：关键变更识别与逐版本实施路径¶

📊 Level ⭐⭐ | 9.3KB | entities/规划-amazon-eks-从-132-升级到-135关键变更识别与逐版本实施路径.md

规划 Amazon EKS 从 1.32 升级到 1.35：关键变更识别与逐版本实施路径¶

概览¶

AWS 官方发布的 EKS Kubernetes 版本升级方法论，针对 1.32→1.35 跨三个 minor 版本的实战规划。核心约束：EKS 不允许跨 minor 升级，必须 1.32→1.33→1.34→1.35 逐版本进行。这套方法论可复用于所有 EKS 集群升级场景。

关键约束：不可跳版本¶

EKS 强制逐版本升级的原因： - Kubernetes API deprecation 政策：每个 minor 版本弃用 → 两个版本后删除 - 跨版本升级会一次性触发多个 deprecation 警告，diagnostics 信息丢失 - 生产风险：跳版本导致 1.32→1.35 的 API 变化累积到 ~30 个，单次升级失败概率指数级上升

升级路径四阶段¶

阶段 1：升级前评估（每个 minor 版本各做一次）¶

自管理组件风险评估： - 自定义 CRD（Cert Manager, ArgoCD, Istio 等）：检查 vendor 的 Kubernetes 版本兼容矩阵 - Operator：每个 Operator 独立验证（OpenShift/Confluent/RabbitMQ） - DaemonSet：kube-proxy / CNI（Calico/Cilium）的版本对齐

托管组件确认清单： - [ ] EKS 托管 nodegroup AMI 更新到目标版本 - [ ] EKS Pod Identity 关联策略验证 - [ ] EBS CSI Driver / EFS CSI Driver 兼容性 - [ ] AWS Load Balancer Controller 版本

阶段 2：升级中（每次升级一个 minor）¶

# 1. 更新 kubeconfig
aws eks update-kubeconfig --name my-cluster --region us-east-1

# 2. 升级 control plane（AWS 托管，自动）
aws eks update-cluster-version --name my-cluster --kubernetes-version 1.33

# 3. 升级 managed nodegroup
aws eks update-nodegroup-version \
  --cluster-name my-cluster \
  --nodegroup-name my-ng \
  --release-version 1.33-20250101

# 4. 升级 self-managed nodegroup
# (使用 AMI 替换 + 滚动重启)

阶段 3：升级后验证¶

• kubectl get nodes 确认所有节点 Ready + 新版本
• kubectl get pods -A 检查 CrashLoopBackOff / ImagePullBackOff
• 应用层 smoke test（关键业务 API + 数据库连接）

阶段 4：cgroup v1 → cgroup v2 迁移（1.32+ 默认）¶

关键变更：Kubernetes 1.32+ 节点默认使用 cgroup v2（统一 cgroup hierarchy） - 旧应用监控工具（cAdvisor 旧版本）可能不兼容 - JVM 应用的 -XX:+UseContainerSupport 行为变化（已自动，无需调整） - 内存 limit 行为：cgroup v2 严格按 limit 触发 OOMKill

AL2023 节点镜像迁移： - AL2 → AL2023 是 EKS 1.30+ 的推荐迁移 - AL2023 默认启用 cgroup v2 - 网络栈变更：nsswitch.conf 默认行为变化

关键变更识别表¶

升级时间窗口与回滚策略¶

• 时间窗口：每次 minor 升级 control plane 约 30 分钟，nodegroup 升级另算（依节点数）
• 回滚：EKS control plane 升级不可回滚——必须 forward fix
• 安全网：升级前 1 周全量 etcd 备份 + 关键 namespace 资源 snapshot

实践启示¶

深度分析¶

1. "不可跳版本"约束是 Kubernetes API deprecation 政策的必然结果¶

EKS 不允许跨 minor 版本升级的根本原因是 Kubernetes 的 API deprecation 政策：每个 minor 版本弃用的 API 在两个版本后删除。跨版本升级会导致 ~30 个 API 变化在单次升级中累积，任何一个兼容性问题都会导致升级失败且无法回滚。这个约束不是 AWS 的技术限制，而是 Kubernetes 社区的政策设计，其目的是确保集群升级的可预测性和可恢复性。Cilium Tetragon 中提到的运行时安全监控组件升级也遵循同样的 API 兼容性约束。

2. 自管理组件风险分级是 EKS 升级的核心工程复杂度¶

本文最有价值的方法论贡献是对自管理组件的三级风险分类（高/中/低）。真正拖慢 EKS 升级的不是 Kubernetes 本身，而是那些"挂着没人动"的自管理监控组件（Prometheus 2021年版本、Filebeat 2019年版本）。这些组件的 client-go 库与目标 K8s 版本不兼容，会在升级当天集中暴露。关键洞察：升级前评估阶段的自管理组件升级应该是独立于 Kubernetes 版本升级的独立工作项，两者解耦可以大幅简化故障排查路径。

3. cgroup v2 是 1.32+ 集群的隐形陷阱，AL2023 迁移是前置必选项¶

cgroup v1 → v2 是 Kubernetes 1.32+ 最重要的运行时变更，但它的影响是隐形的：cAdvisor 旧版本不兼容、JVM -XX:+UseContainerSupport 行为变化（已自动修复）、内存 limit 行为更严格。更关键的是 AL2 → AL2023 是 EKS 1.30+ 的推荐节点迁移路径，而 AL2023 默认启用 cgroup v2。这意味着如果你的集群还在用 AL2，在升级到 1.35 时节点将无法启动——而这个问题无法通过回滚解决，必须在升级前完成 OS 迁移。

4. cluster-autoscaler 版本必须与 Kubernetes 大版本同步¶

本文指出了一个容易被忽视的工程细节：cluster-autoscaler 的版本号需要与 Kubernetes 大版本保持一致，因此每升一个 K8s 大版本就需要同步升级一次 cluster-autoscaler，不能跨多个版本一次到位。这意味着 cluster-autoscaler 升级是每次 minor 版本升级的必做事项，而非可选的"等有空再处理"。Waylens OpenClaw EKS 实践 中的多租户 Operator 管理也涉及类似的组件版本对齐问题。

5. 四阶段升级路径是控制 blast radius 的工程方法论¶

本文的四阶段（升级前准备 → 1.32→1.33 → 1.33→1.34 → 1.34→1.35）揭示了一个关键的工程原则：每次只升级一个变量。阶段 1 的组件升级与 K8s 版本解耦，让后续任何版本升级阶段的故障排查都排除组件兼容性这个变量。这是 SRE 中"改变越小越安全"原则的具体应用。EKS 多租户 AI Agent 中提到的分阶段发布策略与此同构。

实践启示¶

• 不可跳版本是 EKS 强约束，把"升级 3 个版本"拆成 3 个独立项目更可控：每个阶段独立评估、独立验证、独立回滚方案
• cgroup v2 迁移是 1.32+ 的隐形陷阱，应用监控工具需提前升级：cAdvisor、node-exporter 等可观测组件必须支持 cgroup v2
• 升级期间禁止并发部署应用变更：blast radius 控制的原则是"每次只变一件事"
• AL2023 节点迁移是 1.30+ 集群的推荐路径，需重新验证 init 脚本：网络栈变更（nsswitch.conf）可能影响自定义初始化逻辑
• 升级前 1 周执行全量 etcd 备份 + 关键 namespace 资源 snapshot：EKS control plane 升级不可回滚，安全网是唯一保障

→ 原文存档