Using HPA in ScaledObject in restricted network environment

[rushi47]

Hello,
I am trying to evaluate KEDA but I wanted to confirm if it fits my scenario.

Currently we can’t use HPA as from the node where target pods are deployed, ingress is blocked on K8s API Server, lets called those node untrusted nodes.

I wanted to know if we use KEDA operator, will it work in following way:

ScaledObject (with HPA) if we specify address from where to get that metric, does HPA communicate with that metric source or its KEDA which communicates with that metric source to get that metric. We will schedule KEDA pods on trusted node, which can have access to kube api server or other metric sources

As HPA is unable to communicate with API Server from the specific nodes. So KEDA get metric from metric sources. And as KEDA is not sitting on untrusted node, KEDA can use that metric to scale down/up the deployment by communicating with kube api server.

Does KEDA work this way ?

Or it works like: KEDA spins up HPA. And then it’s HPA’s responsibility to communicate with metric sources ?

[rushi47]

cc: @JorTurFer

[zroubalik]

The request flow is following:

(ScaledObject) HPA -> K8s api server -> KEDA metrics server -> KEDA operator -> the actual metric source (the response is sent back then)

[rushi47]

Thank you @zroubalik for quick reply. And there's no way to avoid (scaled object) HPA --> Metric API communication right ?

[zroubalik]

What do you mean by Metric API? Kuberentes API server? This is needed, otherwise scaling woudlnt' work.

[rushi47]

What do you mean by Metric API? Kuberentes API server? This is needed, otherwise scaling woudlnt' work.

That's understandable, I wanted to know by any chance if I can avoid communication between HPA and k8s API. As lot of time, there's need of blocking ingress communication on k8s api from certain nodes, so using HPA isn't possible.

That's the thing I wanted to know, by any chance if there's flow:

External Metric System --> KEDA Operator --> Scaling Decision --> K8s API --> Deployment running on nodes which doesn't have ingress access to Kubernetes api.

It looks like this isn't feasible right now. Do you think this is valid use case ? I can file feature request, if you think this is useful.