📚 课程目录第4章标准化部署原则

4. 标准化部署原则：不可变基础设施、声明式配置、GitOps 工作流在追踪部署中的应用

在值班台分布式追踪系统的部署中，标准化并非仅指“用同一套脚本”，而是要求整个交付过程遵循三大核心原则：不可变基础设施、声明式配置与GitOps 工作流。这三者共同构成了从环境构建到配置变更、再到持续交付的闭环，确保追踪链路在任何集群、任何时间点都能复现一致的观测结果。

4.1 不可变基础设施：追踪组件的“一次构建，到处运行”

传统运维中，运维人员通过 SSH 登录服务器、手动修改配置文件或安装补丁，导致环境逐渐“漂移”。不可变基础设施要求：一旦追踪组件（Collector、Storage、Query Service）的镜像或制品被构建，就不再对其进行原地修改。任何变更都通过替换整个实例来实现。

对比维度	可变基础设施（传统）	不可变基础设施（标准化）
部署单元	虚拟机/物理机 + 配置脚本	容器镜像 + 不可变制品
配置变更	SSH 登录、热修改、补丁	重新构建镜像、滚动替换 Pod
回滚方式	回退脚本、手动恢复	切换镜像 Tag 或版本号
环境一致性	随时间漂移，难以复现	镜像 Hash 锁定，完全一致
对追踪系统影响	Collector 配置易错，链路中断	快速回滚，链路数据不丢失

平台工程实践提示： 将 Jaeger Collector、OpenTelemetry Collector 的配置文件（如 otel-collector-config.yaml）直接打包进容器镜像，而非通过 ConfigMap 挂载。这样每次配置变更都会产生新的镜像版本，彻底杜绝“配置漂移”。

4.2 声明式配置：用“期望状态”替代“操作步骤”

声明式配置的核心思想是：你告诉系统“追踪系统应该是什么样子”，而不是“如何一步步变成那个样子”。在分布式追踪部署中，这体现为使用 Kubernetes 资源清单（YAML）或 Terraform/Crossplane 等工具定义 Collector 副本数、Storage 后端地址、采样率策略等。

4.2.1 声明式 vs 命令式对比

配置方式	典型操作	追踪部署场景	风险等级
命令式	`kubectl scale deployment jaeger-collector --replicas=5`	临时扩缩容，但未记录到版本控制	高（配置漂移）
声明式	修改 `replicas: 5` 并 `kubectl apply -f deployment.yaml`	变更记录在 Git，可审计、可回滚	低（可追溯）
混合式	部分手动 Patch + 部分 YAML	部分组件配置不一致，链路断裂	中（不一致）

4.2.2 追踪配置声明式示例

以下是一个 OpenTelemetry Collector 的声明式配置片段，定义了接收器、处理器和导出器，所有变更都通过 Git 管理：

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
  namespace: tracing
spec:
  mode: deployment
  replicas: 3
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
    processors:
      batch:
        timeout: 1s
    exporters:
      jaeger:
        endpoint: jaeger-collector:14250
        tls:
          insecure: true

常见陷阱： 不要将敏感信息（如 TLS 证书、）直接写在 YAML 中。应使用 Sealed Secrets 或 External Secrets Operator 进行声明式加密管理，确保 Git 仓库中不存储明文凭据。

4.3 GitOps 工作流：以 Git 为单一事实来源的追踪交付

GitOps 将声明式配置与不可变基础设施进一步融合，形成“Git 仓库 → 自动化 Operator → 集群状态”的闭环。对于值班台分布式追踪系统，这意味着：

所有追踪组件的配置（Collector、Storage、Query Service、采样策略）都存储在 Git 仓库中。
任何集群状态的变更都必须通过 Pull Request 发起，经 Code Review 后合并到主分支。
自动化工具（如 Argo CD、Flux）持续监控 Git 仓库，自动将期望状态同步到 Kubernetes 集群。

4.3.1 GitOps 工作流在追踪部署中的步骤

开发/运维人员在 Git 仓库中修改追踪配置（如调整采样率、增加 Collector 副本）。
提交 PR，触发 CI 流水线进行配置校验（如检查 YAML 语法、模拟部署）。
合并到主分支后，GitOps Operator 检测到配置变更。
Operator 自动同步，将新配置应用到目标集群，替换不可变实例。
持续监控：如果同步失败或集群状态偏离 Git，Operator 自动告警或回滚。

4.4 三大原则的协同效应

不可变基础设施、声明式配置与 GitOps 工作流并非孤立存在，而是相互增强：

不可变基础设施为声明式配置提供了“无状态、可替换”的执行单元。
声明式配置为 GitOps 提供了“期望状态”的描述语言。
GitOps 工作流将前两者串联为自动化闭环，确保追踪系统始终与 Git 中的定义保持一致。

  值班台落地建议： 在搭建追踪系统初期，就应将 Collector、Storage 和 Query Service 的部署清单纳入 Git 仓库，并配置 Argo CD 自动同步。这样，当值班人员需要调整采样率或扩容时，只需修改 Git 中的 YAML 文件，系统会自动完成变更，无需手动操作集群。