Unlike sibling commenters who just read about "thundering herd" problems on the Internet, as someone who spent significant time in SRE roles, I agree with you as a matter of what the default approach should be. If you have a small cluster and no more than a handful of services... what thundering herd problem is there supposed to be, exactly, with so few "cattle" in the "herd"? Meanwhile, there are serious benefits, as you describe.

Large clusters with dozens of services and traces that go several services deep, with each service owned by a different team, are a whole 'nother ballgame, especially when overall production uptime is owned by an SRE team and not by the developer teams who wrote each of those services. And even in this scenario, you're not necessarily wrong; the risk attached to the cascading failure is domain-specific and may be acceptable.

Thundering herd / cascading outages. You take out a large enough portion of your fleet, and the remaining load overloads your remaining nodes one by one as they restart, so you can never have enough healthy nodes.

1. was already mentioned in sibling - cascade failures

2. you'll have massive number of restarts for various flake reasons and missing things that got papered over with restarts until you hit 1 and everything is broken. another popular version of this is "just restart when memory leaks too much"

I think the best approach is to have an endpoint which returns the current state without probing the database when you check the endpoint.

Like you have a threat which does all your checks for connectivity write it into memory and the api endpoint checks the last values written.

Then you can respond to different upstream issues differently: Your DB says 'permission denied' due to broken auth data? Your Pod is not ready.

Your backend understand what a db maintenance mode is and should still return "Maintenance", your pod stays ready.

It can be more nuanced.

But the problem with restarting is, as he stated in the blog: What if now EVERY pod restarts in parallel.

> what's the problem with restarting?

Exponential backoff can delay recovery up to kubelet’s maxContainerRestartPeriod (default 5m).

The better solution is to not have too many critical upstream services :)

My favourite: misconfigured Linkerd setup that causes CA certs to rotate every month :) Definitely worth restarting on that

cascading failures on upstream services. then you get 20 different services failing instead of the single one.

What are your feelings about using initContainers and wait-for-it to skirt the thundering-herd problem?

I think it really depends on how much control you have over what you're deploying. In one school regularly restarting something with a memory leak that you can't fix is the correct solution.

On the other hand that's just putting a bandaid on the real issue, and if you can you should just fix the memory leak instead of just covering it up. There's also short vs long term solutions to consider. But saying there's a one size fits all solution is kinda silly.

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

The author re-implemented a bunch of k8s logic in a typescript library just for these animations: https://github.com/ngrok/webernetes