1. 课程概述与目标
1.1 集群升级后的版本漂移背景
在 Kubernetes 集群进行大版本升级（如 1.24 → 1.26）或组件滚动更新后，日志平台往往会出现一种隐蔽但影响深远的异常现象——版本漂移。所谓版本漂移，是指集群中 Loki 相关组件的实际运行版本与预期基线版本之间产生偏差，且这种偏差未被常规监控及时发现。
版本漂移的典型成因包括：
- Helm Chart 与 Operator 版本不匹配：集群升级后，Helm 仓库或 Operator 控制器未同步更新，导致部署的 Loki 实例沿用旧版本镜像。
- 节点镜像缓存滞后：节点升级过程中，kubelet 可能从本地缓存拉取旧镜像，而非从 registry 拉取最新标签。
- Sidecar 或 Agent 版本残留：Promtail / Alloy 等采集端未随集群升级而更新，形成采集端与服务端的协议版本不兼容。
- 自定义资源定义（CRD）版本冲突：Loki Operator 依赖的 CRD 版本在集群升级后未自动迁移，导致控制器逻辑与运行时状态脱节。
⚠️ 风险提示：版本漂移不会直接引发服务中断，但会导致数据写入格式变化、查询协议降级、日志丢失或重复采集等隐蔽故障。在微服务架构中，这种故障往往在数小时甚至数天后才被业务反馈触发，排查成本极高。
1.2 校准的必要性
版本漂移校准不是可选项，而是集群升级后日志平台恢复稳定运行的强制性前置步骤。校准的核心目标包括：
| 校准维度 | 目标状态 | 未校准的风险 |
|---|---|---|
| 组件版本一致性 | 所有 Loki 相关 Pod 镜像版本与基线一致 | 数据写入格式不兼容，查询结果异常 |
| 配置参数对齐 | Loki 配置与 Helm values / Operator spec 完全同步 | Ingester 分片策略变更导致数据分布失衡 |
| 数据路径完整性 | 采集 → 写入 → 存储 → 查询链路无断点 | 日志丢失、重复、乱序，影响可观测性 |
| API 协议兼容性 | 采集端与 Loki 服务端使用同一 Push API 版本 | 写入请求被拒绝或降级，产生大量 4xx 错误 |
校准流程通常包含版本审计、配置比对、数据路径验证和回归测试四个阶段。其中，数据传输测试是唯一能够直接证明日志平台“可用性”的环节——它验证了从日志产生到查询返回的完整闭环。
1.3 Loki 数据传输测试的核心地位
在整个校准流程中，Loki 数据传输测试处于验证与收口的关键位置。版本审计和配置比对只能发现“应该有问题”的隐患，而数据传输测试则直接回答“实际有没有问题”。
数据传输测试覆盖以下核心链路：
- 采集端写入测试：验证 Promtail / Alloy 能否成功将日志推送到 Loki 的 Distributor 组件。
- Ingester 持久化测试：确认日志数据被正确写入对象存储（如 S3、GCS、MinIO）或本地文件系统。
- 查询端读取测试：通过 LogQL 查询验证数据可被检索，且时间戳、标签、日志内容完整。
- 数据一致性校验：对比写入量与查询返回量，确认无丢失、无重复。
💡 关键认知：数据传输测试是校准流程的“试金石”。即使版本号完全一致，配置参数也可能因升级过程中的默认值变更而引入差异。只有通过实际的数据写入与查询验证，才能确认日志平台在升级后真正恢复可用状态。
1.4 课程目标与学习路径
本课程旨在帮助 SRE 和可观测性工程师掌握一套可复现、可自动化的 Loki 数据传输测试方法，确保集群升级后日志平台版本漂移能被快速发现并校准。完成本课程后，你将能够：
- 设计并执行覆盖写入、存储、查询全链路的 Loki 数据传输测试用例。
- 通过 LogQL 和 Loki API 进行数据一致性校验，识别版本漂移导致的异常。
- 构建自动化测试流水线，将数据传输测试集成到集群升级的 CI/CD 流程中。
- 输出标准化的测试报告，为版本校准决策提供数据支撑。
🎯 学习建议：本课程包含大量实操示例和可复用的测试脚本。建议在学习过程中准备一个测试用的 Loki 环境（可以是单实例部署），跟随课程步骤进行实际操作，以加深对数据传输测试各环节的理解。