Remove the checksum workaround for Flannel VXLAN

[hakman]

The issue was addressed in kubernetes/kubernetes#92035 and will be available in next Kubernetes releases.

Reverts: #9074

/assign @KashifSaadat

[hakman]

/retest

[hakman]

/retest

[johngmyers]

I wonder if we want to make applying the workaround dependent on the Kubernetes minor version.

[hakman]

Me personally don't want to keep such workarounds when they are fixed in latest stable version.
I am sure that anyone noticing the issue will be eager to upgrade. And that's not even mentioning the latest security advisories.

[olemarkus]

It is probably worth a mention in the release notes so users at least know to update.

[hakman]

That I can do :).

[johngmyers]

Suggested change

	* Flannel users need to upgrade to Kubernetes versions 1.18.6, 1.17.9, 1.16.13 or higher to avoid significant performance degradation.
	* Flannel and Canal users need to upgrade to Kubernetes versions 1.18.6, 1.17.9, 1.16.13 or higher to avoid significant performance degradation.

[hakman]

I was thinking to remove this for now. If we want this in just in master for a while, doesn't make sense to bundle it with release notes.

[hakman]

I removed the release notes. This way it can be merged to master and tested for a while.

[johngmyers]

/lgtm

[justinsb]

I took a look and it looks like the underlying issue was introduced in k8s 1.16, and the fix has been backported to 1.16 (and later).

I think as a fix is available in a later minor, we shouldn't switch behaviours based on the minor version. (Though we can encourage users to use a later minor version, including posting a warning message if we think that's appropriate).

So I agree that for master branch (kops 1.19) we should just remove the workaround.

So that leaves the question of what we do about backporting our workaround. I think it only made the 1.17 and 1.18 branches. For 1.18 that isn't released yet, so we probably should backport.

For 1.17, we did do a release, so it's trickier. If we backport, anyone with a cluster relying on the workaround that upgrades kops will have their cluster break (if I understand correctly). For that reason, I propose we do not backport it to kops 1.17. What do people think?

In any case, this LGTM for master (and for cherry-picking to 1.18), so ...

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hakman, justinsb

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 [justinsb]

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

[jhohertz]

Sorry I'm late to the discussion here, but wanted to mention... As someone who's been delaying deployment of 1.17 pending a fix for the underlying issue (because I wasn't thrilled with the workaround),

I would like to be able to move ahead without said workaround unnecessarily in place if at all possible.