how to setup kubernetes frontend to serve multiple routes - nginx

Question

I'm learning kubernetes and its eco-system, and even though I saw plenty of examples how to use nginx (as reverse proxy) to perform frontend duties, I struggle to understand how I can setup/configure it to serve multiple paths. For example if I have two backends (app1 and app2) deployed to kubernetes and I want them appear in my frontend as /app1 and /app2 I would assume that I need the following nginx configuration:
upstream app1 {
server app1
}
upstream app2 {
server app2
}
server {
listen 443;
location /app1 {
proxy_pass https://app1:PORT1;
# and additional configuration stuff
}
location /app2 {
proxy_pass https://app2:PORT2;
# and additional configuration stuff
}
}
With this site configuration I can build nginx image and deploy it as service into kubernetes. But for deployment I need to specify in yaml which app to match. And, if I want to match my frontend with my two backends how I should write its deployment spec? I followed example from here [1] but still can't understand how I can extend it to aforementioned use case.
[1] https://coderjourney.com/kubernetes-frontend-service-with-nginx/

Answer 1

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.