Fix bug in reflector not detecting "Too large resource version" error before 1.17.0

[xuzhenglun]

What type of PR is this?

/kind bug

What this PR does / why we need it:

• for 0.18.6-0.18.8 client-go: Automated cherry pick of #92537 upstream release 1.18  #92688 (cherry-pick of Fix bug in reflector not recovering from "Too large resource version"… #92537) fixes "Too large resource version" in reflector and not recovering.
• for 0.18.9-current client-go: Fix bug in reflector not detecting "Too large resource version" error #94316 fixes this problem for kube-apiserver (1.17.0-1.18.5) with newer client-go (>0.18.7)
• but if kube-apiserver is in 1.16.x and client-go is new, it still not work:

since #72170 is reverted in 1.16.x, and the code in the release-1.16 did not return details.cause field (see ref code). so isTooLargeResourceVersionError in reflector should fail to detect this error come from kube-apiserver before 1.17.0, and can not recovery as expected.

I know the version of client-go should align with kube-apiserver as far as we can, and the version skew policy is presented. but in some cases, for example some third party software, is hard to ensure that. so maybe being more comparable is good?

Which issue(s) this PR fixes:

Fixes #94315
Fixed #91073
Fixed #94316

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers before 1.17.0

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

[aojea]

I'm not very thrilled for adding code to support "unsupported" versions, is not just the skewed versions, is that last supported version is 1.22

/assign @liggitt

[pacoxu]

Can we accept such fixes if there is no side-effect for supported versions? (This of course is out of the supported versions scope, but client-go is widely used.) If there is any side effect, we must decline the pr.

• Add my use case of multi-clusters management that may benefit if this is fixed, we support importing Kubernetes 1.10+ as users may have some old clusters that will not be upgraded for some reason(have to run with docker/negative deploying policies: new applications will be deployed into new clusters and just keep old applications running on old servers).

[xuzhenglun]

here is my use case：

• We have some products that don't actually depend on a specific version of Kubernetes, so they are supposed to support a wide range of versions. When they sell to customers, the version of the customer's in-used cluster can be very old. But it is actually unfair to ask the product teams to lower the client-go version for this reason because the newer client-go have tonnes of bugfix/new features.

Considering 1.17 is so old, It's fair if this is declined. But it's really nice if this could be fixed because client-go is so wildly used, and I will really appreciate it.

[liggitt]

I agree that it is useful for the generic aspects of client-go to work well against as many versions as possible, this doesn't seem burdensome to maintain, and the function it is in is already checking conditions which are only true for already-out-of-support servers.

/assign @wojtek-t
for detailed review of pre-1.17 behavior

[cici37]

/triage accepted

[wojtek-t]

I agree that it is useful for the generic aspects of client-go to work well against as many versions as possible, this doesn't seem burdensome to maintain, and the function it is in is already checking conditions which are only true for already-out-of-support servers.

+1
And additionally this code is well separated and easy to follow so that seems fine.

The addition also looks correct:
https://github.com/kubernetes/kubernetes/blob/release-1.16/staging/src/k8s.io/apiserver/pkg/storage/cacher/watch_cache.go#L307

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 3e1cbb21100e706efeb070dcfcbf3270bceb689a

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wojtek-t, xuzhenglun

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:

• staging/src/k8s.io/client-go/tools/cache/OWNERS [wojtek-t]

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

[aojea]

I stand corrected 😄