4. 控制平面架构设计：控制平面与数据平面分离原则、控制平面组件与通信协议选择

在 eBPF 租户隔离系统中，控制平面与数据平面的严格分离是保障多租户安全、可扩展性与可维护性的核心架构原则。控制平面负责策略下发、状态收集与配置管理，而数据平面专注于高性能包处理与隔离执行。本章详细阐述分离原则、核心组件设计以及通信协议的选择依据。

4.1 控制平面与数据平面分离原则

分离原则的核心在于：数据平面不执行任何策略决策，仅根据控制平面下发的指令集进行无状态或轻状态转发与过滤。这种架构带来以下关键优势：

• 安全隔离：控制平面的故障或攻击不会直接影响数据平面的转发路径，反之亦然。
• 独立扩展：数据平面可针对吞吐量进行水平扩展，控制平面可针对租户数量与策略复杂度进行垂直扩展。
• 策略热更新：控制平面可在不中断数据流的情况下，通过原子化 eBPF Map 更新或程序替换来变更策略。
• 可审计性：所有策略变更均通过控制平面记录，数据平面仅执行最终状态。

4.2 控制平面核心组件

控制平面由三个核心组件构成，形成清晰的职责链：API Server → Controller → Agent。每个组件承担特定的功能边界。

4.3 通信协议选择：gRPC vs Netlink

控制平面组件间的通信协议选择直接影响系统的性能、安全性与可维护性。以下从多个维度对比 gRPC 与 Netlink：

4.3.1 推荐通信架构

基于上述对比，推荐采用混合通信模型：

• 南北向通信（API Server ↔ Controller ↔ Agent）：使用 gRPC。理由：跨节点部署、需要强类型接口定义、支持双向流式推送策略变更、mTLS 提供租户级认证。
• 本地通信（Agent ↔ 内核 eBPF）：使用 Netlink。理由：Agent 与内核同节点，Netlink 提供最低延迟的 eBPF 程序加载与 Map 操作接口，且无需额外序列化开销。

4.3.2 gRPC 服务定义示例

以下是一个简化的 gRPC 服务定义，用于 Controller 与 Agent 之间的策略下发：

syntax = "proto3";

package ebpf.tenant.isolation;

service PolicyService {
    // Controller 向 Agent 下发租户隔离策略
    rpc ApplyPolicy(PolicyRequest) returns (PolicyResponse);

    // Agent 向 Controller 实时上报策略执行状态
    rpc ReportStatus(stream StatusReport) returns (StatusAck);

    // Controller 订阅 Agent 的本地事件
    rpc WatchEvents(EventFilter) returns (stream Event);
}

message PolicyRequest {
    string tenant_id = 1;
    string policy_id = 2;
    bytes bpf_program = 3;       // 编译后的 eBPF 字节码
    map<string, bytes> map_config = 4;  // 初始 Map 键值对
    repeated string capabilities = 5;   // 所需内核能力
}

message PolicyResponse {
    bool success = 1;
    string error_message = 2;
    uint64 program_id = 3;       // 内核中的程序 ID
}

4.4 通信安全与权限配置

控制平面通信的安全性直接决定租户隔离的强度。以下是关键配置原则：

• mTLS 双向认证：所有 gRPC 通信必须启用双向 TLS 证书认证，API Server、Controller、Agent 各自持有由集群 CA 签发的身份证书。
• 租户 注入：API Server 在接收租户请求时，通过 JWT 或 OAuth2 提取租户身份，并将其注入到 gRPC 元数据中，确保策略始终与租户绑定。
• Netlink 权限最小化：Agent 进程在启动时持有 CAP_NET_ADMIN，完成 eBPF 程序加载后，通过 prctl(PR_CAP_AMBIENT) 或 seccomp 限制后续系统调用。
• 审计日志：所有控制平面操作（策略创建、更新、删除、Agent 注册）必须记录审计日志，包含租户 ID、操作时间、操作结果。