Welcome to the kubernetes ecosystem!
Let me say the problem back to make sure that we're talking about the same thing:
You have 2 applications in a cluster. From a Kubernetes perspective these should consist of the following in-cluster resources:
- a Deployment for each
- the Deployment for each comprises and therefore also creates in the cluster a ReplicaSet and some Pods for each app.
- the Pod spec for each app references the app's container image
- a Service spec which uses labels to refer to the respective Deployment/ReplicaSet/Pod objects for each application. The name of the Service can be used in other Kubernetes objects
Given that footprint for those two applications, you then want to expose each application under its own route/path, as described above, under a single domain, so outside visitors can get to each independently.
If that's all accurate, then there is no need to deploy your own nginx container. You just use another Kubernetes object, called Ingress.
An Ingress is an abstract name for- if you are running your own Kubernetes cluster on bare metal or similar- what in concrete terms amounts to an specially configured nginx.
If you are running a managed Kubernetes on gcloud or azure or AWS, then Ingress in concrete terms is usually a load balancer provided by the cloud.
The documentation should help:
https://kubernetes.io/docs/concepts/services-networking/ingress/
More specifically, an Ingress Controller is a Kubernetes term for a piece of software in the cluster that watches for Ingress resources, then uses the details in those resources to produce new configuration.
An nginx Ingress Controller:
https://github.com/kubernetes/ingress-nginx/blob/master/README.md
will first create nginx pods in the cluster, then watch for changes to Ingress specs, will update the nginx configuration to match what's specified in the specs, and then restart the nginx pods when the configuration changes.
A cloud Ingress Controller works similarly, though it uses the cloud APIs to update cloud load balancer configuration.
So, to a first approximation, what you might want to do is just follow the Simple Fanout Ingress example, which exposes two applications- each behind their own Service, as described above- under two paths in a single domain:
https://kubernetes.io/docs/concepts/services-networking/ingress/#simple-fanout
Hope that helps.