-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
UPSTREAM: 62152: Keep node.kubeconfig correct during rotation #19857
UPSTREAM: 62152: Keep node.kubeconfig correct during rotation #19857
Conversation
The node.kubeconfig created by bootstrap will not work after the first rotation - write bootstrap credentials into the cert store in order to guarantee that rotation preserves that config.
Do we test actual rotation in any of our CI tests? |
All the GCP tests run with rotation on at 15 minutes, which means they rotate 2 times on average per run. If rotation is broken GCP e2e should break ~10-30% of the time. We don't have a rotation e2e but we need something that forces and verifies upstream. |
/retest |
I think this also fixes a "kubelet bypasses bootstrapping when the last bootstrap cert expires" bug, because we only ever read the bootstrap cert from the store (it will be nil if the cert has expired) and if it's nil we ask for a new cert. I hit this on api.ci tonight when i accidentally killed the autoapprover for > 15m which caused a node's bootstrap cert to expire. I had to clear the certs in order to proceed. With this fix we should have cleared it ourselves. |
@liggitt without this we can’t have rotation |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, smarterclayton 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:
Approvers can indicate their approval by writing |
The node.kubeconfig created by bootstrap will not work after the first
rotation - write bootstrap credentials into the cert store in order to
guarantee that rotation preserves that config.
Without this, SDN, the sync pod, and a few other node level actions will stop working when the pod gets rotated.
@liggitt