extend timeout to workaround slow arm64 math

[joejulian]

What this PR does / why we need it:

The math/big functions are slow on arm64. There is improvement coming
with go1.11 but until such time as that version can be used to build releases,
if a server uses rsa certificates on arm64, the math load for the multitude
of watches over-taxes the ability of the processor and the TLS connections
time out. Retries will also not succeed and serve to exacerbate the problem.

By extending the timeout, the TLS connections will eventually be
successful and the load will drop.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #64649

Special notes for your reviewer:
This was tested on a Raspberry Pi 3

Release note:

Extend TLS timeouts to work around slow arm64 math/big

[joejulian]

/assign @liggitt

[smarterclayton]

You say "if a server uses RSA certificates". Does this also happen with elliptic curves?

[joejulian]

I haven't tested that yet but according to the conversations I found in the golang community, ecdsa should not be a problem.

[anguslees]

(Nice find! I noticed that TLS handshaking was very slow on my rPi2s (arm32), and ended up disabling etcd TLS encryption altogether (!) because etcd at the time didn't offer a way to extend the extremely aggressive 1s connect timeout to peers (typically completed in ~1.1s on my rpi2s, worse when under load). I shall have to retry with ecdsa certs to see how they perform...)

[DJGummikuh]

Hey! I used your changes to build kubernetes for me to test with but how do I actually patch the changes onto my raspberry pi? I have the kube-apiserver binary here but I can't seem to figure out where to place it so that kubernetes uses it - can I create the necessary docker images on my pc or would I have to run that process on my Raspberry Pi?

[dims]

/ok-to-test

[dims]

/assign @xiang90

[joejulian]

/test pull-kubernetes-e2e-gce

[timothysc]

These are really manifest constants then vars. We should also cross-link the issue or some meta-data to outline how this magic number was chosen.

We have O(100)s of magic numbers in the system with little/no history.

[joejulian]

I considered that as well.

The original number seemed to be arbitrary and the new number was just a double of that so equally as arbitrary. When go1.11 is released and is used to build the binaries, this workaround will be moot and can be reverted.

I did reference the hardware to which this was a problem and that this number was chosen as it alleviated that problem for said hardware. There is an issue linked. What further meta-data would you be interested in seeing?

[joejulian]

/test pull-kubernetes-kubemark-e2e-gce-big

[timothysc]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joejulian, timothysc

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/apiserver/pkg/storage/OWNERS [timothysc]

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

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 66341, 66405, 66403, 66264, 66447). If you want to cherry-pick this change to another branch, please follow the instructions here.

[fedebongio]

/cc @cheftako

[neolit123]

/sig api-machinery
adding sig label for release notes tools to fetch.