-
Notifications
You must be signed in to change notification settings - Fork 593
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
Make Knative eventing sources more serverless and scalable #2153
Comments
Same as #2152 (comment) + this requires non-HTTP autoscaling (eg autoscaling based on kafka messages like https://github.com/kedacore/keda) |
@slinkydeveloper Yes. Something like "activator" component that waits for activity related to registered sources and starts source? It could also work as auto-scaling to provide metrics to scale up source service/deployment (and down when no activity)? |
Keda (is pull based autoscaler) so it supports mulitple event sources scaling (0-1) OOTB today, just as @slinkydeveloper mentioned. In case you are interested I could provide help with Keda on this. |
@zroubalik @slinkydeveloper that would add KEDA as dependency for those knative sources that need pull based scaling? If I understand correctly KEDA design we could use ScaledObject (example) to scale knative source deployment? |
@aslom Exactly, in ScaledObject you can specify the specific settings for each Knative Source (ie. how do you want to scale it). I can imagine a very simple controller that creates ScaledObject with preferred settings when Event Source is created. |
I can see that two ways to implement
Or do both which I think may the best - if users have KEDA they can configure Knative to use KEDA. Otherwise can use built-in pulling and scaling in controller to scale sources @zroubalik if the picture below is correct for KEDA and what do you think about the options? Feel free to edit slides: https://docs.google.com/presentation/d/1JNV25z0ZkjA_vhZy0y3dag_xoku3dtunMYtoggyFu6Y/edit?usp=sharing |
@aslom Hi, I think the picture is correct and described correctly both options. As for the options, Keda provides all necessary scaling capabilities for multiple sources OOTB today. So it is up for a decision, where do we want to put the effort. Whether we want to reimplement the same functionality inside Knative, reuse Keda or implement both options. I am willing to help with the Keda and controller part. I'd like to note that Keda is going to release v1.0 soon and is planned to move Keda under CNCF. So there shouldn't any concerns on this, wrt adding it as an dependency for Knative Eventing. |
@zroubalik that sounds good. As the very first step we should be able to use Keda by creating Scaler yaml? That means that controller when it sees KEDA in source configuration then it creates Scaler yaml and assumes KEDA will do scaling. That should allow us to do quick testing - I will start with Kafka source that is already supported in KEDA and see how scaling works. (I already have experience with Kafka source) Does that sound reasonable? |
Yeah, that scenario sounds good. I have an experience with Keda, so I'll be happy to write the controller for managing it. @aslom or do you plan to write that? |
@zroubalik yes going ot write first version for quick review |
@zroubalik do you know what is current state of scaling to zero in KEDA and HPA? It seems that is not possible as defaultHPAMinReplicas is used if MinReplicaCount is set to zero? It seems to be related to HPA not supporting it in some versions of K8S? minReplicas is set in HPA created by KEDA to 1 (as expected on code above) and if I manually edit it to
then I am getting:
Seems to be fixed in k8s 1.16+ Going to test it with 1.16 but I wondered if it is documented somewhere in KEDA? I could not find an issue about it. BTW: the confusing part was that even I manually scaled:
kafkasource deployment would not disappear - took me some time to realize that HPA was scaling it back to 1 ... |
@aslom scaling to 0, is done by KEDA controller (it sets deployment to 0 replicas). It is not managed by HPA at the moment, as you correctly mentioned that this feature is fixed in k8s 1.16+, so it might get into the KEDA later, as we are supporting older k8s versions as well. Scaling to 0 should work correctly, I wonder what caused the problem you are facing. You might hit the cooldown period? |
@zroubalik are you sure that HAP is not used by KEDA? I am using the lates version I deployed from github 2 days ago. Where I can find about how ScaledObject and HPA works in KEDA? When I create ScaledObject I can see corresponding HPA is created. When I delete ScaledObject then HPA is deleted. The created HPA has minScale 1 and that prevents kafka source from going wiht replicas to 0 when I am running kubectl scale deployment |
@aslom HPAs are used by KEDA. But for the scaling itself: 0 <-> 1 is handled by KEDA, 1 <-> N is handled by HPA which si being created for each ScaledObject. |
@zroubalik That makes sense considering HPA will only allow scaling to zero in 1.16+. When scaling to zero what mechanism is used - does it disable HPA so it does not scale replica back to one from zero? |
@aslom it scales Deployment to 0 replicas |
@zroubalik thank you for your help - I have got it now working. TLDR: I did not realize that knative kafka source controller was scaling back to one from zero (and it was doing it very fast ...) and ran into problem with KEDA 1.0 and had to use latest install form git master (details below) Short screen recording: https://vimeo.com/376958832 Now that it is working with manual setup next step I am doing PR to add KEDA support as option in Kafka source yaml. Tested with K8s v1.16.3
Installed KEDA 1.0 using YAML files git clone https://github.com/kedacore/keda.git
cd keda
git checkout v1.0.0
kubectl create namespace keda
kubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml
kubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml
kubectl apply -f deploy/ Deployed Kafka Source using Strimzi: And created test topic with ten partitions (so KEDA scaler for Kafka can scale up to 10 as it scales to number of partitions):
And created Knative Kafka source that is using my-topic-10
Then getting deployment for Kafka source:
Create KEDA scaler that is scaling Kafka source deployment:
But that fails
Then I found related issue So I checked out master with commit ID below (to help with reproducting)
and then redployed KEDA CRDs and applied config Then re-created scaled object
Verify in KEDA controller logs all is good
And I was able to see scaling in response to load generator. To generate messages I am using simple script that sends message every 10ms (sleep 0.01)
and used with
To verify Kafka messages are sent and received
Then watch pods to see scaling
or
To test scaling to zero deleted kafka source controller
Make sure the controller is not runnign
and manually scaled kafka source deployment to zero
|
As next step going to create PR to eventing-contrib Kafka source to modify controller to create ScaledObject if there are scaling parameters in yaml. |
@zroubalik @matzew @n3wscott @lionelvillard I will show quick demo in knative source WG and also here is video https://youtu.be/-zv-6DcU794 and slides showing current status and future plans: Looking forward to your feedback |
I have test failing as I made optional
and they end up serialized as "null" instead of not serialized:
It seems that the best solution may be to use the smae approach tha serving is using: spec:
template:
metadata:
annotations:
autoscaling.knative.dev/minScale: "2"
autoscaling.knative.dev/maxScale: "10" and with custom annotation class: spec:
template:
metadata:
annotations:
autoscaling.knative.dev/metric: cpu
autoscaling.knative.dev/target: 70
autoscaling.knative.dev/class: hpa.autoscaling.knative.dev but changing class to keda: Option 1: spec:
template:
metadata:
annotations:
autoscaling.knative.dev/minScale: "0"
autoscaling.knative.dev/maxScale: "10"
autoscaling.knative.dev/pollingInterval: "1"
autoscaling.knative.dev/cooldownPeriod: "15"
autoscaling.knative.dev/class: keda.autoscaling.knative.dev Other option would be to use new labels, for example: Option 2: metadata:
name: kafka-src10
annotations:
eventing.knative.dev/autoscaler: keda
keda.knative.dev/minReplicaCount: "0"
keda.knative.dev/maxReplicaCount: "2"
keda.knative.dev/pollingInterval: "1"
keda.knative.dev/cooldownPeriod: "15" Using KEDA as prefix may work better for KEDA parameters that are not supported in serving such as pollingInterval or cooldownPeriod - for descriptionhttps://keda.sh/concepts/scaling-deployments/ Both would translate to the same ScaledObject: apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
...
spec:
pollingInterval: 1
cooldownPeriod: 15
minReplicaCount: 0
maxReplicaCount: 10 @lberk @matzew @lionelvillard @zroubalik @n3wscott what do you think about it? Using shared annotations would make it consistent scaling configuration across serving and eventing. Here is what I propose as cooldownPeriod and pollingInterval are generic concept not specific to KEDA so I think the first option works the best? |
I don't have a strong opinion on the options, but tend to like 1 more. IMHO what about: metadata:
annotations:
autoscaling.knative.dev/minScale: "0"
autoscaling.knative.dev/maxScale: "10"
autoscaling.knative.dev/class: keda.autoscaling.knative.dev
keda.knative.dev/pollingInterval: "1"
keda.knative.dev/cooldownPeriod: "15"
|
@zroubalik I used your suggestion with minor modification for class as prefix in annotation field name: annotations:
autoscaling.knative.dev/minScale: "0"
autoscaling.knative.dev/maxScale: "10"
autoscaling.knative.dev/class: keda.autoscaling.knative.dev
keda.autoscaling.knative.dev/pollingInterval: "2"
keda.autoscaling.knative.dev/cooldownPeriod: "15" Details in knative/eventing-contrib@aa0079a |
Updated status and options for scaling pull-based event sources in #2901 (comment) |
This issue is stale because it has been open for 90 days with no |
/reopen |
Is this still relevant? Since I see you worked on this in more specific issues, can we close this more general issue? |
This issue is stale because it has been open for 90 days with no |
Problem
A short explanation of the problem, including relevant restrictions.
Sources are running and consuming resources even when there is no events. And when large number of events is received source do not automatically scale up
Persona:
Which persona is this feature for?
System Integrator, Event consumer (developer)
Exit Criteria
A measurable (binary) test that would indicate that the problem has been resolved.
When event sources are not receiving events they scale down to zero (or almost zero) and scale up when umber of events to send increases
Time Estimate (optional):
How many developer-days do you think this may take to resolve?
weeks
Additional context (optional)
Add any other context about the feature request here.
Ref #2152
The text was updated successfully, but these errors were encountered: