Single Group to Multi-Group

While KubeBuilder v2 will not scaffold out a project structure compatible with multiple API groups in the same repository by default, it’s possible to modify the default project structure to support it.

Let’s migrate the CronJob example.

Generally, we use the prefix for the API group as the directory name. We can check api/v1/groupversion_info.go to find that out:

// +groupName=batch.tutorial.kubebuilder.io
package v1

Then, we’ll rename api to apis to be more clear, and we’ll move our existing APIs into a new subdirectory, “batch”:

mv api apis
mkdir apis/batch
mv apis/v* batch/

Next, we’ll need to update all the references to the old package name. For CronJob, that’ll be main.go and controllers/cronjob_controller.go. If you’ve added additional files to your project, you’ll need to track down imports there as well.

Finally, we’ll add a new line to PROJECT that marks this as a multi-group project:

version: "2"
domain: tutorial.kubebuilder.io
repo: tutorial.kubebuilder.io/project
multigroup: true

While this option doesn’t do anything right now, it’ll indicate to KubeBuilder in future versions that this is a multi-group project.

Now that we’ve migrated this to a multi-group project, normal KubeBuilder scaffolding won’t work (as of KubeBuilder v2.0.0 -- see the warning at the top of this page). You’ll need to copy the setup that KubeBuilder normally does to add new groups for the moment:

  • Copy over <kind>_types.go and groupversion_info.go to apis/<group>/<version>

  • Register the new group-version with the Scheme in main.go

  • Add a new <kind>_controller.go file

  • Add the controller to the manager in main.go

The CronJob tutorial explains each of these changes in more detail (in the context of how they’re generated by KubeBuilder for single-group projects).