Hello,
We are currently using openvidu CE hosted on AWS. I am looking to possibly upgrade to the PRO version however we are also going to be migrating our prod stack over to Kubernetes on GCP. Your website states that Kubnernetes support is “Coming soon”. Do you have a timeline on when that is going to be available ?
Thanks
Jai
We have other priorities in mind right now. We do not plan to publish a kubernetes version in the following months.
Maybe in the future.
Hi Micael, would you be open to having a discussion on this? I’ve started to put together a kubernetes version of OpenVidu CE, but its early days just now. Would appreciate your thoughts on how you would see the design moving forward?
nice intiative , keep it up
i would love to help if you need any
Good idea.
Kubernetes is a complex platform. The main issue appears with ports management. In some early experiment we have configured KMS with network host so it can use a port large port range. Coturn container has the same issue.
Another point to be considered is the proxy. OpenVidu includes a proxy to manage certificates, but Kubernetes has its own proxy as a Ingress resource. So maybe it is interesting to remove OpenVidu’s nginx container and use Ingress.
Other issue is the compatibility with several kubernetes distributions. Depending on the distribution Ingress controller can be very different. So it is needed to verify compatibility with most used k8s distributions.
Good luck!
Regards
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.
With 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.
Regards!
Hi, I know this is a bit late, but I have just got Openvidu working on K8S and wondered if people would be interested in the details.
It is actually pretty easy to set up.
Support is based on Stunner (GitHub - l7mp/stunner: A Kubernetes media gateway for WebRTC. Contact: info@l7mp.io).
Note that performance should be OK: https://www.diva-portal.org/smash/get/diva2:1610168/FULLTEXT02.pdf
We know OpenVidu CE works for Kubernetes (or can somehow be adapted), but it’s not officially supported
If you want anyway to present more details, I am interested anyway 
Stunner is a great piece of technology for WebRTC and k8s