3. 日志平台架构概览：常见日志采集架构与 Deployment 绑定关系
在 Kubernetes 原生环境下，日志平台通常采用 Agent → 聚合 → 存储 → 查询 的分层架构。每一层组件都以 Deployment（或有状态 StatefulSet）的形式运行，并与日志采集、处理、存储的职责绑定。理解这些组件的 Deployment 绑定关系，是实现版本漂移自动校准的前提。
3.1 常见日志采集架构对比
当前主流日志采集方案包括 Fluentd、Filebeat 和 Loki 生态。下表从采集方式、资源开销、与 Kubernetes 集成度三个维度进行对比：
| 采集器 | 部署模式 | 资源开销 | K8s 集成度 | 典型输出 |
|---|---|---|---|---|
| Fluentd | DaemonSet + Deployment | 中（Ruby 运行时） | 高（原生 CRD 支持） | Elasticsearch / Kafka / S3 |
| Filebeat | DaemonSet | 低（Go 二进制） | 中（需配合 Elastic 栈） | Elasticsearch / Logstash |
| Promtail (Loki) | DaemonSet | 极低（Go 二进制） | 高（原生 Label 继承） | Loki |
3.2 日志平台核心组件与 Deployment 绑定关系
一个完整的日志平台通常包含以下 5 个核心组件，每个组件都与一个或多个 Deployment 绑定：
- 日志采集 Agent — 通常以 DaemonSet 部署，但部分场景下会使用 Deployment + Sidecar 模式。
- 日志聚合转发器 — 以 Deployment 部署，负责接收 Agent 上报的日志，进行过滤、缓冲、路由。
- 日志存储引擎 — 以 StatefulSet 部署（有状态），但管理面组件（如 Elasticsearch Coordinator）仍使用 Deployment。
- 日志查询 API — 以 Deployment 部署，提供 HTTP/gRPC 查询接口。
- 日志清洗/转换管道 — 以 Deployment 部署，运行 Logstash 或 Fluentd 聚合器。
以下 SVG 图展示了典型日志平台架构中各组件的 Deployment 绑定关系：
3.3 典型日志采集架构详解
3.3.1 Fluentd 架构
Fluentd 采用 Agent + Aggregator 双层架构。Agent 以 DaemonSet 部署在每台 Node 上，采集容器标准输出和文件日志；Aggregator 以 Deployment 部署，接收 Agent 上报的日志，进行过滤、缓冲后写入后端存储。版本漂移可能发生在 Agent 层或 Aggregator 层，校准策略需分别处理。
3.3.2 Filebeat 架构
Filebeat 以 DaemonSet 部署，直接采集日志并发送到 Elasticsearch 或 Logstash。由于 Filebeat 本身不承担聚合职责，版本漂移影响范围集中在节点级。校准策略通常为：检测 DaemonSet 的 image 版本与预期版本不一致时，触发 DaemonSet 滚动更新。
3.3.3 Loki + Promtail 架构
Promtail 以 DaemonSet 部署，采集日志并直接写入 Loki。Loki 本身由多个组件组成：Distributor（Deployment）、Ingester（StatefulSet）、Querier（Deployment）。版本漂移校准需分别监控每个组件的 Deployment revision。
spec.template.spec.containers[].image 字段是版本漂移检测的原子单位。通过对比当前 image 与预期 image 的 SHA256 摘要，可以精确判断是否发生版本漂移。
3.4 组件与 Deployment 绑定关系清单
以下表格列出了日志平台各组件的 Deployment 绑定关系及版本漂移影响范围：
| 组件名称 | K8s 资源类型 | 绑定 Deployment 名称 | 版本漂移影响范围 | 校准优先级 |
|---|---|---|---|---|
| Fluentd Agent | DaemonSet | fluentd-agent | 节点级 | 中 |
| Fluentd Aggregator | Deployment | fluentd-aggregator | 集群级 | 高 |
| Filebeat | DaemonSet | filebeat | 节点级 | 中 |
| Promtail | DaemonSet | promtail | 节点级 | 中 |
| Loki Distributor | Deployment | loki-distributor | 集群级 | 高 |
| Loki Querier | Deployment | loki-querier | 集群级 | 高 |
| Elasticsearch Coordinator | Deployment | es-coordinator | 集群级 | 高 |
| Kibana | Deployment | kibana | 集群级 | 低 |
3.5 架构设计对校准策略的影响
不同的日志采集架构决定了版本漂移自动校准的实现复杂度：
- 单层架构（Filebeat/Promtail）：校准逻辑简单，只需监控 DaemonSet 的 image 版本，触发滚动更新即可。
- 双层架构（Fluentd Agent + Aggregator）：校准逻辑复杂，需分别监控 Agent 和 Aggregator 的版本，且 Aggregator 的版本漂移可能导致日志丢失，校准需先暂停 Agent 上报。
- 微服务架构（Loki 多组件）：校准逻辑最复杂，需维护组件间的版本兼容性矩阵，避免 Distributor 与 Ingester 版本不匹配导致数据写入失败。