-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry when apiserver fails to listen on insecure port #28797
Conversation
/cc @kubernetes/sig-api-machinery |
Retrying forever doesn't seem quite right, but since you are doing exactly what the secure port is doing I won't make you revisit that. LGTM |
Marking as release note because people might want to verify that a health check is enabled in their configurations, so that this won't cause them to launch a non functional apiserver that never crashes. |
Error seems to be unrelated to this PR. |
@k8s-bot test this please github issue: #IGNORE |
Not sure if I can do that, but figured I'd try. |
GCE e2e build/test passed for commit 25ac0dd. |
Looks good to me 👍 |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 25ac0dd. |
Automatic merge from submit-queue |
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
This is a backport of: kubernetes#28797
The apiserver will already continually retry when it fails to bind to the secure port. However, with the insecure port it does not retry, and any failures cause the apiserver to exit.
This change makes it so the api-server will retry on both insecure/secure ports.
A use-case for this change is for self-hosting the api-server, particularly when you are only running a single copy in your cluster. In some bootstrap and upgrade scenarios - it's necessary to replace/pivot from an existing api-server on the same host -- where you need a new copy running before tearing down the old (which is problematic when the api-server will try to bind to an in-use port and exit).