Adding worker autoscaling support with KEDA

[sdaberdaku]

No description provided.

[sdaberdaku]

For some reason, the trino_execution_resourcegroups_InternalResourceGroup_RunningQueries JMX metric is not exposed by Trino 446. It is by versions 435 and by 467. My KEDA test starts with 0 worker replicas. Then, a query on TPCH is launched on the coordinator, which increases this value from 0 to 1 and triggers the creation of a worker pod. Unfortunately, queries that are submitted when no workers are available enter a state of "WAITING_FOR_RESOUCES" which is not blocked nor queued.

@nineinchnick I am open to suggestions for a better metric or testing strategy.

[sdaberdaku]

I found the trino_execution_ClusterSizeMonitor_RequiredWorkers metric that works with all versions of Trino and allows us to test scaling up from 0 workers.

I am also wondering if the Chart should support the creation of TriggerAuthentication objects to cover the cases when Prometheus requires authentication. One could always create this object outside the chart and reference it in the ScaledObject trigger, so it is not mandatory. What is blocking me is how to implement the trigger - TriggerAuthentication assignment. One TriggerAuthentication can be referenced by multiple triggers. Naming also needs to be deterministic, since the trigger needs to reference the TriggerAuthentication object by name. I could "inject" the {{ Release.Name }} prefix to these objects, but I don't like it very much.

[nineinchnick]

First pass, I haven't yet checked all the new properties.

[nineinchnick]

We should document this is exclusive with server.autoscaling, and if possible, help users make the choice, if they're just starting with autoscaling and don't know either one of those options.

[sdaberdaku]

This makes totally sense. I will improve the documentation on this.

[sdaberdaku]

I tried to clarify this in the documentation. I also added a warning in NOTES.txt to indicate that keda would take precedente over hpa in case they are both enabled.