MaintenanceController doesn't check if currently used container runtime is supported by new image

[voelzmo]

How to categorize this issue?

/kind bug
/priority 3

What happened:
The maintenance controller selected a new MachineImageVersion during maintenance which doesn't list the cluster's container runtime in the CloudProfile

What you expected to happen:
When picking a new version, support for the currently used container runtime is taken into account. It could happen, for example, that future versions of an image drop support for the docker runtime. In this case, these versions must not be selected for clusters which use the docker container runtime.

How to reproduce it (as minimally and precisely as possible):

• Deploy a Shoot using containerd using gardenLinux v184.0
• adapt the CloudProfile:
  • set gardenLinux v184.0 to deprecated with an expirationDate in the past (e.g. 2021-06-30T23:59:59Z)
  • set gardenLinux v318.8.0 to supported
  • Remove containerd support for v318.8.0
• trigger shoot maintenance immediately with ./hack/usage/shoot-operation <shoot-name> <namespace-name> maintain

Anything else we need to know?:
Right now this is probably not that big of an issue, as we haven't seen events of container runtime support being removed. This is likely to happen in the future, though, if we e.g. decide to drop support for docker at some point in time.

Environment:

• Gardener version: 1.26.0
• Kubernetes version (use kubectl version): 1.21.0
• Cloud provider or hardware configuration: gcp
• Others:

[voelzmo]

Related: I can also do this change manually! Updating the Shoot spec, such that my worker's MachineImageVersion refers to a version which doesn't support the currently selected runtime.
For example:

• Create your shoot with gardenlinux and container runtime containerd
• Then update it to use suse-chost (which doesn't support containerd yet and therefore doesn't have it in its list of supported runtimes in the CloudProfile
• This update should be rejected during validation, but it is not!

This is probably worth its own issue: #4308

[BeckerMax]

/assign
/assign voelzmo