Should Kubernetes Ingress lives together with a Spring Cloud Gateway?

4.7k views Asked by At

Small architecture and design question please.

Question: Should Kubernetes Ingress lives together with Spring Cloud Gateway? If not, which one should be preferred?

First, with a Spring Webflux / Spring Cloud Gateway project, I managed to have working route-based forwarding. Meaning, all my clients only need to know this one and only Spring Cloud Gateway endpoint, and the Spring Cloud Gateway will forward to serviceA if the URL contains serviceA, to serviceB if serviceB, etc, straightforward.

I added some more “software level features” such as dynamic configuration (to change the routes at runtime), circuit breaker, rate limit, bulkhead, and few others features, very cool, but really, I ended up using the route forwarding as a main feature.

Then couple of weeks back, I spent time studying Kubernetes, and more precisely Kubernetes Ingress. I managed to learn Kubernetes Ingress is a very cool and strong thing. I managed to perform at least the route based forwarding. Meaning, clients needs to only know this one and only Ingress endpoint, and the Ingress will forward to underlying services within the Kubernetes cluster. Where as of now, it forwards everything to Spring Cloud Gateway, which will forward to everything else. I tried, and it could have forwarded to the real business services in the first place).

And this is the moment where I am having doubts.

Did I just duplicate work? (I mean in terms on functionally, I had fun learning both).

Should I consider an architecture where the Spring Cloud Gateway (only him) is really doing the gating?

Should I consider an architecture where both the Ingress and the Software Gateway have full importance, configuring features in both? (Accept the duplicated work?)

Should I remove the Spring Cloud Gateway entirely?

Thank you

1

There are 1 answers

4
denizg On BEST ANSWER

In my opinion, Kubernetes must lives together with Spring Cloud Gateway.

Reverse proxies has capabilities like central logging, security, caching, routing, traffic management features etc, but there are also things they cannot do. API Gateways come into play at this point. They have all the features of reverse proxies, plus they have extra capabilities that they can't. For this reason, API Gateways are called enhanced reverse proxies.

So Kubernetes ingress acts like reverse proxy, while Spring Cloud Gateway is implementation of API Gateway pattern. As I mentioned in the definition above, I can say few things you can't do with Kubernetes.

  • Can you implement API composition? No
  • Can you implement JWT authentication by Kubernetes? If so, Can you carry JWTs more than 8 KB to downstream service by Kubernetes? No
  • Can you combine all Swagger/Open API documentation by Kubernetes? No