-
Is your feature request related to a problem? Please describe. We are maintaining a lot of k3s deployed projects, about 60+, including other environments about 90+, at present, there is a terrible problem, each k3s cluster certificate is only valid for one year, when the cluster certificate is about to expire, we need to manually log in the environment and rotate it. In some projects, we can get the warning of the certificate expiration by adding monitoring, but there are many projects that are delivered to other enterprises in a pure internal network deployment. In this bad network environment, we cannot know the status of the certificate (whether it is expired or not) at the first time, so the expiration of the cluster certificate often causes the cluster node anomaly. It also brings a lot of trouble for us to maintain, and after the final project is delivered, we can't do a special certificate rotation operation for them every year, so is there any best practice for our situation? Preferably, no certificate rotation is needed, so we don't have to do it every year Describe alternatives you've considered Not yet. Additional context |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
No you don't. If you restart K3s when the certificates are within 90 days of expiring, they will be rotated automatically when the service starts. This is covered in the docs. https://docs.k3s.io/cli/certificate#client-and-server-certificates If you are regularly upgrading your nodes, this shouldn't be a problem. If you are not applying patches every month or two, then just schedule periodic restart of K3s, or do so when the certificates are within 3 months of expiring. |
Beta Was this translation helpful? Give feedback.
-
ok, I see, Thank you very much |
Beta Was this translation helpful? Give feedback.
You need to restart servers first, then agents.