Orchestrateur
Un orchestrateur est le système qui décide de l'endroit et du moment où chaque instance de serveur de jeu s'exécute, la démarre et l'arrête ensuite. Il se situe entre votre système de matchmaking et votre infrastructure : le système de matchmaking indique qu'un match est prêt, et l'orchestrateur produit un serveur pour celui-ci au bon endroit.
Aussi appelé
game server orchestrator
,
What Is a Container Orchestrator?
A container orchestrator runs containers across a group of machines. You declare what should run, such as five copies of a web service, and it keeps that true: it places each container on a machine with room, restarts any that fail, and adds or removes copies as load changes. Kubernetes is the most widely used.
Inside, an orchestrator usually has an API that takes requests, a scheduler that picks where each container runs, a record of what runs where, health checks, and cleanup. The scheduler is one part of the orchestrator, not the whole of it.
Most container orchestrators treat the copies as interchangeable. Any one of them can be stopped to scale down, move to another machine or roll out an update, because another copy serves the next request just as well. A game server holding a live match isn’t interchangeable: stopping it ends the match for every player on it. A game server orchestrator starts from that difference and manages each server as a match with its own lifecycle.
What Does a Game Server Orchestrator Do That a Container Orchestrator Doesn't?
Compared with a general-purpose container orchestrator, a game server orchestrator typically:
Starts a server per match on request, and makes its address and port available, once it’s ready, to the matchmaker or backend that asked.
Doesn’t stop a server while its match runs to scale down or rebalance. The server ends when its match does, or at a set maximum runtime.
Exposes each server’s ports to players, usually UDP, often mapped to a different port outside the container (port mapping).
Places each server by where its players are, rather than wherever a machine has room.
How it knows each server’s state differs between orchestrators. Some track it through an SDK added to the server build; others manage it from outside, through an API, environment variables and a stop call the server makes when its match is over.
Do Live Matches Depend on the Orchestrator?
Not once they're running. An orchestrator is a control plane: it decides where servers run, starts them and stops them. The game server is the data plane: players connect to it directly, and match traffic doesn't pass through the orchestrator. The orchestrator matters most at the moment a match needs a server.
That makes two things worth checking in any orchestrator: how it keeps placing new servers when a provider or location has a problem, and what the game does while a request is retried. Whatever the orchestrator, a client that holds the player’s place in the queue and retries with backoff turns a slow start into a short wait.
Edgegap’s orchestrator runs as a managed service and places servers across 17+ infrastructure providers (as of 18 September 2026), so a new server can be placed with another provider if one has an outage. Hosting needs no Edgegap SDK in the game server: any container image deploys worldwide from a single API call, the server reads its ports and match details from environment variables, and it can end itself with one HTTP call when the match is over (docs). Match servers start and stop on demand on Edge Cloud, while persistent servers, such as a world that keeps its state between sessions, run on Private Fleets (fleet management).
Un mot de notre sponsor (nous-mêmes !)
Les pools chauds rendent l'allocation rapide car vous payez pour des serveurs qui restent inactifs. Edgegap déploie un nouveau serveur de jeu en une médiane de 2 secondes à partir d'un démarrage à froid, mesuré jusqu'à ce que le conteneur soit prêt avant le démarrage de votre moteur, de sorte qu'un serveur n'existe que lorsqu'un match en a besoin.
