Real-Time applications in Kubernetes

The operation of a Real-Time application is hard and requires a lot of work and resources. If you ever tried to deploy one, you know what I am talking about. You have to face with NATs, firewalls, scalability, maintenance, and whatever anomaly appears. However, with Kubernetes, you can reduce these or at least change these problems. Stick with me and I show you two ways to deploy your Real-Time application in Kubernetes.

RTC & Kubernetes

WebRTC is a technology that allows Real-Time Communication between two or more devices over the Internet. It's great for video calls, voice chat, and game servers, but the number of use-cases is much larger.

RTC relies heavily on media servers to provide users with awesome features, such as:

• Signalling
• Relay
• Transcoding
• Recording
• Analytics

Media servers are often exposed to the public internet, which makes them vulnerable to a number of security risks. Some of the most common security risks of media servers include:

• Denial of service (DoS) attacks
• Man-in-the-middle attacks
• Data breaches

Apart from that, media servers have other issues, like:

• Hard to scale: Most of the time, you can’t operate multiple media servers independently from each other. You have to know the whole topology.
• Poor reliability: If your servers go down or it’s under attack, then your clients will suffer connectivity issues.
• Problematic management: Configuring multiple media servers without automation will always carry the chance of misconfiguration.
• Cost: The price of the servers can be high.

Kubernetes can help to mitigate these risks by providing a secure and scalable environment for deploying media servers.

Kubernetes is an open-source container orchestration system that automates the deployment, scaling, and management of containerized applications. It provides a way to run and manage containerized applications at scale across multiple hosts.

There are two main approaches to place a media server inside Kubernetes:

• The hostNetwork approach: This simple but risky solution creates a “regular” server from a Kubernetes node. This means that the public node IP will be visible to everyone and a pod can open any port on the node. Also, this solution does not give you the full operational and maintenance capabilities of Kubernetes. Also, with the hostNetwork approach, if you want to scale your deployment, you have to scale the number of nodes.
• Using STUNner: STUNner is a Kubernetes Gateway that can handle STUN/TURN traffic. This approach does not require you to use hostNetwork, so you do not have to expose all of your ports. It also makes operation and maintenance easier. Unlike using hostNetwork, here you are not forced to scale your nodes for scaling your deployment.

By the way, you can read more about TURN and TURN authentication in this blog post.

The hostNetwork approach

The hostNetwork parameter enables the pods to access the host’s root network namespace directly. This means that your pod is visible without a Kubernetes service. With this parameter, the pod itself can open any port on the host’s network. You can feel it that this comes with a lot of concerns…

There are several disadvantages to use hostNetwork:

• Security: Pods with hostNetwork enabled have full access to the host’s network, which can pose a security risk.
• Scalability: Pods with hostNetwork enabled cannot be scaled within the same node. Just imagine if two pods within the same network try to open the same port…

However, using hostNetwork pods can be similar to using a “regular” server for a media server, but you got some goodies from Kubernetes too. The truth is that this approach just partially solves the issues:

• Improved reliability.
• Scaling is partially solved. You can’t scale media server pods within the same node, but you can scale the number of nodes automatically.
• Reduced management cost.
• Reduced cost because you can scale down to one node anytime to save money.

You can read about how to deploy this approach with LiveKit here. LiveKit is an open source WebRTC stack that gives you everything needed to build scalable and real-time video, audio, and data experiences in your applications.

If you are an absolute newbie to Kubernetes, then maybe this approach suites you well.

Using STUNner

STUNner allows you to deploy any WebRTC service into Kubernetes, smoothly integrating it into the cloud-native ecosystem. STUNner exposes a standards-compliant STUN/TURN gateway for clients to access your virtualized WebRTC infrastructure running in Kubernetes, maintaining full browser compatibility and requiring minimal or no modification to your existing WebRTC codebase. STUNner implements the standard Kubernetes Gateway API so you can configure it in the familiar YAML-engineering style via Kubernetes manifests.

Benefits of using STUNner:

• Expose a WebRTC media server on a two external UDP/TCP port. Using STUNner a WebRTC deployment needs only two public-facing ports, one HTTPS port for the application server and a single UDP/TCP port for all your media.
• No reliance on external services for NAT traversal. STUNner can be deployed into the same cluster as the rest of your WebRTC infrastructure, and any WebRTC client can connect to it directly without the use of any external STUN/TURN service whatsoever, apart from STUNner itself.
• Easily scale your WebRTC infrastructure. STUNner lets you deploy the entire WebRTC infrastructure into ordinary Kubernetes pods, thus scaling the media plane is as easy as issuing a kubectl scale command or using the Kubernetes horizontal pod autoscaler.
• Secure perimeter defense. No need to open thousands of UDP/TCP ports on your media server for potentially malicious access; with STUNner, all media is received through a single ingress port that you can tightly monitor and control.

However, STUNner requires a little more Kubernetes knowledge than the hostNetwork approach. But if you set it right once, you don’t have to bother again with configuring your infrastructure.

The previously mentioned LiveKit, for example, can be deployed based on this tutorial.

Conclusion

Operating a Real-Time application is always difficult. You have to face many problems, such as NAT traversal, scalability, reliability, and be cost-effective. Kubernetes can help to ease these challenges by providing a more secure and scalable environment for deploying your services.

You can deploy your Real-Time application in Kubernetes by simply setting the hostNetwork parameter to true and let your application to use the root network namespace. This is convenient but poses a security risk, as it allows hackers to access the media server directly. Also, scaling is not the best with hostNetwork. You can’t scale your deployment within the same node. You have to scale your nodes and it’s not as efficient as scaling within a node.

Using STUNner is a better way of deploying Real-Time application in Kubernetes. It is more secure and more scalable than using hostNetwork. STUNner will act like the first line of defense and it will be visible only in two ports, so your deployment can scale within a node.

Kubernetes is a great tool that can help to automatize your operational work and with a little bit of extra work, you can use it for almost anything. This is great for technology that requires detailed networking and resource management.