Kubernetes Deployment
Deploy jambonz on Kubernetes
jambonz can be deployed on Kubernetes using a two-step process:
Deploying VoIP applications on Kubernetes has some unique requirements that differ from typical web workloads. Most jambonz components — the web portal, monitoring, databases, Redis, and application-layer feature servers — run normally using Kubernetes’ default overlay networking on the system node pool. However, the SIP and RTP pods that handle the front-end telephony processing must run with host networking enabled (hostNetwork: true).
This is not optional — it is a hard requirement of the SIP protocol. SIP embeds IP addresses directly in the signaling messages (SDP, Via headers, Contact headers). If a SIP or RTP pod uses overlay networking, the IP addresses in the SIP messages will be internal cluster IPs that are unreachable from the outside world. Calls will fail because remote endpoints cannot route media or signaling back to an internal pod IP.
By running the SIP and RTP pods with host networking, these pods use the node’s actual network interface and public IP address. This ensures that the IP addresses advertised in SIP signaling are routable and that carriers and endpoints can reach the jambonz SBC directly.
If you’re experienced with Kubernetes, host networking may feel like an anti-pattern. For VoIP workloads it is an absolute necessity due to how SIP and RTP protocols operate at the network level.
All supported cloud providers use the same general cluster architecture with three node pools:
The SIP and RTP node pools require public IP addresses and host networking so they can be reached directly by SIP trunking carriers and endpoints. The taints ensure that only jambonz VoIP workloads are scheduled onto those nodes.
The general deployment workflow is the same for all providers:
terraform.tfvars.terraform init && terraform plan && terraform apply to provision the cluster.kubectl to connect to your new cluster.