1. 课程导论：流量可视化与 eBPF 配额校准的背景、目标与整体架构概览
1.1 背景：为什么需要流量可视化与配额校准？
在云原生与微服务架构大规模普及的今天，网络流量呈现出高动态、多租户、加密化三大特征。传统的基于端口与 IP 的流量监控手段，在 Kubernetes 环境下面临严重挑战：
- 服务网格（Service Mesh） 引入 sidecar 代理，流量路径变长，丢包与延迟问题难以定位。
- mTLS 加密 使传统 DPI（深度包检测）失效，无法获取应用层协议与请求明细。
- 多租户共享集群 导致网络带宽、连接数等资源争抢，缺乏细粒度配额校准机制。
上述问题直接导致运维团队在故障排查、容量规划、成本分摊时，只能依赖黑盒猜测，无法获得精确的流量拓扑与配额消耗数据。
核心痛点： 没有 eBPF 之前，流量可视化要么依赖 iptables 日志（性能差、信息少），要么依赖 sidecar 代理上报（延迟高、覆盖不全）。配额校准更是停留在“总量除以 Pod 数”的粗放模式。
1.2 目标：本课程要解决什么？
本课程旨在通过 eBPF 技术，构建一套零侵扰、高精度、实时的流量可视化与配额校准体系。具体目标如下：
| 目标维度 | 具体描述 | 关键指标 |
|---|---|---|
| 流量可视化 | 自动发现 Pod/Service 间通信关系，绘制实时流量拓扑，支持 L3-L7 协议解析 | 拓扑更新延迟 < 1s，协议识别准确率 > 99% |
| 配额校准 | 基于 eBPF 采集的真实流量数据，动态校准每个 Pod/Namespace 的带宽与连接数配额 | 校准误差 < 5%，配额生效时间 < 100ms |
| 故障定位 | 通过流量回放与丢包点追踪，快速定位网络瓶颈与异常流量 | MTTR 降低 60% |
| 成本分摊 | 将网络资源消耗精确分摊到业务线/应用，支持按需计费 | 分摊粒度达到 Pod 级别 |
1.3 整体架构概览
本课程落地案例采用四层架构设计，从数据采集到业务呈现，形成完整闭环。下图展示了核心组件与数据流：
1.4 核心组件与职责
架构中的每个组件承担明确职责，下表列出关键模块及其技术选型：
| 组件 | 技术选型 | 核心职责 |
|---|---|---|
| eBPF Probe | Cilium / libbpf + CO-RE | 在 XDP/TC 层捕获所有进出 Pod 的包，提取元数据写入 Per-CPU Map |
| Userspace Agent | Go + bpf2go | 周期性从 eBPF Map 读取数据，完成流表重建、协议解析、指标聚合 |
| Quota Engine | Python + Redis Stream | 接收 Agent 推送的实时流量统计，对比预设配额阈值，生成校准指令 |
| Dashboard | Grafana + Prometheus | 展示实时流量拓扑、配额使用率、异常告警，支持历史回放 |
| Config Store | etcd / Kubernetes CRD | 存储配额策略、校准规则、白名单/黑名单配置 |
1.5 数据流与关键路径
一次完整的流量采集与配额校准流程包含以下步骤：
- 包捕获： eBPF Probe 在 Pod 网卡入口（XDP）和出口（TC）捕获每个数据包。
- 元数据提取： 从包中提取源/目的 IP、端口、协议、TCP 标志位、时间戳，写入 Per-CPU Hash Map。
- 用户态轮询： Userspace Agent 每 100ms 通过
bpf_map_lookup_batch批量读取 Map 数据。 - 流表重建： Agent 将五元组相同的包聚合为流，计算流速率、包量、字节数。
- 协议解析： 对 HTTP/gRPC 等明文协议，解析请求路径、状态码、延迟；对 mTLS 流量，仅统计元数据。
- 配额计算： Quota Engine 接收聚合后的流数据，按 Namespace/Deployment/Pod 维度累加，与预设配额对比。
- 校准执行： 若偏差超过阈值（如带宽超限 10%），Engine 通过 eBPF
bpf_map_update_elem动态调整限速策略。 - 可视化呈现： 所有指标写入 Prometheus，Grafana 实时刷新拓扑图与配额仪表盘。
关键优化点： 步骤 3 中采用 batch 读取 而非逐条读取，将用户态与内核态交互次数降低 90% 以上，避免高流量场景下的 CPU 开销。
1.6 课程案例的落地场景
本课程所有案例均基于一个模拟电商平台的 Kubernetes 集群（3 个 Worker Node，20+ 微服务）。该平台具有以下特征：
- 混合协议： 前端 HTTP/1.1，后端 gRPC，缓存 Redis，数据库 MySQL。
- 部分加密： 订单服务与支付服务之间启用 mTLS，其余服务明文通信。
- 多租户： 三个业务线（交易、搜索、推荐）共享同一集群，各有独立 Namespace 与配额。
- 突发流量： 大促期间流量峰值可达正常值的 20 倍，需要动态校准配额。