SRE here, Strong disagree with do not fail readiness and liveness checks on upstream dependencies failing. There are several reason to do so and unless you have extreme start up time, what's the problem with restarting?
Maybe DNS has changed on you but you are stuck with bad local cache because you poorly respect TTLs (Looking at you Java), reseting the process will clear that cache away.
Maybe TCP connections are in stuck weird state, resetting the process generally helps with that.
Maybe someone gave you bad ENV VARs and you cannot connect to database, by refusing to progress the rollout, no outage generated.
So yea, if you are not ready to do work including critical upstream dependencies, don't lie to system and say you are.
SRE here, Strong disagree with do not fail readiness and liveness checks on upstream dependencies failing. There are several reason to do so and unless you have extreme start up time, what's the problem with restarting?
Maybe DNS has changed on you but you are stuck with bad local cache because you poorly respect TTLs (Looking at you Java), reseting the process will clear that cache away.
Maybe TCP connections are in stuck weird state, resetting the process generally helps with that.
Maybe someone gave you bad ENV VARs and you cannot connect to database, by refusing to progress the rollout, no outage generated.
So yea, if you are not ready to do work including critical upstream dependencies, don't lie to system and say you are.
This does not state anything new, but explains it so much well than the kubernetes documentation.
Sam has a real way with words when it comes to educational content.
Though he did find a legit Kubernetes bug while writing the post, so technically there was at least one new thing :)
Sometimes the k8s docs remind me of google's documentation
many times i have said a company could be built to just make better google documentation.