In such a way that the pod would be scheduled when a Match is made, and taken down when the match ends. The pod would run a game server process which listens for incoming connections.
A match lasts for roughly 5-20 minutes and has 4-6 simultaneous players connected at a given time.
I'm curious about the requirements.
Here's my reasoning. First, back to the basics. A pod is an atomic unit of work, which has some cpu & ram reserved. Depending on the nature of your game, it might or might not require a constant and consistent amount of work at any given time. The direct conclusion is that having a pod for a single unique match might cause a waste of resources, lots of reserved resources being idle.
Finally, I like to try to get my pods stateless as much as I can.
If you use a replication controller Kubernetes makes its best effort to get the pod running, but the pod could be rescheduled to improve cluster resource allocation. Or it could crash and be restarted (maybe on another host).
If you don't use a replication controller, then what happen to your match if the pod crashes?
Finally, a pod isn't usually directly exposed to the public, and you might probably want to use a service or an ingress controller, which therefore also need to carry these match complexity.
Without knowing more about the nature of your match processing, it's difficult to recommend any architecture, but my very first thought would be to check of a game state could be store in some state store (like a db), and your pods would only process pending tasks for this job. (in other words: what is you strong requirements to restrict a match processing to a single pod?)
You'll need to write your own orchestration logic to do that - your application should then make increment / decrement cluster size calls and probably spin up more instances as well if you plan to run a big Kubernetes cluster.
Siddarthan Sarumathi Pandian
Full Stack Dev at Agentdesks | Ex Hashnode | Ex Shippable | Ex Altair Engineering
This is how I would go about this is in a crude way, see if it makes sense to you.
All we're looking to do is boot up a pod and supply some parameters to it to conduct the match.
So, let's say the player(s) hits on start match, you make an API call to boot the pod up. The environment variables can be the list of players playing the match. When the match ends, you make another API call to shut the container down. I do not quite understand why you would need a job for this to schedule terminating and booting of pods.