Alauda Service Mesh v2 Docs
  • 简体中文

    • 迁移到 Jaeger v2

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

    迁移后：

    • 新的追踪数据由 v2 OpenTelemetry Collector 接收，并存储在新的 Jaeger v2 后端中。
    • 切换前生成的追踪数据仍保留在旧版 Elasticsearch 索引中，这些索引会关联到新后端的读取别名。新的 Jaeger UI 会同时显示这些数据和新的追踪数据，因此无需复制或重新索引，也不会丢失任何追踪历史记录。
    • 旧版 Jaeger 实例仅作为回滚目标保留，待新管道验证通过后即可移除——无需再等待完整的保留期限。

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

    迁移期间追踪服务会中断

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

    目录

    前提条件迁移操作步骤

    前提条件

    • 集群管理员已通过 kubectl 登录，且具有 cluster-admin 角色。
    • 当前已安装使用 Service Mesh 配置分布式追踪平台（已弃用）中介绍的旧版 Service Mesh 追踪堆栈——即 OpenTelemetryCollector（名称为 otel）和 Jaeger 实例（名称为 jaeger-prod）均在 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 控制台的 Administrator 视图中卸载 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 Container Platform Application Observability（之前为 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 不再需要存活整个保留期限：将索引关联到读取别名后，切换前的追踪数据会由新的 Jaeger UI 提供。仅在需要保留回滚目标时继续保留旧版实例，然后将其移除。有关数据连续性模型，请参阅 追踪数据连续性策略。

    删除 Jaeger 资源前先移交保留管理

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

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

    1. 删除 istio-system 命名空间中的旧版 Jaeger 实例及其支持资源。以下资源名称与 install-jaeger.sh 配合 --target-namespace='istio-system' 生成的默认名称一致；如果原始安装期间使用了不同的 --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 控制台的 Administrator 视图中卸载 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 部署。