wozzio

7 ms·

1.
We analyzed 3K K8s clusters: one config line costs millions(wozz.io)
2 points by wozzio 9mo ago|0 comments
2.
How to Plan Your 2026 Kubernetes Budget(wozz.io)
1 points by wozzio 9mo ago|0 comments
3.
by wozzio 9mo ago
OP here. One detail I left out: We are currently looking for 3 engineering teams to be 'Design Partners.' If you are managing a cluster with high variance (e.g., AdTech, AI, Data Services) and suspect you have 'Sleep Insuranc
4.
Show HN: Wozz – open-source Kubernetes cost linter and cluster auditor
2 points by wozzio 9mo ago|1 comments
5.
by wozzio 10mo ago
Really fair critique regarding the snapshot approach. You're right optimizing limits based on a single point in time is dangerous for bursty workloads the need 8GB for 10 seconds scenario. The intent of this script isn't to replac
6.
by wozzio 10mo ago
Ideally we would measure Request minus Max_Usage_Over_7_Days. Since this is a snapshot tool (wrapping kubectl top) it can't see historical peaks so it def leans towards being a current state audit. Love the idea of pairing this with a
7.
by wozzio 10mo ago
I’ll update the README instruction to include curl -L immediately thanks for flagging
8.
by wozzio 10mo ago
In the clusters I've audited so far typically 30% to 50% of the total requested capacity is allocatable waste resources that are reserved/billed but never actually touched.
9.
by wozzio 10mo ago
That aggressive release behavior is exactly what we need more of most runtimes (looking at you legacy Java) just hoard the heap forever because they assume they are the only tenant on the server.
10.
by wozzio 10mo ago
That new .NET behavior is the goal smart runtimes that yield memory back to the OS so we don't have to play guess the request in YAML. Unfortunately most legacy Java/Python workloads I see in the wild are doing the exact opposite:
11.
by wozzio 10mo ago
It feels unsolvable because we've been trying to solve it with static spreadsheets and guesses. It's actually very solvable if you treat it as a control loop problem continuous adjustment rather than a set it and forget it config.
12.
by wozzio 10mo ago
If you're small startup burning $5k/year in lazy tax is smarter than distracting your engineers the math flips when you hit scale. For some that safety margin isn't small. At a certain volume, waste exceeds the cost of a full
13.
by wozzio 10mo ago
That doc is gold thanks for linking. Yeah defaults are the enemy here. Most of the waste I'm seeing in the data comes from generic Spring Boot apps running with out of the box settings where the JVM assumes it owns the entire node.
14.
by wozzio 10mo ago
you are technically right that requests are scheduling hints but in a cluster autoscaler world, requests=bill. If I request 8GB for a pod that uses 1GB, the autoscaler spins up nodes to accommodate that 8GB reservation. That 7GB gap is capa
15.
by wozzio 10mo ago
The curl | bash is just for convenience; the README explicitly advises to Download and inspect wozz.sh first if you aren't comfortable piping to shell. As for the newness I just open-sourced this from my personal scripts collection thi
16.
by wozzio 10mo ago
That is the opposite of what I usually see. Are you trading CPU for RAM by running a more aggressive GC like ZGC or Shenandoah? Usually, people starve the CPU to buy more RAM.
17.
by wozzio 10mo ago
Exactly we call it sleep insurance. It is rational for the on call engineer to pad the numbers but it's just irrational for the finance team to pay for it.
18.
by wozzio 10mo ago
CPU bursting is safe you just get throttled. Memory bursting is dangerous you get OOMKilled. That's why Python numbers look so bad here devs set the request high enough to cover that initial model loading spike so they don't crash
19.
by wozzio 10mo ago
The JVM expands to fill the container, but the scheduler still counts that 8GB request as used when packing the node. Even if the app only needs 2GB of working set, we are blocked from scheduling other pods on that wasted 6GB buffer.
20.
by wozzio 10mo ago
I've been consulting on EKS/GKE cost optimization for a few mid-sized companies and kept seeing the same pattern: massive over-provisioning of memory just to be safe. I wrote a simple CLI tool (bash wrapper around kubectl) to auto
21.
Show HN: I audited 500 K8s pods. Java wastes ~48% RAM, Go ~18%(github.com)
36 points by wozzio 10mo ago|47 comments