Istio relies on Kubernetes for service discovery, which generally means that microservices must be deployed within a Kubernetes cluster and use Kubernetes service discovery. However, many existing microservice projects still utilize third-party service registries like Consul and Eureka. This article will explore how to integrate these existing service registries with Istio.

Support for Non-Kubernetes Services in Istio

Originally, Istio supported only Kubernetes services, but over time, to accommodate a broader range of application scenarios, it began supporting third-party service registries like Consul. By introducing the Mesh Configuration Protocol (MCP), Istio was able to communicate with various service discovery backends, such as Consul, thereby managing services in non-Kubernetes environments. With the introduction of the ServiceEntry resource in version 1.1, users were able to manually add external services to Istio’s service registry. By version 1.8, direct support for Consul was removed in favor of a more flexible approach through ServiceEntry, allowing the integration and management of all services, whether hosted on Kubernetes or not.

High-Level Architecture of Istio Proxy Configuration

The following diagram illustrates the high-level architecture of Istio proxy configuration, showing how configurations are ingested, transformed, and ultimately served to the Envoy proxies.

Detailed Process of Configuration Ingestion

• Configuration Storage: Responsible for reading various types of resources and aggregating them. Includes:
  • XDS Client: Reads resources via the xDS protocol.
  • CRD Client: Reads resources from Kubernetes Custom Resource Definitions (CRDs).
  • Filesystem Client: Reads resources from the filesystem.
• Service Discovery: Aggregates service-oriented internal resources. Components used include:
  • Kube Controller: Operates based on core Kubernetes types.
  • ServiceEntry Controller: Operates based on Istio types.

Configuration Translation and Service

After aggregating configurations from Configuration Storage and Service Discovery, the Configuration Translator translates them into a format suitable for the proxies, which are then served by the XDS Server. This is the final step in applying dynamic configurations to the proxies.

Synchronization of Third-Party Registries

To integrate third-party service registries, we can implement an Operator that monitors third-party service registries and pushes services in the form of ServiceEntry and WorkloadEntry resources to the Kubernetes API server. The following flowchart illustrates this synchronization process.

Steps for Synchronization of Third-Party Service Registries

1. The Operator initiates a service query to the Third-Party Service Registry.
2. The Third-Party Service Registry returns the current registered service data.
3. The Operator transforms the service data into Istio’s ServiceEntry objects.
4. The Operator pushes the transformed ServiceEntry to the Kubernetes API Server.
5. The Kubernetes API Server notifies Istiod of the changes.
6. Istiod updates the configurations of the Envoy Proxies.
7. The Operator regularly checks the Third-Party Service Registry to monitor service changes, updating the ServiceEntry and re-pushing it to the Kubernetes API Server upon detection of changes, thus completing the service synchronization.

Istio Registry Sync

Developed by Tetrate, Istio Registry Sync is an extension operator that can run as an add-on for TIS. It supports the integration of non-Kubernetes service registries (such as AWS Cloud Map and Consul) with Istio. This tool provides several use cases:

• Hybrid Application Integration: In hybrid environments, traditional applications using Consul and microservices in AWS using Cloud Map can achieve seamless service discovery through Istio Registry Sync.
• Dynamic Endpoint Management: In environments where services frequently scale, Istio Registry Sync quickly reflects changes from the configured registry, ensuring accurate traffic management strategies within Istio’s service mesh.
• Unified Monitoring and Security Posture: By integrating services from all environments into Istio, it leverages service health metrics and a unified security protocol, such as mTLS, to ensure encrypted and authenticated communication across all services.

Conclusion

Through the methods described above, you can effectively integrate Istio with third-party service registries, whether by developing a custom Operator or using the ready-made Istio Registry Sync tool. This not only maintains the modernization of services but also ensures efficient collaboration across different environments.

References

• Istio Pilot Architecture - github.com
• Istio Registry Sync Documentation - docs.tetrate.io

This blog was initially published at tetrate.io.