📚 课程目录第1章课程导论

1. 课程导论：CAPI与准入控制协同优化集群容量的背景、目标与整体架构概览

在云原生基础设施大规模普及的今天，Kubernetes 集群的容量管理面临三大核心挑战：

资源碎片化：多租户、多工作负载场景下，节点资源利用率不均，导致大量预留但未使用的“空洞”。
扩缩容滞后：Cluster API (CAPI) 管理的声明式集群生命周期，在节点创建/销毁周期内，工作负载可能因资源不足而 pending。
准入策略脱节：传统的 Mutating/Validating Admission Webhook 仅关注 Pod 级别的合规性（如镜像来源、资源配额），缺乏对集群整体容量拓扑的感知。

这种脱节导致运维团队往往需要手动“修补”集群容量：先通过 CAPI 扩容节点池，再等待节点就绪，最后重新调度 Pod。整个过程缺乏自动化闭环，且容易引发资源争抢或过度供给。

  核心痛点：CAPI 负责“造车”（节点），准入控制负责“验票”（Pod），但两者之间缺少一个“交通调度员”来实时匹配车辆与乘客，避免空车跑或乘客滞留。

本课程旨在构建一套 CAPI + 准入控制协同框架，实现以下四个关键目标：

目标维度	具体描述	关键指标
容量感知	准入控制能够实时查询 CAPI 管理的集群节点池状态、剩余资源及扩容进度	节点就绪延迟 < 30s
智能调度	根据集群容量水位，动态调整 Pod 调度策略，优先填充已有节点，避免盲目扩容	节点平均利用率提升 15%
预扩容触发	当准入控制检测到资源不足时，自动向 CAPI 发起扩容请求，并缓存待调度 Pod	扩容触发延迟 < 5s
策略闭环	扩容完成后，自动重试准入检查，确保 Pod 顺利绑定到新节点	端到端调度成功率 > 99.9%

下图展示了协同框架的核心组件与数据流。该架构在标准 Kubernetes 控制面中新增了一个 Capacity-Aware Admission Controller，作为 CAPI 与现有准入链之间的桥梁。

协同框架由以下五个核心模块组成，每个模块承担明确的职责：

容量感知准入控制器：作为协同中枢，拦截 Pod 创建请求，实时评估集群容量水位，并决定是否触发扩容。
CAPI 状态缓存：维护集群内所有 Machine、MachineSet、Cluster 对象的资源拓扑，减少对 API Server 的实时查询压力。
扩容触发器：当准入控制器判定资源不足时，生成 CAPI Machine 扩容模板，并通过 CAPI 客户端发起创建请求。
待调度队列：暂存因资源不足而 pending 的 Pod，等待节点就绪后重新注入准入链。
策略引擎：定义协同规则，例如“当节点利用率超过 80% 时触发预扩容”、“优先扩容 spot 实例池”等。

设计原则：所有协同逻辑均以 AdmissionReview 的形式运行，不修改 kube-scheduler 或 kube-controller-manager 的默认行为，保证与上游 Kubernetes 版本的兼容性。

维度	传统方案（手动/分离）	本课程协同方案
扩容触发	依赖监控告警（Prometheus + Alertmanager），延迟 1-5 分钟	准入控制实时检测，延迟 < 5s
资源感知	调度器仅感知已分配资源，不感知节点池容量	准入控制器感知 CAPI 管理的节点池总量与可用量
Pod 处理	Pod 进入 Pending 状态，等待调度器周期性重试	Pod 暂存于待调度队列，节点就绪后立即重试
策略灵活性	硬编码在 Cluster Autoscaler 或自定义脚本中	通过策略引擎动态配置，支持多集群差异化
运维复杂度	需要维护多套系统（监控、扩缩容、调度）的联动	统一在准入控制层完成协同，降低运维心智负担

本课程共 30 章，分为四个阶段：

前置要求：学习者需具备 Kubernetes 核心概念（Pod、Node、Controller）、Go 语言基础以及 Cluster API 的基本使用经验。建议先完成 CAPI 官方 Quickstart 教程。