3. 租户隔离需求分析：多租户场景下的安全边界、性能隔离、资源配额需求
在构建多租户 eBPF 控制平面时，隔离需求是架构设计的核心输入。不同租户共享同一套内核基础设施，但必须确保彼此不可见、不可干扰、不可超用。本章从安全边界、性能隔离、资源配额三个维度拆解隔离需求，为后续资源模型选型提供决策依据。
3.1 安全边界：内核级不可逾越的隔离墙
安全边界是租户隔离的底线。eBPF 程序运行在内核空间，一旦出现跨租户访问或权限逃逸，后果是全局性的。安全隔离需求可归纳为以下四个层次：
| 隔离层次 | 需求描述 | 威胁场景 |
|---|---|---|
| 数据平面隔离 | 租户 A 的 eBPF map 数据不能被租户 B 读取或篡改 | 恶意租户遍历共享 map 窃取流量元数据 |
| 程序加载隔离 | 租户只能加载经过审核的 eBPF 程序，且不能卸载其他租户的程序 | 租户注入非法字节码或删除关键观测程序 |
| 内核资源隔离 | eBPF 程序不能访问其他租户的进程内存、网络命名空间或文件系统 | 通过 bpf_probe_read 跨命名空间读取敏感数据 |
| 审计与追溯 | 所有 eBPF 操作必须关联到租户身份，支持审计日志 | 无法定位违规操作的来源租户 |
关键约束： 安全边界必须在 eBPF 验证器层面和用户态控制平面层面双重实施。仅依赖内核验证器不够，因为共享 map 和 prog array 可能成为跨租户攻击面。
3.2 性能隔离：避免“吵闹邻居”效应
在多租户场景下，一个租户的 eBPF 程序不应导致其他租户的观测延迟增加或吞吐下降。性能隔离需求聚焦于 CPU、内存和 I/O 三个维度：
- CPU 预算隔离： 每个租户的 eBPF 程序执行时间应受上限约束，防止长尾程序耗尽 CPU 时间片。典型需求：单次 eBPF 程序执行不超过 10μs，租户级 CPU 使用率不超过 5%。
- 内存使用隔离： map 大小、per-CPU 缓冲区、栈空间必须按租户独立核算。需求示例：租户 A 的 map 内存上限 64MB，租户 B 上限 128MB，互不抢占。
- 事件通知隔离： perf event array 或 ring buffer 的写入速率应受控，避免一个租户的突发流量淹没其他租户的事件消费通道。
实践建议： 在控制平面引入 eBPF 调度器或 cgroup 绑定，将每个租户的 eBPF 程序挂载到独立的 cgroup 层级中，利用 cgroup 的 CPU 和 memory 控制器实现硬隔离。
3.3 资源配额：可量化的分配与限制
资源配额是安全边界和性能隔离的落地手段。控制平面需要为每个租户定义明确的配额上限，并在运行时强制执行。核心配额项包括：
| 资源类型 | 配额指标 | 默认上限（参考） | 超限行为 |
|---|---|---|---|
| eBPF 程序 | 最大程序数量 | 100 | 拒绝加载新程序 |
| eBPF map | 最大 map 数量 / 总内存 | 50 个 / 256MB | map 创建失败 |
| 事件吞吐 | 每秒事件数 (EPS) | 100,000 EPS | 降级采样或丢弃 |
| 指令复杂度 | 单程序指令数 | 4096 条 | 验证器拒绝 |
| 并发 attach | 同时挂载点数量 | 20 | attach 失败 |
注意： 配额上限不能仅依赖内核的全局限制（如 rlimit memlock），必须由控制平面维护租户级别的配额计数器，并在用户态和内核态之间同步。否则，一个租户可以通过耗尽全局资源来影响其他租户。
3.4 隔离需求与资源模型的映射关系
不同的资源模型（如进程级、cgroup 级、命名空间级）对上述隔离需求的满足程度不同。下图展示了三种典型资源模型与隔离需求的覆盖关系：
3.5 需求优先级与选型决策框架
在实际项目中，安全边界、性能隔离、资源配额三者并非同等权重。根据典型多租户场景，建议按以下优先级排序：
- 安全边界（P0）： 不可妥协。任何跨租户数据泄露或权限逃逸都构成安全事件。资源模型必须提供内核级隔离能力。
- 资源配额（P1）： 防止单个租户滥用资源导致平台不可用。配额机制必须在控制平面和内核层同时生效。
- 性能隔离（P2）： 在满足安全和配额的前提下，尽可能减少吵闹邻居效应。可通过调度策略和 cgroup 限制优化。
选型决策提示： 如果租户数量 < 10 且信任度较高，可优先考虑 cgroup 级模型（性能隔离好）；如果租户数量 > 100 且存在不可信租户，必须选择命名空间级模型（安全边界强）。进程级模型仅推荐用于开发测试环境或单租户场景。