1. 课程导论：节点池容量规划的重要性、eBPF观测的价值、Helm部署的优势
在云原生基础设施中，节点池（Node Pool）是集群资源调度的基本单元。容量规划直接决定集群的稳定性、成本与弹性效率。本课程将系统讲解如何利用 eBPF 技术实现细粒度观测，并通过 Helm 标准化部署观测栈，最终形成可复用的容量规划方法论。
1.1 节点池容量规划的重要性
节点池容量规划的核心目标是：在保证业务稳定性的前提下，最小化资源浪费与突发风险。规划不当会引发以下典型问题：
| 问题类型 | 表现 | 后果 |
|---|---|---|
| 资源过度预留 | 节点平均利用率 < 30% | 云成本浪费 2~3 倍 |
| 突发资源不足 | Pod 调度失败、OOMKill | 业务中断、SLA 违约 |
| 节点碎片化 | 大量小规格节点 | 管理开销大、调度效率低 |
| 扩缩容滞后 | Cluster Autoscaler 响应慢 | 流量高峰时 Pod 长时间 Pending |
关键指标： 生产环境建议将节点池平均利用率控制在 50%~70% 之间，同时保留 20%~30% 的突发缓冲容量。低于 40% 应缩容或合并节点池，高于 80% 需提前扩容。
1.2 eBPF 观测的价值
传统基于 cAdvisor 或 Prometheus 的指标采集存在两大短板：采样粒度粗（通常 15s~30s）和内核视角缺失（无法追踪系统调用、网络包路径、内存回收等）。eBPF 技术从根本上解决了这些问题：
- 零侵入：无需修改应用代码或重启进程，直接在内核态挂载观测点。
- 全栈可见：可观测 CPU 调度延迟、内存分配路径、磁盘 I/O 栈、网络数据包生命周期。
- 高精度：事件级采样，纳秒级时间戳，支持按进程、容器、cgroup 维度聚合。
- 安全可控：通过 BPF 验证器确保观测程序不会导致内核崩溃。
在节点池容量规划场景中，eBPF 能直接回答以下关键问题：
- 真实资源消耗：每个 Pod 的实际 CPU 使用量（含内核态）、内存工作集大小、网络吞吐。
- 资源争抢热点：哪些 Pod 在争抢 CPU 时间片、内存带宽或磁盘 IOPS。
- 内核开销分布：系统调用、软中断、内存回收等内核活动消耗了多少资源。
- 网络延迟瓶颈：从 Pod 网卡到宿主机协议栈再到对端的完整延迟分布。
实践建议： 在容量规划初期，优先使用 eBPF 观测工具（如 Cilium、Pixie、BCC）采集 7 天以上的基线数据，覆盖业务高低峰周期，避免基于短时快照做决策。
1.3 Helm 部署的优势
Helm 是 Kubernetes 生态中最成熟的包管理工具。在部署 eBPF 观测栈时，Helm 提供了以下不可替代的价值：
| 维度 | Helm 方案 | 原生 YAML 方案 |
|---|---|---|
| 配置管理 | values.yaml 集中管理，支持环境差异化覆盖 | 多份 YAML 文件，手动修改易出错 |
| 版本控制 | Chart 版本与 App 版本分离，支持回滚 | 无版本概念，回滚需手动恢复 |
| 依赖管理 | 自动处理 CRD、RBAC、DaemonSet 等依赖关系 | 需手动确认安装顺序 |
| 升级策略 | 支持 pre-upgrade/post-upgrade hook，可灰度 | kubectl apply 全量覆盖，风险高 |
| 多集群部署 | 同一 Chart 通过不同 values 部署到多集群 | 需维护多套 YAML 目录 |
本课程将使用 Helm 部署以下 eBPF 观测组件：
- Cilium：提供网络观测、Service Mesh 与安全策略。
- Pixie：提供无埋点的 Pod 级性能剖析与分布式追踪。
- Hubble：Cilium 的可观测性子项目，展示网络流与依赖关系。
- Node Exporter + eBPF 插件：采集宿主机级内核指标。
注意： eBPF 观测组件通常需要以 DaemonSet 形式运行在每个节点上，且要求内核版本 ≥ 4.19（推荐 5.10+）。在部署前务必确认节点内核版本，避免因兼容性问题导致观测数据缺失。
1.4 整体架构概览
下图展示了本课程所构建的节点池容量规划观测体系的核心组件与数据流：
1.5 课程学习路径
本课程共 30 章，分为四个阶段：
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第 1~8 章 | 节点池容量模型、eBPF 原理、Helm 基础、观测指标设计 |
| 部署篇 | 第 9~16 章 | Cilium/Hubble/Pixie 的 Helm 部署、配置调优、多集群管理 |
| 分析篇 | 第 17~24 章 | eBPF 数据采集、指标聚合、容量预测模型、异常检测 |
| 实战篇 | 第 25~30 章 | 真实案例：电商大促容量规划、成本优化、自动化扩缩容策略 |
前置要求： 建议读者具备 Kubernetes 基础操作能力（kubectl、Pod/Deployment/Service 概念），了解 Linux 内核基础（进程、内存、网络栈）。无需 eBPF 或 Helm 经验，课程将从零开始讲解。