3. 模板制品库概念：什么是eBPF模板制品库、制品库的版本管理、元数据标准与复用策略

3.1 eBPF模板制品库的定义与定位

eBPF模板制品库是一个集中存储、版本化管理和分发eBPF程序模板及其关联元数据的中央仓库。它不同于普通的代码仓库（如Git），其核心单元是制品（Artifact）——一个经过编译、验证并附带完整描述信息的eBPF模板包。

在Kubernetes网络观测场景中，制品库解决了以下关键问题：

• 模板标准化：确保团队内所有eBPF探针遵循统一的数据采集结构。
• 版本追溯：每次模板变更都生成不可变版本，支持回滚与审计。
• 跨环境复用：同一模板可部署到开发、预发、生产集群，行为一致。
• 与Hubble集成：制品库中的元数据直接驱动Hubble的流量解析与过滤策略。

3.2 制品库的版本管理策略

版本管理是制品库的核心能力。每个eBPF模板制品遵循语义化版本（SemVer）规范，格式为 MAJOR.MINOR.PATCH，并附加构建元数据。

版本管理流程通常包含以下步骤：

1. 开发阶段：在Git分支上迭代源码，使用 0.x.x 预发布版本。
2. CI构建：编译生成 .o 文件，自动生成元数据JSON，计算SHA256校验和。
3. 制品发布：推送至制品库，打上版本标签，触发Hubble配置同步。
4. 部署验证：Cilium Agent拉取指定版本，加载并验证探针健康状态。
5. 版本废弃：标记旧版本为 deprecated，但保留历史记录用于审计。

3.3 元数据标准

元数据是连接eBPF模板与Hubble可观测性的桥梁。每个制品必须附带一个标准化的元数据文件，通常为JSON格式，包含以下核心字段：

一个典型的元数据文件示例如下：

{
  "name": "http_flow_monitor",
  "version": "1.2.0",
  "hook_points": ["tcp_connect", "tcp_close", "tcp_sendmsg"],
  "maps": [
    {"name": "flow_stats", "type": "hash", "key_size": 16, "value_size": 64}
  ],
  "kernel_constraints": {
    "min_version": "5.10",
    "require_btf": true
  },
  "hubble_labels": {
    "protocol": "http",
    "direction": "both",
    "service": "{{.ServiceName}}"
  },
  "dependencies": [
    {"name": "base_socket_trace", "version": ">=2.0.0"}
  ]
}

3.4 复用策略与最佳实践

模板复用是降低eBPF开发成本、保证观测一致性的关键。以下是经过生产验证的复用策略：

具体复用策略包括：

• 组合复用：定制模板通过 dependencies 字段引用一个或多个基础模板。例如，http_monitor 依赖 socket_trace_base 提供TCP事件，自身只添加HTTP解析逻辑。
• 参数化复用：模板支持参数注入，如 max_flow_entries、sampling_rate。同一模板在不同命名空间可配置不同参数，无需复制代码。
• 版本锁定复用：在 dependencies 中指定精确版本范围（如 >=1.0.0 <2.0.0），避免破坏性更新影响生产环境。
• 标签继承复用：子模板自动继承父模板的 hubble_labels，并允许覆盖或扩展。这保证了流量标签体系的一致性。

3.5 与Hubble集成的元数据映射

制品库的元数据标准直接服务于Hubble的流量可视化。映射关系如下：

通过这种映射，Hubble能够自动识别由不同模板生成的流量数据，并在同一个Grafana仪表盘中统一展示，无需手动配置字段映射。