Just to complement @micael.gallego answer. In my experience, the problem of WebRTC services in combination with Kubernetes, is that WebRTC services use massively port ranges, which creates a friction with the kubernetes design, which is intended to be used for microservices with some opened ports (not thousands as Coturn and KMS). When you deploy, for example, Kurento and Coturn in a Kubernetes cluster, you need to run it using
network=host, and this breaks completely the kubernetes “mindset” because with
network=host, you can’t access a service by its service name (Kubernetes DNS) and you can’t deploy the same service in the same kubernetes node.
network=host, services end up governing the entire kubernetes node where they’re deployed, and you need to play a lot with “affinity rules” and it becomes complex and hacky. We end up concluding that kubernetes is not intended for WebRTC applications.
OpenVidu can be tricky sometimes to install, and we make a great effort to ease its installation with docker, but deploying it with kubernetes and considering the high amount of kubernetes distributions that there are available, it would be more complex than beneficial.
Anyways, this was our experience implementing OpenVidu in Kubernetes, but any approach is very welcome, so feel free to comment here some progress.