fix node notReady in first sync period after kubelet restart

[AllenXu93]

fix nodeNotReady once after kubelet restart: execute updateRuntimeUp before syncNodeStatus

What type of PR is this?

/kind bug

What this PR does / why we need it:

When kubelet start, it will execute kl.syncNodeStatus to sync node status to APIServer, and one of the check is checking containerRuntime state.
But containerRuntime state update execute after kl.syncNodeStatus

kubernetes/pkg/kubelet/kubelet.go

Lines 1625 to 1641 in bf07ef3

	if kl.kubeClient != nil {
	// Start two go-routines to update the status.
	//
	// The first will report to the apiserver every nodeStatusUpdateFrequency and is aimed to provide regular status intervals,
	// while the second is used to provide a more timely status update during initialization and runs an one-shot update to the apiserver
	// once the node becomes ready, then exits afterwards.
	//
	// Introduce some small jittering to ensure that over time the requests won't start
	// accumulating at approximately the same time from the set of nodes due to priority and
	// fairness effect.
	go wait.JitterUntil(kl.syncNodeStatus, kl.nodeStatusUpdateFrequency, 0.04, true, wait.NeverStop)
	go kl.fastStatusUpdateOnce()
	// start syncing lease
	go kl.nodeLeaseController.Run(context.Background())
	}
	go wait.Until(kl.updateRuntimeUp, 5*time.Second, wait.NeverStop)

This PR will execute kl.updateRuntimeUp() before kl.syncNodeStatus .

Which issue(s) this PR fixes:

Fixes #124397

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix node report notReady with reason 'container runtime status check may not have completed yet' after Kubelet restart

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: xiaozhouX (3c67445, 4bfc731)

[k8s-ci-robot]

Hi @AllenXu93. Thanks for your PR.

I'm waiting for a kubernetes 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/test-infra repository.

[HirazawaUi]

Please provide a release-note for it as this is a user-facing change.

[aojea]

What do you think about using this approach instead #124397 (comment) ?

[bart0sh]

/triage accepted
/priority important-longterm
/ok-to-test

[aojea]

/lgtm
/assign @dchen1107

Dawn this will improve the p99 percentiles on node startup as it seems there is a race that can postpone the node readiness by 10 seconds

when go in to next period (default 10s), node status resume to Ready.

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 7826400af9f6ba80406770076a90449375efe27f

[dchen1107]

@aojea thanks for pointing out the overall improvement on the node startup latency even the original issue shouldn't cause any other disruption to the running workloads if there is any. cc/ @yujuhong @bobbypage for vis.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AllenXu93, dchen1107

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:

• pkg/kubelet/OWNERS [dchen1107]

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

[pacoxu]

/milestone v1.31

• approved just before code freeze