Exclude kms-provider from apiserver startup checks

Originally posted by @andyatwork in #10058

The issue occurs when static pods are declared that provide functionality to the API server that signal health, such as when implementing the KMS provider as a static pod. Because static pods are blocked by the kubelet waiting on the api server, and the api server is blocked on the status of the registered KMS endpoint (see API contract ) , we're in a classic deadlock situation. Other k8s distros are not blocking the kubelet on the API server being healthy, and thus this circular dependency is avoided.

Originally posted by @brandond in #10058

There a node password secrets that are required for agents to start, yes. Servers get to temporarily bypass this on startup though. So if there is a specific health/readiness check (you can see the list with kubectl get --raw /readyz?verbose) that we could skip when a self-hosted KMS is enabled... that might work.

I'm guessing it might be:

复制

[+]kms-providers ok

... in which case we could add &exclude=kms-providers to the apiserver readiness check that blocks kubelet startup.

Excluding kms-provider from apiserver checks would allow the kubelet to come up and start static pods that were used to self-host the local kms endpoint.