Always reset agent connection backoff and enter fast sync when client count < server count

[carreter]

Part of #358 (see #358 (comment)).

Current behavior

Currently, if an agent receives an increased server count from a server it is already connected to, it doesn't reset the backoff and just uses the last set duration. This could result in an agent taking a long time to connect to new proxy servers if it receives the updated server count from a server it is already connected to.

This cannot currently happen as there is no way to update the server count on a proxy server without restarting it and dropping the connection, but this will be an issue once #273 is implemented.

Testing the fix

Using #631, I set up https://github.com/carreter/apiserver-network-proxy/tree/backoff-reset-fix-test-example . Run the following in the repo root to set up a cluster with 1 proxy server on a KCP node and 1 proxy agent on a worker node:

make docker-build

cd examples/kind-multinode

# These are the default values of the registry, image name, and tag used by the Makefile.
# Edit them if necessary.
REGISTRY=gcr.io/$(gcloud config get-value project)
TAG=$(git rev-parse HEAD)
TARGET_ARCH="amd64"
SERVER_IMAGE="$REGISTRY/proxy-server-$TARGET_ARCH:$TAG"
AGENT_IMAGE="$REGISTRY/proxy-agent-$TARGET_ARCH:$TAG"

# Bring up the cluster!
./quickstart-kind.sh --cluster-name custom-knp-test --server-image "$SERVER_IMAGE" --agent-image "$AGENT_IMAGE" \
  --num-kcp-nodes 1 --num-worker-nodes 1 --sideload-images

Then, apply server-count-file.yaml with the following to upload a file with an updated server count:

kubectl apply -f server-count-file.yaml

Give it a couple seconds and you should see logs showing that the client is issuing new connection requests every 5 secs (i.e. --sync-interval) instead of every 30 secs (i.e. --sync-interval-cap) like it would without this fix!

I0613 22:04:19.702443       1 client.go:215] "Connect to server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22"
I0613 22:04:19.702687       1 clientset.go:186] "duplicate server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22" serverCount=1 clientsCount=1
I0613 22:04:19.703466       1 client.go:474] "received DATA" connectionID=1
I0613 22:04:19.703585       1 client.go:600] "write to remote" connectionID=1 lastData=48 dataSize=48
I0613 22:04:45.631336       1 client.go:215] "Connect to server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22"
I0613 22:04:45.631365       1 clientset.go:219] "Server count change suggestion by server" current=1 serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22" actual=4
I0613 22:04:45.631588       1 clientset.go:186] "duplicate server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22" serverCount=4 clientsCount=1
I0613 22:04:51.070279       1 client.go:215] "Connect to server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22"
I0613 22:04:51.070593       1 clientset.go:186] "duplicate server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22" serverCount=4 clientsCount=1
I0613 22:04:56.324115       1 client.go:215] "Connect to server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22"
I0613 22:04:56.324438       1 clientset.go:186] "duplicate server" serverID="50ea06e6-89fa-444a-9f8e-1ee9bf0d4a22" serverCount=4 clientsCount=1

[k8s-ci-robot]

Hi @carreter. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[carreter]

@avrittrohwer for visibility

[jkh52]

/ok-to-test

[jkh52]

LGTM. See latest suggestion, happy to approve when you're ready.

[carreter]

@jkh52 Should be ready now!

[jkh52]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: carreter, jkh52

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

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