Search code examples
kubernetesmicroservicesreverse-proxykubernetes-ingressapi-gateway

API gateway in kubernetes environment

I am still learning about microservices architecture and can't get a clear idea how to tackle a given problem.

Let's say I have a k8s cluster with some BE microservices, FE app or any other services deployed into it. I have also an ingress controller that does consumes traffic and route to services.

Somewhere inside that setup I would like to put API gateway, which would do some additional (customizable) stuff on the requests like authentication, logging, adding headers etc. We could wrap up this functionality as a reverse-proxy for the whole cluster. I have found three possible solutions:

AGW outside cluster in front of Ingress:

Approach 1

AGW as an Ingress Controller:

Approach 2

AGW inside cluster after Ingress:

Approach 3

In first approach AGW routes all traffic to ingress, but then we need to have a "private domain" that ingress will be exposed under. AGW will be exposed under public domain and route traffic to this private domain. That is not great, because Ingress is not exposed under the public domain. E.g. we faced a problem, when Ingress was doing some redirects and was using it's private domain in Location header instead of the public one.

In second approach AGW functionality is embedded in Ingress Controller, however I haven't find a suitable controller for our need. Building a custom Ingress Controller doesn't sound too good.

In third AGW is inside cluster, but then Ingress is not doing any routing. All routing (and load balancing) will happen in AGW.

Are there any other solutions? If not which of them would you recommend? Or maybe there is a different approach to included mentioned reverse-proxy funcionality?

Solution

  • The second and third solution usually works best. The Ingress doesn't loadbalance, it's the service objects that configure the loadbalancing rules.

    If you can manage to use an Api Gateway as Ingress Controller, like ambassador, or Istio (those are the ones I know about), that would be even better. You will remove an additional extra network hop.
    Because ambassador and Istio are kubernetes minded, using kubernetes Resource objects, you can control whatever you like using those Ingress Controllers.