1. 升级概述：Kubernetes集群升级的重要性、常见升级策略及资源配额瓶颈的宏观影响
1.1 为什么集群升级是SRE的核心职责
Kubernetes 版本迭代速度极快，每三个月发布一个次要版本。长期运行在旧版本集群会带来以下风险：
- 安全漏洞暴露：CVE 补丁仅反向移植到最近三个次要版本，老旧版本无安全修复。
- API 版本废弃：K8s 1.22 移除了一批 beta API，1.25 起内置资源如 PodSecurityPolicy 被移除，不升级将导致工作负载无法部署。
- 功能缺失与性能退化：新调度算法、原地调整 Pod 资源（InPlacePodVerticalScaling）、拓扑感知路由等特性无法使用。
- 社区与厂商支持终止：云厂商托管集群（EKS、AKS、GKE）会强制停止对过期版本的支持。
SRE 经验： 建议集群版本落后不超过两个次要版本。例如当前最新为 1.30，生产集群至少应运行 1.28 或 1.29。版本差距越大，升级路径越长，资源配额瓶颈越容易暴露。
1.2 三种主流升级策略对比
| 策略 | 原理 | 资源消耗特征 | 典型场景 |
|---|---|---|---|
| 原地升级 | 逐台替换节点操作系统或 Kubelet 版本，节点保持 IP 不变 | 单节点资源被占用，集群总容量短暂下降 | 自建裸金属、有状态工作负载、固定 IP 场景 |
| 蓝绿部署 | 创建完整的新版本集群（绿），流量一次性切换 | 需要 2x 集群资源，资源配额需求翻倍 | 金融核心、合规审计、零停机要求极高 |
| 滚动升级 | 逐个或分批替换节点，新老节点并存 | 资源占用逐步增加，需预留缓冲容量 | 大多数无状态微服务、标准生产环境 |
关键结论： 三种策略对资源配额的需求差异巨大。原地升级对配额冲击最小，但风险集中；蓝绿部署最安全，但资源成本最高；滚动升级是平衡方案，但需要精确计算缓冲资源。
1.3 资源配额瓶颈的宏观影响
资源配额（ResourceQuota）是 Kubernetes 多租户隔离的核心机制。升级过程中，配额瓶颈会从以下三个层面产生连锁影响：
- 节点资源不足导致 Pod 驱逐失败：升级节点时，Pod 需要被驱逐到其他节点。如果集群整体 CPU/内存配额不足，Pod 将处于 Pending 状态，影响业务可用性。
- Namespace 配额超限阻塞新 Pod 创建：每个 Namespace 的 ResourceQuota 限制了 CPU、内存、PVC 等总量。升级过程中临时创建的 Pod（如 DaemonSet 更新、迁移 Pod）可能触发配额上限，导致升级流程卡死。
- 控制面组件资源竞争：kube-controller-manager、kube-scheduler 等组件在升级期间需要处理大量 Pod 重调度、Endpoint 更新等事件。如果控制面 Pod 的 QoS 保障不足，可能引发调度延迟或 API Server 过载。
常见误区： 很多团队只关注节点 CPU/内存水位，忽略了 Namespace 级别的 ResourceQuota 和 LimitRange。升级前必须检查每个 Namespace 的配额使用率，尤其是
count/pods、requests.cpu、requests.memory 三个核心指标。
1.4 升级流程与资源配额瓶颈关系图
下图展示了滚动升级过程中，资源配额瓶颈出现的典型位置：
1.5 资源配额瓶颈的三种典型表现
| 瓶颈类型 | 现象 | 影响范围 | 升级阶段 |
|---|---|---|---|
| 节点容量瓶颈 | Pod 处于 Pending，kubectl describe pod 显示 Insufficient cpu/memory |
单个工作负载 | 节点排空、Pod 重调度 |
| Namespace 配额瓶颈 | Pod 创建失败，Event 显示 exceeded quota |
整个 Namespace | Pod 重调度、新版本 DaemonSet 部署 |
| 控制面组件瓶颈 | API Server 响应延迟、Scheduler 队列堆积、Leader Election 超时 | 全局集群 | 升级全过程 |