3. 租户隔离需求分析：多租户场景下的资源隔离、安全隔离、性能隔离与故障隔离需求
在构建多租户 eBPF 控制平面时，隔离需求是架构设计的核心驱动力。租户隔离不仅仅是“互不干扰”，而是需要在资源、安全、性能、故障四个维度上同时满足严格约束。本章从 eBPF 程序的生命周期与内核共享资源出发，逐一拆解四类隔离需求，并给出对应的架构设计目标。
3.1 四类隔离需求总览
下表从隔离目标、核心挑战、eBPF 特有风险三个维度对比四类隔离需求，为后续架构设计提供需求基线。
| 隔离类型 | 隔离目标 | 核心挑战 | eBPF 特有风险 |
|---|---|---|---|
| 资源隔离 | CPU、内存、Map 容量、指令预算 | 内核全局资源池无原生租户标签 | Map 共享导致内存泄漏跨租户；Tail Call 链耗尽指令数 |
| 安全隔离 | 数据访问、内核能力、程序加载 | eBPF 程序运行在内核态，绕过传统 LSM | Helper 函数滥用；Map 指针泄漏；未授权 kprobe/tracepoint |
| 性能隔离 | 延迟、吞吐、CPU 占比 | 事件触发型程序抢占内核路径 | 高频率 tracepoint 导致 CPU 抖动；Map 竞争锁 |
| 故障隔离 | 崩溃、死循环、OOM 不扩散 | eBPF 验证器无法完全防止逻辑炸弹 | 无限循环被验证器放行；Map 满导致拒绝服务 |
架构提示： 四类隔离并非独立存在。例如，资源隔离不足会直接引发性能隔离失效（CPU 争抢），安全隔离漏洞可能导致故障隔离被绕过（恶意程序故意触发 OOM）。控制平面必须设计统一的租户身份上下文，才能同时支撑四类隔离策略。
3.2 资源隔离需求
资源隔离要求每个租户的 eBPF 程序及其使用的内核资源（Map、Per-CPU 数据、辅助结构）在配额上互不侵占。核心需求包括：
- CPU 指令预算隔离： 每个租户每秒钟可执行的 eBPF 指令总数应受上限约束，防止单个租户通过高频率事件耗尽 CPU。
- Map 容量隔离： 每个租户创建的 Map 总大小（key+value 数量）应独立统计，避免一个租户填满全局 Map 内存导致其他租户分配失败。
- 程序加载配额： 控制每个租户可加载的程序数量与总字节数，防止恶意加载大量小程序耗尽内核 JIT 内存。
- Per-CPU 数据隔离： 使用 Per-CPU Map 时，每个租户的 CPU 本地副本应独立核算，避免跨租户数据残留。
关键指标： 资源隔离的验收标准通常为“单租户资源耗尽不影响其他租户的 eBPF 程序加载与运行”。例如，租户 A 填满其 Map 后，租户 B 仍能正常创建新 Map 并写入数据。
3.3 安全隔离需求
安全隔离是多租户 eBPF 场景中最敏感的维度。eBPF 程序运行在内核地址空间，一旦出现安全漏洞，影响范围是整个主机。安全隔离需求包括：
- 数据访问隔离： 租户只能读取/写入自己创建的 Map 和 Per-CPU 数据，禁止通过 Map ID 或指针访问其他租户的数据。
- Helper 函数权限隔离： 不同租户应被授予不同的 Helper 白名单。例如，普通租户禁止使用
bpf_probe_write_user或bpf_override_return等高危 Helper。 - 事件源隔离： 租户只能 attach 到被授权的 kprobe/tracepoint/cgroup 事件源，防止通过内核符号探测获取敏感信息。
- 程序替换与卸载隔离： 租户只能管理自己加载的程序，禁止卸载或替换其他租户的 eBPF 程序。
风险警示： 如果控制平面不强制 Map 归属检查，恶意租户可以通过
bpf_map_lookup_elem 传入其他租户的 Map FD（文件描述符）来窃取数据。控制平面必须在加载时绑定租户身份，并在每次 Map 操作时校验。
3.4 性能隔离需求
性能隔离确保每个租户的 eBPF 程序不会因其他租户的行为而出现不可预测的延迟或吞吐下降。需求分解如下：
- CPU 时间片隔离： 每个租户的 eBPF 程序总 CPU 消耗应被限制，避免一个租户的高频 tracepoint 抢占其他租户的调度时间。
- Map 操作延迟隔离： 使用 Per-CPU Map 或无锁 Map 时，应避免一个租户的长时间更新操作阻塞其他租户的读取。
- 事件处理优先级隔离： 关键租户（如网络监控）的事件处理应优先于非关键租户（如审计日志），通过 cgroup 或调度类实现。
- JIT 编译隔离： 租户程序的 JIT 编译过程不应影响其他租户的运行中程序，编译线程应使用独立 CPU 亲和性。
性能隔离的典型场景是：租户 A 部署了一个每秒触发 100 万次的 tracepoint 程序，租户 B 的网络延迟不能因此增加超过 5%。
3.5 故障隔离需求
故障隔离是最难实现的隔离类型，因为 eBPF 程序在内核态运行，一旦崩溃可能导致整个主机宕机。需求包括：
- 程序崩溃隔离： 单个 eBPF 程序因非法内存访问或验证器漏报导致的崩溃，不应影响其他租户的程序或内核稳定性。
- 死循环与超时隔离： 验证器无法完全检测所有循环场景，控制平面应设置看门狗（watchdog）机制，强制终止超时执行的程序。
- Map 满拒绝服务隔离： 一个租户的 Map 写满后，不应导致全局 Map 操作 hang 住；应返回 -E2BIG 并仅影响该租户。
- 控制平面崩溃恢复： 控制平面自身崩溃后，已加载的 eBPF 程序应继续运行，且恢复后能重新接管租户上下文。
架构提示： 故障隔离的最佳实践是“舱壁模式”（Bulkhead Pattern）——每个租户拥有独立的 eBPF 程序链表、Map 命名空间和错误处理回调。控制平面通过 per-tenant 的监控协程检测异常，并执行局部重置。
3.6 四类隔离的依赖关系与架构映射
四类隔离并非平行关系，而是存在明确的依赖链。下图展示了隔离需求之间的依赖关系以及对应的控制平面架构组件。
3.7 隔离需求对控制平面的设计约束
综合四类隔离需求，控制平面架构必须满足以下设计约束：
- 全局租户上下文： 所有 eBPF 程序、Map、事件源在加载时必须绑定租户 ID，且该 ID 在控制平面内全局唯一。
- per-tenant 资源记账： 控制平面必须维护每个租户的实时资源使用计数器（指令数、Map 容量、程序数量），并在达到阈值时拒绝新操作。
- 分层权限模型： 控制平面应实现“租户 → 角色 → 权限”三层模型，而非简单的 root/non-root 二元划分。
- 独立错误域： 每个租户的错误处理、日志记录、监控指标应完全隔离，避免一个租户的异常日志淹没另一个租户的关键告警。
- 可观测性不隔离： 控制平面自身的管理接口（如租户资源使用量查询）应不受租户隔离限制，以便运维人员全局排障。
架构决策： 上述约束直接决定了控制平面应采用“中心化租户注册 + 分布式执行引擎”的混合架构。租户注册与权限校验由中心控制面处理，而 eBPF 程序的加载、执行、监控由每个节点的 Agent 在本地完成，Agent 通过共享的租户上下文实现隔离。