[POC] KEDA scalable functions

[kwiatekus]

Description

Prove the following Concept: "User may install KEDA and configure kyma serverless to stop using HPA based scaling and use KEDA API (Scaled Object CRD ) to delegate scaling function deployment based on arbitrary scaler. serverless uses the existing HPA strategy to replicate functions by default"

Please propose any necessary API changes (Function CRD). Propose draft changes in the serverless tooling ( kyma CLI, Kyma Dashboard )

Assumptions:

• We should not assume KEDA is part of serverless. we offer integration point towards KEDA.
• Using KEDA instead of HPA is a decision made by user and realised via configuration
• Customer may use any arbitrary scaler that suits his usecase and matches the technologies used in his application (i.e various eventing mechanisms, various metrics, etc ...).
• We make no assumptions about Keda installation. It may be installed by user. It may be uninstalled at any time.
• Mixing Keda with HPA is not allowed. A selected scaler strategy is global
• User who is able to install KEDA should be able to change the scaling strategy (permission-wise)
• Changing the scaling to KEDA should not be reverted by reconciler.

Questions:

• Could Prometheus scaler be a default scaler suggested to the users ( i.e in the ui ) as a "generic" scaler based on incoming requests? How to observe an incomming request outside of an istio side cart (scaling to zero case)
• Is it possible to change the scaling strategy in runtime (as opposed to installation time) Reasons

We want to give developers freedom to scale parts of their kyma hosted applications based on their own strategies. We want to support KEDA integration as it comes with a variety of official and community driven scalers.

Attachments

https://github.com/kyma-project/kyma/issues/11225 https://github.com/kyma-project/kyma/issues/11997

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-stale-bot[bot]]

This issue has been automatically closed due to the lack of recent activity.

[a-thaler]

Will be also interesting to see the impact of shipping a 3party component-> What is the estimated effort to keep all dependencies up-to-date. Have you thought about the expectations to users? They might want to use it for regular deployments as well but based on other metrics or even other metrics sources as well? Can you support that and to which extend, what is the integration point?

[kyma-stale-bot[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[pPrecel]

After a quick investigation of how Keda is working with Kubernetes resources, I figured out that we may support the /scale sub-resource to allow users to create Keda's ScaledObject CR for Function instead of creating it for Deployment. It would be much easier for users because every Function's deployment has a name with a suffix generated that has to be known before creating Keda's resource. If we would support the /scare sub-resource then users would know the function's name only and they may not need to wait for the function's deployment. It's a huge pros from the perspective of resource versioning (like GitOps) or making serverless functions a kind of black box where users should not know (or just don't want to know) about resources managed by the serverless controller.

References:

• https://keda.sh/docs/2.7/concepts/scaling-deployments/#scaling-of-custom-resources
• https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource

The next step of this POC will be the investigation and implementation of the /scale sub-resource for the Function CRD