1. 课程导论与蓝图总览

在云原生多租户环境中，网络观测面临的核心挑战是：如何在共享的eBPF数据采集平面上，为每个租户提供安全、隔离、可审计的网络流量视图。Hubble作为Cilium原生的可观测性层，利用eBPF在内核态捕获网络事件，并通过身份感知与标签策略实现租户级别的数据隔离。本章将阐述Hubble的核心价值，并勾勒出租户隔离蓝图的整体架构与目标。

1.1 Hubble在eBPF网络观测中的核心价值

Hubble并非传统的sidecar或代理采集模式，它直接挂载到Cilium的eBPF数据路径上，具备以下不可替代的优势：

维度	传统观测方案（如Prometheus + Sidecar）	Hubble + eBPF 方案
数据捕获点	用户态代理（延迟高、资源开销大）	内核态eBPF钩子（零拷贝、低延迟）
身份关联	依赖IP/端口映射（动态环境易漂移）	基于Cilium Identity（标签驱动，随Pod调度实时更新）
租户隔离粒度	需额外配置网络策略或命名空间过滤	原生支持基于标签的流量过滤与数据掩码
性能开销	通常占用5%-15%的额外CPU	低于3%的CPU开销（生产验证）
协议解析	需单独集成协议解析库	内置HTTP/gRPC/DNS/TCP等解析器

1.2 租户隔离蓝图的整体架构

本课程设计的租户隔离蓝图，围绕“采集隔离 → 存储隔离 → 查询隔离”三层模型构建。下图展示了核心组件及其交互关系：

1.3 蓝图目标与关键指标

本蓝图旨在为云原生平台团队提供一套可落地的、生产级别的网络观测租户隔离方案。具体目标如下：

• 数据面零信任隔离： 确保租户A的eBPF观测数据不会被租户B的观测端点或Relay实例访问。
• 查询面权限收敛： 所有Hubble API/CLI/UI请求必须携带租户上下文，后端强制过滤。
• 性能损耗可控： 启用租户隔离后，Hubble整体CPU开销增加不超过5%，内存增加不超过10%。
• 审计合规： 所有跨租户的数据访问尝试必须记录审计日志，并支持告警。

1.4 与传统方案的对比优势

下表将本蓝图方案与业界常见的两种替代方案进行对比，帮助学员理解为何选择Hubble+eBPF路径：

对比维度	本蓝图（Hubble + eBPF）	传统 Prometheus + 网络探针	服务网格 Sidecar 观测
隔离实现方式	内核态标签 + 用户态RBAC	用户态IP白名单过滤	Sidecar 进程级隔离
数据完整性	完整L3-L7流日志	仅聚合指标，丢失流细节	完整流日志，但增加延迟
部署复杂度	中（依赖Cilium CNI）	低（独立部署探针）	高（需注入Sidecar）
资源开销	低（<3% CPU）	中（5-8% CPU）	高（10-20% CPU + 内存）
动态适应性	强（Pod创建即感知）	弱（需预配IP段）	中（依赖控制面同步）