The hardware crunch is real, and it is finally worth running Kubernetes like resources are scarce.
Can you afford the excess?
The cost of building a server has roughly doubled inside a year, and the reasons are structural. Gartner puts server costs up more than 125% in the first half of 2026, and enterprise SSD contract prices rose around 80% in a single quarter as AI infrastructure consumed the available NAND output. SK Hynix has warned the shortage could last beyond 2030. Every wafer the big three memory makers allocate to an HBM stack for an AI accelerator is a wafer denied to the DDR5 and NVMe that the rest of us build servers from, and that reallocation is a deliberate, multi-year commitment, not a blip.
An actual quote from a hardware reseller we work with included the following clause.. “Quotes have gone from lasting a month, to only being good for a day. The price you see attached may change, due to competing with what datacenters are willing to pay. For example, the servers we purchased last year for $9000 are now $45000.” and this is the sad reality we are currently operating in.
For anyone self-hosting, this ends the era where the answer to any capacity problem was to buy more iron. Lead times of six months and near double pricing mean RAM and NVMe are now genuinely scarce budgeted resources, and efficiency has a real dollar value attached to it for the first time in years. That changes the calculus in two directions that our industry has spent a long time avoiding.
The first is requests and limits. Almost everyone running Kubernetes finds them tedious, and most estates run with them unset or wildly over-provisioned because compute used to be cheap enough that nobody paid the price of the waste. That waste is now expensive. Setting sensible requests and limits, and actually right-sizing workloads against real consumption, reclaims capacity you have already paid a premium to own. The tooling to do this well has existed for years. What was missing was a commercial reason to bother, and the hardware market has just supplied one.
The second is the "weight" of the Kubernetes distribution and the tooling stack sitting on top of your nodes. A large share of every cluster is spent not on running applications but on running the platform itself, the bloated Kubernetes distribution (RH, I'm looking at you!!), the observability sprawl, the half-used operators, the in-cluster tooling that seemed free when RAM was cheap. It is not free any more. Stripping the estate back to a lean Kubernetes distribution and a very lightweight management tooling framework that frees scarce CPU, RAM and storage to do the one thing you bought the hardware for, which is running your apps.
The teams that come through this well will be the ones that treat their existing fleet as something to run tightly rather than something to keep expanding. Scarcity has a way of making good engineering discipline look like strategy.