Drop support for seeds running K8s <= 1.17

[timuthy]

How to categorize this issue?

/area security
/area performance
/area scalability
/kind enhancement
/priority 3

What would you like to be added:
Gardener should only support seed clusters running K8s 1.18.x and later.

Why is this needed:
At the moment the minimum supported version of a seed cluster is K8s 1.15 or 1.16 if ManagedIstio is enabled (ref). However, these versions aren't officially supported any more (ref) and thus often don't contain important security or bug fixes. There might be exceptions when cloud providers maintain their own fork (e.g. GKE) but we don't want to rely on these exception and neither do we want to motivate using a non-maintained K8s version in any Gardener landscape.
After discussing with @timebertt and @rfranzke, we decided to go for a minimum version of 1.18 (one version below official version skew) as support for this version was added to Gardener over a year ago and most cloud providers offer this version as well. This should give us enough confidence that the community already run their seeds with >= 1.18 or can update them accordingly.

But there is another reason to go for at least 1.18: Server-Side Apply. We identified many places, especially in the Gardenlet code, that will benefit from SSA compared to Json-Merge/Strategic-Merge patches that are used today. Less conflicts, less network transfers, less API calls, lower code complexity, etc.. Other components in the Gardener landscape, e.g. Etcd-Druid or provider extensions, will benefit from SSA to at least the same extent.

[timebertt]

Thanks for the excellent summary!
One addition: If the SeedKubeScheduler feature gate is enabled, we also require >=1.18 as a seed cluster kubernetes version already (ref)

[timebertt]

With this, we will also be able to finally get rid of the infrastructure cleanup wait, which will make shoot deletion faster by ~5m 🎉

gardener/pkg/gardenlet/controller/shoot/shoot_control_delete.go

Lines 432 to 448 in e3e68cc

	// Services (and other objects that have a footprint in the infrastructure) still don't have finalizers yet. There is no way to
	// determine whether all the resources have been deleted successfully yet, whether there was an error, or whether they are still
	// pending. While most providers have implemented custom clean up already (basically, duplicated the code in the CCM) not everybody
	// has, especially not for all objects.
	// Until service finalizers are enabled by default with Kubernetes 1.16 and our minimum supported seed version is raised to 1.16 we
	// can not do much more than best-effort waiting until everything has been cleaned up. That's what the following task is doing.
	timeForInfrastructureResourceCleanup = g.Add(flow.Task{
	Name: "Waiting until time for infrastructure resource cleanup has elapsed",
	Fn: flow.TaskFn(func(ctx context.Context) error {
	ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
	defer cancel()
	<-ctx.Done()
	return nil
	}).DoIf(cleanupShootResources),
	Dependencies: flow.NewTaskIDs(deleteManagedResources),
	})

[rfranzke]

I don't know, we have to test that thoroughly. We have seen issues with AWS when we deactivated the explicit LB deletion with gardener/gardener-extension-provider-aws#290 and had to reactive it with gardener/gardener-extension-provider-aws#295 because it didn't work as expected.

[ialidzhikov]

#4426 was only a doc change that raises the requirement for the Seed Kubernetes version. I guess we can also clean up the handling for Kubernetes < 1.18 in few releases (I assume we have handling in the seed-bootstrap chart, there is also #4083 (comment) that needs further investigations, etc).

[rfranzke]

FYI: With #5272 we have dropped support for clusters < 1.17.

[gardener-ci-robot]

The Gardener project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close

/lifecycle stale

[timebertt]

/remove-lifecycle stale

[timebertt]

I guess we can also clean up the handling for Kubernetes < 1.18 in few releases (I assume we have handling in the seed-bootstrap chart, there is also #4083 (comment) that needs further investigations, etc).

@rfranzke @ialidzhikov does it make sense to perform this cleanup now/soon?
If so, maybe one of @acumino @shafeeqes @ary1992 can take this over.

[rfranzke]

/assign

[rfranzke]

I checked the code and there doesn't seem to be more things to cleanup, so
/close

We decided to tackle #4083 (comment) separate once we raise the minimum Kubernetes version for shoots (to 1.18 or higher).

[gardener-prow]

@rfranzke: Closing this issue.

In response to this:

I checked the code and there doesn't seem to be more things to cleanup, so
/close

We decided to tackle #4083 (comment) separate once we raise the minimum Kubernetes version for shoots (to 1.18 or higher).

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.