集群升级
EKS 自动模式：增强的共享责任
Kubernetes 由控制平面和数据平面组件（工作节点）组成。
EKS 一直管理 Kubernetes 控制平面和升级。在 EKS Auto Mode之前，集群所有者负责启动控制平面和数据平面的升级。这包括升级自管理节点组、托管节点组和其他附加组件中的工作节点。
EKS Auto Mode代表了 Kubernetes 集群管理的重大进步，扩展了 AWS 的责任范围，包括自动升级集群基础设施。这一增强覆盖了工作节点和核心集群功能，大大减轻了客户的运营负担。
为了说明 EKS Auto Mode下的共享责任模型，请参考下图：
- 红色区域：代表由 AWS 完全管理的组件
- 绿色区域：表示仍由客户管理的方面
EKS Auto Mode通过为整个集群基础设施提供零接触更新，彻底改变了 Kubernetes 集群管理方式。
升级流程
1. 版本验证
- 集群所有者检查最新可用的 Amazon EKS 版本并验证与当前应用程序的兼容性
- 集群所有者可以启动版本更新
2. 控制平面和集群组件更新
- 启动控制平面版本升级
- 使用Auto Mode，任何托管集群功能也将自动更新，以确保跨版本的兼容性
3. 数据平面更新
优雅的节点更新遵循：
- 使用 Karpenter 的漂移管理功能，通过最新的 AMI 替换节点
- 滚动更新策略
- 满足Pod 中断预算 (PDBs)的限制
时间控制
过期设置
- 默认：工作节点将在不晚于 14 天内完全自动升级
- 自定义 NodePools：最多 21 天
中断控制
我们可以通过 NodePool 的 spec.disruption.budgets 限制 EKS Auto Mode中断节点的速率。通过中断预算，我们可以控制工作节点升级的速率，或确保升级仅在特定日期和时间进行（使用调度）。
默认情况下，Amazon EKS 自动模式通用 NodePool 具有以下Disruption配置：
# 使用此disruption，EKS Auto Mode一次最多会中断 10% 的活动节点。
spec:
disruption:
consolidateAfter: 0s
consolidationPolicy: WhenEmptyOrUnderutilized
budgets:
- nodes: 10%
...
# 使用此预算，我们限制 Amazon EKS 自动模式在工作日营业时间内不中断节点（"0"），如果触发了漂移，并且在所有其他时间最多允许中断 10% 的活动节点。
spec:
disruption:
consolidateAfter: 0s
consolidationPolicy: WhenEmptyOrUnderutilized
budgets:
- nodes: 10%
- schedule: 0 9 * * mon-fri
duration: 8h
nodes: "0"
reasons:
- Drifted
...
升级集群
我们可以看到我们的 Amazon EKS 控制平面正在运行 Amazon EKS 版本 1.31。
➤ 现在，让我们观察当前工作节点（数据平面）版本：kubectl get nodes
输出应类似于以下内容：
我们可以看到工作节点也在运行 Amazon EKS 版本 1.31。
查找已弃用的 API 和集群中安装的其他组件的新版本
在共同责任模型下，我们需要查看 Kubernetes 发布 页面，并对于我们要升级到的每个版本，验证没有影响我们业务应用的 API 弃用或更改。
此外，我们还需要为集群中安装的任何第三方或社区插件寻找新版本，并在 EKS 集群升级后对它们进行升级。
升级控制平面
让我们将 Amazon EKS 控制平面版本升级到 1.32。
➤ 执行以下命令：
aws eks update-cluster-version --region $AWS_REGION --name $CLUSTER_NAME --kubernetes-version 1.32
我们将看到类似于以下的输出：
{
"update": {
"id": "161695f2-6f78-327a-addc-b2b3495a1f9e",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": "1.32"
},
{
"type": "PlatformVersion",
"value": "eks.4"
}
],
"createdAt": "2025-02-28T21:34:10.330000+08:00",
"errors": []
}
}
(END)
在输出中，Amazon EKS 版本将更新到 1.32。还要注意 PlatformVersion 参数，这在 Amazon EKS 平台版本
中有文档说明。
控制平面升级过程通常需要约 10 分钟。
检查升级
等待控制平台更新完成到1.32：
升级完成10min左右，节点也会自动被升到1.32
验证节点：kubectl get nodes
工作节点也运行的是Amazon EKS版本_1.32_。
我们可以看到有与Drifted/Replaced相关的事件，这些事件是因为 EKS Auto Mode检测到EKS控制平面版本与工作节点版本不同，并通过Drift触发了替换。
➤ 执行以下命令：
kubectl get events | grep Drifted/Replace
Amazon EKS Auto Mode会首先启动一个新的节点替换，驱逐Pod，然后等待新的节点替换准备就绪，然后才会终止要替换的节点。当配置了PDB时，Auto Mode通过使用回退重试驱逐策略来满足PDB的限制。