By Qiuyang Liu (Liming)
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.
After creating gs,
PortAllocation
by default according to the PortAllocation
policy.Creating
state and the controller starts to create a pod corresponding to gs.Starting
state and waits for pod scheduling.Scheduled
state.RequestReady
state.Ready
.When deleting gs:
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.
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:
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.
Send a ping to confirm whether gs is healthy
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.
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.
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.
Return to GameServer configuration and status
The callback method is implemented using this SDK to handle the logic after listening to the change of gs status.
Management of gs Metadata
Set the label of gs through SDK
Set the annotation of gs using SDK
Player Tracking
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.
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.
Update GameServer.Status.Players.Capacity field values.
Obtain GameServer.Status.Players.Capacity field values.
Obtain GameServer.Status.Players.Count field values.
Determine whether this playerID is connected.
Get the IDs of all players connected to the gs
[Agones Series – Part 3] The Scale In and Scale Out of the Game Server
501 posts | 48 followers
FollowAlibaba Cloud Native Community - October 19, 2022
Alibaba Cloud Native Community - October 19, 2022
Alibaba Cloud Native Community - October 19, 2022
Alibaba Cloud Native Community - October 19, 2022
Alibaba Cloud Community - October 21, 2022
Alibaba Tech - February 24, 2020
501 posts | 48 followers
FollowProvides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn MoreAccelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreWhen demand is unpredictable or testing is required for new features, the ability to spin capacity up or down is made easy with Alibaba Cloud gaming solutions.
Learn MoreAlibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn MoreMore Posts by Alibaba Cloud Native Community