feature: Include CRDs into operator

[mjudeikis]

Feature Description

When developing more complicated setup changes for the operator, you sometimes need to test it in more complex environments, such as a multi-shard setup.

If this involves adding or modifying existing CRD fields, the process becomes more complicated because you must build the operator image, extract the new CRDs, and apply them to the target cluster.

It would be ideal if the operator could self-bootstrap the CRDs it requires as part of an init container.
This would make testing changes much faster by removing an extra step from the development process.

Proposed Solution

Enable the operator to automatically create or update the required CRDs as part of its initialization (e.g., a dedicated init container). This automates the process and reduces manual intervention for changes to CRDs.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

[embik]

I'm not a huge fan of this at all, especially not for production setups. What is wrong with kubectl apply -k config/crd for development?

[mjudeikis]

because each time you need to do this in production cluster, its 3 step machine:

1. Redeploy operator helm chart. It will revert to old crd.
2. Your shards gets redeployed or even worse, bricked
3. You do kubectl apply -k config/crd to "get PR code" and it redeploys again.

It just very irritating doing more complex changes when each time you need to redeploy all stack 2 times to check if things works fine.

I know this is "helm way", but I think code relaying on these objects should own the objects itself, as now its unessarsy sepration.

[embik]

I would never suggest to deploy PR code to a production cluster 😬 What we can do is fix the manifests in this repo to properly deploy kcp-operator, then you can do kubectl appy -k config directly, but embedding CRDs feels like a hack around the actual problem.