1. 课程导论：eBPF 网络观测与租户隔离蓝图的概念、跨环境迁移的挑战、仪表盘对账的核心价值
1.1 什么是 eBPF 网络观测？
eBPF（extended Berkeley Packet Filter）是一项在内核中安全运行沙箱程序的技术，无需修改内核源码或加载内核模块。在网络观测领域，eBPF 能够以极低的开销捕获网络数据包、跟踪连接状态、监控系统调用，并提供细粒度的网络拓扑与性能指标。
相比传统基于 iptables、netfilter 或用户态代理的观测方式，eBPF 具备以下优势：
- 零侵入：无需修改应用代码或容器镜像。
- 全栈可见：从网卡驱动到 socket 层，覆盖 L2–L7 网络栈。
- 高性能：通过 JIT 编译和 map 结构实现纳秒级数据采集。
- 安全可控：通过 BPF verifier 确保程序不会导致内核崩溃。
关键概念：eBPF 网络观测的核心是
kprobe/tracepoint 挂载点 + BPF_MAP_TYPE_HASH/BPF_MAP_TYPE_PERF_EVENT_ARRAY 数据通道，配合用户态程序（如 Cilium、Pixie）实现实时可视化。
1.2 租户隔离蓝图的概念
在多租户云原生环境中，租户隔离蓝图是一套声明式网络策略 + 观测配置 + 资源配额的组合模板。它定义了每个租户的：
- 网络边界：VPC、子网、安全组、NetworkPolicy。
- 观测范围：哪些命名空间、Pod、Service 需要被 eBPF 探针采集。
- 指标与日志：租户级别的吞吐量、延迟、丢包率、DNS 解析成功率。
- 仪表盘模板：预定义的 Grafana Dashboard JSON 模型，包含租户标签过滤变量。
| 维度 | 单租户蓝图 | 多租户蓝图 |
|---|---|---|
| 网络策略 | 固定 CIDR + 白名单 | 动态 CIDR + 租户标签选择器 |
| 观测范围 | 全集群采集 | 按租户命名空间过滤 |
| 仪表盘变量 | 无租户维度 | $tenant_id、$namespace 多级变量 |
| 数据隔离 | 共享 Prometheus 实例 | 租户级 Prometheus 或 Thanos 分区 |
1.3 跨环境迁移的挑战
当租户隔离蓝图从开发环境迁移到预发、生产环境时，面临以下核心挑战：
- 网络拓扑差异：不同环境的 CNI 插件（Calico vs Cilium）、Service Mesh 注入策略、节点网络 MTU 可能不同，导致 eBPF 探针挂载点失效或数据采集偏差。
- 观测基础设施不一致：Prometheus 版本、Grafana 数据源、Loki 日志存储路径在环境间存在差异，仪表盘变量无法直接复用。
- 租户标识漂移：同一租户在不同环境可能使用不同的命名空间名称、标签键值对，导致仪表盘过滤条件失效。
- 数据口径不统一：eBPF 采集的指标（如
tcp_retransmit、dns_latency）在不同内核版本或 eBPF 程序版本下，计算逻辑可能不一致。
常见陷阱：直接复制生产环境的 Grafana Dashboard JSON 到开发环境，往往因为数据源名称、租户变量默认值不同而导致面板报错“No data”。跨环境迁移必须经过仪表盘对账环节。
1.4 仪表盘对账的核心价值
仪表盘对账（Dashboard Reconciliation）是一套自动化校验 + 差异修复的流程，确保跨环境迁移后，eBPF 网络观测仪表盘的数据准确、面板完整、租户隔离生效。其核心价值体现在：
- 数据一致性：校验源环境与目标环境的指标命名、标签键值、PromQL 查询是否语义等价。
- 租户隔离验证：确认每个租户的仪表盘变量（如
$tenant_id）能正确过滤出该租户的 eBPF 数据，不泄露其他租户信息。 - 面板完整性：检查目标环境是否缺失任何面板、图表类型是否兼容、告警规则是否同步。
- 自动化修复：通过脚本或 Operator 自动修正数据源 URL、变量默认值、面板尺寸等环境差异。
1.5 课程目标与学习路径
通过本课程，你将掌握：
- 如何设计可跨环境复用的 eBPF 网络观测蓝图。
- 如何构建租户隔离的仪表盘模板，支持多级变量和标签路由。
- 如何实现仪表盘对账自动化，包括差异检测、修复策略和 CI/CD 集成。
- 如何在实际项目中落地“蓝图 → 迁移 → 对账 → 持续观测”的完整闭环。
课程前置知识：建议具备 Kubernetes 基础操作、Grafana 仪表盘编辑经验、了解 eBPF 基本概念（如 kprobe、map）。无需精通内核编程。