Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog [Agones Series – Part 4] Lifecycle of the Game Server

[Agones Series – Part 4] Lifecycle of the Game Server

Part 4 of the Agones Series describes the lifecycle management of the game server in Agones.

By Qiuyang Liu (Liming)

1

Game Server Status

The game server is a further abstraction of pods. When creating gs, the controller creates the corresponding pods and sets the owner of the pods to the gs. Let's look at the status change of gs and pod when gs is created through an experiment.

Start from watch gs and pod objects:

kubectl get gs -w
...

kubectl get po -w
...

After the game server is created, the following are the changes to gs and pod:

# gameserver
simple-server                    PortAllocation                                                     0s
simple-server                    Creating                                                           0s
simple-server                    Starting                                                           0s
simple-server                    Scheduled        xxx.xxx.xxx.xxx   7036   cn-xxx.xxx.xxx.xxx       0s
simple-server                    RequestReady     xxx.xxx.xxx.xxx   7036   cn-xxx.xxx.xxx.xxx       5s
simple-server                    Ready            xxx.xxx.xxx.xxx   7036   cn-xxx.xxx.xxx.xxx       5s

# pod
simple-server                    0/2     Pending   0          0s
simple-server                    0/2     Pending   0          0s
simple-server                    0/2     ContainerCreating   0          0s
simple-server                    2/2     Running             0          3s
simple-server                    2/2     Running             0          5s

Status change of gs: PortAllocation → Creating → Starting → Scheduled → RequestReady → Ready

Status change of pod: Pending → ContainerCreating → Running

We try to delete gs and observe the change between pod and gs:

# gs
simple-server                    Ready       xxx.xxx.xxx.xxx   7036   cn-xxx.xxx.xxx.xxx   6m17s
simple-server                    Ready       xxx.xxx.xxx.xxx   7036   cn-xxx.xxx.xxx.xxx   6m48s

# pod
simple-server                    2/2     Terminating   0          6m17s
simple-server                    0/2     Terminating   0          6m48s
simple-server                    0/2     Terminating   0          6m48s
simple-server                    0/2     Terminating   0          6m48s

Status change of gs: Ready → Object Deletion

Status change of pod: Terminating → Object Deletion

Create a gs again, delete the pod after ready, and observe the corresponding changes:

# pod
simple-server                    2/2     Terminating         0          21s
simple-server                    0/2     Terminating         0          52s
simple-server                    0/2     Terminating         0          52s
simple-server                    0/2     Terminating         0          52s

# gs
simple-server                    Unhealthy        xxx.xxx.xxx.xxx   7593   cn-xxx.xxx.xxx.xxx   53s

Status change of pod: Terminating → Object Deletion

Status change of gs: Unhealthy

We combine the following game server state diagram with the experiment just conducted to illustrate the significance of each state.

1

After creating gs,

  1. The controller sets the gs status to PortAllocation by default according to the PortAllocation policy.
  2. If the port allocation is completed, gs enters the Creating state and the controller starts to create a pod corresponding to gs.
  3. After the pod object is generated, gs enters the Starting state and waits for pod scheduling.
  4. After pod scheduling is completed, the gs controller obtains the IP address of the host where the pod is located as the address of gs, and gs enters the Scheduled state.
  5. After the game server process is started, run ready() through SDK, which indicates that the game server is ready and gs enters the RequestReady state.
  6. The controller finds that the corresponding pod is running, runs normally, and sets gs to Ready.

When deleting gs:

  1. The gs waits for the corresponding pod to be deleted. The pod enters the Terminating state.
  2. After the pod is deleted, the gs object is deleted immediately.

When the pod is deleted, the game server finds that the connection time exceeds the threshold through SDK health(). Then, gs enters the Unhealthy state.

In addition to the phenomenon just observed in the experiment, we used the GameServerAllocation to set gs to the Allocated state in the article The Scale In and Scale Out of the Game Server, which shows that gs has been assigned, waiting for the corresponding player to connect. The game server can actively enter gs into the Shutdown state through sdk shutdown() and then get deleted.

Agones SDK

The introduction of the game server status shows that Agones largely relies on SDK for gs status management. The game server process needs to send grpc/htpp requests through SDK to report its status. The SDK server, as a sidecar of pods, adjusts the status of the game server at the Kubernetes level after receiving the request.

Let's take a look at the SDK methods for lifecycle management:

  • Ready()

Call this method to notify Agones that the game is ready and can be called at initialization, or when the game ends, try to reuse gs.

  • Health()

Send a ping to confirm whether gs is healthy

  • Reserve(seconds)

The original intention of this method is to retain gs. The parameter represents the retention time, the unit is seconds, and 0 represents permanent. This kind of gs will not be allocated by GameServerAllocation, nor will it trigger FleetAutoscaler scaling. The game has more rights to maintain its state.

  • Allocate()

Use this method to mark that the game server has been allocated. The allocation will be an important parameter of the gs matching mechanism for matching games, which has a huge impact on the matching mechanism.

  • Shutdown()

Call this method to notify Agones to disable the current running game server

In addition to actively reporting information, the Agones SDK provides the ability to retrieve queries.

  • GameServer()

Return to GameServer configuration and status

  • WatchGameServer(function(gameserver){…})

The callback method is implemented using this SDK to handle the logic after listening to the change of gs status.

Management of gs Metadata

  • SetLabel(key, value)

Set the label of gs through SDK

  • SetAnnotation(key, value)

Set the annotation of gs using SDK

Player Tracking

  • PlayerConnect(playerID)

The player's ID will be reported to Agones through this method. The GameServer.Status.Players.Count and GameServer.Status.Players.IDs will be changed accordingly. Count adds one, and IDs will add an entry.

  • PlayerDisconnect(playerID)

Corresponding to PlayerConnect, the Agones controller will perform actions after the player disconnects and change the corresponding GameServer.Status.Players.Count and GameServer.Status.Players.IDs.

  • SetPlayerCapacity(count)

Update GameServer.Status.Players.Capacity field values.

  • GetPlayerCapacity()

Obtain GameServer.Status.Players.Capacity field values.

  • GetPlayerCount()

Obtain GameServer.Status.Players.Count field values.

  • IsPlayerConnected(playerID)

Determine whether this playerID is connected.

  • GetConnectedPlayers()

Get the IDs of all players connected to the gs

Gaming Developers Containers Kubernetes cloud native ACK Agones Game Server Dedicated Game Server
0 0 0
Share on

Read previous post:

[Agones Series – Part 3] The Scale In and Scale Out of the Game Server

Read next post:

[Agones Series – Part 5] Agones Summary and Outlook

Alibaba Cloud Native Community

481 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

481 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All