Hey everyone! I'm in the process of deploying a demo microservices application that consists of 11 different services on AWS EKS. For this setup, I'm utilizing an NGINX Ingress Controller with an NLB for public-facing traffic, and I plan to implement another NGINX Ingress Controller with a separate NLB for internal tools like Grafana, which will be accessed via private Route53 and VPN only.
Right now, I'm contemplating whether I should create one ingress resource for 2-3 of my microservices or if it's better to consolidate all 11 services into a single ingress resource. Cramming all 11 `path` rules into one Ingress manifest seems messy, even if it's technically feasible. Additionally, I'm curious if having two ingress controllers (one for public access and one for internal use) is a production-ready approach. I appreciate any insights on how you've managed similar setups!
5 Answers
Using two ingress controllers is definitely production-friendly! In larger setups, it helps to separate concerns—like having a dedicated internal ingress controller for tools accessed only within a private network, and another for your public-facing apps. For your setup with just 11 microservices, it might make sense to group related services into 2-3 ingress resources instead of putting everything into one giant ingress. This keeps things clean and manageable, and avoids maintenance headaches later on.
If you're using NLB, you might not be gaining much for your use case. I suggest consolidating all your microservices under a single ALB instead. It saves costs and simplifies routing without losing any benefits. Multiple ingress resources can add unnecessary expenses and complexity.
It's all about how you structure your microservices. If they're organized into different namespaces, it's practical to create an Ingress resource per namespace. For example, if you have two services in one namespace, say 'webapp1' and 'webapp2', you could route them with prefixes like [example.com/w1](http://example.com/w1) for 'webapp1' and [example.com/w2](http://example.com/w2) for 'webapp2'. This keeps your routing tidy and intuitive. If you can't use prefix-based routing, consider grouping microservices based on functionality.
The key is to choose the setup that's most understandable for your team. If it feels cleaner to manage them all within a single ingress, go for that. But if it starts to feel cluttered, then splitting them into separate ingresses is the way to go. In the end, it all depends on what makes sense for your microservices' architecture.
You might want to consider the new gateway-api for Kubernetes, which is designed for these kinds of scenarios. Basically, you would have one gateway for each load balancer and then one Httproute for each microservice. So, you could have an ingress per microservice while reusing load balancers, which would simplify management.
That makes sense! Keeping it organized will be a lot easier. Thanks for the advice!