Istio Service discovery

Question

I'm trying out a very simple Istio setup on a Docker Desktop Kubernetes installation.

I have 2 Spring boot micro services and have deployed these 2 services in my K8s "cluster" without any replication. All I have in my YAML file is the Service and Deployment for both services.

I have installed istio and I can see there are 2 containers in my pod. One is the spring boot application, the other is the istio sidecar.

I am making a rest call from service 2 to service 1 like this and it works fine.

restTemplate.exchange("http://service1:8080/getSomeString", HttpMethod.GET, null, String.class, new Object()).getBody();

However, now if I disable sidecar injection and rededloy me services, it still works fine. Basically it is Kubernetes that is resolving where service1 is and completing the rest call and Not istio.

How do I do service discovery using istio ?

Answer 1

Istio is a Service Mesh, as such it isn't responsible for service discovery. A service mesh adds functionality to the Service -> Service traffic (monitoring, routing, etc). So when running on a Kubernetes cluster, Kubernetes continues to be responsible for service discovery, as you've observed.

As Arghya's answer states, with Istio you can apply a VirtualService on top of this, which allows you to do "clever" additional features such as custom routings, but this in no way replaces or changes the functionality of the underlying Kubertetes Service Discovery.

In my opinion, VirtualService is a confusing term because it sounds like it's somehow replacing Kubernete's existing features. I prefer to think of a VirtualService as "Custom Routing".

By the way, you only need a virtualservice if you need one. By which I mean, you might have 1,000 services defined in your cluster (using the normal Kubernetes Service construct). But perhaps you want to apply custom routing rules to just one service - that's fine, you just define 1 VirtualService in Istio to handle that.

Answer 2

In Istio you can use virtual service for traffic management. Address multiple application services through a single virtual service. If your mesh uses Kubernetes, for example, you can configure a virtual service to handle all services in a specific namespace. Mapping a single virtual service to multiple “real” services is particularly useful in facilitating turning a monolithic application into a composite service built out of distinct microservices without requiring the consumers of the service to adapt to the transition. Your routing rules can specify “calls to these URIs of monolith.com go to microservice A”, and so on. You can see an example of how this works.