2. K8s 升级基础回顾：控制面与节点升级流程、kubeadm 与托管集群差异
在深入资源配额调优之前，必须对齐 Kubernetes 集群升级的基础流程。升级路径的选择直接影响控制面与工作节点的资源消耗模式，也是后续瓶颈分析的前提。本节从升级流程、组件交互和集群类型差异三个维度进行回顾。
2.1 控制面升级流程
控制面组件（API Server、Controller Manager、Scheduler、etcd）的升级遵循严格的顺序依赖。先升级 etcd，再升级控制面组件，最后升级节点。以下是标准流程：
- 备份 etcd 快照：升级前必须通过
etcdctl snapshot save创建快照，用于回滚。 - 升级 etcd 集群：逐个节点滚动升级 etcd，确保 quorum 始终存在。
- 升级 kube-apiserver：先升级 API Server，因为其他组件依赖其 API 版本。
- 升级 kube-controller-manager 与 kube-scheduler：这两个组件可并行升级，但必须确保 API Server 已稳定运行。
- 验证控制面健康：使用
kubectl get componentstatuses检查所有组件状态。
瓶颈提示： 控制面升级期间，API Server 的
--max-requests-inflight 和 --max-mutating-requests-inflight 参数会限制并发请求量。如果集群规模较大（超过 500 节点），建议在升级前临时调高这两个值，避免因请求排队导致升级超时。
2.2 节点升级流程
工作节点升级的核心原则是“先腾空，再升级，后恢复”。kubelet 和 kube-proxy 的版本必须与控制面版本匹配（允许 n-2 版本偏差）。
| 步骤 | 操作 | 资源影响 | 调优关注点 |
|---|---|---|---|
| 1 | kubectl drain <node> --ignore-daemonsets |
Pod 驱逐，节点负载归零 | PodDisruptionBudget (PDB) 是否允许驱逐 |
| 2 | 升级 kubelet & kube-proxy 版本 | kubelet 重启，节点短暂 NotReady | kubelet 启动参数中的 --node-status-update-frequency |
| 3 | 重启节点（如需内核升级） | 节点完全不可用 | Graceful Shutdown 超时设置 |
| 4 | kubectl uncordon <node> |
节点重新调度 Pod | Scheduler 的 --node-startup-grace-period |
常见陷阱： 如果节点上运行了
DaemonSet 且未使用 --ignore-daemonsets，drain 操作会失败。此外，PDB 配置过于严格（如 maxUnavailable: 0）会导致驱逐阻塞，升级无法继续。建议在升级窗口前检查所有 PDB 的 maxUnavailable 值。
2.3 kubeadm 与托管集群的差异
kubeadm 自建集群与云托管集群（如 AKS、EKS、GKE）在升级流程、控制面可访问性和资源配额管理上存在本质差异。这些差异直接影响升级期间的瓶颈位置。
| 维度 | kubeadm 自建集群 | 托管集群（AKS/EKS/GKE） |
|---|---|---|
| 控制面升级 | 手动升级每个组件，需自行处理 etcd 快照与回滚 | 云厂商自动升级控制面，用户仅需升级节点池 |
| etcd 管理 | 用户负责 etcd 备份、磁盘 IOPS 监控与扩容 | etcd 由云厂商托管，用户无法直接访问 |
| API Server 参数 | 可自定义 --max-requests-inflight 等参数 |
参数由云厂商锁定，通常有默认上限 |
| 节点升级方式 | 逐节点 drain/upgrade/uncordon | 节点池滚动升级或蓝绿替换 |
| 资源配额瓶颈 | 控制面节点 CPU/内存/磁盘 IOPS 容易成为瓶颈 | API Server 请求速率配额（如 AKS 的 500 req/s） |
| 升级回滚 | 可通过 etcd 快照回滚整个集群 | 回滚通常需要重建节点池，控制面版本不可逆 |
2.4 升级版本偏差策略
Kubernetes 官方支持的版本偏差规则决定了升级路径的步长。理解这些规则有助于规划升级窗口，避免因版本跳跃过大导致组件不兼容。
- kube-apiserver：最高版本，其他组件版本不能高于它。
- kube-controller-manager / kube-scheduler：可以比 API Server 低一个次要版本（如 API Server v1.28，Controller Manager 可以是 v1.27）。
- kubelet：可以比 API Server 低两个次要版本（如 API Server v1.28，kubelet 可以是 v1.26）。
- kube-proxy：必须与 kubelet 版本一致。
- kubectl：可以比 API Server 高一个次要版本或低一个次要版本。
调优建议： 在升级过程中，如果节点数量超过 100，建议分批次升级节点，每批次不超过集群节点总数的 20%。同时监控 API Server 的
inflight_requests 指标，确保不超过 --max-requests-inflight 的 80%，为升级期间的额外请求（如节点状态更新、Pod 驱逐事件）预留缓冲。