Migrate app platform components from operatorkit to kubebuilder

[rossf7]

Summary:

In SIG Operator we've recently discussed migrating our operators and other components from operatotkit to kubebuilder.

See https://github.com/giantswarm/giantswarm/discussions/16755

User value

As a user of the GIant Swarm app platform if I'm familiar with kubebuilder I can more easily contribute to the components. This is unlikely with operatorkit since its only used by Giant Swarm.

Business value:

As a Platform Engineer if I"m familiar with kubebuilder I can work on app platform components without having to learn operatorkit. I can also more easily switch between Cluster API controllers and app platform components since they use kubebuilder.

Components:

• app-admission-controller
• app-exporter
• app-operator
• chart-operator
• cluster-apps-operator

[rossf7]

@cokiengchiara Here is the roadmap issue PTAL.

When we start on this I think migrating app-admission-controller first makes sense because https://github.com/giantswarm/management-cluster-admission already uses kubebuilder and its smaller than the operators.

[LolloneS]

@weatherhog with us slowly converging on the Flux ecosystem, does it make sense to keep this open?

[weatherhog]

@LolloneS, yes.

chart-operator will get replaced by flux but for example app-operator still will be used and therefor a migration from operatorkit to kubebuilder still makes sense.

[weatherhog]

@giantswarm/team-honeybadger does a migration still makes sense? Can we create a list of components that need to be migrated?

[uvegla]

I would say absolutely makes sense. OperatorKit should be dead for a long time. Any *-operator repo here that we still care about would need to change: https://github.com/search?q=org%3Agiantswarm+operatorkit+path%3Ago.mod&type=code

The most notable ones are listed in the issue description above, but:

• app-operator
• chart-operator (worth it? how long do we still have it?)
• cluster-apps-operator (we own it but its Kaas, really)
• rbac-operator (owned by shield now)
• app-exporter
• app-admission-controller
• silence-operator (still used very much and should be simple I think)
• aws-operator (vintage only I think)
• config-controller ((vintage only, possibly not worth it)
• prometheus-meta-operator (owned by atlas)
• release-operator (owned by tenet)
• etc...

[weatherhog]

@JosephSalisbury does it make sense to put some priority on this and taking this to sig-product? To finally get all operators migrated and removing the technical debt?

[JosephSalisbury]

yeah, i'll add it to the agenda - if we agree on priority, we can make a list and dispatch issues to teams

[JosephSalisbury]

• open a github issue for each operator we need to migrate (i.e: won't die within 12 months), make POs aware that they have a risk
• work out a migration path (how to avoid a big-bang change)

ping @JosephSalisbury

[JosephSalisbury]

Closing here, taking #3722 as the more high-level tracking issue