Integration with KEDA

[tspearconquest]

trafficstars

Hello,

We are looking at adopting Flux CD in our environment and I noticed that Flux integrates with KEDA.

I realize it is still early for this project, so I thought I'd ask about the possibility of having an integration with KEDA in the future.

TF-Controller is definitely going to be something we will want to adopt alongside Flux when it reaches production readiness, in order to do CD of our Azure resources deployed via Terraform.

CD of the Azure managed resources is a very important priority. Because Flux will handle CD of Kubernetes resources, we want to have end to end CD, but without losing the benefits of Terraform.

However, we also want to adopt KEDA to manage scaling of both in-cluster Kubernetes resources as well as out-of-cluster Azure resources automatically.

Unfortunately it doesn't appear KEDA plays well with Terraform, so I had the idea to feature request here for integration between TF-Controller and KEDA which could work alongside the Flux integration with KEDA to allow us to have the best of both worlds.

It would be most desirable to be able to deploy a resource in Azure with TF-Controller and Terraform code, and have TF-Controller have the ability to dynamically scale Azure resources up and down based on events handled by KEDA.

I look forward to your thoughts on this.

Thanks for taking the time to hear me out. Have a great week!

Thomas Spear Sr DevSecOps Engineer

[chanwit]

Thank you @tspearconquest

I don't know much about it, but KEDA-based autoscaler for TF-controller would be a really nice use case. Let's discuss more around the tech bits.

[tspearconquest]

Hey! I actually don't know much about KEDA either, but I may have initially thought it could do more than it does. My initial research on KEDA mislead me into thinking that it could see events from (as an example) a postgres db, like high utilization, and automatically provision additional DB nodes, but that seems not to be possible, as KEDA is focused on scaling pods in the cluster with the HPA resource.

That said, I think there is still a use case for this, though it would be more limited in scope because of the above.

What I'm thinking now is a couple of things:

1. Azure has a configurable pod limit for cluster nodes. This defaults to 30 but can be raised as high as 250. So if KEDA scaled pods up to near the configured limit (as defined in Terraform), then I'd want TF-Controller to have the ability to adjust that limit in response.
2. Additionally, if the limit is configured to 250 and the nodes are greater than 80% capacity (200 pods running on each node), then I'd want TF-Controller to have the ability to create additional nodes to better distribute the pods and lower the workload of each node, and if KEDA later scaled pods back down to under 40% of the total capacity, (less than the value of "100 pods per node multiplied by n number of nodes"), then I'd want TF-Controller to start lowering the node count.

Ideally, this would result in a cluster which maintains a workload around 60% of the pod limit as the target, to allow for growth and high traffic periods without running short on CPU or Memory, while preventing overspending on nodes that we aren't utilizing.

[artem-nefedov]

I think KEDA integrates with Flagger, not with Flux (unless I missed something).

[tspearconquest]

Yes, you're correct. Flagger being a part of the Flux "ecosystem", so I meant Flux in a more general sense, rather than the specific product named Flux. Apologies for any confusion.

[lasomethingsomething]

Thanks so much for the suggestion but closing this now due to other priorities.