1. 课程导论：为什么需要关注K8s集群生命周期运维？延迟水位与异常事件的定义与价值
1.1 从“建好”到“管好”：K8s集群生命周期运维的必然性
Kubernetes 集群并非一次部署、永久稳定的静态基础设施。随着业务规模增长、版本迭代、节点扩缩、配置变更以及底层硬件老化，集群会经历从规划、部署、运行、升级到最终下线的完整生命周期。在这一过程中，集群的“健康水位”会持续波动，运维团队面临的核心挑战从“如何建集群”转变为“如何持续管好集群”。
缺乏生命周期视角的运维，往往表现为“救火式”响应：节点磁盘写满导致 Pod 驱逐、API Server 因证书过期而拒绝请求、CNI 插件版本不兼容引发网络分区。这些问题在早期通常有可观测的征兆——延迟缓慢上升、异常事件频率增加——但如果没有系统化的监控与预警，这些征兆会被淹没在日常噪音中。
1.2 延迟水位：集群健康度的“体温计”
延迟水位 是指 Kubernetes 控制面组件（API Server、etcd、Scheduler、Controller Manager）以及核心数据面（kubelet、kube-proxy、CNI 插件）在处理请求或执行操作时所消耗的时间分布。它直接反映了集群内部各模块的负载压力与响应能力。
我们将延迟水位分为三个关键层级：
| 层级 | 典型指标 | 健康阈值参考 | 异常影响 |
|---|---|---|---|
| API Server 请求延迟 | apiserver_request_duration_seconds | P99 < 1s | kubectl 响应缓慢、控制器循环阻塞 |
| etcd 读写延迟 | etcd_request_duration_seconds | P99 < 100ms | 集群状态更新延迟、Leader 选举超时 |
| kubelet Pod 启动延迟 | kubelet_pod_start_duration_seconds | P99 < 5s | Pod 调度后长时间处于 Pending |
延迟水位是集群性能退化的早期信号。例如，etcd 的读写延迟从 20ms 缓慢爬升至 200ms，通常意味着磁盘 IO 压力增大或网络链路出现拥塞，此时尚未触发任何错误事件，但集群的“体温”已经升高。
1.3 异常事件：集群的“病理报告”
异常事件 是指 Kubernetes 集群中发生的、不符合预期状态的操作记录。这些事件通过 kubectl get events 或 API Server 的 Event 资源暴露，是集群内部状态机转换的副产品。常见的异常事件类型包括：
- 节点级： NodeNotReady、NodeHasDiskPressure、NodeHasMemoryPressure
- Pod 级： FailedScheduling、FailedMount、BackOff、OOMKilling
- 控制面级： LeaderElectionLost、CertExpiryInDays、APIServerHighErrorRate
异常事件的价值在于其“语义丰富性”——每条事件都携带了 type（Normal/Warning）、reason、message、involvedObject 等结构化字段，可以直接用于自动化告警和根因分析。但挑战在于：一个中等规模的集群每天可能产生数万条事件，其中 90% 以上是 Normal 类型的重复事件（如拉取镜像成功、健康检查通过），真正需要关注的 Warning 事件往往被淹没。
1.4 延迟水位与异常事件的关联价值
延迟水位和异常事件并非孤立维度，而是互为因果、相互印证的关系。下图展示了二者在集群生命周期中的典型联动模式：
从图中可以看出：延迟水位上升是“因”，异常事件爆发是“果”。通过 Prometheus 持续采集延迟指标，可以在异常事件尚未大规模出现时，提前识别集群的健康退化趋势。这正是本课程的核心方法论——以延迟水位为前置指标，以异常事件为后置验证，构建集群生命周期运维的可观测体系。
1.5 本课程的核心价值
通过本课程的学习，你将掌握以下能力：
- 量化集群健康度： 建立延迟水位基线，用数据而非直觉判断集群是否“健康”。
- 事件驱动的自动化运维： 基于异常事件的频率和模式，设计自动化的扩缩容、驱逐、自愈策略。
- 生命周期阶段的可观测适配： 集群在创建期、运行期、升级期、缩容期、退役期有不同的监控重点，课程将逐一覆盖。
- Prometheus + Kubernetes 深度集成： 从指标采集、告警规则编写到 Grafana 仪表盘设计，全链路实战。