Using Istio and Kong in Kubernetes Cluster

This document discusses using istio and kong in the same kubernetes cluster. We will discuss about how istio service mesh is different from kubernetes, what are the advantages and shortcoming of istio and how kong is resolving them so that we can have a more secure service to service communication in our kubernetes cluster. This document assumes that you are familiar with Kubernetes, Istio, and Kong API gateway.

Introduction

We are all familiar with Kubernetes and what benefits it is providing to us. Traffic management is something which is a key part of kubernetes cluster, and when we talk about traffic management in kubernetes, istio is probably the first term that coins in our minds.
Let’s discuss in detail how istio and Kong both can be installed over the same cluster and how we can use both of them in order to make service to service communication more reliable and secure.

One question that can come to your mind is why we chose istio and kong only, as there are quite a lot of service mesh and API gateways available in the market. This is because istio and kong are the most popular one’s and both have security features that are easily customizable. Depending on what product use case you have, you can use either istio or kong or both. We will help you choose which solution to go for. We will also discuss about what are the key focus areas that need to be taken care of while choosing service mesh.

Choosing a service mesh

It is not necessary every time to have service mesh in the kubernetes cluster. It is something that depends on how much observability we want out of our infra and platform. There are certain parameters that need to be evaluated before choosing a service mesh for a kubernetes cluster

1. Features : Some service mesh provides features like canary, blue/green, and traffic mirroring it depends on the user how much feature rich service mesh the user wants to have.
2. Cost : When talking about cost, it is not the physical cost, but it is how much effort one needs to put in on order to upgrade or maintain that service mesh.
3. Network Isolation : Network isolation is the primary requirement of every network, It is about how much access we want to provide to our gateways and services.

These are primary criteria to be considered while choosing a service mesh. There can be more dependent factors according to product needs.

Installing Istio in Kubernetes Cluster

to install Istio in the kubernetes cluster, follow this article:- https://istio.io/latest/docs/setup/getting-started/

Installing Kong API Gateway in Kubernetes Cluster

to install Kong API Gateway in the kubernetes cluster, follow this article:- https://docs.konghq.com/gateway/3.1.x/install/kubernetes/helm-quickstart/

Istio Service Mesh vs. Kubernetes

Traffic Forwarding

Istio allows us to use one sidecar per pod, which communicates to control plane and other sidecars in the same service. Istio control plane then communicates to kubernetes api server so each sidecars does not directly goes to control plane. Istio sidecar (istio data plane) also communicates with one another without interacting with istio control plane.
While kubernetes has kube-proxy running on each node, which communicates to kubernetes api server. It then gets the service communication information from Kubernetes API server and sets iptables rules to send requests.

Traffic Forwarding

Service Discovery

Service discovery in istio is significantly smooth as compared to kubernetes because istio sidecar proxy intercepts traffic to and from pods, while kubernetes kube-proxy intercepts traffic to and from nodes. Istio is here helped by its underlying envoy proxy, which acts as a transparent proxy network as the application has no idea about proxy configuration.

Advantages of Istio

1. Istio service mesh takes control over the service layer in the kubernetes cluster, providing more elasticity to configurations at a granular level.
2. Istio also has concepts of envoy filters, which allows us to modify our istio control plane sidecar proxy generation mechanism to provide more control on how we want to configure request/response filters according to our needs.
3. It reduces stress on the main kubernetes cluster as traffic management is now taken care of by istio.
4. We can use canary, blue/green, red/black, traffic mirroring, circuit breaking, dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxies and fault injection quite easily so that our application deployment can be checked and updated using these mechanisms.
5. Authorization filters can be used over ingress and egress gateway for header based traffic routing.
6. Istio allows us to develop microservices that are loosely coupled.

While istio provides us quite a lot of stuff, but there are certain features it is still lacking

1. When traffic is already routed to a pod via istio ingress gateway, then request can only be validated by application. This causes issues sometimes as we might need to authenticate users at gateway level only.
2. We can not alter the request or response when the request is inside the istio service mesh.
3. We can use JWT tokens in istio, but we can only use the CRD’s that are provided by istio.
4. It is tedious to ensure that istio setup is correct and communication is encrypted.
5. Adding proxies can be a challenge as it makes infrastructure more complex, which results in low visibility.

Using Kong in Kubernetes cluster

Kong is an API gateway that is lightweight, fast, and flexible as it has a concept of customizable plugins based on your security, resiliency, observability, and traffic control needs.

Kong API Gateway has this unique capability of running in front of the RESTful API of application. This can be achieved by using different modules and plugin support that Kong provides. It is designed in a decentralized way so that it can be used with other service mesh as well. Unlike istio, which uses envoy proxy, kong uses NGINX at its base. One can also use NGINX service mesh along with Kong API Gateway.

Kong vs Istio

Kong is an API gateway which allows us to play with request or response coming from application while Istio is a service mesh which doesn’t allow us to play with request or response coming out from application at any point.

Kong can be used as an addition to istio service mesh or any service mesh in order to provide more security, resiliency, and observability.

Kong API Gateway and Istio service mesh can be combined to provide more control over service connectivity.

Kong allows us to use application level policies while istio allows us to have routing level policies only.

Kong API Gateway linking to Istio Service Mesh

So we can conclude here that there is no Kong API Gateway vs Istio Service Mesh as both provide features that help in inter-service communication in a more secure way.

How Kong is dealing with shortcomings of Istio Service Mesh

1. Kong API Gateway uses plugins like request and response transformer, which gives us the capability to change or update requests and responses on kubernetes service, gateway routes, and Kong consumer plugins.
2. It can also be used to restrict or block requests going out or coming in to the desired IP’s.
3. Kong Consumer API can be used to authenticate multiple services inside of kubernetes cluster based on API keys that can also be generated to ensure service to service encryption.
4. We can leverage Kong API Plugin’s to fully utilize JWT authentication according to product needs, and for that, no custom CRD’s are required over here.
5. Kong API’s observability allows us to check that communication and setup doesn’t have any issues.
6. We can also enforce application level policies like validating requests and responses, etc.
7. Kong also has capabilities like GraphQL caching and routing to intermediary HTTP proxies.

Conclusion

Istio and Kong API gateway can be used hand in hand wherever we want to increase service to service communication security, resilience, and observability. Kong API gateway and Istio based system will look something like the diagram

Kubernetes Cluster with Kong and Istio

In this architecture request which is going to pod-1 is via Istio Ingress gateway, virtual service, service and destination rule, while request which is going to pod-2 is traversing via Kong API Gateway and then request which is going to pod-3 can be served via both Kong API gateway and Istio Gateway. We can have authentication at Istio Gateway as well as Kong API Gateway levels.

For Example:- In an online shopping application, your catalog will be served by pod-1 along with user registration and login, user information validation like credit card details and address validation will be done by pod-2 and final order placing or cart checkout will be done by pod-3.

So when the user is browsing, pod-1 will be responsible for that, and when the user is providing or validating sensitive information like credit card details and address, then pod-2 will be responsible. User sessions generated by pod-1 are authenticated by Kong API Gateway and Istio gateway before request reaches pod-2 and pod-3, respectively. We have already validated that the user is already authorized for shopping.

When the user is checking out directly or finally placing the order, pod-3 will be responsible. There are 2 flows from which the user can come:

1. The user is directly checking out the cart (express checkout) where the user is not validating any info he is simply placing the order. In that case, the user will be directly taken to pod-3 with istio gateway authentication for express checkout.
2. The user is validating delivery address and credit card information (normal checkout) where the user is verifying or checking the information provided at the time of signup. In that case, Kong API Gateway had already authenticated the information. Then API Gateway simply forward that authentication information to pod-3 for smoother checkout.

This way, both the Istio and Kong API gateway can be utilized with application, and data can be authenticated in a more secure way.