Feature: Script Based Autoscaler

[markmandel]

I’ve had this idea floating around in my head for a while (I think it came up in a meeting?) and should really get it out 😆 and see if people like it.

Is your feature request related to a problem? Please describe.
If there is a need for any kind of custom logic with an autoscaler, a webhook autoscaler is the only solution. The friction point there is that this needs to be a http service that is also hosted somewhere. Sometimes, that’s not an option, or at the very least, it would be handy to not have to deploy a whole extra service as well as Agones itself to a cluster - but still have the ability to implement custom autoscaling logic with relative ease.

Describe the solution you'd like
Be able to configure the math for autoscaling using a script that’s embedded in the FleetAutoscaler configuration.

My first thought is embedding Go into the yaml, via https://github.com/traefik/yaegi , but there are a variety of scripting languages (linked below) , so something like this is a sacrificial draft:

apiVersion: autoscaling.agones.dev/v1
kind: FleetAutoscaler
metadata:
  name: fleet-autoscaler-counter
spec:
  fleetName: fleet-example
  policy:
    type: Script
    script: |
       func Scale(r FleetAutoscaleRequest) (FleetAutoscaleResponse, error) {
           response := FleetAutoscaleResponse{
             UID = r.UID
             Scale = true
             Replicas = r.Status.AllocatedReplicas + 1
           }
           return response, nil
       }

Some extra options that might be needed/wanted:

• function - the name of the function to use for scaling. Could have a default value of “Scale” (or similar), could also introspect the script and if there is only one function, and therefore use that one.

I do like yaegi though, since we can reuse the Go types we use inside Agones for the scripting language without as much need for interop layers.

Describe alternatives you've considered

Keep only the webhook autoscaler. A webhook does allow for custom logic as needed.

The only other downside to having this, is testability could be tricky.

In theory, people could use the script library itself to write unit tests for the script contents, likely pulled from their YAML files. A little tricky, but definitely not impossible. We could provide an example (and we’d probably want to have one anyway for our unit tests).

Additional context

• https://agones.dev/site/docs/getting-started/create-webhook-fleetautoscaler/
• https://agones.dev/site/docs/reference/fleetautoscaler/
• https://github.com/avelino/awesome-go?tab=readme-ov-file#embeddable-scripting-languages