📖 update supported Kubernetes versions

[sbueringer]

Signed-off-by: Stefan Büringer [email protected]

What this PR does / why we need it:
See issue.

I think we should only try to keep the supported versions of the current book up-to-date (it's hard enough). So I wouldn't fix the old 0.3 book. Or at least as we're currently referencing the current and the last release series in our matrix and I wouldn't maintain it in both books.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #4988

[sbueringer]

I think v0.3 and v0.4 Management is correct. @fabriziopandini I'm not sure about workload cluster support in v0.4. What is the lowest version we support?

[vincepri]

Lowest workload cluster should be 1.19 IIRC

[sbueringer]

We're also running tests for v1.18 (upgrade v1.18=>1.19)

[vincepri]

Are we testing 1.16 as well? Should we start testing all the combinations we support?

[sbueringer]

I think that brings up more or less: #4444

My personal opinion. We currently have 3 kinds of versions (applies to workload and management clusters):

1. versions we test
2. versions that should work (no tests, best effort support on bug reports, but as far as we know they work)
3. versions that definitely don't work (usually because of hard incompatibility like controller-runtime v0.5.x => Kubernetes v1.22)

Ideally we test all versions that should work.

We would need:

• 1.19-1.22 management cluster tests (currently: afaik 1.21)
• depending on what works 1.16/1.18-1.22 workload cluster tests (currently: 1.18-1.22)

Those are only the tests for v1alpha4. In this scenario we probably would have to add one management and one workload cluster test every 4 months (aka Kubernetes release) during the lifespan of a CAPI release.

Probably better discussed elsewhere :)

/cc / fyi @fabriziopandini

[sbueringer]

A significant improvement imho would be to make it transparent what we test in the book, e.g. different symbols for "should work" vs "is tested periodically in CI" vs "will not work" (but of course same problem as before, ideally we should keep it up-to-date)

[fabriziopandini]

Lowest workload cluster should be 1.19 IIRC

What is the reason why workload cluster are limited to v1.19? It is n-3 or there are other considerations?

We're also running tests for v1.18 (upgrade v1.18=>1.19)

That's ok, it ensures there is a migration path for users on oldest versions

(discussion about skew vs documentation)

Some time ago (I can search for the issue) we discussed about the idea of a recommended version for the management cluster, with the specification that this was the version being tested (only one); but It won't be a big deal to run quickstart using different version kindest/node.

For the workload clusters we are testing a wider skew, but until #4444 gets addressed it is hard to say what we should test.

If we can agree on support skew rules, that it will be easier to document them, otherwise I don't see other options than upgrading manually every time there is a K8s version

[sbueringer]

Based on the policies we currently have what should I put in the doc?

Currently I have:

• v0.3:
  • mgmt: v1.16-v1.21
  • workload: v1.16-v1.22
• v0.4:
  • mgmt: v1.19-v1.22
  • workload: v1.16-v1.22

I couldn't really gather it from the responses :)

As mentioned, I'm mostly unsure about the workload Kubernetes version support with v0.4. I know we test a v1.18 installation. So it probably comes down to if I should include v1.16 and v1.17 (with v0.4).

[vincepri]

We can probably include 1.18 if we have test coverage for it in v0.4, other than that, +1

[sbueringer]

Thx, adjusted the PR accordingly

[vincepri]

/lgtm

[k8s-ci-robot]

@sbueringer: GitHub didn't allow me to request PR reviews from the following users: fyi, /.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

I think that brings up more or less: #4444

My personal opinion. We have 3 kinds of versions (applies to workload and management clusters):

1. versions we test
2. versions that should work (no tests, best effort support on bug reports, but as far as we know they work)
3. versions that definitely don't work (usually because of hard incompatibility like controller-runtime v0.5.x => Kubernetes v1.22)

Ideally we test all versions that should work, not sure if that's realistic though.

We would need:

• 1.19-1.22 management cluster tests (currently: afaik 1.21)
• and depending on what works 1.16/1.18-1.22 workload cluster tests (currently: 1.18-1.22)

Those are only the tests for v1alpha4. In this scenario we probably would have to add one management and one workload cluster test every 4 months (aka Kubernetes release) during the lifespan of a CAPI release.

Probably better discussed elsewhere :)

/cc / fyi @fabriziopandini

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.

[sbueringer]

Fixed some of the findings. Only need consensus on: https://github.com/kubernetes-sigs/cluster-api/pull/5012/files#r678573856 now :)

[sbueringer]

@fabriziopandini @vincepri ptal :)

[fabriziopandini]

/lgtm
if people will ask for support of older release with 0.4 we will iterate after setting up CI coverage

[vincepri]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment