One NGINX Ingress for meshed and not meshed ingresses

[PDVJAM]

Hey! I'm new to service meshes, it is the first time I will try one.
The question is the following: we have a k8s cluster with nginx ingress to manage ingress traffic. There are multiple apps exposed to the internet via ingresses. We have a new application for which we want to implement a blue-green deployment workflow. I have tried flagger, it works fine with nginx ingress controller. But we would like to use linkerd for more granular traffic control/monitoring.
What I see is that we must enable linkerd injection to nginx ingress:

helm upgrade nginx-ingress ingress-nginx/ingress-nginx \
--reuse-values \
--set controller.metrics.enabled=true \
--set controller.podAnnotations."prometheus\.io/scrape"=true \
--set controller.podAnnotations."prometheus\.io/port"=10254 \
--set controller.podAnnotations."linkerd\.io/inject"=enabled

But does it break all other "old" ingresses that are not meshed? Do I need to keep somehow two separate nginx ingresses - one for mesh and a "clean" one? Or its a bad idea to have meshed and non-meshed workload on one cluster?
WIll appreciate any help!

[wmorgan]

Typically you would just have one nginx deployment and you would mesh the whole thing. Unless you have a good reason for running both a meshed and unmeshed one, that's where I would start.

[PDVJAM]

Well, the reason is that we have some old apps that are no longer in development, and we don't want to change them and use linkerd only for the new application that is currently under heavy development...

[ErikEngerd]

Is there an example somewhere on how to configure an unmeshed kubernetes nginx ingress resource such that it connects to a meshed backend service? I am also looking at a migration scenario where I want to migrate one namespace at a time. In this particular case I also don't want to touch the existing ingress because that is not managed by me.

There is also another solution perhaps which is to use ssl-passthrough on on unmeshed nginx and route traffic for some hosts to a meshed nginx, deployed as a cluster ip service. That means Ssl termination on the meshed ingress but still reusing a common external Ip for all ingress traffic.

Then use skip inbound ports on the meshed nginx for external traffic. This second nginx can also be deployed a a separate ingress class (nginx-meshed). Then create ingress resources for meshed workloads using the meshed ingress class.