1. 课程导论：Helm 与 Kubernetes 调度概述、课程目标与受众、性能调优的核心挑战
1.1 Helm 与 Kubernetes 调度：从包管理到资源博弈
在云原生生态中，Kubernetes 作为容器编排的事实标准，其核心职责是将 Pod 调度到最合适的 Node 上运行。而 Helm 作为 Kubernetes 的包管理器，通过 Chart 将一组相关的 Kubernetes 资源（Deployment、Service、ConfigMap 等）打包、配置并部署。当 Helm 执行 helm install 或 helm upgrade 时，它本质上是在向 API Server 提交一组资源声明，这些声明随后触发调度器的决策过程。
Helm 与调度器的交互并非简单的“提交-执行”关系，而是一场复杂的资源博弈：
- 批量提交：Helm Chart 可能一次性创建数十个 Pod，瞬间压入调度队列。
- 依赖顺序：Helm Hooks 和资源依赖可能导致调度器面临“先有鸡还是先有蛋”的阻塞问题。
- 资源模板化：Helm 的
values.yaml动态注入的资源请求（Requests/Limits）直接影响调度器的节点打分与过滤。 - 版本回滚：Helm 的版本管理机制在回滚时可能引发资源残留与调度冲突。
核心认知：Helm 不是调度器的替代品，而是调度事件的“放大器”。一个配置不当的 Helm Chart 可能将调度器的性能瓶颈放大 10 倍甚至 100 倍。
1.2 课程目标与受众
本课程旨在帮助学员掌握在 Helm 架构下，如何诊断、分析并优化 Kubernetes 集群的资源调度性能。课程覆盖从理论到实战的全链路调优方法。
| 维度 | 详细说明 |
|---|---|
| 课程目标 |
|
| 目标受众 |
|
| 前置知识 |
|
1.3 性能调优的核心挑战
在 Helm 架构下进行调度性能调优，面临三大核心挑战：调度延迟、资源碎片 与 大规模并发。这三者相互影响，形成复杂的性能三角。
1.4 挑战详解与 Helm 的放大效应
下表详细拆解三大挑战在 Helm 场景下的具体表现：
| 核心挑战 | Kubernetes 原生表现 | Helm 架构下的放大效应 |
|---|---|---|
| 调度延迟 | Pod 在调度队列中等待；调度器执行 Filter & Score 耗时 | Helm 批量创建 Pod 时，调度队列瞬间积压；helm upgrade 触发滚动更新导致 Pod 频繁重建与重新调度 |
| 资源碎片 | 节点上 CPU/Memory 碎片化，无法容纳新 Pod | Helm Chart 中固定的资源 Requests 缺乏弹性，导致节点资源分配不均；回滚操作遗留的旧 Pod 资源未及时释放 |
| 大规模并发 | 调度器吞吐量有限（默认约 10 Pods/s） | Helm 在 CI/CD 流水线中同时部署多个 Chart，产生“部署风暴”；Helm Hooks 中的 Job 可能阻塞后续 Pod 调度 |
常见误区：很多团队认为调度性能只是 K8s 调度器的问题，忽略了 Helm 作为“部署触发器”的角色。实际上，一个未经优化的 Helm Chart 可能包含大量隐性的调度反模式，例如：所有 Pod 使用相同的
nodeSelector、缺乏 Pod 拓扑分布约束、资源 Requests 设置过高或过低。
1.5 课程路线图：从诊断到优化
本课程将按照以下逻辑主线展开，帮助学员系统性地解决上述挑战：
- 基础篇（第 2-5 章）：深入 Helm 部署流程与调度器内部机制，建立性能基准。
- 诊断篇（第 6-12 章）：学习使用 Metrics Server、Prometheus、调度器 Profiling 以及 Helm 日志分析工具定位瓶颈。
- 优化篇（第 13-24 章）：从 Helm Chart 模板优化、资源声明策略、调度器配置调优、节点拓扑管理等多个维度进行实战调优。
- 实战篇（第 25-30 章）：通过大型案例（微服务全链路部署、大数据作业调度）综合运用所学知识。
课程承诺：每章均包含可复用的 Helm Chart 代码片段、调度策略 YAML 以及性能对比数据，确保学员能够“学完即用”。