1. 课程导论：eBPF与K8s网络策略的关系、课程目标与受众、整体技术栈概览
1.1 为什么需要eBPF + K8s网络策略？
Kubernetes 网络策略（NetworkPolicy）是集群内微服务间流量管控的声明式标准，但在生产环境中长期面临三大痛点：
- 性能瓶颈：传统 iptables/IPVS 规则链在节点 Pod 数量超过 500 时，规则更新延迟可达秒级，且占用大量 CPU。
- 可观测性缺失：策略生效后，运维人员难以快速定位“哪个 Pod 被哪条策略拒绝”，排障依赖抓包和日志。
- 配置复杂度：大规模集群中，人工维护数百条 NetworkPolicy 极易出错，缺乏自动化校验与分发机制。
eBPF（extended Berkeley Packet Filter）作为 Linux 内核的沙箱运行时，允许在无需修改内核代码或加载内核模块的前提下，安全高效地注入自定义程序。将 eBPF 引入 K8s 网络策略领域，能够实现：
- 微秒级策略生效：eBPF 程序直接挂载在 XDP/TC 钩子点，规则更新无需重建连接。
- 原生可观测性：通过 eBPF Map 实时导出丢包/拒绝事件，与 Prometheus 无缝集成。
- 策略即代码：将 NetworkPolicy 编译为 eBPF 字节码，通过制品仓库进行版本管理与自动化部署。
核心洞察：eBPF 不是替代 K8s 网络策略，而是为其提供“内核级执行引擎”与“可编程观测层”。本课程将围绕“eBPF 制品库”这一中间件，打通从策略编写、编译、存储到集群分发的全自动化链路。
1.2 课程目标与受众
| 维度 | 详细说明 |
|---|---|
| 课程目标 |
|
| 目标受众 |
|
| 前置知识 |
|
1.3 整体技术栈概览
本课程涉及的核心组件及其职责如下表所示：
| 层级 | 组件 | 职责 | 关键技术点 |
|---|---|---|---|
| 策略定义层 | K8s NetworkPolicy API | 声明式策略模型（ingress/egress/podSelector/namespaceSelector） | YAML 编写、策略冲突检测 |
| 策略编译器 | 将 NetworkPolicy 转换为 eBPF 中间表示（IR） | bpftrace、libbpf、CO-RE（一次编译到处运行） | |
| 执行引擎层 | eBPF 运行时（Cilium Agent） | 加载/卸载 eBPF 程序，维护 BPF Map（策略表、连接跟踪表） | XDP 钩子、TC 钩子、cgroup/skb 绑定 |
| Linux 内核 eBPF 子系统 | 验证器（Verifier）、JIT 编译、BPF Map 操作 | 指令数限制、辅助函数调用、尾调用 | |
| 制品管理层 | OCI 制品仓库（Harbor） | 存储 eBPF 字节码（.o 文件）、策略元数据（JSON）、签名信息 | OCI Artifact Manifest、Referrers API |
| 策略同步控制器 | 监听仓库变化，通过 CRD 将策略分发到目标集群 | K8s Operator 模式、Webhook 校验 | |
| 可观测性层 | Prometheus + Grafana | 采集 eBPF 导出的指标（策略命中数、拒绝数、延迟） | BPF Perf Event、kprobe/tracepoint 埋点 |
1.4 课程核心流程
本课程将带领学员完成以下端到端自动化流程：
- 编写策略：使用标准 K8s NetworkPolicy YAML 定义微服务间访问规则。
- 编译为 eBPF：通过策略编译器（基于 Cilium 的 bpf-next）将 YAML 转换为 eBPF 字节码，并生成 CO-RE 兼容的 .o 文件。
- 推送至制品库：将字节码、策略元数据（名称、命名空间、标签选择器）打包为 OCI 制品，推送到 Harbor。
- 集群同步：策略同步 Controller 监听仓库中特定 Tag 或 Digest 变化，通过 CRD 将策略下发到目标集群。
- 加载执行：Cilium Agent 接收 CRD 事件，调用 libbpf 加载 eBPF 程序到内核 XDP/TC 钩子，并更新 BPF Map。
- 观测与告警：eBPF 程序通过 Perf Event 输出拒绝事件，Prometheus 采集后由 Grafana 展示，异常时触发告警。
课程亮点：本课程不依赖任何商业产品，全部基于开源组件（Cilium、Harbor、Prometheus、Grafana）构建。学员将获得一套可直接用于生产环境的“策略即制品”自动化流水线。
1.5 为什么选择 eBPF 制品库模式？
传统 NetworkPolicy 配置方式（直接 kubectl apply）与 eBPF 制品库模式的对比如下：
| 对比维度 | 传统方式（kubectl apply） | eBPF 制品库模式 |
|---|---|---|
| 策略生效速度 | 依赖 kube-controller-manager 同步，平均 1-3s | eBPF 程序热加载，微秒级生效 |
| 版本管理 | 依赖 Git 仓库，无二进制版本追踪 | OCI 制品天然支持版本、签名、依赖管理 |
| 回滚能力 | 需重新 apply 旧 YAML，可能残留规则 | 通过制品 Tag 回滚，原子性卸载旧程序 |
| 可观测性 | 仅 API Server 事件，无内核级数据 | eBPF 导出连接统计、拒绝原因、延迟直方图 |
| 跨集群分发 | 需手动或 CI 脚本逐个集群 apply | Controller 自动同步，支持多集群策略一致性 |
注意：eBPF 制品库模式虽然优势明显，但需要集群内核版本 ≥ 5.10（推荐 5.15+）以支持 CO-RE 和 BPF 链接（bpf_link）。本课程所有实验环境将基于 Ubuntu 22.04 + Kernel 5.15 构建。