kubernetes - 有没有办法在 Kubernetes 中处理 SIP、RTP、DIAMETER、M3UA 流量？

Question

通过快速阅读 Kubernetes 文档，我注意到 kube-proxy 的行为类似于 4 级代理，并且可能适用于 TCP/IP 流量(通常是 HTTP 流量)。

但是，还有其他协议(protocol)，如 SIP(​​可以通过 TCP 或 UDP)、RTP(通过 UDP)和核心电信网络信令协议(protocol)，如 DIAMETER(通过 TCP 或 SCTP)或类似的 M3UA(通过 SCTP)。有没有办法在 Kubernetes minion 中运行的应用程序中处理此类流量？

在我的阅读中，我遇到了 Kuberntes 的 Ingress API 的概念，但我理解它是一种扩展代理功能的方法。那是对的吗 ？

此外，目前确实没有已知的 Ingress API 实现(开源或闭源)，可以允许 Kubernetes 集群处理上述类型的流量？

最后，除了使用 Ingress API 之外，有没有办法处理上面列出的流量，即使它有性能限制？

Answer 1

Also, it is true that currently there is no known implementation (open-source or closed-source) of Ingress API, that can allow a Kubernetes cluster to handle the above listed type of traffic ?

可能，还有这个 IBM study on IBM Voice Gateway "Setting up high availability"



(此处为 SIPs (Session Initiation Protocol)， like OpenSIPS)

Kubernetes deployments

In Kubernetes terminology, a single voice gateway instance equates to a single pod, which contains both a SIP Orchestrator container and a Media Relay container.
The voice gateway pods are installed into a Kubernetes cluster that is fronted by an external SIP load balancer.
Through Kubernetes, a voice gateway pod can be scheduled to run on a cluster of VMs. The framework also monitors pods and can be configured to automatically restart a voice gateway pod if a failure is detected.

Note: Because auto-scaling and auto-discovery of new pods by a SIP load balancer in Kubernetes are not currently supported, an external SIP.

并且，为了说明 Kubernetes 的局限性:

Running IBM Voice Gateway in a Kubernetes environment requires special considerations beyond the deployment of a typical HTTP-based application because of the protocols that the voice gateway uses.

The voice gateway relies on the SIP protocol for call signaling and the RTP protocol for media, which both require affinity to a specific voice gateway instance. To avoid breaking session affinity, the Kubernetes ingress router must be bypassed for these protocols.

To work around the limitations of the ingress router, the voice gateway containers must be configured in host network mode.
In host network mode, when a port is opened in either of the voice gateway containers, those identical ports are also opened and mapped on the base virtual machine or node.
This configuration also eliminates the need to define media port ranges in the kubectl configuration file, which is not currently supported by Kubernetes. Deploying only one pod per node in host network mode ensures that the SIP and media ports are opened on the host VM and are visible to the SIP load balancer.

this answer 中最好地说明了 Kubernetes 的网络配置。 ，其中描述了 pod/node-communication 中涉及的元素: