I have a two-node k3s cluster that I use for home lab and learning purposes. Whenever I shut it down and restart it, I'm trying to avoid issues with persistent volume claims, but I'm running into a persistent problem. I've noticed that Longhorn is taking a long time to start up because it begins its initialization before CoreDNS is ready, leading to a lot of CrashLoopBackOff errors. Has anyone experienced this issue and found a solution? Any tips would be really appreciated!
3 Answers
Another approach is to use Kustomize. You can render your Helm chart with Kustomize and then tweak the output to suit your needs. This way, you might be able to customize the deployment to work around the CoreDNS issue.
You might want to consider using an init container that checks for CoreDNS readiness before allowing Longhorn to start. This could help ensure that everything is up and running smoothly before Longhorn kicks off its processes. Just keep in mind that you may need to adjust your Helm chart since it might not allow for an init container by default.
You could also consider using taints on your worker nodes right before shutting down. Then, run a workload that removes the taint when CoreDNS is functioning, and have CoreDNS tolerate that specific taint. This could help manage the startup sequence better.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures