Skip to content

Extension mechanism for cross-cutting concerns #1048

@tomasaschan

Description

@tomasaschan

Feature Description

Problem Statement:
We have a "platform team for our platform teams" which administers and operates our Kro installation. Other platform teams can then add RGDs in our clusters to build products that compose or abstract over existing ones, without the central platform owner's needing to engage with every change.

However, there are a number of conventions we'd like to encourage or enforce, where it's unpractical to try to do it on every RGD defined - especially since there will be dozens of teams owning RGDs. Examples include:

  • Ensuring generated CRDs have a category field set with (at least) a common value to indicate it's an internal product (we can currently do this with a Kyverno policy, but it's hacky and would be better to handle in Kro itself)
  • Ensuring certain labels and annotations are propagated through the DAG when users create instances of the root CRDs. For example, KCC supports deletion policy annotations to allow users more control over what happens when configuration is removed from the cluster; we want to allow users to have that level of control even if the KCC resource is implicitly defined through a Kro RGD, which means the annotation must propagate from the root object to all children.

Many of these things are probably already supported in terms of defining them on the RGD itself, but what we're looking for here is a way to centrally manage these from the perspective of the team that operates the Kro installation itself, and have it apply to all RGDs created without having to do anything particular in the RGD itself.

Proposed Solution:
I don't have a particular design in mind; I could imagine either some YAML based thing the Kro controllers look at, or perhaps some kind of webhook that the controller calls out to when reconciling various objects. Given the two examples above are pretty different (one for CRD generation, one for reconciliation of CRD instances) they might warrant different designs.

  • Please vote on this issue by adding a 👍 reaction to the original issue
  • If you are interested in working on this feature, please leave a comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions