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 管道处理阶段
- 抓取层(Capture Layer):基于 eBPF XDP/TC 钩子,在网卡驱动层或内核协议栈入口处捕获数据包。支持按 Pod 标签、命名空间、协议(TCP/UDP/ICMP)进行过滤,避免无效包进入管道。
- 流聚合层(Flow Aggregation Layer):将原始包按五元组(srcIP, dstIP, srcPort, dstPort, proto)聚合成流记录。聚合窗口默认 30 秒,支持动态调整。此阶段计算基础指标:包数、字节数、TCP 重传率。
- 延迟计算层(Latency Computation Layer):针对 TCP 流,通过 eBPF 跟踪内核 TCP 时间戳选项,计算 RTT(往返时延)与 RTT 抖动。对于 UDP 流,通过注入的探针包测量单向延迟。结果以百分位(P50/P95/P99)形式输出。
- 元数据富化层(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 图展示了从流记录到达策略引擎到最终动作下发的完整流程:
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 | 端到端延迟低,异常事件秒级响应 |