-1

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?

user2896438
  • 795
  • 13
  • 21
  • Ideally what I imagine would work would be a headless-server/nodeport hybrid, where we can hit a service endpoint to see all available pod endpoints. I could simply use a Nodeport per "Workshop", but how would the client know what ports to access the respective pods on once created? I could have the client specify what port each workshop should be available on, but I'd prefer to avoid this, as later the pod may be accessed by many different clients that may come and go, not just the ones around at creation time. So service discoverability is important. – user2896438 Feb 28 '20 at 08:35

1 Answers1

1

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?

mlody3k
  • 73
  • 7
  • I ended up making my workshop ID map to my nodeports, and having an external ngin proxy (which I already had setup and running other traffic) redirect uri paths to the appropriate nodeport – user2896438 Mar 01 '20 at 02:16