Running Asterisk & FreeSWITCH on Kubernetes: Production DevOps Guide
How to containerise Asterisk and FreeSWITCH, handle RTP media on Kubernetes (hostNetwork, NodePort, STUN), deploy with Helm, manage SIP registration at scale, and build CI/CD pipelines for VoIP infrastructure.
Running Asterisk & FreeSWITCH on Kubernetes: Production DevOps Guide
How to containerise Asterisk and FreeSWITCH, handle RTP media on Kubernetes (hostNetwork, NodePort, STUN), deploy with Helm, manage SIP registration at scale, and build CI/CD pipelines for VoIP infrastructure.
Kaushik Parmar
Founder & VoIP Architect, CelloIP Technologies
VoIP on Kubernetes: Why It's Hard
Running VoIP systems on Kubernetes is more complex than stateless web apps. Three challenges conflict with Kubernetes defaults: (1) RTP media requires UDP transport — ClusterIP Services don't NAT UDP well. (2) SIP registration is stateful — phones register to specific IPs; load balancing breaks re-registration if a pod restarts. (3) RTP port ranges are wide (10,000–20,000 UDP ports) — impractical with NodePort or LoadBalancer. The hostNetwork pattern resolves these constraints.
The hostNetwork Pattern for RTP Media
Use hostNetwork: true in the pod spec. This gives the VoIP container direct access to the node's network interfaces — no NAT, no iptables, no UDP penalty. The tradeoff: one VoIP pod per node (port conflicts). Use topologySpreadConstraints to enforce one pod per node.
asterisk-deployment.yaml — hostNetwork for RTP
apiVersion: apps/v1
kind: Deployment
metadata:
name: asterisk-media
spec:
replicas: 2
template:
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
containers:
- name: asterisk
image: your-registry/asterisk:21
env:
- name: NODE_IP
valueFrom:
fieldRef: { fieldPath: status.hostIP }
resources:
requests: { cpu: "2", memory: "2Gi" }
limits: { cpu: "4", memory: "4Gi" }CI/CD Pipeline for VoIP Infrastructure
CI/CD for VoIP on Kubernetes: (1) Config validation — run dialplan linting and config syntax checks on each PR. (2) Container build — build Asterisk/FreeSWITCH Docker image with custom modules. (3) Integration tests — run SIPP (SIP load testing tool) against a test namespace. (4) Blue-green deployment — deploy alongside current production, gradually shift SIP traffic using Kamailio's dispatcher module, monitor error rates, then complete the cutover or rollback.
Frequently Asked Questions
Should I use Kubernetes for a small Asterisk deployment?
Not necessarily. For under 500 concurrent calls, Kubernetes adds complexity without proportional benefit. Use it when you need multi-region failover, automated scaling, or managing multiple VoIP services as microservices.
How do I handle SIP registration persistence?
Use a StatefulSet with sticky pod identities, or run Kamailio as a SIP proxy in front of Asterisk pods and store registration state in Redis.
What monitoring stack do you recommend?
Prometheus + Grafana for metrics (asterisk-prometheus-exporter or mod_prometheus for FreeSWITCH), Loki for logs, alerts on call failure rate >2% and jitter >30ms.
Need help implementing this for your project?
Talk to a VoIP Engineer