4. NetPolicy 架构总览:核心组件、数据采集管道、策略引擎

NetPolicy 的架构设计遵循“采集-计算-执行-观测”的闭环原则。整个系统由三大核心层构成:数据采集管道负责从容器网络平面抓取原始流量与指标;策略引擎负责对采集数据进行实时匹配与决策;观测与事件层负责将决策结果、延迟水位和异常事件输出给可观测性平台。本章将逐一拆解这些组件的职责与协作关系。

4.1 核心组件全景

NetPolicy 采用微服务 + 边车代理的混合部署模型。以下表格列出了所有核心组件及其功能定位:

组件名称 部署形态 核心职责
Policy Agent DaemonSet(每节点一个) 本地策略缓存、eBPF 挂载点管理、延迟探针注入
Data Collector DaemonSet(每节点一个) 原始包捕获、流聚合、指标预计算、元数据标签
Policy Engine Deployment(2-3 副本) 全局策略编译、规则匹配、蓝绿流量识别、决策下发
Event Bus Deployment(有状态) 异常事件排序、延迟水位广播、告警去重
Observability Exporter Deployment(无状态) Prometheus 指标暴露、OpenTelemetry 链路导出、日志格式化
Config Controller Deployment(单副本) CRD 监听、策略版本管理、蓝绿配置热更新
架构要点:Policy Agent 与 Data Collector 运行在数据面,直接与容器网络命名空间交互;Policy Engine 与 Config Controller 运行在控制面,通过 gRPC 流与数据面通信。这种分离保证了策略变更不影响数据转发路径。

4.2 数据采集管道

数据采集管道是 NetPolicy 观测能力的基石。它从容器网络接口(veth pair / macvlan)抓取原始数据,经过四级处理流水线后,输出结构化的流记录与指标。

4.2.1 管道处理阶段

  1. 抓取层(Capture Layer):基于 eBPF XDP/TC 钩子,在网卡驱动层或内核协议栈入口处捕获数据包。支持按 Pod 标签、命名空间、协议(TCP/UDP/ICMP)进行过滤,避免无效包进入管道。
  2. 流聚合层(Flow Aggregation Layer):将原始包按五元组(srcIP, dstIP, srcPort, dstPort, proto)聚合成流记录。聚合窗口默认 30 秒,支持动态调整。此阶段计算基础指标:包数、字节数、TCP 重传率。
  3. 延迟计算层(Latency Computation Layer):针对 TCP 流,通过 eBPF 跟踪内核 TCP 时间戳选项,计算 RTT(往返时延)与 RTT 抖动。对于 UDP 流,通过注入的探针包测量单向延迟。结果以百分位(P50/P95/P99)形式输出。
  4. 元数据富化层(Metadata Enrichment Layer):将流记录中的 IP 与端口映射为 Kubernetes 资源信息(Pod 名称、Service 名称、Deployment 标签、命名空间)。同时标记蓝绿版本标识(color: blue/green)。
性能指标参考:在 1000 节点集群中,单节点 Data Collector 处理 10 Gbps 流量时,CPU 占用控制在 1.5 核以内,内存占用约 512 MB。延迟计算精度达到微秒级(±5μs)。

4.2.2 管道输出格式

经过四级处理后,每条流记录包含以下关键字段:

{
  "flow_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "timestamp": 1712345678.123,
  "src": {
    "pod": "frontend-v2-abc-123",
    "namespace": "prod",
    "color": "green",
    "ip": "10.244.1.15"
  },
  "dst": {
    "service": "backend-svc",
    "namespace": "prod",
    "color": "blue",
    "ip": "10.244.2.22"
  },
  "protocol": "TCP",
  "latency": {
    "rtt_p50_us": 120,
    "rtt_p95_us": 350,
    "rtt_p99_us": 890,
    "jitter_us": 45
  },
  "metrics": {
    "packets": 1500,
    "bytes": 2048000,
    "retransmit_rate": 0.002
  },
  "anomaly": null
}

4.3 策略引擎

策略引擎是 NetPolicy 的决策大脑。它接收来自数据采集管道的流记录,与用户定义的策略规则进行匹配,输出执行动作(允许/拒绝/标记/告警)。

4.3.1 策略模型

策略采用三层匹配模型:

  • 基础匹配层:匹配源/目的 Pod 标签、命名空间、IP 段、端口范围。支持精确匹配、通配符匹配、CIDR 匹配。
  • 蓝绿识别层:通过 color 标签识别流量的蓝绿版本归属。支持“仅蓝到蓝”、“仅绿到绿”、“蓝绿交叉”三种模式。交叉模式用于灰度验证期间的蓝绿通信观测。
  • 延迟水位层:将流记录的延迟指标与预设水位线(阈值)比较。水位线分为三级:正常(绿色)、警戒(黄色)、危险(红色)。超过危险水位时触发策略动作。

4.3.2 策略执行流程

以下 SVG 图展示了从流记录到达策略引擎到最终动作下发的完整流程:

策略引擎执行流程 流记录输入 基础匹配层(标签/命名空间/IP/端口) 蓝绿识别层(color 标签匹配) 延迟水位层(阈值比较) 决策输出(允许/拒绝/告警) 匹配模式说明 基础匹配:精确/通配符/CIDR 蓝绿识别:仅同色/交叉模式 延迟水位:绿/黄/红三级阈值 延迟水位阈值示例 绿色:RTT < 200μs 黄色:200μs ≤ RTT < 500μs 红色:RTT ≥ 500μs

4.4 策略引擎与数据管道的协作

数据采集管道与策略引擎之间通过事件驱动模式协作,而非传统的轮询拉取。具体协作机制如下:

  • 流记录推送:Data Collector 每完成一个聚合窗口,立即将流记录通过 gRPC 双向流推送给 Policy Engine。推送频率默认 30 秒一次,支持按需调整。
  • 策略缓存同步:Policy Engine 将编译后的策略规则通过边车代理同步到每个节点的 Policy Agent。Agent 本地缓存策略,实现毫秒级匹配。
  • 异常事件回传:当策略引擎检测到延迟水位超过危险阈值或蓝绿流量异常时,立即生成异常事件,通过 Event Bus 广播给 Observability Exporter 和告警系统。
避坑指南:在蓝绿部署切换期间,Data Collector 可能会同时收到两个版本的流量。务必在策略引擎的蓝绿识别层配置“交叉模式”,否则引擎会误判为异常流量并触发告警风暴。建议在切换窗口期将交叉模式设置为“仅观测不告警”。

4.5 架构总结

NetPolicy 的架构设计体现了云原生可观测性的最佳实践:

架构特性 实现方式 收益
数据面与控制面分离 Agent/Collector 在数据面,Engine/Controller 在控制面 策略变更不影响数据转发,提升稳定性
eBPF 零侵入采集 XDP/TC 钩子 + 内核时间戳 无需修改应用代码,延迟计算精度高
三层策略匹配 基础匹配 → 蓝绿识别 → 延迟水位 精准识别蓝绿流量异常,避免误判
事件驱动推送 gRPC 双向流 + Event Bus 端到端延迟低,异常事件秒级响应