I'm trying to set up a system that can automatically spin up and down video game servers as docker images. In this case, factoriotools/factorio-docker. Each game is a different, distinct single-pod deployment of that container, and therefore (in the simplified case) needs its own IP address that can listen on a specific UDP port. Load balancers are redundant and irrelevant, and Cloud NAT doesn't appear to allow ingress traffic easily.
There's a couple ways I know of to get this to work, both with pretty major compromises:
- I can use a NodePort service, and lose control over which port the client needs to connect to. That's an issue because the server registers itself with a server listing.
- I can use host networking. If my information is correct, that requires privileged containers, which is Definitely Not Good.
- I could maybe use a UDP load balancer, but even if that exists and works, it's expensive.
There are probably ways to work around the limitations of either approach (for the second, keep the hosts short-lived and keep the firewall strict, and it should be mostly OK?), but I can't help but think there's a better option that I can't find described in the official kubernetes docs. Does traefik have some trick I don't know about? Is there some way to get a variant of MetalLB that can dynamically allocate public IP addresses as I need them?
How do I get each server-container to listen on a different public IP address with a specific UDP port, without making security impossible in the process?
Edits:
- The port can be configured, so long as I know which port the server needs to run on before the pod starts up.
- Unless I'm misunderstanding the server docs, the client needs to be able to connect to the same port the server is listening on. The difference k8s draws between the app listening port and the client connecting port is unhelpful in my case.
- Addressing this question , I don't want a load balancer because it does literally nothing for me. Changing IP addresses do not matter, the system is designed to handle that. If the server goes down for 15s, everyone's going to have to reconnect anyway, and they'll find the new IP address then. The server can't handle multiple pods on the same game, so there will never be more than one replica.
- I just tried a
NodePort
service with a randomized public port (hadn't yet seen that I can choose the external port), and I got direct connections to work, but not server listing connections. The server listing process first auto-detects how to connect to the server by having the server send outbound UDP traffic to a given endpoint. So, not only do I need to control what port inbound traffic connects to, I also need to control how outbound traffic is routed, including any NAT that might be used.