Introduced ability to use KEDA triggers for autoscaling

[ritmas]

Why is this pull request needed and what does it do?

Introduced ability to use KEDA triggers for autoscaling

Which issues (if any) are related?

N/A

Checklist:

• I have bumped the chart version according to versioning.
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.

Changes are automatically published when merged to main. They are not published on branches.

Note on DCO

If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.

[ritmas]

@hagaibarel what's missing for this PR to be merged?

[hagaibarel]

@ritmas I haven't got the chance to take a good look at this yet, but I'm curious why do you think we need another scaling option (aside from the hpa and the proportional-sutoscaler)?

I would like to understand the use case for this functionallity

[ritmas]

HPA is raw/native k8s approach for setting up deployment's autoscaling which is smoothly covered by high-level managers like KEDA or cluster-proportional-autoscaler itself.

I don't work with the latter one so I'm not familiar with it nor willing to due to wide adoption of KEDA within projects I'm working with. Another tool's adoption would increase personal work complexity on daily basis.

From community point of view, based on Github popularity (stars/forks), KEDA is more popular one and it should give more flexibility to use coreDNS itself.

[hagaibarel]

I understand what you're saying, but I'm trying to understand the usecase of introducing (yet) another way of auto scaling coredns

[ritmas]

My usecase is to auto-scale based on DNS request lag (coredns_dns_request_duration_seconds_bucket), which is a custom/external metric and requires extra service/adapter in the scope.

It might be metrics-server, prometheus-adapter or in GCP case Stackdriver Adapter. But I don't want either of these as KEDA has it's own metrics server and it's already running on my clusters.

So this PR would allow me to use Prometheus scaler and auto-scale based on that metric.

@hagaibarel

[ritmas]

@hagaibarel is this use-case enough to accept this PR?