How to choose an API gateway in Kubernetes?

Question

We've used Zuul as API gateway for a while in Microservices scene, recently we decided to move to Kubernetes and choose a more cloud native way.

After some investigation and going through the Istio docs, we have some questions about API gateway selection in Kubernetes:

• Which aspects should be considered when choosing an API gateway in Kubernetes?
• Do we still need Zuul if we use Istio?

Gravimetric

Answer 1

I assume that Zuul offers a lots of features as an edge service for traffic management, routing and security functions. It has to declare API Gateway the main point of accessing microservices by the external clients as per Microservice Architecture pattern Design. However, Zuul needs to somehow discover underlying microservices and for Kubernetes you might need to adapt Kubernetes Discovery Client which defines the rules how API Gateway will detect routes and transmit network traffic to the nested services.

As per design, Istio represents Service mesh architecture and becomes Kubernetes oriented solution with smooth integration as well. The main concept here is using advanced version of Envoy proxy by injecting sidecars into Kubernetes Pods with no need to change or rewrite existing deployment or use any other methods for service discovery purposes. Zuul API Gateway can be fully replaced by Istio Gateway resource as the edge load balancer for ingress or egress HTTP(S)/TCP connections. Istio contains a set of traffic management features which can be included in the general configuration.

You might be interested with other fundamental concepts of functional Istio facilities like:

• Authorization model;

• Authentication policies;

• Istio telemetry and Mixer policies.

Blacksnake

Answer 2

We use Kong Gateway. It's pretty simple and nginx based gateway. Easy to install and ready-to-go.

Gilthead

running kong production ? how much traffic you are handling and which type of kong deployment are you using ? with db or stateless ? – Andaman