1. 课程导论：多租户 K8s 性能挑战、瓶颈分析的价值、课程目标与学习路径
1.1 多租户 K8s 的性能挑战
在单集群中承载多个业务团队或应用（即多租户）时，K8s 的默认调度与资源隔离机制会暴露出显著的性能瓶颈。这些挑战并非由单一组件引起，而是控制面、数据面与存储面协同失效的综合结果。
| 挑战维度 | 典型表现 | 根因简述 |
|---|---|---|
| 控制面过载 | API Server 响应延迟 > 5s，etcd 写入限速 | 租户激增导致 List-Watch 连接数、资源变更事件量超出设计上限 |
| 调度竞争 | Pod 调度时延从 200ms 飙升至 8s，Pending 率上升 | 默认调度器按 FIFO 处理，缺乏租户级公平排队与抢占感知 |
| 网络性能衰减 | 跨节点吞吐量下降 40%，DNS 解析超时率升高 | 大量 Service/EndpointSlice 导致 iptables/IPVS 规则膨胀，CoreDNS 缓存命中率下降 |
| 存储 IO 争抢 | PV 挂载延迟 > 30s，CSI 操作排队 | 共享存储后端缺乏租户级 QoS，控制面 Attach/Detach 操作串行化 |
| 资源碎片与隔离失效 | 节点资源利用率不均，部分租户被“饿死” | 缺乏拓扑感知调度与租户级资源配额动态调整 |
关键数据： 在 200+ 节点、50+ 租户的生产集群中，未经优化的多租户环境平均 API 响应延迟是单租户场景的 6~12 倍，Pod 调度时延的 P99 可达 15s 以上。
1.2 瓶颈分析的价值
性能优化不是盲目调参，而是基于数据驱动的精准定位。瓶颈分析的价值体现在三个层面：
- 定位真实瓶颈： 区分控制面、数据面还是存储面，避免“头痛医脚”。例如，Pod 启动慢可能是调度器排队，也可能是 CNI 插件延迟。
- 量化优化收益： 通过基线指标（如 API 延迟 P99、调度吞吐量、网络带宽）对比优化前后的效果，避免主观判断。
- 建立可复用的优化模式： 将瓶颈分析流程固化为工具链（如压测脚本、监控看板、Profiling 工具），使每个租户都能自助诊断。
实践建议： 在开始任何优化前，先建立集群的“性能基线仪表盘”。推荐使用 Prometheus + Grafana 采集 API Server 延迟、etcd 磁盘 IO、调度器队列深度、节点资源碎片率等核心指标。
1.3 课程目标与学习路径
本课程旨在培养学员具备以下核心能力：
- 诊断能力： 熟练使用 K8s 性能诊断工具（如 kube-state-metrics、etcdctl、pprof、tcpdump）定位多租户场景下的性能瓶颈。
- 优化能力： 掌握控制面、调度、网络、存储四大维度的优化技术，包括 API Server 限流调优、调度器配置、CNI 选择、CSI QoS 等。
- 架构能力： 能够设计适合多租户的 K8s 集群架构，包括租户隔离策略、资源配额模型、监控告警体系。
课程分为四个阶段，循序渐进：
| 阶段 | 章节范围 | 核心产出 |
|---|---|---|
| 基础篇 | 第 1~5 章 | 掌握多租户性能模型与瓶颈分析工具链 |
| 控制面优化 | 第 6~12 章 | API Server、etcd、调度器性能调优 |
| 数据面优化 | 第 13~22 章 | 网络、存储、运行时性能优化 |
| 实战与架构 | 第 23~30 章 | 多租户集群架构设计、压测与持续优化 |
学习前提： 本课程要求学员具备 K8s 基础操作能力（kubectl、Pod/Service/Deployment 概念），并了解 Linux 性能分析基础（CPU、内存、IO、网络）。建议提前准备一个至少 3 节点的 K8s 集群用于实验。