Is it possible to specific custom rules for running new containers in Kubernetes/Docker?

Question

EDIT: It doesn't have to be kubernetes. It can be Docker.

I'm not sure if this is the right question, but this is what I want to achieve:

I want to run game server (UnrealEngine) in cloud using containers (Azure). I know how to achieve it using virtual machines, but I'd like to try Kubernetes. For both learning experience and tha fact that CI/CD using it should be easier in long run.

What I need to achieve:

1. Client ask match making service to find other players to run with.
2. Match maker find other players.
3. It tells kubernetes to spin on new container and route matched players to it.

OR:

1. Client enter map.
2. Go trough portal.
3. I assume that one map - one server. So I want to shutdown previous map, and spin on new server with new map.

With VM while not trivial it's easy enough to do it with C# SDK for Azure.

But In case of Kubernetes I don't really know where to start looking. Been looking trough documentation, but can't really find what I'm looking for (or I don't know I just looked at it..).

I have seen this article: http://blog.juliaferraioli.com/2015/11/containerized-minecraft-roulette.html

But that's not exactly what I want, here players are distributed randomly and all needed containers are running. I want to have more fine grained controll over where players go, and how many instances there are running at once.

Answer 1

For the top "OR" parts, using an Ingress controller will do that (the one I have in my head is haproxy , but there are quite a few implementations): its job is to be a router from Internet traffic to the kubernetes Service(s) that declare their interest. The awesome thing about an Ingress controller is that it is controlled through kubernetes APIs in exactly the same way as all other parts of kubernetes.

So, in my head:

1. is totally in your setup, so I won't speak to it with the exception of saying that if launching a new game server for the upcoming group of players is time consuming, this might be the time to start that process in motion. It would create the Service (named, for example, game-1502350068 of type ClusterIP , and with all the ports: you would need to play the game), add the selector: of whatever-whatever, but also game: g1502350068 (you can, of course, use game: "1502350068" as a legal Pod label, but will need to remember to quote it everywhere it is used, since labels must be strings)

   This is also the time you would consider creating a new Ingress resource that maps game-1502350068.example.com to the aforementioned Service, creating the linkage from a (presumably wildcard) DNS record down into the cluster and to the Service. But don't worry, there are currently no Pods matching that selector so traffic will just die if someone attempts to connect

2. up to you
3. with the player matching complete, now you can attach the game: g1502350068 label to the Pod(s) (if you launched it/them in step 1, or launch it/them with that label if not), and after the Pod is "Ready" (for however you define that), traffic will flow all the way through, arriving only to the Pods matching the selector of the Service

Everything I just described is 100% possible through the kubernetes API, and invoking kubectl --v=100 as you do that process manually once or twice will show you the exact endpoints and (I believe) the exact payloads. Then, as you might suspect, the kubernetes API can tear all of those down, conserving resources for other players