How does service communication work?

1

Hey, I have watched the following presentation [https://www.youtube.com/watch?v=k42jqkjtYKY](Ray’s Istio Intro) by Ray Tsang about Istio and would like to know how service communication works. In particular:

  1. The code to make a service call. Locally to make a call from Service A to Service B you set a port and endpoint address but when deployed you would not know this since they are dynamic. So how do you call Service B? A C# example would be nice :slight_smile:
  2. Istio injects a sidecar proxy service that intercepts all service communication. How does Istio route the call from Service A to an instance of Service B?
  3. How does the sidecar proxy know to which service the request is made? Service A could call a Service B,Service C etc

Screenshot from Ray’s presentation:

Service A calls Service B

2

When Istio is put on your cluster subsequent pods are started with an init container that configures IP so that all traffic goes to localhost:15001 no matter where it was supposed to go
Note: localhost traffic unaffected, traffic from user 1337 unaffected

Pods have a sidecar with Envoy running at localhost:15001 as user 1337
Envoy thus sees all the packets and can do whatever it wants
Every Envoy in your mesh is configured by Istio. Istio watches all pods and services.

Envoy has captured all the traffic. So when A calls B then A’s proxy sees the “HOST: B” header and it has been told by Istio that pods at for example 10.10.0.1 and 10.10.0.5 match B’s selector. Envoy will send traffic with the “HOST: B” header to those pods directly.

In Istio 1.0, every sidecar knows about every service. When service A starts calling service C the sidecar already knows the IP addresses of service C.

There might be another service, D, which never calls A, B, or C but it’s sidecar is configured for them anyway.

1 Like
3

Thanks for the reply! If I understand correctly then Istio will automatically route all traffic correctly between services. The only thing unclear to me is coding it. Below is a C# code example that makes a service call to a GRPC service which reverses text in a localhost environment:

private static void Main()
        {
            var channel = new Channel("127.0.0.1:50051", ChannelCredentials.Insecure);

            var client = new ReverseService.ReverseServiceClient(channel);

            var reply = client.ReverseString(new ReverseRequest
            {
                Data = "Hello, World"
            });

            Console.WriteLine("Got: " + reply.Reversed);

            channel.ShutdownAsync().Wait();

            Console.WriteLine("Press any key to exit...");
            Console.ReadKey();
        }

If deployed to production would you initialize the ReverseService.ReverseServiceClient without specifying a channel? Or will Istio override the channel’s IP and port behind the scenes and the code above will work as is?

4

I am not a C# user but I see that you have a channel open to 127.0.0.1. Istio does not get involved in localhost traffic and will not touch the communication here.

I expected to see something like “service-b:50051” instead of “127.0.0.1”.

5

Ahh, ok so you would use “service-name:port” in a production environment. I assume Istio will then lookup the active service instances which have that name and what their IP addresses are. Then depending on the load balancing setup select a service and send the request to it