Kong / gateway-operator

Kubernetes Operator for Kong Gateways
Apache License 2.0
52 stars 15 forks source link

Improve `kong/gateway-operator` Helm chart RBACs and CRDs propagation #770

Open czeslavo opened 1 month ago

czeslavo commented 1 month ago

Problem Statement

Currently, a Helm chart for the operator (kong/gateway-operator) resides in a separate repository (kong/charts), a central place for our charts to live.

The tests verifying an upgrade procedure live in the KGO repository and rely on the Helm chart.

Testing our Helm chart with the main version of the operator comes with an issue - when adding new RBAC rules or CRDs, those have to be updated manually in the charts repo first and released. That makes the process of robust testing before the actual release cumbersome.

This issue aims to find a solution that will make this process smoother, ticking as many as possible of the following boxes:

Proposed Solutions

Solution A - keep a separate branch in the charts repo

Maintain a kgo/next (or a specific kgo/vX.Y.Z) branch in the kong/charts repository where we'll stack all the changes needed for the next release (and merge it after a KGO release). Test against it in the KGO upgrade tests (could be done by cloning the charts repo and using it locally to avoid unnecessary releases polluting charts).

Pros:

Cons:

Solution B - Make CRDs and RBACs templates conditionally render new content based on KGO versions

Similarly to KIC, introduce version-based conditionals in templates, adding RBAC rules and CRDs if they're satisfied. (Note: this potentially could be automated with a generator iterating over all KGO versions, assembling the output files with conditionals).

This approach would impose the following flow when adding new CRDs/RBACs to KGO and implementing a reconciler for them:

Pros:

Cons:

Acceptance Criteria

pmalek commented 3 weeks ago

Another approach could be

Solution C

Move KGO chart related code into KGO repository. This would allow some parts of the mechanism to be automated, e.g. generating the manager role's policy rules and will resolve the chicken and egg problem that we have.

The chart would still be available to users from https://github.com/Kong/charts/: we'd introduce a mechanism for syncing the chart with https://github.com/Kong/charts/blob/gh-pages/index.yaml which is the source of truth for helm artifacts.

There are 2 challenges that I can see at this moment: