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
kubeadm join: wait for API endpoints #34703
Conversation
Can a kubernetes member verify that this patch is reasonable to test? If so, please reply with "@k8s-bot ok to test" on its own line. Regular contributors should join the org to skip this step. |
defer wg.Done() | ||
wait.Until(func() { | ||
fmt.Printf("<node/bootstrap> trying to connect to endpoint %s\n", endpoint) | ||
if err := clientSet.CoreClient.Get().AbsPath("version").Do().Error(); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be handy to grab the version string and print it, don't you think? We might want to move this to second log-level, but for now just printing it in human-readable format would help folks who are trying --kubernetes-version
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sure :) does this match what you had in mind about failing early?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see : to grab the version I would need to unmarshall the response from the simple GET on /version
.
But the DiscoveryClient
method ServerVersion()
here actually does exactly that. I don't see a need to duplicate the code, except if you think that the Get().AbsPath('version')
is somehow more explicit (or if by some chance the behavior of discoveryClient.ServerVersion()
is subject to change in the future).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also the server version was used in the checkCertsAPI
, so I had to refactor a bit ... Do you think it makes sense to actually have a checkAPIEndpoint()
function that does both checks one after the other (checks the server version, then checks the certs API with a ServerGroups
call, as is currently done in checkCertsAPI
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, thanks 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, please see if it's ok :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one nit, LGTM overall 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
a36bcbc
to
931c751
Compare
Jenkins verification failed for commit 890e4ed69e2cf4155e36a466241b8bc5937c3d43. Full PR test history. The magic incantation to run this job again is |
@taimir there seems to be an issue here:
|
@taimir Yes, please fix the verification test |
Ah, I was AFK, sorry - sure thing, I'll fix it |
* Introduce a concurrent retry mechanism for bootstrapping with a single API endpoint
@luxas I think it's missing your lgtm. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Automatic merge from submit-queue kubeadm join: polling discovery service API **What this PR does / why we need it**: Enhance kubeadm to allow for parallel provisioning of API endpoints and slave nodes, in addition to #33543. This PR let's `kubeadm join` poll the discovery service API and retry connecting to it every couple of seconds. That way `kubeadm init` and `kubeadm join` can be executed in parallel. **Fixes**: #33542 **Special notes for your reviewer**: @pires @errordeveloper last part of the discussed changes, in addition to #33543 and #34703
What this PR does / why we need it: enhance kubeadm to allow for parallel provisioning of API endpoints and slave nodes, continued from #33543
Fixes: #33542
Special notes for your reviewer:
kubeadm join
(this was left out in Decouple master bootstrap from CSR in kubeadm #33543 so that it can be implemented in a separate PR). The polling of the discovery service API itself is yet to come.@errordeveloper @pires
This change is