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

1. 课程导论：eBPF租户隔离的背景与挑战，控制平面资源模型的核心概念

1.1 为什么需要eBPF租户隔离？

在云原生与微服务架构中，多个租户（Tenant）共享同一套内核基础设施。传统基于Namespace/Cgroup的隔离方案在可观测性、安全策略与网络性能方面存在显著短板。eBPF（extended Berkeley Packet Filter）凭借其在内核中的安全沙箱执行能力，为租户隔离提供了全新的技术路径——但同时也引入了控制平面资源模型设计的复杂性。

核心矛盾： eBPF程序运行在内核空间，不同租户的eBPF程序可能共享同一套Map、Hook点与Perf Event缓冲区。如何在不牺牲性能的前提下，确保租户间的资源隔离、安全隔离与故障隔离，是控制平面设计的第一性原理。

1.2 租户隔离面临的关键挑战

从生产环境实践来看，eBPF租户隔离主要面临以下四大挑战：

挑战维度	具体问题	影响范围
资源竞争	eBPF Map、Perf Buffer、BPF程序数量等内核资源被所有租户共享，缺乏配额机制	性能抖动、OOM、程序加载失败
安全边界	Helper函数权限、Map访问控制、Kprobe/Tracepoint注入点缺乏租户级鉴权	数据泄露、内核提权、拒绝服务
故障爆炸半径	单个租户的eBPF程序崩溃或死循环可能影响整个宿主机的内核稳定性	全局宕机、其他租户业务中断
可观测性盲区	无法区分某个eBPF事件或Map操作来自哪个租户，排障与计费困难	运维复杂度高、成本分摊不透明

生产教训： 某头部云厂商在早期eBPF多租户实践中，因未对Map进行租户级隔离，导致一个租户的恶意程序通过共享Map读取了另一个租户的网络流量元数据。此后，该厂商将“Map命名空间化”列为控制平面的强制要求。

1.3 控制平面资源模型的核心概念

控制平面资源模型（Control Plane Resource Model）是eBPF租户隔离的“骨架”。它定义了如何将内核中的eBPF资源抽象为可管理、可配额、可审计的逻辑单元。核心概念包括：

资源域（Resource Domain）： 每个租户拥有独立的资源域，域内包含该租户所有的eBPF程序、Map、Perf Event等资源。域之间默认不可见、不可访问。
配额池（Quota Pool）： 对每个资源域设置硬性上限，如最大Map大小、最大程序数量、最大指令数、最大Perf Event频率等。超出配额的操作被内核拒绝。
标签与元数据（Label & Metadata）： 每个eBPF资源在创建时被注入租户ID、应用ID、环境标签等元数据，用于审计、计费与排障。
策略引擎（Policy Engine）： 控制平面核心组件，负责在eBPF程序加载、Map访问、Helper调用等关键路径上执行租户级鉴权与配额检查。

下图展示了控制平面资源模型在eBPF多租户架构中的位置与核心组件关系：

1.4 资源模型选型的核心维度

在构建eBPF租户隔离控制平面时，资源模型选型需要从以下四个维度进行权衡：

选型维度	关键考量	典型方案
隔离粒度	按进程、容器、Pod还是用户组隔离？粒度越细，控制平面开销越大	进程级（PID命名空间）、容器级（Cgroup）、Pod级（K8s标签）
资源配额模型	静态配额 vs 动态配额？是否支持超卖？	固定配额池、弹性配额池、基于信用度的动态配额
安全策略执行点	在eBPF加载时检查，还是在运行时检查？	加载时静态检查、运行时Hook拦截、混合模式
可观测性集成	是否支持租户级Metrics、Tracing与审计日志？	Prometheus标签注入、OpenTelemetry上下文传播、结构化审计日志

实践建议： 在Kubernetes环境中，推荐以Pod为最小隔离单元，利用Pod的UID作为租户ID注入eBPF资源元数据。控制平面通过CRD（Custom Resource Definition）定义租户配额策略，实现声明式管理。

1.5 课程路线图

本课程将围绕以下主线展开：

基础篇： 深入eBPF资源模型的内核实现（Map、Program、Perf Event、BTF）
设计篇： 对比分析三种主流控制平面资源模型（命名空间模型、标签模型、混合模型）
实现篇： 基于Cilium、Falco、Pixie等开源项目的隔离方案源码剖析
实践篇： 从零构建一个支持多租户的eBPF控制平面原型
进阶篇： 大规模集群下的性能优化、故障注入与混沌工程验证

通过本课程，你将掌握eBPF租户隔离的核心设计模式，能够根据业务场景选择或定制合适的控制平面资源模型。