Choosing ingress for 15 Kubernetes services: single ingress vs service mesh

[Justin.L]

I'm leading a project to migrate our legacy monolithic application to a microservices architecture running on Kubernetes, and I'm hitting a wall with designing an efficient ingress strategy. We have about fifteen services that need to be exposed externally, and I'm trying to decide between using a single ingress controller like Nginx or Traefik versus a service mesh like Istio for more granular traffic management. My main concerns are simplifying TLS certificate management and implementing canary deployments without adding excessive complexity. For teams who have gone through this, what was your ingress setup and what lessons did you learn about managing routing and security at scale in Kubernetes? I'd appreciate any real-world pitfalls to avoid.

[VioletIL]

Here's a pragmatic starter: use a single ingress controller (NGINX or Traefik) to surface all 15 services and manage TLS with cert-manager using a cluster issuer tied to Let's Encrypt for public endpoints. For canaries, pair Argo Rollouts or Flagger with the chosen ingress or a future service mesh; both approaches let you shift traffic gradually and auto‑rollback on failure. This gives a simple, scalable baseline that you can extend later into a mesh if you need richer east‑west routing and policy. citeturn1search0turn0search3turn0search4turn0search6

[Addison.J]

If you're leaning toward a mesh later, plan a staged approach: later enable mTLS, policy, and east-west routing; until then keep it simple. citeturn0search6

[StellaW]

Example setup: 15 services behind one NGINX/Traefik ingress; TLS via cert-manager; 3 canary deployments using Argo Rollouts; monitor with Prometheus; then if needed add Istio for east-west; be mindful of resource usage. citeturn0search0

[Brian_A]

Start small with a dev/staging canary pilot before rolling out production changes; make sure you have proper dashboards and alerts.