The app for independent voices

Three replicas should give you high availability.

Without one line of config, they all die during maintenance.

I watched this happen.

A routine node upgrade. Three pods. All evicted at once. Service went dark.

Not because of a failure. Because of maintenance.

Here's what nobody tells you about replicas.

They protect you from crashes. Node failures. Hardware death.

But Kubernetes has two types of disruptions.

๐—œ๐—ป๐˜ƒ๐—ผ๐—น๐˜‚๐—ป๐˜๐—ฎ๐—ฟ๐˜†: The ones you plan for.

๐—ฉ๐—ผ๐—น๐˜‚๐—ป๐˜๐—ฎ๐—ฟ๐˜†: Controlled drains. Cluster upgrades. Autoscaler decisions.

Without a PodDisruptionBudget, Kubernetes assumes it can evict everything at once.

It's being efficient. Why drain one node at a time when it can drain three?

Your three-replica deployment becomes zero replicas.

The worst part? It happens during low-traffic hours. While you're asleep.

Your monitoring misses it. But your users don't.

This is one of 5 anti-patterns that look fine until production disagrees.

Configurations that pass code review. That works for months. Then conditions align and your pager goes off.

I broke down all 5 in this week's newsletter:

1. The "Guaranteed" QoS class that guarantees OOMKills

2. Liveness probes that amplify slowness into cascading restarts

3. Rolling updates that aren't actually rolling

4. Hardcoded dependencies that kill your velocity

The full breakdown includes the exact YAML fixes and why each pattern fails under load.

Read it here:

Dec 31
at
3:02 PM
Relevant people

Log in or sign up

Join the most interesting and insightful discussions.