Allocate a game server
Allocating a GameServer will transition its state from “StandingBy” to “Active” and will unblock the “ReadyForPlayers” GSDK call. You can read the gameserver lifecycle document to learn more about the lifecycle of a GameServer.
If you are running Thundernetes on a cloud service like Azure Kubernetes Service, you can use the following commands to allocate a game server (below is using Windows Subsystem for Linux
# grab the IP of the external load balancer that is used to route traffic to the allocation API service IP=$(kubectl get svc -n thundernetes-system thundernetes-controller-manager -o jsonpath='{.status.loadBalancer.ingress[0].ip}') # do the allocation call. Make sure the buildID is the same as the one that you created your Build with # the sessionID is a unique identifier (GUID) that you can use to track the game server session curl -H 'Content-Type: application/json' -d '{"buildID":"85ffe8da-c82f-4035-86c5-9d2b5f42d6f6","sessionID":"ac1b7082-d811-47a7-89ae-fe1a9c48a6da"}' http://${IP}:5000/api/v1/allocate
If you are running Thundernetes on kind your IP can be replaced with localhost and you only need to run the following:
curl -H 'Content-Type: application/json' -d '{"buildID":"85ffe8da-c82f-4035-86c5-9d2b5f42d6f6","sessionID":"ac1b7082-d811-47a7-89ae-fe1a9c48a6da"}' http://localhost:5000/api/v1/allocate
The arguments to the allocation call are two:
- buildID (required): this must be the same as the buildID configured in the GameServerBuild
- sessionID (required): a GUID that you can use to identify the game server session. Must be unique for each game server you allocate. If you try to allocate using a sessionID that is in use, the call will return the details of the existing game server.
- sessionCookie (optional): an optional string that contains information that is passed to the game server. Retrievable by GSDK
- initialPlayers (optional): an optional array of strings containing the user IDs of the players that are expected to connect initially to the server. Retrievable by GSDK
Result of the allocate call is the IP/Port of the server in JSON format.
{"IPV4Address":"52.183.89.4","Ports":"80:10000","SessionID":"ac1b7082-d811-47a7-89ae-fe1a9c48a6da"}
You can now use the IP/Port to connect to the allocated game server. The .NET game server we use exposes a /Hello
endpoint that returns the hostname of the container.
curl http://52.183.89.4:10000/Hello Hello from fake GameServer with hostname gameserverbuild-sample-netcore-mveex
Note: If you use mTLS authentication, you should include the crt and key files in the curl command. For example:
curl --key tls.key --cert tls.crt --insecure -H 'Content-Type: application/json' -d '{"buildID":"85ffe8da-c82f-4035-86c5-9d2b5f42d6f6","sessionID":"85ffe8da-c82f-4035-86c5-9d2b5f42d6f5"}' https://${IP}:5000/api/v1/allocate
You can check the state of your game servers using kubectl get gameservers
or kubectl get gs
. Our sample games request 2 standingBy and 4 maximum servers. The allocation call caused one StandingBy server to transition to Active. So, Thundernetes created an extra GameServer, which eventually reached the StandingBy state. We can now see that we have 2 StandingBy and 1 Active. We can also see the SessionID of the Active GameServer.
NAME HEALTH STATE PUBLICIP PORTS SESSIONID gameserverbuild-sample-netcore-ayxzh Healthy StandingBy 52.183.89.4 80:10001 gameserverbuild-sample-netcore-mveex Healthy Active 52.183.89.4 80:10000 ac1b7082-d811-47a7-89ae-fe1a9c48a6da gameserverbuild-sample-netcore-pxrqx Healthy StandingBy 52.183.89.4 80:10002
Lifecycle of a game server
The game server will remain in Active state as long as the game server process is running. Once the game server process exits, the GameServer Custom Resource will be deleted. This will make the game server pod to be deleted and a new one will be created in its place (provided we are not beyond the GameServerBuild’s maximum). For more information on the GameServer lifecycle, please check here.
Scaling a GameServerBuild
There are two properties that determine the number of game servers that will be created in a GameServerBuild.
- the standingBy number is the number that defines the number of servers that we want to have in the standingBy state.
- the max number is the total number of servers that we want to have in this GameServerBuild. The count of Initializing+StandingBy+Active servers will never be more than the max for a given GameServerBuild.
To modify the StandingBy and Max numbers, you can use kubectl edit gsb <name-of-gameserverbuild>
. Thundernetes also supports the kubectl scale gsb <name-of-gameserverbuild> --replicas=X
to set the standingBy number for a GameServerBuild.