TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.

If you're not using AI, you're spending 40 hours doing what they do in 4.

These 100+ Claude Code hacks fix that and help you ship 10x faster.

Sign up for The Code and get:

Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Most Kubernetes clusters run overprovisioned. A team sets a pod's memory request to 2Gi because the container occasionally spikes to 1.2Gi, then never revisits that number again. Multiply that pattern across a few hundred services and a cluster ends up reserving far more CPU and memory than it actually uses, while the AWS bill keeps growing with it. Static VM sizing had the same problem, but Kubernetes gives you the tools to fix it: dynamic scaling, automated right sizing, and node provisioning that reacts to real demand instead of guesswork.

The catch is that every one of those tools moves or removes running pods to do its job. A pod gets evicted so a node can shrink. A container gets recreated with new resource values. A node gets drained so a cheaper one can replace it. None of that is safe to do blindly, so the right place to start is the guardrail that keeps optimization work from turning into downtime, before getting into the actual levers for cutting waste, the sizing of individual pods, the automation that reacts to load, and the node layer underneath all of it.

A PodDisruptionBudget (PDB) answers a narrow question: how many pods from a group are allowed to be unavailable at the same time because of a voluntary action? Voluntary disruption means something a person or a controller chose to do, a kubectl drain, a Karpenter node consolidation, a rolling cluster upgrade. It has no power over involuntary disruption, a node crashing, a kernel panic, an out of memory kill. Those bypass the PDB entirely because nothing asked permission.

Mechanically, a PDB does not block anything by itself. It works through the Eviction API. When kubectl drain or a node controller wants to remove a pod, it does not delete the pod directly, it calls the eviction endpoint, and the API server checks the pod's PDB before approving the request. If evicting the pod would drop the group below the budget, the API server returns a 429 and the caller retries later. This is why a stuck drain often has nothing to do with the node itself, it is a PDB silently refusing every eviction attempt.

The two most common ways teams configure this produce very different outcomes, and picking the wrong one either blocks routine operations or removes the protection entirely.

Setting maxUnavailable: 0 reads like the safest option, but it behaves closer to a lock. Node drains stall indefinitely, cluster version upgrades stall, and Karpenter cannot consolidate any node running one of these pods, it will simply skip that node forever. Reserve this only for a genuine singleton, a workload with exactly one replica that cannot tolerate any downtime, and even then treat it as a signal that the workload itself needs to run with more than one replica.

minAvailable: "80%" gives Kubernetes room to actually work. A rolling upgrade, a scale down, or a node replacement can proceed as long as most of the group stays up. For a deployment running five replicas, this permits one pod down at a time, close to the common N minus 1 pattern, but expressed as a percentage it keeps working correctly even as the replica count changes over time, which a hardcoded absolute number does not. This is the setting that lets the rest of the techniques below run without a person babysitting every disruption.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)