Game Servers is a managed game service built for game infrastructure teams to easily deploy and manage global dedicated game server fleets. Game Servers provides management of game server clusters using Kubernetes for container orchestration and Agones for game server fleet orchestration and lifecycle management. You can connect and disconnect clusters from management by Game Servers at any time without any impact to existing game sessions. After disconnecting a cluster, you can continue to run an open source Agones installation.
You control game server clusters using global game server configs, defining rules for the location and number of servers to spin up, as well as which game server binary to deploy. Game Servers automatically creates Agones fleets based on centrally-managed rollouts, ensuring they are automatically and safely rolled out to all managed clusters. In particular, in-progress game sessions are never disrupted because an in-use game server is never abruptly halted.
Game Servers resources
This section describes the main resources you interact with to manage Game Servers. The following figure shows how these resources are used to deploy a game project.
Figure 1. Sample game project deployment on Game Servers
Game Servers project
A single environment, such as production or testing and is a Google Cloud project with Game Servers enabled on it. To improve isolation and security, you typically manage a single game title using multiple Google Cloud projects, such as My Game Production and My Game Testing.
Location defines the scope of a resource, and defaults to
provides the highest availability and where data is redundant across multiple
Google Cloud regions. You can manually set the location for a resource to a
specific Google Cloud region. If you want control over where data is
stored, or what your failover domains are, then override the default
Game Servers is designed to support Kubernetes clusters running on Google Kubernetes Engine. To build on the concepts of Google Cloud regions and zones, Game Servers introduces the meta-region concept of realms. A realm is a user-defined grouping of game server clusters based on the game's latency requirements for player populations. Realms have a time zone assigned to them that allows for time-based scaling configs to be used on clusters within the realm. Realms exist within a location.
Game server cluster
A game server cluster is a sub-resource of a realm resource. Each game server
cluster corresponds to a namespace on a Kubernetes cluster running Agones that
is registered to a realm. Game server clusters within a realm should be
considered equivalent from the user experience perspective with regards to
measurements such as latency or compute performance. Using a namespace other
default requires that the namespace be created on Kubernetes, and Agones
configured to use it.
After you delete a game server cluster, Game Servers doesn't delete any resources in the cluster, including Agones fleets and autoscalers created by Game Servers.
Game server deployment
A game server deployment is a global record of a game server software version that can be deployed to any or all game server clusters worldwide. A game server deployment is the parent resource of both the game server config and rollout resources.
Game server config
A game server config is a sub-resource of a game server deployment resource that specifies game server count, buffer, and game server version. You define scaling policies in a game server config. Scaling policies can be static or time-based, as illustrated by the following examples:
- During peak hours there should be enough servers to support N allocations per minute, during off-peak hours M allocations per minute.
- For planned game events, increase reserved capacity by N% for a date and time range.
A rollout is a sub-resource of a game server deployment resource that maps game server configs to target realms. By default, a rollout assigns a game server config to all realms. For A/B testing and canary testing, you can override specific realms to receive an alternate game server config.
Game Servers exposes a globally-available control plane API, through
which you can control resources describing the deployment using API calls, the
Cloud Console, or the
gcloud command-line tool, including:
- creating and modifying realms
- creating, registering, and modifying game server clusters in realms
- creating, deploying, and updating game server deployments, game server configs, and rollouts
A Kubernetes service account needs to be in place for Agones to manage game servers in the namespace that you pass to Game Servers when creating a Game Servers cluster. If you are using a namespace other than the default namespace, you would typically create this service account as part of the helm install.
A Google Cloud project service account needs to be in place for Game Servers to connect to the Agones clusters. This service account is created automatically when you first create a resource, such as a realm or a deployment.
Each game server deployment describes game server parameters, equivalent to an
GameServerSpec, and specifies a policy to target game server clusters
where fleets of game servers running a particular build should be created. You
can also set individual cluster scaling preferences using policies.