What is the process for supporting new version of Kubernetes?

[tamalsaha]

Kubernetes releases a new major client-go every 3 months. Usually every release has some breaking that needs updating any library that uses k8s.io packages to same release. We are interested in using kubebuilder. I would appreciate if you could answer the following questions:

• What are the usual technical steps for updating kubebuilder to support a new version of Kubernetes?

• Are there any plans to do this at the same time a version of kubernetes is released? (like client-go etc.)

Thanks. /cc: @pwittrock

[tamalsaha]

xref: kubernetes-sigs/cluster-api#522 (comment)

[droot]

We are getting lot of queries around upgrading to new kubernetes. I will write a detailed section in the kubebuilder book, but here is a quick summary:

kubebuilder project uses controller-runtime (higher level abstraction built on top of client-go and other k8s stuff in core) and controller-tools for manifests generation. So let say controller-{runtime, tools} have been upgraded to desired k8s version, then the steps involved in your kubebuilder project would be to update the deps using dep ensure -update sigs.k8s.io/controller-runtime sigs.k8s.io/controller-tools. Here is the doc describing versioning for controller-runtime.

Re: timing of moving to newer releases of k8s, so far we have been 3 months behind the official releases. As we are improving tooling around releases etc in kubebuilder repos, we hope to move faster on that.

[tamalsaha]

Thanks @droot !

Regarding timing, do you accept contributions on upgrading the runtime and tools? Or, things just stay in review until other downstream projects are ready to update?

In other words, if we send prs to upgrade these repos, will those be merged?

[droot]

Regarding timing, do you accept contributions on upgrading the runtime and tools? Or, things just stay in review until other downstream projects are ready to update?

Yes, We accept contributions on upgrading and We don't wait for downstream projects to update. We do coordinate updating the deps in controller-runtime/tools at the same time because kubebuilder projects can't have the mix of tools and runtime depend on different k8s releases.

For last couple of releases upgrading k8s didn't introduce any breaking changes to the controller-runtime/tools API, so it has been mostly straight forward, but if they do then then will require bumping up the revisions for runtime/or tools which may require some communication and impact analysis.

[tamalsaha]

The issue is client-go makes breaking changes in every release. https://github.com/kubernetes/client-go/blob/master/CHANGELOG.md

So, there may be no changes in the parts used by runtime/tools. But downstream projects always have some impact as they may use the parts that had breaking changes in client-go.

[mengqiy]

@tamalsaha You are welcome to contribute.
kubernetes-sigs/controller-runtime#221 is an example of upgrading k8s dependencies. You can see that even though there are breaking changes in client-go, there are no breaking changes at controller-runtime surface.

[droot]

Closing this issue since there aren't any next steps.