1. 课程导论：为什么集群升级需要巡检 eBPF 节点池？Hubble 流量基线对比的核心价值
1.1 集群升级的“黑盒”困境
Kubernetes 集群升级（尤其是控制面与数据面分离升级）历来是运维风险最高的操作之一。传统升级流程依赖 Pod 启动状态、节点 Ready 状态 和 API Server 响应 等粗粒度指标来判断升级是否成功。然而，这些指标无法感知数据面网络策略、服务路由、DNS 解析等关键路径的细微变化。
典型事故场景： 某团队升级节点内核后，所有节点状态正常，但 Cilium 的 eBPF 程序因内核 API 变更导致
bpf_skb_load_bytes 调用偏移错误，造成 30% 的 Service 流量被静默丢弃，监控面板无任何告警，直到用户反馈超时才被发现。
eBPF 节点池（Cilium Agent 所在节点组）是集群数据面的核心载体。升级过程中，内核版本、eBPF 辅助函数、cgroup v2 挂载点、BPF 文件系统等底层依赖可能发生不兼容变更。仅靠“进程存活”或“接口 UP”无法发现这类静默故障。
1.2 为什么需要巡检 eBPF 节点池？
eBPF 节点池巡检的核心目标是在升级前后对数据面进行 逐节点、逐路径、逐策略 的验证。与传统节点健康检查相比，eBPF 巡检关注以下维度：
| 维度 | 传统检查 | eBPF 节点池巡检 |
|---|---|---|
| 内核兼容性 | 检查内核版本号 | 验证 eBPF 辅助函数可用性、BTF 信息完整性、BPF 程序加载成功率 |
| 网络连通性 | Pod 间 ICMP ping | 验证 L3/L4/L7 策略命中、NAT 转换、封装/解封装路径 |
| 服务路由 | ClusterIP 可达 | 验证 eBPF 尾调用链、BPF 哈希表查找、后端端点一致性 |
| 可观测性 | Metrics 聚合面板 | 验证 Hubble 流事件完整性、TCP 标志位序列、DNS 响应码分布 |
通过巡检，运维团队可以在升级前建立 节点池基线，升级后对比基线，快速定位异常节点并回滚或修复。
1.3 Hubble 流量基线对比的核心价值
Hubble 是 Cilium 原生的 eBPF 可观测性层，能够以 每个数据包、每个流、每个 TCP 连接 的粒度捕获网络事件。在集群升级场景中，Hubble 流量基线对比提供了以下不可替代的能力：
- 全量流事件捕获：Hubble 通过 eBPF 程序在内核中直接捕获网络事件，不依赖 iptables 日志或 sidecar 代理，覆盖所有节点上的所有 Pod 流量。
- 多维聚合对比：支持按 源/目的 Pod、Service、TCP 标志位、DNS 域名、HTTP 方法/路径 等维度聚合流量基线。
- 异常检测灵敏度：能够发现 TCP 重传率上升、DNS 解析失败率增加、HTTP 5xx 比例突变 等微小的流量特征变化，这些变化在传统监控中往往被平均延迟掩盖。
- 节点级隔离分析：Hubble 的
node_name标签允许按节点池粒度过滤流量，升级前后对比可以精确到 哪个节点 的 哪个 eBPF 程序 出现了问题。
核心价值总结： Hubble 流量基线对比将集群升级验证从“黑盒状态检查”升级为“白盒流量审计”，使运维团队能够在升级后 分钟级 发现数据面异常，避免大规模故障扩散。
1.4 升级前后流量基线对比流程
下图展示了集群升级过程中，基于 Hubble 的 eBPF 节点池巡检与流量基线对比的完整工作流：
1.5 课程内容概览
本课程将围绕以下知识体系展开，帮助学员掌握从理论到实战的完整技能：
| 模块 | 核心内容 | 实战产出 |
|---|---|---|
| eBPF 节点池巡检原理 | Cilium Agent 生命周期、eBPF 程序加载验证、内核兼容性检测 | 巡检脚本框架 |
| Hubble 流量基线采集 | Hubble 流事件格式、hubble observe CLI、流量聚合策略 | 基线采集 Pipeline |
| 基线对比算法 | 统计假设检验、百分比偏差、异常阈值设计 | 对比分析模块 |
| 自动化巡检集成 | 与 Argo Rollouts / Flagger 集成、升级前准入检查 | GitOps 集成方案 |
| 故障排查案例 | eBPF 辅助函数缺失、Hubble 流丢失、策略冲突 | 排障决策树 |
学习建议： 建议学员在实验环境中准备一个至少 3 节点的 Cilium 集群（v1.14+），并开启 Hubble 中继与 Hubble UI，以便跟随课程进行流量基线采集与对比实操。