-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide CloudEvent design proposal to extend KEDA #479
Comments
Thoughts @jeffhollan? |
We should definitely implement the Kuberenetes eventing approach (created #530). This could be lower priority item. |
Thanks for that! Since Kubernetes doens't support CloudEvents (yet), I would leverage this as a seperate component as well to make it easier to integrate with other products/tools that are not Kubernetes event specific. See kubernetes/kubernetes#85544 for CloudEvents support in Kubernetes. |
The reason for that is that, for most scenarios you'd want to react on these events, and these workloads are not always in Kubernetes. If we only support Kubernetes events how it is today, events are stuck inside the cluster so they are, in my opinion, often pointless. If we have CloudEvents, we can just forward them to things like Azure Event Grid and take it from there with FaaS/SaaS/PaaS services like Azure Functions. |
I will provide a more thorough proposal before we start on this. |
But similarly to how we offer scale-to-zero, we can leverage this as well in my opinion. If it's technically possible, which I think it should be but I do agree that this could be in a separate component if need be. |
Can you please help me to understand how rising Cloud Events will help with multi-cluster use-case #1587 ? |
Events will allow you to extend KEDA to close our current multi-cluster gap and take required actions. For example if we're at max replicas you can scale out in another region or if it fails to scale, etc. However, we are open to event requests that can help you more though. |
Last call for reviews before we close it on Tuesday EOB European time. /cc @kedacore/keda-maintainers |
I have taken another look and I agree with all but |
I tend to disagree and say that this is implementation detail because KEDA's focus is making application autoscaling simple and using HPA is just an implementation detail that some/most KEDA end-users don't even know about. Because of that, it's up to us to provide a unified autoscaling solution imo. |
I hope we'll agree to start mult-cluster support for KEDA.
It's a crucial feature for enterprise scale systems.
|
All work items have been created and can be progress can be found on https://github.com/orgs/kedacore/projects/2/views/23?query=is%3Aopen+sort%3Aupdated-desc |
Provide CloudEvent that are emitted by the runtime so that customers can extend KEDA.
Events that come to mind are:
New Trigger Authentication Created
Deployment Scaled to Zero
New Scaled Object Created
Only concern I have is that folks could go through the Kubernetes eventing approach to get the information, but if we would emit it ourselves we could make it more user friendly rather than having to figure this out via the Kube way
Tasklist
The text was updated successfully, but these errors were encountered: