Looking for a k8s expert to be able to run mediasoup with a public external IP

Job Opportunities 💰
1

Searching for a k8s expert to be able to run mediasoup with a public external IP if it’s possible.
Important: it has to work behind an Nginx load balancer for the cluster autoscaler of the nodes to work and the range of udp ports should be exposed.

I already have a Docker container that works but I want to run that container in a k8s pod that is already set up in a working k8s cluster in which the pod and also the node autoscales to 1 in case of failure before the adventure of horizontal autoscaling :).

2

Nginx won’t load-balance your media-servers the way you think. It actually make things more complicated you cannot sticky session and with round robin type stuff your users will get lost in the network without proper intelligence on each media-server which is more computing than you need to offer-up; truthfully.

Scaling horizontally comes down to good signaling and your ideas. I’d say best way is to run a pool of media-servers connecting to a chat-server that way you can forward and destroy connections easily (if user bans a broadcaster).

So in regards to failure, if disconnection occurs with web-socket server (chat/signalling) you would be able to detect it or with this setup you can balance who goes where based off your project design. (not applying but may help you avoid testing what won’t work)

3

Ok, so yes yo can have sticky sessions in k8s for multiple pods.

And thanks for thinking I would load balance connections across different nodes hoping clients would magically connect without interconnecting nodes with pipetorouter and some Redis type server to keep track of where clients are publishing/subscribing, or directly connecting them to the proper ones only with the pub/sub mechanism.

I’m trying to go fast for now, not building the perfect arquitecture as you might have read in the description, so I’m not planning to run a pool of servers.

I have a server in k8s that relaunches automatically in case of failure (with the help of the loadbalancer and its health checks), and I think the best alternative would be to have a dockerized Turn server in front of this one (in the same pod) for the moment, but thanks anyway :slight_smile: