-
Notifications
You must be signed in to change notification settings - Fork 716
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
Kubelet can't running after renew certificates #2054
Comments
/cc @fabriziopandini |
the bootstrap-kubelet.conf missing should not be an issue as long as there is a kubelet.conf, see the kubelet flags:
i'm going to test this as well. |
please note that this feature is not really supported by kubeadm anymore and we don't have e2e tests for it... |
I enable kubelet dynamic config manually, not use |
Did kubelet use kubelet.conf first, if error it use bootstrap-kubelet.conf retry? |
there should not be an error if the bootstrap-kubelet.conf is missing, but the kubelet.conf is present. |
@pytimer @SataQiu i cannot reproduce the issue. here are my steps:
if you are doing the steps exactly like so:
by running /priority awaiting-more-evidence |
Update the host datetime to assume certificate expired.Why did you think this is wrong, can you explain it, i don't understand it. If this is wrong, which way to test |
ok, i was able to understand better what you are trying to do.
on a running cluster this means the kubelet now has an invalid client certificate for the API server stored in the file kubelet.conf.
it's important to note that this command does not update kubelet.conf. the client credentials in there are managed by the kubelet.
if the year has changed and if you run this command the kubelet will find an outdated certificate in the kubelet.conf file and it will start looking for bootstrap-kubelet.conf. but nowadays we delete this file after TLS bootstrap for security reasons. so the kubelet will fail because it has not credentials to connect to the API. normally this will not happen because the kubelet certificate manager has logic to monitor for certificate expiration and it will auto-rotate your client certificates once ~70% of the expiration period is reached. by forcing a date you are bypassing this mechanism and you end up with a certificate which was not rotated.
i suggest you don't touch your system date. hope this explains the issue. |
Thanks @neolit123
Kubeadm certs renew command works well.
@neolit123 Update the host time make kubelet client certificates expriation time between 70%~100%, i found kubelet can't rotate certificates, the new certificates created until kubelet restarted. Do you know reason? I can't find some documents about it. |
i don't think that updating the host time is a valid approach for testing. this could be tripping the kubelet client cert rotation. but yes, the exact process is not documented fully: |
if the kubelet client certificate expired for some reason you can renew it manually. look at the contents of |
I've hit this in 1.17.1, after master node rebooted Please help! |
I manually copied the renewed cert and key from /var/lib/kubelet/pki/kubelet-client-current.pem to /etc/kubernetes/kubelet.conf, and it started. Phew! |
instead of copying the cert/key inside the kubeconfig, see what is suggested here:
|
Ahh! I see, thanks! |
I got a cluster, all certs are expired except ca.crt, so control plane are also down.
|
Just ran into this and blocked. Cluster is currently down. Running Kubernetes I ran the following on the master/control plane: ubuntu@kubernetes-master:~/.kube$ sudo kubeadm alpha certs renew all
certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healtcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed Then rebooted the master/control plane. However, kubelet is failing to start still: Feb 4 04:01:52 kubernetes-master systemd[1]: Started Kubernetes systemd probe.
Feb 4 04:01:52 kubernetes-master kubelet[7251]: I0204 04:01:52.544916 7251 server.go:425] Version: v1.15.12
Feb 4 04:01:52 kubernetes-master kubelet[7251]: I0204 04:01:52.545090 7251 plugins.go:103] No cloud provider specified.
Feb 4 04:01:52 kubernetes-master kubelet[7251]: I0204 04:01:52.545103 7251 server.go:789] Client rotation is on, will bootstrap in background
Feb 4 04:01:52 kubernetes-master kubelet[7251]: E0204 04:01:52.546511 7251 bootstrap.go:263] Part of the existing bootstrap client certificate is expired: 2022-01-26 02:08:58 +0000 UTC
Feb 4 04:01:52 kubernetes-master kubelet[7251]: F0204 04:01:52.546545 7251 server.go:273] failed to run Kubelet: unable to load bootstrap kubeconfig: stat /etc/kubernetes/bootstrap-kubelet.conf: no such file or directory
Feb 4 04:01:52 kubernetes-master systemd[1]: kubelet.service: Main process exited, code=exited, status=255/n/a
Feb 4 04:01:52 kubernetes-master systemd[1]: kubelet.service: Failed with result 'exit-code' All the certificates are showing as valid: ubuntu@kubernetes-master:~/.kube$ sudo kubeadm alpha certs check-expiration
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf Feb 04, 2023 04:00 UTC 364d no
apiserver Feb 04, 2023 04:00 UTC 364d no
apiserver-etcd-client Feb 04, 2023 04:00 UTC 364d no
apiserver-kubelet-client Feb 04, 2023 04:00 UTC 364d no
controller-manager.conf Feb 04, 2023 04:00 UTC 364d no
etcd-healthcheck-client Feb 04, 2023 04:00 UTC 364d no
etcd-peer Feb 04, 2023 04:00 UTC 364d no
etcd-server Feb 04, 2023 04:00 UTC 364d no
front-proxy-client Feb 04, 2023 04:00 UTC 364d no
scheduler.conf Feb 04, 2023 04:00 UTC 364d no What am I missing? Do I need to manually update a configuration file? |
Kubeadm does not manage rotation of kubelet.conf. This might help you
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert
|
@neolit123 thanks for the reply. The fix for me was to copy the contents of Why is this not more obvious when invoking |
this is not ideal, as it grants the kubelet client super admin credentials....you are also hardcoding non-rotatable credentials.
this is documented:
but back to the original problem, for the credentials to expire something must have gotten wrong on the node...or you had hardcoded kubelet.conf credentials instead of pointing to the rotatable symlink (explained in the docs). EDIT: also check this warning in the docs:
|
@neolit123 thanks for the detailed reply. I think the core problem was the original Kubernetes cluster was really old and upgraded via This is of-course an on-prem cluster (not cloud managed) and created using sudo kubeadm init --config /tmp/kubernetes-master-config.yaml | sudo tee /tmp/kubeadm-init.log |
Yes, it should.
…On Feb 5, 2022 03:24, "Justin Keller" ***@***.***> wrote:
@neolit123 <https://github.com/neolit123> thanks for the detailed reply.
I think the core problem was the original Kubernetes cluster was really
old and upgraded via kubeadm a few times. I'm wanting to completely
rebuild from scratch using 1.21.5. I assume doing this will use the
correct rotatable symlinks and update kubelet.conf to point to the those
symlinks?
—
Reply to this email directly, view it on GitHub
<#2054 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACRATG4FVKIIGTL5ZU2OR3UZR35XANCNFSM4LCC2CQQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi @neolit123, Can you please help me. was faced certificate expiry issue and renewed it properly but /var/lib/kubelet/pki/kubelet-client-current.pem certificate doesn't updated so, as per the steps mentioned on below Kubernetes link I did the steps to regenerated kubelet.conf file and I made a mistake were I have changed node name in newly generated kubelet.conf file due to that not it's giving permission related error s and node doesn't coming into ready state. Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1" Thanks, |
Is this a BUG REPORT or FEATURE REQUEST?
BUG REPORT
Versions
kubeadm version (use
kubeadm version
):Environment:
kubectl version
):bare-metal
uname -a
):Linux k8s-236 3.10.0-957.12.2.el7.x86_64 #1 SMP Mon May 20 08:41:20 EDT 2019 x86_64 x86_64 x86_64 GNU/Linux
What happened?
I using the kubeadm command to renew the cluster certificates, the
kubeadm alpha certs renew all
works well, and i found the certificates have been changed. But when restart kubelet, kubelet can't running, it exited. I don't know why?How to do renew control plane certficates and kubelet certficates, which docs can i reference.
What you expected to happen?
Renew all cluster certificates successfully and kubelet running.
How to reproduce it (as minimally and precisely as possible)?
kubeadm alpha certs renew all
commandAnything else we need to know?
kubelet
log:server.go:821] Client rotation is on, will bootstrap in background bootstrap.go:265] part of the existing bootstrap client certificate is expired: 2021-03-04 14:19:56 +0000 UTC systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a server.go:273] failed to run Kubelet: unable to load bootstrap kubeconfig: stat /etc/kubernetes/bootstrap-kubelet.conf: no such file or directory
The text was updated successfully, but these errors were encountered: