1. 课程导论：为什么需要节点扩容？资源调度与容量规划的关系，课程目标与学习路径
1.1 为什么需要节点扩容？
在 Kubernetes 集群的日常运营中，节点扩容（Node Scaling）是最常见的运维操作之一。当集群现有工作节点无法承载 Pod 调度请求时，必须通过增加节点来恢复或提升集群容量。触发节点扩容的核心场景包括：
- 资源耗尽：节点 CPU、内存或本地存储使用率持续超过阈值（如 85%），导致 Pod 调度失败或 Eviction。
- 突发流量：业务高峰期（如电商大促、秒杀活动）导致 Deployment 副本数激增，现有节点无法容纳新增 Pod。
- 节点故障：部分节点因硬件故障、内核崩溃或网络分区变为 NotReady，剩余节点容量不足。
- 资源碎片化：长期运行后，节点上剩余资源碎片无法满足单个 Pod 的 Request，造成调度死锁。
- 合规与隔离：需要将特定工作负载（如 GPU 任务、敏感数据）调度到专用节点池，需新增节点。
关键指标：集群扩容的触发通常依赖
cluster-autoscaler 或自定义监控。当 Pending Pod 数量持续大于 0 且节点资源利用率超过预设水位线时，扩容流程自动启动。
1.2 资源调度与容量规划的关系
资源调度与容量规划是集群管理的两个核心维度，二者相互依赖、协同运作。下表梳理了它们的关键差异与协作点：
| 维度 | 资源调度（Resource Scheduling） | 容量规划（Capacity Planning） |
|---|---|---|
| 关注点 | Pod 与节点的匹配（Request/Limit、亲和性、污点容忍） | 集群整体资源供给与业务需求的中长期匹配 |
| 时间尺度 | 秒级 ~ 分钟级（实时调度决策） | 天级 ~ 月级（容量预测与预算） |
| 核心工具 | Scheduler、Descheduler、Node Affinity、Topology Spread | Cluster Autoscaler、VPA、成本分析、资源预留策略 |
| 失败后果 | Pod 调度失败、Pending、资源争抢 | 集群过载、扩容延迟、成本失控 |
| 协同点 | 调度器将 Pending Pod 信息反馈给 Autoscaler；容量规划为调度策略提供节点池水位上限 | |
在实际运维中，资源调度负责“如何把 Pod 放到合适的节点上”，而容量规划负责“何时需要增加节点以及增加多少”。两者通过 cluster-autoscaler 形成闭环：调度器发现无法调度 Pod → Autoscaler 触发扩容 → 新节点加入 → 调度器重新分配 Pod。
最佳实践：不要将容量规划视为一次性工作。建议每季度根据业务增长曲线、Pod 资源规格变化、节点利用率趋势重新评估节点池配置，避免“扩容滞后”或“过度预留”。
1.3 节点扩容的核心流程（SVG 图）
下图展示了从 Pod 调度失败到节点扩容完成的完整闭环流程，包含调度器、Autoscaler、云商 API 和节点注册四个关键阶段：
1.4 课程目标与学习路径
本课程旨在帮助学员建立从资源调度到容量规划的完整知识体系，掌握节点扩容的实战技能。课程分为四个模块：
- 基础篇（第 1-8 章）：理解 Kubernetes 调度原理、节点资源模型、Request/Limit 机制，以及
cluster-autoscaler的安装与配置。 - 策略篇（第 9-16 章）：深入节点池设计、污点与容忍、拓扑分布约束、PodDisruptionBudget 等高级调度策略。
- 容量篇（第 17-24 章）：容量预测模型、资源预留策略、成本优化、多集群容量管理。
- 实战篇（第 25-30 章）：基于真实业务场景的扩容演练、故障排查、性能调优与自动化运维。
前置要求：学员需具备 Kubernetes 基础操作能力（kubectl 常用命令、Pod/Deployment/Service 概念），了解 Linux 资源管理（cgroup、CPU/Memory 限制）。建议先完成《Kubernetes 入门与核心概念》课程。
通过本课程学习，你将能够：
- 独立设计并实施节点扩容方案，应对业务流量波动。
- 配置
cluster-autoscaler与自定义指标，实现自动化弹性伸缩。 - 分析集群资源碎片，优化调度策略以提升节点利用率。
- 制定容量规划模型，平衡成本与可用性。
1.5 课程核心概念关系（SVG 图）
下图展示了本课程涉及的三大核心概念——资源调度、容量规划、节点扩容——之间的依赖与协同关系：