This message was deleted.
# k3s
a
This message was deleted.
c
It’s not about your certificates. its about the timestamp on the token that Kubernetes generates internally for service accounts.
The tokens have a fixed validity period, if you screw around with time on your hosts the tokens won’t be valid yet or will have already expired. Don’t do that.
Why are you screwing around with the system time to begin with? Just to see what happens?
containerd will also be mad about the pod ages, as you noticed.
You’re just going to piss off a bunch of things by screwing with time. don’t.
m
If there could be such a work scenario like this: Firstly,I install the k3s at
Wed Oct 25 16:24:41 CST 2023
.But I found the system real time is
Tue Aug 22 10:11:54 CST 2023
. Next,I need to change the system time into ``Tue Aug 22 101154 CST 2023``.So,the system time is before certificates‘s start time,that cause k3s unavailability.
So,I want to use a widely period self-Signed certificates to fixed this problem😅
Because I won't to re-install the k3s,beacuse this mean I will re-install my own pod,
c
don’t set the system time backwards. It is going to break all kinds of things
Ensure that the time is set right before k3s starts, or live with it.
m
But I have noticed that the system time is incorrect already.So I must to change the system time correctly. In that case, can I only reinstall K3s?
c
or at least run a killall and restart
m
Use
k3s-killall.sh
firstly,and the coredns and metrics-server is killed.Then,use
systemctl restart k3s
.But the coredns and metrics-server process can't start anymore:
Copy code
NAMESPACE     NAME                                      READY   STATUS      RESTARTS   AGE
kube-system   local-path-provisioner-84db5d44d9-g2ds5   1/1     Running     0          <invalid>
kube-system   metrics-server-67c658944b-5rzh6           0/1     Completed   0          <invalid>
kube-system   coredns-6799fbcd5-md9t8                   0/1     Completed   0          <invalid>