Document policies around Kubernetes and dependencies

[vincepri]

Every now and then, there is going to be breaking changes that need to be made for a number of reasons. A common which usually happens at every cycle:

• Minimum Kubernetes version
  • For management clusters
  • For workload clusters
• Controller Runtime version
  • Usually carries other Kubernetes dependencies pinned to a specific version, like k8s.io/api or client-go.

This issue should start a discussion on how to propose these changes in the community, and how to allow at the same time the project to move forward. An ideal process would give enough visibility well in advance when these changes need to happen.

/kind documentation
/milestone v0.4.0
/priority critical-urgent
/cc @detiber @CecileRobertMichon @ncdc @timothysc

[vincepri]

/assign

[vincepri]

Hey folks, at the Oct 14th community meeting we brought up this topic, in general I'd propose something along these lines while we're in alpha:

• Clearly document the management cluster support matrix for each alpha/minor version published.
• During planning, we should discuss what should be the suggested Kubernetes version for management clusters.
  • Suggested version is going to be used throughout testing, and we can provide some support for it.
  • Older versions MAY work fine with our controllers, although we won't necessarily test them or provide extensive support.

In general, I'd like to keep up with upstream Kubernetes at least for the management cluster (N, N-2) so we can adopt new features and keep our controllers up to date.

Workload clusters are definitely different, because Cluster API today is able to create clusters on a wide range of versions. That said, we should document what range of versions are supported for each release, and when/how we can sunset support for some older versions.

[detiber]

One thing to note as we define a policy, the range of n -> n-2 is only valid for k8s <= v1.18, starting with v1.19 the support statement has moved from 9 months and/or n-2 to 1 year.

https://kubernetes.io/docs/setup/release/notes/#increase-the-kubernetes-support-window-to-one-year

[vincepri]

The new policy could work very well for the newly defined release cadence, with some good overlap

[fabriziopandini]

@vincepri can I give this a try?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fabriziopandini]

/lifecycle frozen

[vincepri]

/milestone v1.0

[fabriziopandini]

#6122 improved our version documentation
/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

#6122 improved our version documentation
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.