Configuring cluster scaling behavior

This page explains how to create and manage a Game Servers config that specifies the scaling behavior of a deployment. The scaling configuration can be customized to only target specific Game Servers clusters in a realm.

Before you begin

Before you start, we recommend you familiarize yourself with key concepts in the Game Servers Overview. Make sure you have also performed the following tasks:

Ensure that you have enabled the Game Services API.

Enable Game Services API

Either choose a shell with Cloud SDK installed, or use an API client:

Cloud Shell

To launch Cloud Shell, perform the following steps:

Go to Google Cloud Console.

Google Cloud Console
From the upper-right corner of the console, click the Activate Cloud Shell button:

A Cloud Shell session opens inside a frame lower on the console. You use this shell to run gcloud commands.

Local shell

To install gcloud, install the Cloud SDK, which includes the gcloud command-line tool.

Verify that you have set desired default project for gcloud command-line tool (otherwise you need to specify flag --project explicitly for each command later):

gcloud config list project

If not you can run the following command to set a default project, replacing PROJECT_ID with your desired project ID :

gcloud config set project PROJECT_ID

Run the following command to verify your version of the Google Cloud SDK. Game Servers requires version 306.0.0 or higher of the SDK.

gcloud version

To update your installation, run the following command:

gcloud components update

curl / PowerShell

To use the REST API with curl or Windows PowerShell, do the following:

Create a service account.
Download a private key as a JSON file.
Set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the path of the JSON file that contains your service account key. This variable only applies to your current shell session, so if you open a new session, set the variable again.
Example: Linux or macOS
```
export GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"
```
Replace KEY_PATH with the path of the JSON file that contains your service account key.

For example:
```
export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"
```
Example: Windows

For PowerShell:
```
$env:GOOGLE_APPLICATION_CREDENTIALS="KEY_PATH"
```
Replace KEY_PATH with the path of the JSON file that contains your service account key.

For example:
```
$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"
```
For command prompt:
```
set GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH
```
Replace KEY_PATH with the path of the JSON file that contains your service account key.

Client Library

Google Cloud Game Servers can be controlled programmatically using a client library. See Client Libraries Overview for instructions on using the library and authenticating.

Creating a config

Make sure you have created a Game Servers deployment.

You can create a Game Servers config in a deployment using the gcloud command-line tool.

To create a game server config:

Copy the following fleet specification into a file:

- name: fleet-spec-1
  fleetSpec:
   replicas: 0
   scheduling: Packed
   strategy:
     type: RollingUpdate
     rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%
   template:
     metadata:
       labels:
         gameName: udp-server
     spec:
       ports:
       - name: default
         portPolicy: Dynamic
         containerPort: 7654
         protocol: UDP
       health:
         initialDelaySeconds: 30
         periodSeconds: 60
       sdkServer:
         logLevel: Info
         grpcPort: 9357
         httpPort: 9358
       template:
         spec:
           containers:
           - name: dedicated
             image: gcr.io/agones-images/udp-server:0.21
             imagePullPolicy: Always
             resources:
               requests:
                 memory: 200Mi
                 cpu: 500m
               limits:
                 memory: 200Mi
                 cpu: 500m

Copy the following scaling config specification into a file:

- name: scaling-config-1
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        bufferSize: 1
        minReplicas: 0
        maxReplicas: 4

Run the following command and replace the placeholder values, such as deploymentID and configID, with appropriate values:
```
gcloud game servers configs create configID --deployment deploymentID --fleet-configs-file fleetSpecFile --scaling-configs-file scalingConfigsFile
```
The variable placeholders correspond to the following descriptions:

configID is a unique identifier that you can specify for this config.
deploymentID is the unique identifier for the deployment.
fleetSpecFile is the path to the file with the Agones Fleet specification.
scalingConfigsFile is the path to the file with the scaling specification.

Setting the config for a deployment

After you have created a Game Servers config with a scaling policy, set it as the default config by updating the rollout for the Game Servers deployment.

Game Servers applies scaling behavior to all clusters.

Verifying scaling specifications

To determine whether Game Servers has applied the configured scaling to a cluster, run the following command for each cluster within the realm. Replace the namespace placeholder with the namespace you specified when registering the Kubernetes cluster as a Game Servers cluster:

   kubectl get fleetautoscaler --namespace namespace

The variable placeholders correspond to the following descriptions:

namespace is the namespace you used when registering.

Scale specific clusters only

You may want to limit the scaling configuration to specific Game Servers clusters in a realm. You do this by adding a label to clusters and then targeting only those clusters with the label in the scaling config.

Follow these steps:

Update the cluster to add a label. Labels are key-value pairs in the form key=value. For this example, specify the label as --labels=cloud=true.
```
gcloud game servers clusters update gscID --realm=realmID --location=region \
  --update-labels=labels --no-dry-run
```
The other variable placeholders correspond to the following descriptions:
- gscID is a unique identifier that you can specify for this cluster.
- realmID is the unique identifier for the realm where you want to store the cluster.
- region is the region for the cluster. Pick the same region as the parent realm.
  
  Note: You can also create a cluster with a label using the --labels option.

Create a config by following the steps in the Creating a config section with the following addition: add the label to the scaling config specification. For example:

  - name: scaling-config-1
    fleetAutoscalerSpec:
      policy:
        type: Buffer
        buffer:
          bufferSize: 1
          minReplicas: 0
          maxReplicas: 4
      selectors:
      - labels:
          "cloud": "true"

Set the config as the default config by updating the rollout for the Game Servers deployment.

Game Servers only applies scaling configs to Game Servers clusters that have a label matching the label selector in the scaling config. So in this example, any clusters you have labeled with cloud=true get a scaling config and any clusters without that label don't get a scaling config.

Creating scaling schedules

Game Servers allows you to configure multiple scaling schedules. You can configure multiple scaling schedules that include start and optional end times or recurring schedules, known as cron schedules. You can also combine multiple and recurring schedules.

Game Servers evaluates start and end times in Coordinated Universal Time (UTC). Other timezones are supported as an offset of UTC. Start and end times are formatted as RFC 3339 date strings. The lowest precision Game Servers supports is minutes.

Game Servers evaluates the scaling schedules in the order they are listed in a config until a matching schedule is found. This section describes a variety of scheduling examples.

Creating multiple scaling schedules

You can adapt the following scaling schedule specification for special events. In this example, Game Servers applies the following scaling schedules:

scaling-config-june1-and-7 on June 1, 2020 between 17:00 and 22:30 as well as June 7, 2020 between 12:00 and 18:00

The default scaling-config-default config for all other times between May 25, 2020 and May 31, 2021

- name: scaling-config-june1-and-7
  schedules:
  - startTime: "2020-06-01T17:00:00Z"
    endTime: "2020-06-01T22:30:00Z"
  - startTime: "2020-06-07T12:00:00Z"
    endTime: "2020-06-07T18:00:00Z"
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 100
        minReplicas: 10
        bufferSize: 5
- name: scaling-config-default
  schedules:
  - startTime: "2020-05-25T00:00:00Z"
    endTime: "2021-05-31T00:00:00Z"
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 5
        minReplicas: 1
        bufferSize: 1

Creating recurring scaling schedules

The following example specification illustrates a recurring cron scaling schedule to handle an increase in capacity during peak hours. In this example, Game Servers applies the following scaling schedules:

scaling-config-weekday-peak during weekdays between 17:00 and 20:00
scaling-config-weekend-peak during weekends between 13:00 and 17:00

The default scaling-config-default config at all other times

- name: scaling-config-weekday-peak
  schedules:
  - cronJobDuration: 3600s
    cronSpec: '0 17-20 * * 1-5'
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 100
        minReplicas: 10
        bufferSize: 5
- name: scaling-config-weekend-peak
  schedules:
  - cronJobDuration: 3600s
    cronSpec: '0 13-17 * * 0,6'
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 150
        minReplicas: 20
        bufferSize: 10
- name: scaling-config-default
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 5
        minReplicas: 1
        bufferSize: 1

Creating multiple recurring scaling schedules

Scaling specifications can include both start and end time fields as well as a recurring cron schedule. In this example, Game Servers applies the following scaling schedules:

scaling-config-july4 from July 4 to July 7 between 9:00 and 23:00
scaling-config-peak everyday between 17:00 and 22:00

The default scaling-config-default config at all other times

- name: scaling-config-july4
  schedules:
  - cronJobDuration: 3600s
    cronSpec: '0 9-18 * * *'
    startTime: "2020-07-04T00:00:00Z"
    endTime: "2020-07-07T00:30:00Z"
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 150
        minReplicas: 10
        bufferSize: 5
- name: scaling-config-peak
  schedules:
  - cronJobDuration: 3600s
    cronSpec: '0 17-22 * * *'
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 100
        minReplicas: 10
        bufferSize: 5
- name: scaling-config-default
  fleetAutoscalerSpec:
    policy:
      type: Buffer
      buffer:
        maxReplicas: 40
        minReplicas: 5
        bufferSize: 4

What's next

Learn how to rollout a config.
Learn how to delete a config.