如何在 Istio 中集成第三方服务注册表？

查看本文大纲

Istio 依赖 Kubernetes 来进行服务发现，这通常意味着必须在 Kubernetes 集群中部署微服务并使用 Kubernetes 服务发现。然而，很多现有的微服务项目还在使用如 Consul、Eureka 这样的第三方服务注册表，本文将探讨如何将这些现有的微服务的注册表与 Istio 集成。

Istio 对非 Kubernetes 服务的支持

Istio 最初只支持 Kubernetes 服务，但随着时间的推移，为了适应更广泛的应用场景，它开始支持像 Consul 这样的第三方服务注册表。通过引入 Mesh Configuration Protocol（MCP），Istio 能够与各种服务发现后端通信，如 Consul，从而管理非 Kubernetes 环境中的服务。在 Istio 1.1 版本中，引入了 ServiceEntry 资源对象，这使得用户可以手动将外部服务添加到 Istio 的服务注册表中，并在 Istio 1.8 中取消了对 Consul 的直接支持，转而通过 ServiceEntry 提供了一种更灵活的方式来集成和管理所有服务，无论它们是否托管在 Kubernetes 上。

Istio 代理配置的高层架构

下图展示了 Istio 代理配置的高层架构，揭示了配置如何从各种源被摄取、转换，并最终服务于 Envoy 代理。

要想详细了解 Istiod 的架构，可以参考 Istio 架构详解。

配置摄取过程详解

ConfigStore: 负责读取多种类型的资源并进行聚合。包括：
- XDS Client: 通过 xDS 协议读取资源。
- CRD Client: 从 Kubernetes 自定义资源定义（CRD）读取资源。
- Filesystem Client: 从文件系统读取资源。
ServiceDiscovery: 聚合面向服务的内部资源。使用的组件包括：
- Kube Controller: 依据 Kubernetes 核心类型运行。
- ServiceEntry Controller: 依据 Istio 类型运行。

配置翻译与服务

配置从 ConfigStore 和 ServiceDiscovery 聚合后，由 Config Translator 翻译成适合代理的格式，然后通过 XDS Server 服务于 Envoy 代理。这是将动态配置应用于代理的最终步骤。

第三方注册表同步

为了集成第三方服务注册表，我们可以实现一个 Operator，该 Operator 监视第三方服务注册表并将服务以 ServiceEntry 和 WorkloadEntry 资源形式推送至 Kubernetes API 服务器。以下流程图展示了该同步过程。

第三方服务注册表同步的步骤说明

Operator 向第三方服务注册表发起查询请求。
第三方服务注册表返回当前注册的服务数据。
Operator 将服务数据转换为 Istio 的 ServiceEntry 对象。
Operator 将 ServiceEntry 推送至 Kubernetes API 服务器。
Kubernetes API 服务器将变更通知 Istiod。
Istiod 更新 Envoy Proxies 的配置。
Operator 定期检查第三方服务注册表以监控服务变化，发现变更后更新 ServiceEntry 并重新推送至 Kubernetes API 服务器，完成服务同步。

Istio Registry Sync

Tetrate 开发的 Istio Registry Sync 是一个扩展 Operator，可以作为 TIS 的 add-on 运行。它支持非 Kubernetes 服务注册表（如 AWS Cloud Map 和 Consul）与 Istio 的集成。此工具提供了以下几个使用场景：

混合应用集成: 在混合环境中，如使用 Consul 的传统应用与 AWS Cloud Map 中的微服务可以通过 Istio Registry Sync 实现无缝的服务发现。
动态端点管理: 在服务频繁扩缩的环境中，Istio Registry Sync 能快速反映来自配置注册表的变更，确保 Istio 服务网格中的流量管理策略准确有效。
统一的监控与安全态势: 通过将所有环境的服务集成至 Istio，可以利用 Istio 提供的服务健康指标和统一的安全协议，如 mTLS，确保跨所有服务的加密和认证通信。

总结

通过上述方法，你可以有效地将 Istio 与第三方服务注册表集成，无论是通过开发自定义的 Operator 还是使用现成的 Istio Registry Sync 工具。这样不仅能够保持服务的现代化，还能确保在不同环境之间的高效协同工作。