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?)