This message was deleted.

Certificates are used for most of the core service communication in Kubernetes, and as the error says, certs are considered invalid if their creation time is in the future from the system time. Also you can have all sorts of weirdness anyway swapping your time around and the confusion to distributed decision-making could get stuck in deadlocks too for all I know (time going backwards isn't generally something on software test plans). If I were you and didn't want to just redo my cluster, I'd leave the time in the past for everything and I'd set up a local server to act as an NTP server for your cluster and set its time as a day ahead of your cluster and then turn NTP on for your cluster. Then tomorrow when getting in to work at a presumably normal time, I'd set the NTP server to be 1 AM on 08 Sept so it's future for everything but still has a few hours in case need to try screwing around more. I'd then try checking if the cluster settled 15 min, 60 min, 2 hours, 4 hours, end of day. If the cluster had settled then I'd have the NTP server set itself to current time on Monday morning if things still looked good. If it didn't settle I'd check again Monday morning and try debugging including maybe setting NTP server time ahead 30 min at times if I think it's needed or a distributed decision looks like it needs a kick. After getting it to settle I'd wait a day to set NTP server to normal time. If still debugging & NTP server caught up with current time and I still didn't want to just junk the cluster & re-image, I'd shut down all the cluster machines for a day or two and set the NTP server for an hour after shutting the cluster machines down before bringing them back up and continue. Note that sometimes your cluster can get to a completely unrecoverable state and you don't have a choice. Kubernetes mindset tends to be that you can just use Helm & other similar tools to quickly deploy your clusters to config so a nuke & pave approach isn't too hateful.