This article is part 15 of my MisLinux series on Kubernetes on Hetzner. It reflects my own operating experience and cost tradeoffs, not a vendor benchmark. I am not affiliated with Hetzner or any other vendor mentioned here.
When people compare the cost of a small Kubernetes cluster against a managed-cloud alternative, they usually compare invoices first. That is sensible, but incomplete.
The invoice matters. It just is not the whole bill.
There is a second cost layer that shows up in operator time, debugging attention, and the number of low-level details you have to keep honest as the cluster ages. That is the hidden maintenance cost, and it is one of the main reasons a small cluster can be either a smart decision or a bad bargain depending on who is running it.
The hidden cost is not "Kubernetes is hard"
I do not find the phrase "Kubernetes is hard" especially useful. The more practical truth is:
> Kubernetes is a multiplier on the quality of your operational habits.
If your cluster is small and focused, the visible infrastructure bill can be very attractive. What grows in parallel is the maintenance surface around it:
- image publishing discipline
- registry storage hygiene
- node disk pressure and log growth
- monitoring retention tuning
- backup and restore confidence
- failover preparation
- architecture-specific build handling
None of these are shocking individually. Together, they become a real recurring cost center.
What the invoice misses
On the invoice, I can usually see:
- compute
- volumes
- IPv4 addresses
- backups
- bandwidth when relevant
What the invoice does not show is the human maintenance needed to keep the cluster from drifting into fragility.
That hidden work often includes:
| Hidden cost area | What it really means |
|---|---|
| Registry maintenance | not just storing images, but protecting pullability, multi-arch correctness, and safe cleanup |
| Monitoring maintenance | keeping alerts meaningful, storage right-sized, and exporter scope honest |
| Node hygiene | log routing, image GC, ephemeral storage checks, and "why is this disk filling?" investigations |
| Recovery readiness | validating snapshots, standby paths, credentials, and DNS cutover steps before a crisis |
| Automation safety | making sure the things that save time do not create silent production risk |
This is why a cheap cluster can still be expensive if the operating discipline is weak.
Why small clusters are especially tricky
A large organization often spreads these responsibilities across roles. A small cluster usually does not get that luxury.
The same person or small team ends up owning:
- platform design
- incident response
- registry maintenance
- monitoring hygiene
- build troubleshooting
- application rollout validation
That concentration can be efficient. It can also mean that every unresolved low-level maintenance issue becomes future debt for the same operator.
The maintenance that surprised me most
The areas that changed my thinking the most were not the ones that felt dramatic initially.
Registry correctness
I expected the registry to need disk space and backup attention. What surprised me was how much care is needed around tag semantics, cleanup heuristics, and multi-architecture manifest safety. That is not just storage administration. It is deployment correctness.
Monitoring retention
I expected Prometheus and Grafana to need resources. What surprised me was how quickly retention strategy becomes a design problem rather than a configuration detail once you care about restart behavior, WAL replay, and realistic history windows.
Node disk pressure
I expected workloads to use disk. What surprised me was how much slow, indirect growth comes from side effects:
- unrotated logs
- stale image layers
- abandoned temp files
- orphaned overlay snapshots
Those are the kinds of costs that do not show up in architectural diagrams but absolutely show up in late-night debugging.
Why this does not invalidate the small-cluster choice
The hidden maintenance cost is real, but it does not automatically mean "do not run the cluster yourself."
It means you need to compare two honest totals:
- vendor invoice plus managed-service convenience
- lower infrastructure invoice plus self-managed maintenance burden
For some workloads, the second option is still clearly better. That has often been my experience. But only if the operator is willing to count the maintenance burden as part of the decision instead of pretending the invoice tells the whole story.
The question I ask now before adding anything
Whenever I add infrastructure to a small cluster, I ask:
> What new maintenance loop does this create?
Not "can I deploy it?" Not even "is it useful?"
The most important question is whether it creates a new recurring responsibility around:
- cleanup
- rotation
- recovery
- monitoring
- correctness validation
That question helps me avoid systems that look cheap to start and expensive to keep honest.
What I think small-cluster operators should optimize for
I do not think the right goal is "run as much as possible yourself." I think the right goal is:
- keep the architecture understandable
- automate the repeatable pain
- document the non-obvious failure modes
- avoid adding components whose maintenance cost is larger than the problem they solve
That is what makes a small Kubernetes cluster sustainable rather than merely affordable.
Final thought
The hidden maintenance cost of a small Kubernetes cluster is not a reason to dismiss the model. It is a reason to evaluate it honestly.
If you only compare the provider invoice, you will underestimate the real price. If you only compare the maintenance burden, you will miss how much control and cost-efficiency a small cluster can still offer.
The useful middle ground is to treat maintenance time as part of the platform budget. Once I started doing that, my infrastructure decisions got less romantic and more reliable.
