4. Jaeger 架构与部署：组件、模式与 Kubernetes 实践
Jaeger 作为 CNCF 毕业的分布式追踪系统，其架构设计遵循“采集-存储-查询”的经典可观测性链路。理解其组件职责与部署模式，是构建生产级 SLO 台账诊断能力的基础。本章将拆解 Jaeger 核心组件、对比部署模式，并给出 Kubernetes 环境下的生产级部署方案。
4.1 Jaeger 核心组件与职责
Jaeger 架构由四个主要组件构成，它们协同完成 Trace 数据的采集、处理、存储与可视化。下表总结了各组件的核心功能与部署位置：
| 组件 | 角色 | 部署位置 | 关键职责 |
|---|---|---|---|
| Agent | 边车代理 | 与业务容器同 Pod | 接收应用 Span 数据，批量压缩后转发至 Collector；支持 UDP/gRPC 协议 |
| Collector | 数据处理器 | 独立 Deployment | 验证、清洗、索引 Span；写入后端存储（Cassandra/Elasticsearch/Badger） |
| Query | 查询服务 | 独立 Deployment | 提供 gRPC/HTTP API 检索 Trace；聚合服务依赖关系与 SLO 指标 |
| UI | 可视化面板 | 与 Query 同 Pod 或独立 | Trace 搜索、火焰图展示、服务拓扑图、SLO 台账看板 |
架构要点： Agent 是“无状态轻量代理”，只做数据转发，不参与存储；Collector 是“有状态处理节点”，负责数据持久化；Query 与 UI 通常部署在一起，对外暴露 16686 端口。
下图展示了 Jaeger 组件间的数据流与依赖关系：
4.2 Jaeger 部署模式对比
Jaeger 提供两种官方部署模式：All-in-One 用于开发测试，Production 用于生产环境。选择错误模式会导致性能瓶颈或资源浪费。
| 维度 | All-in-One | Production |
|---|---|---|
| 组件整合 | Agent + Collector + Query + UI 合并为单进程 | 各组件独立部署，可水平扩展 |
| 存储 | 内嵌 Badger（本地文件） | 外部存储：Cassandra / Elasticsearch / OpenSearch |
| 高可用 | 单点，无 HA | Collector/Query 多副本 + 负载均衡 |
| 数据持久化 | 容器重启数据丢失 | 外部存储保证持久化 |
| 适用场景 | 本地开发、功能验证、Demo | 生产环境、SLO 台账、长期存储 |
| 资源占用 | 低（单 Pod 即可） | 中高（按组件独立分配） |
生产避坑： 切勿在生产环境使用 All-in-One 模式！其内嵌 Badger 存储不支持集群扩展，且单进程故障会导致全链路追踪中断。生产环境必须使用 Production 模式 + 外部存储。
4.3 Kubernetes 环境下的 Jaeger 生产部署
在 Kubernetes 中部署 Jaeger Production 模式，推荐使用 Jaeger Operator 或 Helm Chart。以下给出基于 Helm 的部署步骤与关键配置。
4.3.1 部署前提
- Kubernetes 集群版本 ≥ 1.19
- 已部署存储后端（推荐 Elasticsearch 7.x+ 或 OpenSearch）
- 已安装 Helm 3
4.3.2 Helm 部署命令
# 添加 Jaeger Helm 仓库
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm repo update
# 创建命名空间
kubectl create namespace observability
# 部署 Jaeger Production 模式（使用 Elasticsearch 存储）
helm upgrade --install jaeger jaegertracing/jaeger \
--namespace observability \
--set provisionDataStore.cassandra=false \
--set storage.type=elasticsearch \
--set storage.elasticsearch.host=elasticsearch-master.elastic.svc.cluster.local \
--set storage.elasticsearch.port=9200 \
--set collector.replicas=2 \
--set query.replicas=2 \
--set agent.strategy=DaemonSet4.3.3 关键配置说明
| 参数 | 推荐值 | 说明 |
|---|---|---|
storage.type |
elasticsearch | 生产环境首选 ES/OpenSearch；Cassandra 已逐步弃用 |
collector.replicas |
2~3 | 根据 Trace 吞吐量调整；建议与 ES 节点数匹配 |
agent.strategy |
DaemonSet | 每个 Node 部署一个 Agent，减少 Sidecar 资源开销 |
query.replicas |
2 | 保证 UI 查询高可用；可配置 HPA |
storage.elasticsearch.createIndexTemplates |
true | 自动创建 Jaeger 索引模板，优化 mapping |
4.3.4 部署后验证
# 检查 Pod 状态
kubectl get pods -n observability -l app.kubernetes.io/instance=jaeger
# 预期输出（示例）
# NAME READY STATUS RESTARTS AGE
# jaeger-collector-7d8f9c6b4c-2xq9k 1/1 Running 0 5m
# jaeger-collector-7d8f9c6b4c-j4m5n 1/1 Running 0 5m
# jaeger-query-6b7f8c9d4f-8p2q3 1/1 Running 0 5m
# jaeger-query-6b7f8c9d4f-9r4s5 1/1 Running 0 5m
# jaeger-agent-2x9k4 1/1 Running 0 5m
# jaeger-agent-j4m5n 1/1 Running 0 5m
# 端口转发访问 UI
kubectl port-forward -n observability svc/jaeger-query 16686:16686
# 浏览器打开 http://localhost:16686 验证 UI 可访问
SRE 建议： 在 Production 模式下，建议为 Collector 和 Query 配置 PodDisruptionBudget（PDB），确保滚动更新期间至少保留一个可用副本。同时为 Elasticsearch 存储设置 ILM（索引生命周期管理），按 SLO 台账保留周期自动清理过期 Trace 数据。
4.4 部署模式选择决策树
根据团队规模与业务阶段，可参考以下决策逻辑选择部署模式：
4.5 本章小结
- Agent 作为 Sidecar 或 DaemonSet 部署，负责 Span 采集与转发；Collector 负责数据清洗与写入；Query + UI 提供检索与可视化。
- All-in-One 仅适用于开发测试；Production 模式必须使用外部存储，并配置多副本保证高可用。
- Kubernetes 环境推荐使用 Helm Chart 或 Jaeger Operator 部署，关键参数包括
storage.type、collector.replicas、agent.strategy。 - 生产部署后需验证 Pod 状态、UI 可访问性，并配置 PDB 与 ILM 策略保障稳定性。