Alauda Service Mesh v2 Docs
  • 简体中文

    • 迁移到 Jaeger v2

    本文介绍如何将现有的 Service Mesh 分布式追踪堆栈——旧版 Alauda Build of Jaeger（Jaeger 1.60.0）以及 使用 Service Mesh 配置分布式追踪平台（已弃用） 中所述的 Alauda Build of OpenTelemetry 集成——迁移到当前基于 Jaeger v2（2.20.0）以及 Alauda Build of OpenTelemetry v2 的 Alauda 分布式追踪 集成。

    迁移后：

    • 新追踪由 v2 OpenTelemetry Collector 接收，并存储在新的 Jaeger v2 后端中。
    • 切换前生成的追踪仍保留在旧版 Elasticsearch 索引中，这些索引会附加到新后端的读取别名。新的 Jaeger UI 会将它们与新追踪一起提供，因此无需复制或重新索引，也不会丢失任何追踪历史记录。
    • 旧版 Jaeger 实例仅作为回滚目标保留，在新管道验证完成后将其移除——不再需要让它存活完整的保留周期。

    有关背景信息、对比表和回滚路径，请参阅底层的 从 Alauda Container Platform Tracing 迁移 指南；本文档重点介绍 Service Mesh 部署中有所不同的步骤。

    迁移期间的追踪中断

    从删除旧版 OpenTelemetryCollector 到将 Istio 资源修补为指向新的 OpenTelemetry Collector 期间，追踪数据接收会中断。应用程序流量不受影响，但此时间窗口内生成的 span 将被丢弃。请在低流量时段安排迁移，并提前通知遥测数据使用者。

    目录

    前提条件迁移操作步骤

    前提条件

    • 集群管理员已通过 cluster-admin 角色建立活动的 kubectl 会话。
    • 使用 Service Mesh 配置分布式追踪平台（已弃用） 中所述的旧版 Service Mesh 追踪堆栈当前已安装，即名为 otel 的 OpenTelemetryCollector 和名为 jaeger-prod 的 Jaeger 实例均在 istio-system 命名空间中运行，并且 Istio 资源定义了一个指向 otel-collector.istio-system.svc.cluster.local 的 otel 扩展提供程序。
    • 已通知遥测数据使用者（开发人员、Kiali 用户、SRE 信息板）和应用程序所有者计划的中断时间窗口。

    迁移操作步骤

    卸载旧版 OpenTelemetry Collector 和 Operator

    v1 和 v2 Alauda Build of OpenTelemetry Operator 共享相同的 CRD，因此必须先移除 v1 Operator，然后才能安装 v2 Operator。旧版 Alauda Build of Jaeger Operator 管理单独的 CRD（jaegertracing.io/v1.Jaeger），因此会继续运行，使旧版 Jaeger 在观察窗口期间继续提供历史追踪。

    1. 删除 istio-system 命名空间中的旧版 OpenTelemetryCollector 实例：

      kubectl -n istio-system delete opentelemetrycollector otel

    2. 在 Web 控制台的管理员视图中卸载 Alauda Build of OpenTelemetry Operator。

      • 从 Marketplace → OperatorHub 中，使用搜索框搜索 Alauda build of OpenTelemetry。
      • 单击 Alauda build of OpenTelemetry 标题进入其详情。
      • 在 Alauda build of OpenTelemetry 详情页中，单击右上角的 Uninstall 按钮。
      • 在 Uninstall "opentelemetry-operator"? 窗口中，单击 Uninstall。

    有关为何必须先移除 v1 Operator 才能安装 v2 Operator，以及由此产生的中断特征，请参阅 Alauda Distributed Tracing 迁移指南中的 将 Alauda Build of OpenTelemetry 迁移到 v2。

    部署新的分布式追踪堆栈

    完成使用 Service Mesh 配置分布式追踪平台中的前提条件部分，以启动 v2 堆栈：

    • 安装 Alauda Build of OpenTelemetry v2 Operator。
    • 部署新的 Jaeger v2 实例（默认为 jaeger-system 命名空间）。
    • 部署 v2 OpenTelemetry Collector（默认为 jaeger-system 命名空间）。

    v2 堆栈与 istio-system 中的旧版 jaeger-prod Jaeger 隔离在不同命名空间中，因此二者可以在观察窗口期间共存。

    NOTE

    完成使用 Service Mesh 配置分布式追踪平台的前提条件后即停止。在迁移期间，网格侧配置（Istio 和 Telemetry 资源）已在旧版安装中就位，并会在下一步通过修补进行更新——不要在迁移期间执行该文档的操作步骤部分。

    将旧版 Elasticsearch 索引附加到新的读取别名

    切换前生成的追踪位于旧版 Jaeger 实例写入的索引系列中。将这些索引附加到新索引系列的读取别名后，即可在新的 Jaeger UI 中查询这些追踪，因此无需继续运行旧版 Jaeger 来响应历史查询。不会复制、重命名或重新索引任何内容，旧版索引仍保持只读。

    请在重新指向网格之前完成此步骤，以确保新的 Jaeger UI 在开始接收 span 时已经包含完整数据。

    按照 Alauda Distributed Tracing 迁移指南中的 将旧版索引附加到新的读取别名 执行，并使用以下两个值：

    • LEGACY_ES_INDEX_PREFIX — 安装旧版 Jaeger 时使用的 --jaeger-es-index-prefix 值（例如 istio-tracing-<cluster>）。请从旧版实例中读取该值，而不要依赖记忆：

      kubectl -n istio-system get jaeger jaeger-prod \
  -o jsonpath='{.spec.storage.options.es\.index-prefix}{"\n"}'

    • JAEGER_ES_INDEX_PREFIX — 在使用 Service Mesh 配置分布式追踪平台中为新的 Jaeger v2 实例选择的前缀。

    两个 Jaeger 实例必须使用同一个 Elasticsearch 集群；如果新实例是针对旧实例的端点安装的，则满足此条件。

    多集群网格

    在多集群网格中，旧版前缀和新版前缀由每个集群共享，因此整个网格只有一个旧版索引系列和一组读取别名。只需附加一次索引，无需为每个集群重复执行。

    将 Istio 扩展提供程序重新指向新的 OpenTelemetry Collector

    修补 Istio 资源，使 otel 扩展提供程序指向 jaeger-system 命名空间中的新 v2 OpenTelemetry Collector，而不是已删除的 istio-system 中的旧版 Collector：

    kubectl patch istio default --type=merge -p '
spec:
  values:
    meshConfig:
      enableTracing: true
      extensionProviders:
      - name: otel
        opentelemetry:
          port: 4317
          service: otel-collector.jaeger-system.svc.cluster.local
'
    WARNING

    此命令使用 JSON 合并修补，会替换整个 meshConfig.extensionProviders 数组。如果 Istio 资源定义了其他扩展提供程序，请使用 kubectl edit istio default 以交互方式编辑该资源，或使用 JSON Patch（--type=json）将内容追加到 /spec/values/meshConfig/extensionProviders/-，以保留这些提供程序。

    应用修补程序并且 Istio 控制平面完成调谐后，sidecar 会将 span 发送到新的 OpenTelemetry Collector，并且新的追踪会显示在 Jaeger v2 UI 中。无需更改 Telemetry 资源，因为它已经通过名称（otel）引用了该提供程序。

    卸载旧版 Jaeger 实例和 Operator

    由于切换前的追踪已附加到读取别名并由新的 Jaeger UI 提供服务，旧版 Jaeger 无需再运行超过保留窗口。仅在需要保留回滚目标期间运行旧版实例，然后将其移除。有关数据连续性模型，请参阅 追踪数据连续性策略。

    删除 Jaeger 资源前先接管保留策略

    jaeger-es-index-cleaner CronJob 由 Jaeger 资源管理，并会随该资源一起被垃圾回收；之后将没有任何机制使旧版索引过期。请先完成 接管旧版索引的保留策略。

    删除 Jaeger 资源不会删除其 Elasticsearch 索引，因此切换前的追踪之后仍可在新的 Jaeger UI 中查询。

    1. 删除 istio-system 命名空间中的旧版 Jaeger 实例及其支持资源。以下资源名称与使用 --target-namespace='istio-system' 的 install-jaeger.sh 生成的默认名称一致；如果在初始安装期间使用了不同的 --jaeger-instance-name，请相应调整这些名称。

      kubectl -n istio-system delete ingress      jaeger-prod-query         --ignore-not-found
kubectl -n istio-system delete podmonitor   jaeger-prod-monitor       --ignore-not-found
kubectl -n istio-system delete jaeger       jaeger-prod               --ignore-not-found
kubectl -n istio-system delete rolebinding  jaeger-prod-rb            --ignore-not-found
kubectl -n istio-system delete role         jaeger-prod-role          --ignore-not-found
kubectl -n istio-system delete sa           jaeger-prod-sa            --ignore-not-found
kubectl -n istio-system delete secret       jaeger-prod-oauth2-proxy  --ignore-not-found
kubectl -n istio-system delete secret       jaeger-prod-es-basic-auth --ignore-not-found
kubectl -n istio-system delete configmap    jaeger-prod-oauth2-proxy  --ignore-not-found

    2. 在 Web 控制台的管理员视图中卸载 Alauda build of Jaeger Operator。

      • 从 Marketplace → OperatorHub 中，使用搜索框搜索 Alauda build of Jaeger。
      • 单击 Alauda build of Jaeger 标题进入其详情。
      • 在 Alauda build of Jaeger 详情页中，单击右上角的 Uninstall 按钮。
      • 在 Uninstall "jaeger-operator"? 窗口中，单击 Uninstall。

    当旧版索引按照上述策略过期后，请按照 Alauda Distributed Tracing 迁移指南中 禁用旧版功能开关并停用旧版索引系列 的说明，移除遗留的索引模板和仅删除策略。该文档中提到的 acp-tracing-ui 功能开关属于平台追踪堆栈，不适用于 Service Mesh 部署。