Can Kubernetes L7 ingress be used for non-HTTP port traffic?

2/11/2019

I have two different Minecraft server containers running, both set to use the default TCP port 25565. To keep things simple for laymen to connect, I would like to have a subdomain dedicated to each server, say mc1.example.com and mc2.example.com, such that they only put the address in and the client connects.

For an HTTP(s) service, the NGINX L7 ingress works fine, but it doesn't seem to work for Minecraft. NodePort works well, but then each server would need a different port.

This is also installed on bare metal - there is not a cloud L4 load balancer available, and a very limited pool of IP addresses (assume there are not enough to cover all the various Minecraft servers).

Can the L7 ingress be modified to redirect mc1.example.com to the correct container's port 25565? Would I need to use something like MetalLB?

-- user1943640
kubernetes
kubernetes-ingress
nginx-ingress

1 Answer

2/11/2019

This is also installed on bare metal - there is not a cloud L4 load balancer available, and a very limited pool of IP addresses (assume there are not enough to cover all the various Minecraft servers).

If you don't have enough IP addresses, then MetalLB won't help you, since it is just using BGP to v-host for you but you'd have to virtual addresses to hand out. Based on your description of the situation and your problem, I'd venture to say you're trying to do this on the cheap, and it is -- as one might expect -- hard to work without resources.

That said:

As best I can tell, there is no redirect in the modern Minecraft protocol, but interestingly enough during the Handshake the client does actually send the hostname to which it is attempting to connect. That may or may not be something that BungeeCord takes advantage of, I didn't study its source code.

It could therefore be theoretically possible to make a Minecraft-specific virtual-hosting proxy, since there are already quite a few implementations of the protocol. But, one could have to study all the messages in the protocol to ensure they contain a reference to the actual connection id, otherwise you'd have to resort to just (client-ip, client-port) identification tuples, effectively turning your server into a reverse NAT/PAT implementation. That may be fine, just watch out.

-- mdaniel
Source: StackOverflow