-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster #6029
Comments
For my better understanding, where the capbk provider is being deployed, on the local machine or on a remote infrastructure? |
The capbk provider controller is deployed into the bootstrap cluster ("bootstrap"). The cluster that's being created ("mycluster") is not on the same machine, but is on machines that have the correct time. What matters is that the capbk controller (on "bootstrap") that's creating the join token be behind the cluster that |
/milestone v1.2 |
Not sure, but we can at least check the creation time when we get the created resource back and error if it's within TTL/<some number (4?)> |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
What steps did you take and what happened:
What did you expect to happen:
I expected the bootstrap controller to emit an error event and log entry because it cannot create a token that won't be expired before it can be used. With the expiration time in the past, Kubernetes will immediately clean it up.
Anything else you would like to add:
A secret, eg.
bootstrap-token-zuzhz4
is created in the workload cluster. Because the expiration time is in the past, TokenCleaner deletes the token immediately after creation. One side-effect of this is that thecapi-kubeadm-bootstrap-controller-manager
logs will fill with lines like:Environment:
kubectl version
): 1.22.6/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]
The text was updated successfully, but these errors were encountered: