Add PredictKube scaler

[daniel-yavorovich]

This PR adds a new PredictKube scaler, ready-to-use for the community.
PredictKube - is a tool for proactive scaling based on the AI model’s prediction.

Related docs PR: kedacore/keda-docs#617

This is an example of what the TriggerAuthentication and the ScaledObject definitions would look like:

apiVersion: v1
kind: Secret
metadata:
  name: predictkube-secrets
type: Opaque
data:
  apiKey: # Required: base64 encoded value of PredictKube apiKey
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-predictkube-secret
spec:
  secretTargetRef:
  - parameter: apiKey
    name: predictkube-secrets
    key: apiKey
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: example-app-scaler
spec:
  scaleTargetRef:
    name: example-app
  pollingInterval: 60
  cooldownPeriod: 300
  minReplicaCount: 3
  maxReplicaCount: 50
  triggers:
  - type: predictkube
    metadata:
      predictHorizon: "2h"
      historyTimeWindow: "7d"  # We recomend to use minimum 7-14 days time window as historical data
      prometheusAddress: http://kube-prometheus-stack-prometheus.monitoring:9090
      metricName: http_requests_total # Note: name to identify the metric, generated value would be `predictkube-http_requests_total`
      query: sum(irate(http_requests_total{pod=~"example-app-.*"}[2m]))
      queryStep: "2m" # Note: query step duration for range prometheus queries
      threshold: '2000' # Value to start scaling for
    authenticationRef:
      name: keda-trigger-auth-predictkube-secret

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Tests have been added
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Changelog has been updated

Related to #197, #2401
Fixes #2458

[JorTurFer]

First, thanks a lot for this contribution ❤️
There are some topics that I commented in the code and apart from those, there are 2 global points:

• Add e2e tests for the scaler (we could add needed secrets if you need)
• Use s for referring the scaler instead of pkg. The majority if the scalers use s and it gives consistency across them.

And again, thanks a lot for this ❤️

[zroubalik]

+1 to the concerns raised by @JorTurFer
I will add one thing, would be nice to describe the architecture a little bit, ie. what is happenning under the hood, since this is not a standard scaler. The best thing is to open an issue and describe it there. And cover this in the docs as well.

[zroubalik]

There are 20 vulnerabilities in various dependencies brought through github.com/searKing/golang@v1.0.145.

[zroubalik]

There are 20 vulnerabilities in various dependencies brought through github.com/searKing/golang@v1.0.145.

I think that a better way would be actually not implement enums via that library (so it doesn't have to be included) and use more standard/idiomatic golang way. If I am not mistaken, that is the only place where this dependency is being used.

[daniel-yavorovich]

There are 20 vulnerabilities in various dependencies brought through github.com/searKing/golang@v1.0.145.

I think that a better way would be actually not implement enums via that library (so it doesn't have to be included) and use more standard/idiomatic golang way. If I am not mistaken, that is the only place where this dependency is being used.

We have implemented enum with golang standard way, thank you.

[zroubalik]

/run-e2e predictkube*
Update: You can check the progres here

[zroubalik]

LGTM, thanks for the contribution, it is looking great!

[zroubalik]

@daniel-yavorovich @alex60217101990 could you please resolve the outstanding issues in docs pr so we can go ahead and merge this one? Thanks!