1. 课程导论：集群升级背景、服务目录平台定义、容量水位巡检的重要性与目标
1.1 集群升级背景：为什么需要关注容量水位？
在云原生架构演进过程中，Kubernetes 集群升级是保障基础设施安全性与功能迭代的常规操作。然而，集群升级并非单纯的版本替换，它涉及控制面组件重启、节点驱逐、Pod 重调度、API 版本变更等一系列高风险操作。当集群承载着企业核心的服务目录平台时，升级期间的资源波动极易触发容量瓶颈，导致服务不可用或性能降级。
核心痛点： 集群升级期间，由于节点分批下线、镜像拉取并发激增、临时 Pod 副本数调整等因素，集群的 CPU、内存、存储及网络资源会出现瞬时或持续性的水位异常。若未提前进行容量水位巡检，轻则升级失败回滚，重则引发生产事故。
以下表格总结了集群升级期间常见的容量风险场景：
| 风险阶段 | 典型容量问题 | 影响范围 |
|---|---|---|
| 节点驱逐 | 剩余节点 CPU/内存过载，Pod 无法调度 | 服务目录平台整体响应延迟 |
| 控制面升级 | etcd 磁盘 I/O 飙升，API Server 超时 | 服务注册/发现中断 |
| 镜像拉取 | 节点磁盘空间不足，镜像拉取失败 | 新版本 Pod 无法启动 |
| 网络策略更新 | CNI 插件内存泄漏，网络吞吐下降 | 服务间调用超时 |
1.2 服务目录平台定义：云原生时代的服务治理枢纽
服务目录平台（Service Catalog Platform）是企业内部微服务架构中的核心基础设施，它负责服务的注册、发现、配置管理、健康检查及流量路由。在云原生环境中，服务目录平台通常以 Operator 或 Sidecar 模式部署在 Kubernetes 集群之上，其自身也由多个微服务组件构成。
一个典型的服务目录平台包含以下关键组件：
- 注册中心： 维护所有服务的实例列表与元数据（如 Consul、Nacos、Eureka）。
- 配置中心： 管理服务的动态配置与版本控制（如 Apollo、Spring Cloud Config）。
- 网关/代理： 负责流量路由、限流熔断与安全认证（如 Kong、Envoy）。
- 健康检查器： 周期性探测服务实例状态，剔除异常节点。
- 监控与告警： 采集服务调用链、指标与日志，提供可观测性。
关键认知： 服务目录平台本身也是集群中的“租户”，其组件对资源的需求具有高敏感性。升级期间，若平台自身的 Pod 因资源不足被驱逐或 OOMKilled，将导致整个微服务体系失去导航能力。
1.3 容量水位巡检的重要性与目标
容量水位巡检（Capacity Watermark Inspection）是指在集群升级前、中、后三个阶段，对服务目录平台所依赖的计算、存储、网络资源进行系统性检查与评估，确保资源使用率始终处于安全阈值内。
其核心重要性体现在以下三个方面：
- 预防升级中断： 通过提前发现资源瓶颈，避免升级过程中因资源耗尽导致服务目录平台组件崩溃。
- 保障服务连续性： 确保升级期间服务注册、发现、配置下发等核心功能不降级，维持微服务体系的正常运转。
- 加速升级回滚： 当巡检发现容量异常时，可快速决策回滚或扩容，缩短故障恢复时间。
常见误区： 很多团队只在升级前做一次资源检查，忽略了升级中动态水位的变化。容量水位巡检应是一个持续、动态的过程，而非一次性快照。
本次课程设定的容量水位巡检目标如下表所示：
| 巡检维度 | 目标指标 | 安全阈值 | 巡检时机 |
|---|---|---|---|
| CPU 使用率 | 集群整体 & 服务目录平台 Pod | < 70% (预留 30% 给升级波动) | 升级前、升级中每 5 分钟 |
| 内存使用率 | 节点内存 & 平台组件堆内存 | < 75% (避免 OOM) | 升级前、升级中每 5 分钟 |
| 磁盘 I/O | etcd 数据盘 & 镜像存储盘 | iowait < 10%，磁盘使用率 < 80% | 升级前、节点驱逐后 |
| 网络带宽 | 集群内东西向流量 & 网关入口 | 带宽使用率 < 60% | 升级前、升级中持续 |
| Pod 密度 | 每节点可调度 Pod 数量 | 不超过节点容量的 80% | 升级前、节点排空后 |