How to Stop Overprovisioning in Kubernetes

Author

Govardhana M K
October 04, 2025

In partnership with

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.

👋 👋 A big thank you to today's sponsor THE CODE

The Tech newsletter for Engineers who want to stay ahead

Tech moves fast, but you're still playing catch-up?

That's exactly why 100K+ engineers working at Google, Meta, and Apple read The Code twice a week.

Here's what you get:

  • Curated tech news that shapes your career - Filtered from thousands of sources so you know what's coming 6 months early.

  • Practical resources you can use immediately - Real tutorials and tools that solve actual engineering problems.

  • Research papers and insights decoded - We break down complex tech so you understand what matters.

All delivered twice a week in just 2 short emails.

👀 Remote Jobs

📚️ Resources

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

🧠 DEEP DIVE USE CASE

How to Stop Overprovisioning in Kubernetes

If infra costs go up, DevOps engineers are responsible.

If the app goes down, DevOps engineers are still responsible.

Most DevOps engineers feel stuck in the middle, and they find it hard to set the right size for their workloads.

If a pod crashes or gets throttled, it becomes a serious issue. To avoid that, teams usually add more resources than required because they are more afraid of downtime than extra cost. Over time, this becomes a habit and leads to high cloud bills.

Having said that, how can we fine tune our workloads to stop this overprovisioning without risking downtime?

PodDisruptionBudgets Other Side

A PodDisruptionBudget (PDB) tells Kubernetes how many pods from an application must stay running during actions like node upgrades, drains, or restarts.

In the above example, Kubernetes is trying to drain Node 2. However, the PodDisruptionBudget prevents it from doing so because the new pods scheduled on Node 3 are still in the Pending state.

Until those pending pods become Running, Kubernetes will not allow the eviction of pods from Node 2.

This behavior protects availability but delays the drain process, leaving nodes in a half drained state for longer.

In many clusters, PDBs are configured too strictly with maxUnavailable: 0. This setting means Kubernetes cannot take down even one pod from that application group at any time.

While this guarantees uptime, it also blocks node drains, and autoscaler scale downs. The cluster ends up holding unnecessary nodes and idle resources just to satisfy the PDB.

A better setup is to use a minAvailable value instead of maxUnavailable: 0.

For example, setting minAvailable: "80%" tells Kubernetes to always keep at least 80 percent of the pods running, while allowing up to 20 percent to be stopped when needed.

This balance keeps the application highly available but also gives Kubernetes enough flexibility to drain nodes, perform upgrades, or scale down unused capacity. It improves cost efficiency, avoids stuck operations, and lets autoscalers do their job without affecting uptime.

Let us move on to a few more practical cases..

👋 I built this newsletter to ~55,000 subscribers. It makes USD $12,000 MRR and sends 150,000 emails every week.

I can confidently say that without BEEHIIV, this wouldn’t have been this easy.

Growth tools, ad recommendations, automations, website design — they’ve covered everything you need to run hassle free.

The #1 platform for newsletters. Period.

beehiiv is the one platform that does everything for your newsletter. And they do mean everything:

  • A newsletter editor that makes your words shine like they belong on a bestseller list

  • A no-code website builder that doubles as your 24/7 subscriber magnet

  • Revenue tools that make earning money so easy it feels like cheating: ads, referrals, and paid subs

If you’ve got a newsletter (or even just the idea for one), beehiiv is the ultimate no-brainer.

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 200+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session