Cluster-api: Update apiserver-builder from 1.9, or switch to CRDs?

Created on 27 Jun 2018 · 14Comments · Source: kubernetes-sigs/cluster-api

Some core components depend on apiserver-builder v1.9-alpha.3, which depends on Kubernetes 1.9.x. Therefore components are locked to the Kubernetes 1.9.x.

Updating apiserver-builder to a newer release does not seem trivial. The project is not actively maintained. Kubebuilder--a similar project that targets CRDs--is actively maintained. CRDs do not have feature parity with API extension servers, but are closer than a few releases ago, when Cluster API chose them over CRDs. In light of the above, the time seems right to revisit the choice.

Core components that are generated by (and import) apiserver-builder:

Generated API code /pkg/apis
Generated OpenAPI spec /pkg/openapi
Cluster API controllers /pkg/controller
API server /cmd/apiserver
Controller manager /cmd/controller-manager

Why does cluster API need an updated apiserver-builder?

The cluster API controllers may have issues running on a 1.11 or newer cluster. The Kubernetes control plane is guaranteed to be compatible with the previous minor version, so the cluster API controllers should have no issues running on a 1.10 cluster.

Source

dlipovetsky

Most helpful comment

+1 to move to CRDs

dims on 23 Jul 2018

👍7

All 14 comments

The apiserver-builder project appears to not be active; the latest commit is in the v1.9-alpha.3 release from May 6. The kubebuilder project may be a good option in the future, but today does not provide functionality we get from apiserver-builder[0].

[0] Based on @medinatiger's comments at the WG 6/27/2018 meeting.

dlipovetsky on 27 Jun 2018

Wondering if this is alluding to the discussion of switching back to CRDs?

kris-nova on 28 Jun 2018

@kris-nova Yes. I should have been more explicit: kubebuilder is for CRDs only, so we could use it only if we switched back to CRDs.

For reference: CRDs have gained parity with Aggregated APIs since the time the of the decision to use an Aggregated API.

dlipovetsky on 30 Jun 2018

Though I do suspect cluster-api should move to CRDs for the maintenance reasons discussed here on "Wed 14 February 2018".

davidewatson on 1 Jul 2018

One of the key of the missing things CRDs is version conversion - especially when you need custom conversion (field X is spitted into fields Y and Z for example). The good thing is that there is a design document for this change - http://bit.ly/k8s-crd-conversion
The other thing that is missing is subresources. We at the moment don't use it, but we might in the future.
I'm for CRDs change.

mvladev on 18 Jul 2018

+1 to move to CRDs

dims on 23 Jul 2018

👍7

@enxebre FYI

ingvagabund on 1 Aug 2018

We discussed this issue during the working group meeting today and the consensus is that folks think we should move back to CRDs. @detiber has started doing some prototype work using kubebuilder (see https://github.com/detiber/cluster-api-crd) but we could use some help moving this issue forward.

roberthbailey on 22 Aug 2018

What's needed to move this forward, and do we want it done within the 1.12 timeframe?

randomvariable on 29 Aug 2018

@randomvariable So far in https://github.com/detiber/cluster-api-crd I have the basic API structs migrated over, but work still needs to be done to finish up the generated controllers, adding the validating webhooks to ensure validation parity, and adding the mutating webhooks for setting default values.

It'll probably be next week sometime before I'll be able to continue any work on it. I'm more than happy to add additional collaborators to the repo for anyone that wants to help move the conversion forward.