1. 课程导论：Cilium与eBPF背景、控制面架构故障排查的重要性、课程目标与受众
1.1 为什么是Cilium与eBPF？
云原生网络正从传统的“隧道封装+iptables”模式向“内核可编程+身份感知”模式演进。Cilium 基于 eBPF（extended Berkeley Packet Filter）技术，将网络策略的执行点从用户态下沉到内核态，实现了无代理（agentless）的服务网格与网络安全策略。eBPF 允许用户在 Linux 内核中安全地运行沙箱程序，而无需修改内核源码或加载内核模块。
核心优势： eBPF 带来的可观测性、安全性与性能提升，使得 Cilium 成为 Kubernetes 环境下 CNI（Container Network Interface）与网络策略的事实标准之一。
下表对比了传统网络策略方案与 Cilium eBPF 方案的关键差异：
| 维度 | 传统方案（iptables / Calico） | Cilium eBPF |
|---|---|---|
| 策略执行点 | 用户态 iptables 规则链 | 内核态 eBPF 程序（XDP / TC hook） |
| 性能开销 | 规则数量增加时线性下降 | O(1) 哈希查找，规则数量影响极小 |
| 可见性 | 依赖 conntrack 与日志 | 原生支持 L3/L4/L7 可观测性 |
| 身份标识 | 基于 IP/CIDR | 基于 Kubernetes 标签与安全身份（Security Identity） |
| 故障排查工具 | iptables -L / tcpdump | cilium monitor / hubble / bpftrace |
1.2 控制面架构故障排查的重要性
在 Kubernetes 集群中，控制面组件（kube-apiserver、etcd、kube-controller-manager、kube-scheduler）是集群的“大脑”。Cilium 作为数据面组件，其网络策略的正确下发与执行高度依赖控制面的健康状态。当控制面出现故障时，Cilium 可能面临：
- 策略同步失败： Cilium Agent 无法从 kube-apiserver 获取最新的 CiliumNetworkPolicy CRD。
- 身份映射混乱： etcd 中存储的安全身份（Security Identity）与节点本地缓存不一致。
- 端点（Endpoint）状态漂移： 控制面与数据面之间的心跳超时，导致策略应用滞后。
- Hubble 可观测性中断： Hubble Relay 依赖控制面进行流量聚合与策略审计。
工程痛点： 许多运维团队在排查网络策略问题时，往往只关注数据面（如丢包、延迟），而忽略了控制面故障才是根因。本课程将系统性地建立“控制面→数据面”的故障排查思维。
1.3 课程目标与受众
本课程面向以下受众，提供从原理到实战的完整知识体系：
| 受众角色 | 核心痛点 | 课程收益 |
|---|---|---|
| 云原生 SRE | 集群网络策略故障定位慢、影响面大 | 掌握 Cilium 控制面故障的快速诊断与恢复方法 |
| 平台架构师 | 需要设计高可用的 Cilium 网络策略体系 | 理解控制面架构瓶颈与 eBPF 策略执行原理 |
| K8s 运维工程师 | 对 Cilium 内部机制不熟悉，排查无从下手 | 学会使用 cilium CLI、hubble、bpftrace 等工具链 |
| 安全工程师 | 需要验证网络策略是否被正确执行 | 掌握策略审计与控制面一致性校验方法 |
1.4 Cilium 控制面与数据面交互架构
下图展示了 Cilium 在 Kubernetes 集群中的核心组件及其交互关系，重点标注了控制面故障可能影响的路径：
1.5 课程内容概览
本课程共 30 章，分为以下五大模块：
- 基础篇（第 1-5 章）： Cilium 与 eBPF 原理、控制面架构详解、网络策略模型。
- 工具篇（第 6-10 章）： cilium CLI、Hubble、bpftrace、kubectl 插件等排查工具实战。
- 故障场景篇（第 11-20 章）： 控制面故障模拟与排查，包括 etcd 性能瓶颈、apiserver 限流、Agent 崩溃、身份缓存不一致等。
- 策略审计篇（第 21-25 章）： 网络策略一致性校验、安全身份审计、L7 策略验证。
- 进阶篇（第 26-30 章）： 大规模集群优化、多集群策略同步、生产环境最佳实践。
学习建议： 建议读者在本地或测试集群中搭建一套 Cilium 环境（推荐使用 kind 或 minikube），跟随每章的故障模拟步骤进行实操，以加深对控制面故障排查的理解。