29 Mar
2023
29 Mar
'23
7:42 p.m.
I usually recommend considering if you really need to
do it, the (added) large complexity
is in most cases not worth the (small) benefit.
I don't disagree. There's an ongoing "containerize all the things"
effort here, and Kamailio may need to be exempt from that considering how much traffic a
single instance can potentially handle. The minimum requirement is active/backup failover
with a floating IP, despite the chance that an Elastic IP might not move
"instantly". It's the internal network Kamailio is talking to that actually
benefits from containerization.
If you want to go for it anyway, one way of doing it
is just binding the public IP(s) to
individual Kamailio instances. Using an IP load balancer to have multiple Kamailio
server
behind a single IP only works in limited scenarios (stateless).
Is there an AWS-ism that lets an IP follow a pod but doesn't assign it to the worker
node itself? The thought of putting a worker node in a public subnet makes me
uncomfortable.
It's been my understanding that Kamailio clustering would solve life behind a load
balancer? This is the part where I'm hesitant to follow guidance from ten year old
blog posts and YouTube videos and need to grok the current state of clustering. I'm
working with the presumption that call state can be stored externally, i.e. Redis, and any
node could handle any messages from any dialog. Similarly for rtpengine. "Is this the
real life? / Is this just fantasy?"