My application requires an arbitrary number of pods to expose their services to the internet. I'm not sure what the best approach is to allow discoverability of these pods from an external server (let's call it the client).
The workflow consists of an external server(the client) requesting a "Workshop" deployment be created, and providing a Workshop ID. Kubernetes then creates the deployment, and a pod alongside it with the API that the client will use running in a container on the pod.
The client should be able to see all Workshop pod instances, and must be able to identify which Pod belongs to which workshop.
I've simplified the actual kubernetes infrastructure. It uses CRDs and operators to setup more elaborate infrastructure, but only the pod's API and its discoverability should be of concern to the client. What is the best way to approach this?
If APIs are HTTP let's use an ingress maybe? You have just ingress controller (like traefik) exposed with nodePort and it takes care of proxying to the desired client-specific API service. If they're not HTTP you can set up this kind of reverse proxy using nginx for example. Idea is the same - single API endpoint for all clients, and taking care of proxying by subdomain or path.
About discovery - Why not provide namespaced kubeconfig to the client?