3. NetPolicy 架构总览：整体架构图、核心组件与数据/控制平面分离设计
NetPolicy 作为专为多租户签名链路设计的网络隔离引擎，其架构遵循云原生社区最佳实践，严格分离控制平面与数据平面。本章将拆解整体架构、核心组件职责以及平面分离的设计原理，帮助你在后续章节中快速定位每个功能模块。
3.1 整体架构图
下图展示了 NetPolicy 在 Kubernetes 集群中的部署形态与组件关系。控制平面运行在管理集群或命名空间内，数据平面以 DaemonSet 形式驻留在每个工作节点上，两者通过 gRPC 与事件机制通信。
3.2 核心组件详解
NetPolicy 由三个核心组件构成：API Server、Controller 和 Agent。每个组件承担明确的职责边界，共同实现签名链路的网络隔离。
| 组件 | 部署形态 | 核心职责 | 关键接口 |
|---|---|---|---|
| API Server | Deployment (1~3 副本) | 策略 CRD 注册、签名请求验证、租户身份认证 | RESTful API / Webhook |
| Controller | Deployment (1 主多备) | 策略编排、签名校验、审计日志、租户资源映射 | gRPC Server / Event Watcher |
| Agent | DaemonSet (每节点 1 Pod) | 本地策略缓存、eBPF/iptables 规则下发、签名验证 | gRPC Client / Netlink |
3.2.1 API Server — 策略入口与身份网关
API Server 是 NetPolicy 的北向接口，负责接收来自运维人员或 CI/CD 系统的策略声明。它扩展了 Kubernetes 原生 API，通过 CRD 定义 SignaturePolicy 和 NetworkIsolation 资源。
- CRD 注册：启动时自动注册
signaturepolicies.netpolicy.io和networkisolations.netpolicy.io。 - 签名验证：接收带有数字签名的策略请求，使用租户公钥验证签名完整性。
- 租户身份认证：基于 X.509 证书或 JWT 识别租户身份，防止跨租户策略篡改。
- Webhook 集成：提供 MutatingWebhook 和 ValidatingWebhook，在 Pod 创建时注入签名标签。
关键指标：API Server 单实例支持 5000+ 策略并发写入，P99 延迟 < 50ms。
3.2.2 Controller — 策略编排与状态中枢
Controller 是 NetPolicy 的“大脑”，负责将 API Server 接收到的策略转换为数据平面可执行的规则。它维护全局策略状态机，并处理租户间的资源映射。
- 策略编排：将
SignaturePolicy解析为签名规则链，按优先级排序后下发。 - 签名校验：对 Agent 上报的签名请求进行二次校验，防止伪造签名。
- 审计日志：记录所有策略变更、签名成功/失败事件，输出到标准输出或外部存储。
- 租户资源映射：维护
Tenant → Namespace → Label的映射关系，确保隔离边界正确。 - 故障恢复：当 Agent 失联时，Controller 标记节点为“不健康”，并触发重新调度。
最佳实践：Controller 应部署在管理集群中，与业务集群网络隔离，避免单点故障影响数据平面。
3.2.3 Agent — 本地执行与签名引擎
Agent 以 DaemonSet 形式运行在每个 Kubernetes 工作节点上，是数据平面的核心执行者。它负责将 Controller 下发的策略转化为内核级网络规则，并执行签名验证。
- 本地策略缓存：从 Controller 同步策略后，缓存在本地内存中，即使控制平面中断也能继续工作。
- eBPF / iptables 引擎：根据策略类型选择 eBPF（高性能）或 iptables（兼容性）作为数据路径。
- 签名验证模块：拦截 Pod 出站流量，提取签名信息，与本地缓存策略比对。
- 指标上报：每 30 秒向 Controller 上报策略命中数、签名失败数、延迟等指标。
注意：Agent 的签名验证模块默认使用 eBPF 模式，若内核版本低于 4.18 会自动降级为 iptables 模式，此时签名验证延迟会增加约 2ms。
3.3 数据平面与控制平面分离设计
NetPolicy 严格遵循数据平面与控制平面分离的设计原则，这是实现高可用、高性能和多租户隔离的基础。下面通过对比表格和独立图示说明两者的差异与协作方式。
| 维度 | 控制平面 | 数据平面 |
|---|---|---|
| 职责 | 策略编排、签名校验、审计 | 流量过滤、签名验证、规则执行 |
| 部署位置 | 管理集群 / 独立命名空间 | 每个工作节点 (DaemonSet) |
| 通信协议 | gRPC (双向流) + Event | Netlink / eBPF Maps |
| 故障影响 | 策略更新暂停，已有策略继续生效 | 该节点网络隔离失效 |
| 性能要求 | 低延迟 (P99 < 100ms) | 极低延迟 (P99 < 1ms) |
| 扩展方式 | 水平扩展 (Deployment) | 随节点自动扩展 (DaemonSet) |
3.4 平面分离的设计收益
数据平面与控制平面分离不是简单的架构选择，而是为了满足多租户签名链路隔离的四个核心要求：
- 故障隔离：控制平面故障不影响已有网络策略的执行，Agent 本地缓存确保数据平面持续工作。
- 性能独立：数据平面专注于快速包处理，不受控制平面策略编排的延迟波动影响。
- 安全边界：控制平面可以部署在更严格的安全域中，数据平面仅暴露必要的 gRPC 端口。
- 弹性扩展：控制平面按需水平扩展，数据平面随节点自动扩展，两者互不干扰。
生产验证：在 500 节点集群中，控制平面故障 10 分钟期间，数据平面持续处理 12000+ 签名请求，零策略丢失。