Implement E2E test for streamlined upgrades

[fabriziopandini]

What would you like to be added (User Story)?

It will be great to have a signal about streamlined upgrades in CAPI as well (both for legacy and classy clusters)

Detailed Description

This KEP introduced the idea of streamlined upgrades, and, by playing around with K8s version skew policies, making it possible to upgrade by 2 or 3 Kubernetes minor versions by minimizing the worker's machines rollouts.

Anything else you would like to add?

The UX for streamlined upgrades in CAPI is not ideal, it requires manually upgrading through all the minors and applying "topology.cluster.x-k8s.io/hold-upgrade-sequence" to the first MD till the target version is reached, but it should work.

Label(s) to be applied

/kind feature
/area testing
/area conformance

[fabriziopandini]

/triage accepted
/help

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/triage accepted
/help

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.

[vincepri]

What do we mean by "streamlined", as in just go through each revision programmatically?

[fabriziopandini]

"streamlined" was a term used in some discussions, but I'm not sure it is the best one or the most correct one.

What we want to test is an upgrade sequence that is allowed by K8s skew policies, which allows you to go up by three minors in faster than going through each revision; the trick is to make the control plane go through all the steps, and only after the control plane is at the target version you can make a single upgrade for all the workers skipping the intermediate steps.

The example from the proposal is

1. Begin: control plane and nodes on v1.40
2. Control plane upgrade: v1.40 → v1.41 → v1.42 → v1.43
3. Node upgrades: v1.40 → v1.43

[fabriziopandini]

Thinking again to this issue I'm now leaning toward closing it because IMO we should aim at implementing first-class support for skipping worker upgrades (vs stretching the usage of "topology.cluster.x-k8s.io/hold-upgrade-sequence" for a use case it was not designed for)

/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

Thinking again to this issue I'm now leaning toward closing it because IMO we should aim at implementing first-class support for skipping worker upgrades (vs stretching the usage of "topology.cluster.x-k8s.io/hold-upgrade-sequence" for a use case it was not designed for)

/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.