在 Kubernetes 环境中验证 Jaeger 的链路追踪能力时，往往缺乏稳定的后端服务来产生真实流量。通过 Node.js 编写一个名为 Mock2Image 的工具，可以将本地构造的 Jaeger Mock 数据自动打包为容器镜像，并推送到集群内部署。这种方式让测试人员无需依赖生产服务，即可观察 Jaeger Agent 与 Collector 对模拟 Span 的处理表现。
Jaeger Mock 数据与 K8s 镜像的映射原理
Jaeger 的 Mock 数据通常以 JSON 数组形式描述若干 Trace，每个 Trace 包含多个 Span，Span 中带有 operationName、startTime、duration 以及父子关系引用。Mock2Image 的核心任务，就是把这些静态数据变成容器内可执行的负载。在 Node.js 中，我们先解析这些 JSON，将其序列化为本地文件，随后由镜像内的 Node 脚本在容器启动时读取，并通过 Jaeger 客户端库向 Agent 发送 UDP 包。
从 K8s 视角看，生成的镜像需要包含一个轻量基础镜像（如 node:18-alpine），以及预置的 Mock 数据与发送脚本。工具在构建阶段会动态生成 Dockerfile，其中 COPY 指令把 Mock 数据放入 /app/mock 目录，ENTRYPOINT 指定 Node 执行发送程序。这样在 K8s 中无论以 Job 还是 Deployment 运行，Pod 启动后都会自动注入模拟链路，不需要人工干预。
这种映射方式相比直接跑本地进程的优势在于环境一致性。K8s 调度后的网络命名空间、DNS 解析以及和 Jaeger Agent Sidecar 的通信，都和真实业务 Pod 完全一致。Node.js 的事件循环模型也适合处理批量 Span 的定时重放，不会因为同步阻塞导致发送遗漏。
Node.js 工具核心模块与代码实现
Mock2Image 工具可拆分为三个模块：数据加载器、镜像构建器、配置生成器。数据加载器负责读取用户提供的 Jaeger Mock 文件，并做基础校验，比如检查 traceID 是否重复。镜像构建器调用 dockerode 连接构建后端，或在无守护进程场景下降级使用 kaniko 命令行。配置生成器输出 K8s 的 Job YAML，方便一键部署。
下面给出一个简化的数据加载与发送脚本示例，展示如何用 Node.js 读取 Mock 并借助 jaeger-client 发送。注意代码中的标签名在讨论时已被转义，但运行逻辑不受影响。
const fs = require('fs');
const { initTracer } = require('jaeger-client');
// 读取本地 Jaeger Mock 数据
const mockData = JSON.parse(fs.readFileSync('/app/mock/traces.json', 'utf8'));
const config = {
serviceName: 'mock-sender',
sampler: { type: 'const', param: 1 },
reporter: { agentHost: 'jaeger-agent', agentPort: 6831 }
};
const tracer = initTracer(config, {});
mockData.forEach(trace => {
trace.spans.forEach(span => {
const sp = tracer.startSpan(span.operationName);
sp.setTag('mock.traceId', trace.traceID);
sp.finish(span.startTime + span.duration);
});
});
上述代码在容器启动后执行，将 Mock 中的 operationName 映射为 Span，并把原始 traceID 写入标签。实际工具中还会加入限速逻辑，避免瞬时 UDP 包超出 Agent 处理能力。镜像构建器部分则可利用 dockerode 的 buildImage 方法，将内存中的 Dockerfile 字符串直接传给 Docker 引擎，省去临时文件落地。
对于不能使用 Docker 守护进程的情况，工具会输出构建上下文并调用 kaniko 在 K8s Pod 内构建。Node.js 通过 child_process 执行命令行，把镜像推送到私有仓库，再回填到生成的 Job YAML 的 image 字段。整个流程对使用者透明，只需提供 Mock 文件路径与目标仓库地址。
在 Kubernetes 中的部署与避坑要点
生成的镜像通常配合一个 K8s Job 使用，因为 Mock 发送属于一次性任务。Job 的 Pod 需要与 Jaeger Agent 处于同一命名空间，并通过服务名 jaeger-agent 互通。若集群启用了 mTLS，还需在 Pod 注解中配置流量放行，否则 UDP 6831 端口会被网格拦截，导致 Span 丢失且无报错。
另一个常见误区是认为 Mock 数据越多越好。实际上 Jaeger Collector 默认有内存队列上限，一次性重放数万 Span 会触发丢弃。Node.js 工具中应实现分批发送，比如每批 500 条，间隔 200 毫秒。下面的表格列出不同批次策略在测试环境中的表现：
| 批次大小 | 间隔(ms) | Collector 接收率 |
|---|---|---|
| 200 | 100 | 99.8% |
| 500 | 200 | 98.1% |
| 2000 | 0 | 82.4% |
从表中可见，适度限速能显著提升链路完整度。此外，Mock2Image 生成的 Job 应设置 TTL 自动清理，防止测试命名空间堆积大量 Completed Pod。通过 Node.js 渲染 YAML 时，可直接写入 ttlSecondsAfterFinished 字段，让 K8s 原生回收资源。
最后要注意镜像内的时区与时钟。Jaeger 依赖 startTime 绝对值，若容器使用 UTC 而 Mock 数据基于本地时间，虽不影响拓扑但会造成查询面板时间错位。建议在 Dockerfile 生成阶段由 Node.js 注入 TZ 环境变量，并在发送脚本中用 Date.now() 做偏移校正，保证模拟链路在时间轴上合理分布。
Node.jsJaegerk8s_Mock2Image修改时间：2026-08-15 17:52:30