Istio and managing microservices

More and more users have moved to microservices architecture for their applications, and this brings challenges as to how to manage these microservices efficiently. Istio is an open technology that provides a way to connect, secure, control, and observe networks of different microservices, regardless of platform, source, or vendor.

Istio relies heavily on the Kubernetes service registry and discovery. It will, by default, manage all services running on Kubernetes clusters. The reality is that a lot of users are depending on some framework for their microservices development and service registry and discovery. Spring Cloud and Apache Dubbo are two typical examples. These services might also be running outside of Kubernetes clusters. In that scenario, how can they move to the Istio service mesh without modifying their code and deployment model? In this post, I will share a solution.

Implement an MCP server and plug it into Istio

Starting from Istio 1.0, it has supported MCP (Mesh Configuration Protocol) for configuration distribution. This opens the door for easily integrating external systems. We can implement an MCP server by ourselves and easily plug it into Istio. This MCP server provides two major functions:

• Connect and monitor the external service registry system to get the latest service info (e.g., Eureka Server in Spring Cloud and Zookeeper for Apache Dubbo).
• Convert the external service info into Istio ServiceEntry and publish it through MCP resources.

The only thing you need to change from the Istio side is to add this MCP server address into the Istio config map. The following is a snippet for the sample configuration change:

configSources:     – address: istio-galley.istio-system.svc:9901     – address: 9.119.56.229:9902

The following diagram shows architecture for the solution:

So what are the key points when implementing an MCP server?

MCP server

An implementation for an MCP server is actually in Istio Galley, meaning we can reference it and implement our own MCP server. The key takeaways I want to highlight are as follow:

• Define the resource collection we want to monitor in our MCP server. In our case, we are monitoring all Istio supported collections:

coptions := source.CollectionOptionsFromSlice(metadata.Types.Collections())

• Define a Watcher for the MCP server which will set the MCP resources dynamically.
• Define other server options (e.g., rate limit,  AuthChecker, etc.).

Move to Istio without any code or deployment model changes

By defining our own MCP server, we allow users to move to the Istio service mesh without any code and deployment model changes. This means we can easily use Istio to control, observe, connect, and secure services running outside Kubernetes clusters.

Learn more

• IBM Cloud Kubernetes Service
• Managed Istio on IBM Cloud