Quickstart: Create a Fleet Autoscaler
Prerequisites
It is assumed that you have followed the instructions to Create a Game Server Fleet and you have a running fleet of game servers.
Objectives
- Create a Fleet Autoscaler in Kubernetes using Agones custom resource.
- Watch the Fleet scale up when allocating GameServers
- Watch the Fleet scale down when shutting down allocated GameServers
- Edit the autoscaler specification to apply live changes
1. Create a Fleet Autoscaler
Let’s create a Fleet Autoscaler using the following command :
kubectl apply -f https://raw.githubusercontent.com/googleforgames/agones/release-1.49.0/examples/simple-game-server/fleetautoscaler.yaml
You should see a successful output similar to this :
This has created a FleetAutoscaler record inside Kubernetes.
2. See the autoscaler status.
kubectl describe fleetautoscaler simple-game-server-autoscaler
It should look something like this:
You can see the status (able to scale, not limited), the last time the fleet was scaled (nil for never) and the current and desired fleet size.
The autoscaler works by changing the desired size, and the fleet creates/deletes game server instances to achieve that number. The convergence is achieved in time, which is usually measured in seconds.
3. Allocate a Game Server from the Fleet
If you’re interested in more details for game server allocation, you should consult the Create a Game Server Fleet page. In here we are only interested in triggering allocations to see the autoscaler in action.
kubectl create -f https://raw.githubusercontent.com/googleforgames/agones/release-1.49.0/examples/simple-game-server/gameserverallocation.yaml -o yaml
You should get in return the allocated game server details, which should end with something like:
Note the address and port, you might need them later to connect to the server.
4. See the autoscaler in action
Now let’s wait a few seconds to allow the autoscaler to detect the change in the fleet and check again its status
kubectl describe fleetautoscaler simple-game-server-autoscaler
The last part should look something like this:
You can see that the fleet size has increased, the autoscaler having compensated for the allocated instance. Last Scale Time has been updated, and a scaling event has been logged.
Double-check the actual number of game server instances and status by running
kubectl get gs
This will get you a list of all the current GameServers and their Status > State.
5. Shut the allocated instance down
Since we’ve only got one allocation, we’ll just grab the details of the IP and port of the
only allocated GameServer:
kubectl get gameservers | grep Allocated | awk '{print $3":"$4 }'
This should output your Game Server IP address and port. (eg 10.130.65.208:7936)
You can now communicate with the GameServer:
You can finally type EXIT which tells the SDK to run the Shutdown command, and therefore shuts down the GameServer.
6. See the fleet scaling down
Now let’s wait a few seconds to allow the autoscaler to detect the change in the fleet and check again its status
kubectl describe fleetautoscaler simple-game-server-autoscaler
It should look something like this:
You can see that the fleet size has decreased, the autoscaler adjusting to game server instance being de-allocated, the Last Scale Time and the events have been updated. Note that simple-game-server game server instance you just closed earlier might stay a bit in ‘Unhealthy’ state (and its pod in ‘Terminating’ until it gets removed.
Double-check the actual number of game server instances and status by running
kubectl get gs
This will get you a list of all the current GameServers and their Status > State.
7. Change autoscaling parameters
We can also change the configuration of the FleetAutoscaler of the running Fleet, and have the changes
applied live, without interruptions of service.
Run kubectl edit fleetautoscaler simple-game-server-autoscaler and set the bufferSize field to 5.
Let’s look at the list of game servers again. Run watch kubectl get gs
until you can see that are 5 ready server instances:
Note
If you want to update a Fleet which has RollingUpdate replacement strategy and is controlled by a FleetAutoscaler:
- With
kubectl apply: you should omitreplicasparameter in aFleetSpec before re-applying theFleetconfiguration. - With
kubectl edit: you should not change thereplicasparameter in theFleetSpec when updating other field parameters.
If you follow the rules above, then the maxSurge and maxUnavailable parameters will be used as the RollingUpdate strategy updates your Fleet.
Otherwise the Fleet would be scaled according to Fleet replicas parameter first and only after a certain amount of time it would be rescaled to fit FleetAutoscaler BufferSize parameter.
You could also check the behaviour of the Fleet with Fleetautoscaler on a test Fleet to preview what would occur in your production environment.
Next Steps
Read the advanced Scheduling and Autoscaling guide, for more details on autoscaling.
If you want to use your own GameServer container make sure you have properly integrated the Agones SDK.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.
Last modified June 13, 2025: Promote FeatureRollingUpdateFix to Beta (#4205) (30237be)