Realizing a gRPC client-server communication in kubernetes using Istio

Well this was in my draft for a long time!
I had been working on developing and deploying applications on kubernetes for quiet sometime now and I love doing it so much so that I recently appeared for and cleared my kubernetes certified developer exam. I have written a blog on how to prepare for the same here.

Most of the times the deployed application in kubernetes cluster is expected to have inbound communication traffic with service type of ClusterIP. But in the scenarios where the client and server reside in different networks the service Type NodePort is required to realize a connection between the two parties.

Image credit: grpc.io

A gRPC based connection requires a service definition on both sides via proto files and supports HTTP/2 based transport over the internet. Now the question arises that any incoming request into the cluster requires to be load balanced. For a kubernetes cluster, there are many load balancing solution available like GCE, HAProxy, Istio, trafeik etc.

NOTE: One key thing to note here is that the load balancing and SSL authentication etc. can be done at the service level itself but that will be a lot of configuration at the service end and is not easily maintainable when application are scaled. However maintaining it at the cluster level is rather a good architecture decision and should be promoted amongst developers.

Going back to the load-balancing configuration at the cluster level, Istio-ingress is a choice I have made amongst the existing ingress controller supported by Kubernetes for this article for the traffic management to and from a cluster. Adding Istio to a gRPC architecture can be useful for collecting telemetry, adding traffic rules, and setting RPC-level authorization. It is also useful for scenarios where traffic is a mix of HTTP, TCP etc.

To begin visualizing the gRPC traffic with Istio, I have created the below diagram which helps to envisage how a gRPC client request is routed via Istio service mesh to interact with a gRPC server hosted within the cluster.

Let’s take a look on some of the key points for each of the primary istio objects used to make this connection possible:

• Gateway: This Istio object will do the ingress routing at the doorstep of the cluster service. Make sure to include the protocol name as GRPC for the port which is exposed over the Istio ingress gateway.
• VirtualService: The details of the routing rules like matching Uri, destination/hosts within the cluster, port etc. are defined in here. The port here should match to the one specified in the gateway configuration.
• Service: Kubernetes service should provide the port and targetPort configuration for each of the endpoints and may have multiple ports as per the design.
• DestinationRule: In this Istio object once the routing is done, the next immediate operations of the connection request are configured. It could vary from configuring load Balancing policy like ROUND_ROBIN or LEAST_CONN or specifying the paths of ca certs, pem files etc. in addition to the mentioning connection-pool size at the service level.
• AuthorizationPolicy : To have each gRPC method authorized for different actions like ALLOW, DENY or CUSTOM can be configured in this file so that we have control to provide access to all eligible endpoints within a microservice like those of performance metrics or actual service endpoint etc. again as per the design.
• RequestAuthentication : This object covers the security aspect of any request within the cluster. Any incoming request which is not having a valid token from the issuer mentioned in this file would be considered a bad request and would result in gRPC error code 7: Permission Denied.

Summary: When trying to configure communication using NodePort or LoadBalancer type of service in kubernetes then Istio is a very popular open-source service mesh to manage the communication, observability, error handling, security etc. as a cross cutting topic that come as part of the microservice architecture. Instead of populating the code of each microservice with duplicate logic, Istio service mesh can be leveraged to do all these things at one place.