Skip to content

Latest commit

 

History

History
73 lines (45 loc) · 5.66 KB

SCALERS.md

File metadata and controls

73 lines (45 loc) · 5.66 KB
Raw

Scaler Governance

This document describes how KEDA handles governance of built-in scalers and how it relates to external scalers maintained by the community.

Scalers in KEDA

Each event source has unique characteristics on how KEDA needs to connect to it and the types of metrics available to drive scaling. KEDA is made up of many scalers, or simple extensions to the core KEDA operator that allows it to connect to an event source.

📝 You can find a full list of supported scalers in our documentation.

Scalers are shipped with KEDA in two ways:

  • Built-in Scalers - Scalers are packaged and shipped as part of the core KEDA runtime
  • External Scalers - Scalers that are running outside of KEDA but are capable of being used to scale workloads with. Workloads can be scaled by using the "External" or "External Push" scalers which integrate with the external scalers by using gRPC to drive scale.

Choosing the right model for a scaler

When introducing a new scaler, it is important to choose the right model for it - Should it be a built-in scaler or an external scaler?

The general rules of thumb for built-in scalers are the following:

If all of the above are true, then it is a potential case for a new built-in scaler. We recommend opening a feature request to propose and discuss it before doing the actual implementation though. This is to avoid throwing things away if it does not meet the needs after all.

Requirements for a built-in scaler

In order to contribute a scaler to KEDA's core, it must meet the following requirements:

  • A scaler MUST be written in Go
  • A scaler maintainer(s) MUST be assigned (individual(s)/company) and will be tagged for bug reports. If this is not the case, then it will be considerd to be "community-maintained" and all issues will be tagged with "help-wanted".
  • A scaler MUST have e2e and unit tests to guarantee its quality
  • A scaler CAN be deprecated when:
    • Maintainers believe it is best for the project, after a vote
    • The scaler maintainer(s) are not responsive and support volume is too high
    • The technology is proven to be no longer used/abandoned
  • Scaler MUST follow KEDA release cycles
  • A scaler MUST be supported, as per our support policy, by the scaler maintainer(s) and will be automatically assigned to PRs. This will be done by using GitHub's Codeowners.

Choosing a home for external scalers

Given the nature of external scalers, we recommend that they are maintained by the community and have a home outside of the KEDA organization. The reason for this is that it sets clear expectations for the community in terms of ownership and support.

There have been exceptions where they have been added to the KEDA organization, but that is because they are governed and co-maintained by the community. Regardless of the fact that they are part of the KEDA organization, the KEDA maintainers are not responsible for them but they work closely together with the scaler maintainers who are responsible for the quality of the scaler, timelines, etc.

Every external scaler inside the KEDA organization will have a liason which acts as a contact person between the KEDA maintainers and scaler maintainers. In case of a need, KEDA maintainers can influence requirements for new releases in order to ensure end-users have the best experience using the scalers in a consistent manner that fits the KEDA ecosystem.

Changing ownership of a built-in scaler

At a certain point in time, it is possible that a maintainer of a scaler is no longer possible/interested in maintaining a scaler. The same goes for community-maintained scalers where one or more people/company want to become the maintainer of a scaler.

In both cases, this change of scaler ownership has to be proposed to the KEDA maintainers and be discussed by opening an issue on our GitHub repository. It should elaborate on the motivation of this change and why this should be changed.

However, this decision should not be taken lightly as KEDA end-users rely on scalers. When a scaler transitions from dedicated maintainers to community-maintained, this can have implications on our end-users and raise concerns as they used to have (better) support on these scalers.

Once there is an agreement across the maintainers, the change of ownership will be made and communicated:

  • An announcement will be made on GitHub Discussions
  • Codeowners file in our Core repo must be updated
  • The KEDA documentation must be updated to reflect the new maintainers
  • The next KEDA release will include a note in the changelog with the new scaler maintainer(s)/community-based maintenance

Building an ecosystem around external scalers

While external scalers are not part of KEDA's core, we highly encourage the community and vendors to build them and make sure they are discoverable.

Artifact Hub allows the community to browse and list external scalers as a "kind" of artifact. Maintainers of external scalers are encouraged to list them in the Artifact Hub as per the documentation.

All external scalers in Artifact Hub are automatically listed on KEDA's website to make sure they are discoverable.