从 MeshConfig 迁移到 Istio Telemetry API：提升网格观测性和灵活性

通过迁移到 Telemetry API 配置 SkyWalking 提供商，从而提升 Istio 网格的追踪能力和灵活性。

阅读原文请转到：https://jimmysong.io/blog/migrate-to-istio-telemetry-api/

Istio 的 Telemetry API 是替代传统 MeshConfig 遥测配置的现代化方式，提供了更灵活的工具来定义服务网格中的 Tracing、Metrics 和 Access Logging。相比传统的 EnvoyFilter 和 MeshConfig，Telemetry API 更具模块化、动态更新和跨层次配置能力。

在本篇中，我们将详解如何使用 Telemetry API 配置 Istio 遥测功能，涵盖 Tracing、Metrics 和 Logging 的具体实现，同时展示如何迁移过时的 MeshConfig 配置。

Telemetry API 发展历程

Istio 的遥测能力在早期版本中依赖于较为传统的配置方法，如 Mixer 和 MeshConfig 的 configOverride，这些方法虽然能够满足基本需求，但在复杂场景下显得力不从心。为了解决这些问题，Istio 引入了基于 CRD 的 Telemetry API。

关键版本更新

为了帮助读者了解 Telemetry API 的进化过程，以下是一些重要版本的更新信息：

1. 1. Istio 1.11：引入 Telemetry API（Alpha），提供了基本的指标和日志自定义功能。

2. 2. Istio 1.13：支持 OpenTelemetry 日志记录、自定义追踪服务名称，以及更强的日志过滤功能。

3. 3. Istio 1.18：默认不再安装 Prometheus 的 EnvoyFilter，完全依赖 Telemetry API 定义遥测行为。

4. 4. Istio 1.22：Telemetry API 升级为稳定版（v1），全面支持生产环境需求。

为什么迁移到 Telemetry API？

尽管传统的 MeshConfig 和 EnvoyFilter 提供了基础的遥测能力，但它们的配置方式在灵活性、动态性和扩展性方面存在诸多限制。为了更清晰地理解这些局限性，我们将从几个关键维度展开说明。

使用 MeshConfig 和 EnvoyFilter 的复杂性

在介绍具体问题之前，我们先了解一下 MeshConfig 和 EnvoyFilter 的定位：MeshConfig 适用于全局配置，而 EnvoyFilter 用于细粒度的自定义。但正是这种分工，导致了它们在管理上的复杂性。

1. 配置方式分散

• • MeshConfig 用于集中定义全局网格行为，例如访问日志路径、追踪采样率和指标维度。虽然适合简单场景，但无法满足命名空间级或工作负载级的需求。

• • EnvoyFilter 则可以覆盖或扩展 Envoy 的配置，允许更细粒度的控制。但这种方式直接操作 Envoy 内部结构（xDS 字段），配置语言复杂且容易出错。示例࿱