Je Kubernetes-cluster draait. Deployments rollen uit, pods worden gescheduled, alerts zijn stil. Alles werkt. Dat zou genoeg moeten zijn, toch?
Dat is het niet. Het CAST AI 2025 Kubernetes Cost Benchmark Report analyseerde meer dan 2.100 organisaties en vond een gemiddeld CPU-gebruik van 10%. Geheugen: 23%. Datadog's State of Cloud Costs formuleert het anders: 83% van de containeruitgaven gaat naar idle resources. En de CNCF FinOps-enquête liet zien dat 49% van de organisaties hun cloudkosten zag stijgen na de overstap naar Kubernetes.
De clusters "werken." De facturen ook. Maar niet in je voordeel.
TL;DR
- Het gemiddelde Kubernetes-cluster gebruikt 10% van de beschikbare CPU en 23% van het geheugen. De rest betaal je voor niets.
- De scheduler wijst resources toe op basis van requests, niet op daadwerkelijk gebruik. Te ruime requests vergrendelen capaciteit die niemand gebruikt.
- Europese cloudproviders (Hetzner, OVHcloud, STACKIT) zijn 50–70% goedkoper per node dan hyperscalers, maar bieden minder managed services en geen spot-instances.
- Begin met VPA in recommendation-only modus en OpenCost. Beiden gratis, laag risico, en je hebt binnen een week inzicht.
- FinOps is geen toolingvraagstuk. Het begint bij het bewust instellen van resource requests vóór deployment.
Inhoudsopgave
- Waar het geld verdwijnt
- De scheduler doet precies wat je vroeg
- Het Europese prijsvoordeel (en de trade-offs)
- Shift-left: kostenbewustzijn vóór deployment
- Tools om vandaag mee te beginnen
- Wanneer FinOps overdreven is
- Key takeaways
Waar het geld verdwijnt
De verspilling is niet spectaculair. Niemand start een 64-core node op en loopt weg. Het is cumulatief, verspreid over elke deployment in het cluster, en onzichtbaar zonder de juiste instrumentatie.
Drie patronen domineren:
Te ruime resource requests. Teams kopiëren resource requests van Stack Overflow of zetten ze "ruim voor de zekerheid." Het verschil tussen gevraagde en daadwerkelijk gebruikte CPU's is gemiddeld 40%. Dat is capaciteit die de scheduler reserveert maar die niemand aanraakt.
Idle nodes en vergeten workloads. Dev- en staging-clusters worden opgestart voor een project, draaien maanden na afloop nog door, en niemand merkt het op. CronJobs en batch Jobs zijn bijzonder verspillend: 60–80% van hun gealloceerde resources wordt gemiddeld niet gebruikt.
Orphaned storage. PersistentVolumes en PVCs die de workloads overleven waarvoor ze zijn aangemaakt. De cloudopslagfactuur blijft komen, of er nu een pod aan hangt of niet.
De CNCF-enquête identificeerde de oorzaken: 70% noemde overprovisioning, 43% resource sprawl, en 45% een gebrek aan bewustzijn. Die laatste is de belangrijkste. Teams verspillen niet expres geld. Ze kunnen het gewoon niet zien.
De scheduler doet precies wat je vroeg
Dit is het mechanisme dat kostenverspilling in Kubernetes structureel maakt, niet incidenteel.
De Kubernetes-scheduler plaatst pods op basis van resource requests, niet op basis van actueel gebruik. Als een container requests.cpu: "2000m" declareert maar normaal 200m gebruikt, reserveert de scheduler twee volledige CPU's op een node. Die CPU's zijn niet beschikbaar voor andere pods, ook al zit 90% van de reservering ongebruikt.
En het wordt erger. Pods zonder resource requests krijgen BestEffort QoS. De scheduler heeft dan geen data om bin-packing mee te doen, dus de plaatsing is een gok. Bij geheugendruk worden BestEffort-pods als eerste geëvict. "Ik sla requests even over" is dus zowel een kostenprobleem als een betrouwbaarheidsprobleem.
Requests hoog zetten voelt veilig. Je workload krijgt wat het nodig heeft. Maar op clusterniveau is de rekensom genadeloos. Tien deployments die elk 1,5 CPU te veel vragen: dat zijn 15 CPU's fantoomcapaciteit. Op een hyperscaler is dat zo'n $150–200/maand aan compute waar je voor betaalt maar niets mee doet. Bij een cluster van 20 nodes lopen die kleine overschattingen op tot duizenden euro's per maand.
De oplossing is niet "lagere requests instellen." Het is "requests instellen op basis van data." Daar komen VPA en meettools bij kijken.
Het Europese prijsvoordeel (en de trade-offs)
Als je Kubernetes draait in Europa, is de keuze van cloudprovider de grootste kostenhefboom die je hebt. Het prijsverschil tussen EU-native providers en Amerikaanse hyperscalers is niet marginaal. Het is structureel.
Een concrete vergelijking voor een 4 vCPU / 16 GB dedicated node:
| Provider | Maandelijks | Control plane | Egress |
|---|---|---|---|
| Hetzner CCX23 | ~€31,49 | Zelf beheerd | 20 TB/mnd gratis |
| OVHcloud B2-15 | ~€28 | Gratis | Gratis |
| AWS m6i.xlarge (EKS) | ~$133 + $73 CP | $73/maand | $0,09/GB |
| GCP e2-standard-4 (GKE) | ~$97 | Gratis (zonal) | $0,08/GB |
Voor een 10-node cluster kost Hetzner dedicated nodes zo'n €315/maand. Het equivalent op AWS EKS: rond de $744/maand, vóór egress. Dat is geen afrondingsverschil.
Maar de trade-offs zijn echt:
Hetzner biedt geen managed Kubernetes control plane. Je draait k3s, kubeadm, of gebruikt een managed oplossing van een derde partij zoals Syself of Cloudfleet. Geen spot-instances ook. De besparing komt van de rauwe computeprijs en de inclusieve egress, niet van managed-service gemak.
OVHcloud biedt wel een managed Kubernetes-dienst met een gratis control plane, gratis intern verkeer en redelijke nodeprijzen. Van de EU-opties is dit de meest "batterijen inbegrepen"-variant.
STACKIT (het cloudplatform van de Schwarz Group, het moederbedrijf van Lidl en Kaufland) biedt een managed Kubernetes Engine met datacenters in Duitsland en Oostenrijk. De soevereiniteitshoek is hier concreet: STACKIT is volledig in EU-handen, zonder Amerikaans moederbedrijf dat onder de CLOUD Act valt. Voor organisaties in gereguleerde sectoren (financiën, zorg, overheid) telt dat juridisch steeds zwaarder, niet alleen als principe.
Eén concrete trade-off van EU-native providers: spot-instances zijn grotendeels niet beschikbaar. Hetzner en STACKIT bieden ze niet aan. Op AWS kunnen spot-instances 60–90% besparen op compute. Als je workloads preëmptie verdragen, is dat een hefboom die EU-providers simpelweg niet hebben. De basisprijs is lager, maar de vloer is ook het plafond.
Mijn positie: voor teams die 3–20 nodes draaien met voorspelbare workloads weegt het EU-prijsvoordeel zwaarder dan de trade-offs in managed services. Voor teams met sterk wisselende loads die profiteren van spot en Karpenter-achtige dynamische instance-selectie blijft AWS of GCP logischer. Het juiste antwoord hangt af van je workloadpatroon.
Shift-left: kostenbewustzijn vóór deployment
Het State of FinOps 2026 rapport van de FinOps Foundation vond dat pre-deployment architecture costing de op één na meest gevraagde tooling-functie was onder practitioners. Het idee is simpel: als je weet wat iets gaat kosten vóórdat je het deployt, neem je andere beslissingen.
In Kubernetes betekent shift-left drie dingen:
-
Vereis resource requests op elke workload. Gebruik een LimitRange om defaults te injecteren als teams het vergeten, en een ResourceQuota per namespace om totaalverbruik te begrenzen. Een admission policy (Kyverno of OPA Gatekeeper) kan deployments blokkeren die requests overslaan. Als je Kyverno al gebruikt voor namespace bootstrapping, is een "vereis resource requests"-policy een logische uitbreiding. Dit is basisgovernance.
-
Baseer requests op werkelijk gebruik, niet op gokken. Draai VPA in recommendation-only modus voor 7–14 dagen, lees de aanbevelingen, en stel bij. De FinOps Foundation "Calculating Container Costs" werkgroep adviseert p95 historisch gebruik met 20–30% marge als uitgangspunt voor CPU-requests.
-
Maak kosten zichtbaar per team. Namespace-level kostenallocatie, al is het maar als read-only dashboard, verandert gedrag. Slechts 14% van de organisaties doet echte chargeback (geld verschuiven tussen budgetten). De meesten doen showback: kosten tonen zonder consequenties. Dat alleen al is vaak genoeg om right-sizing in gang te zetten.
Op KubeCon EU 2026 in Amsterdam wees Anton Weiss erop dat FinOps niet eens voorkomt als focusgebied in de platformengineering.org 2025 enquête. Platform-teams zien kostenoptimalisatie niet als hun taak. Die blinde vlek is precies de reden dat clusters zonder kostenzichtbaarheid maar blijven groeien.
Tools om vandaag mee te beginnen
Je hebt geen FinOps-platform of zes maanden durend volwassenheidsmodel nodig. Twee gratis, open-source tools dekken de eerste 80% van de zichtbaarheid:
OpenCost is een CNCF Incubating-project (gepromoveerd vanuit Sandbox in oktober 2024). Het biedt vendor-neutrale, real-time kostenallocatie per namespace, deployment, pod en label. Het integreert met de billing API's van AWS, GCP en Azure, en exporteert Prometheus-metrics. Voor teams op EU-providers kun je aangepaste nodeprijzen invoeren. IBM's acquisitie van Kubecost in september 2024 valideerde deze markt, maar OpenCost blijft het vendor-neutrale startpunt.
Fairwinds Goldilocks wikkelt VPA in recommendation-only modus met een dashboard eromheen. Label een namespace met goldilocks.fairwinds.com/enabled: "true", wacht een week, en Goldilocks toont welke workloads te veel vragen ("too large"), te weinig ("too small"), of goed zitten ("just right"). Het verschil tussen de "too large"-aanbevelingen en de huidige requests is je verspilling, gekwantificeerd.
Voor infrastructure-as-code pipelines voegt Infracost kostenschattingen toe aan Terraform pull requests. Engineers zien de maandelijkse kostendelta van elke infrastructuurwijziging vóór het mergen.
Voor teams op hyperscalers die geautomatiseerde optimalisatie willen, handelen CAST AI en Karpenter (AWS-native) dynamische instance-selectie en spot-management af. Maar dit zijn optimalisatietools. Ze werken het best nadat je zichtbaarheid hebt. Begin met het probleem zien, pas dan automatiseer je de oplossing.
Wanneer FinOps overdreven is
Niet elk cluster heeft een kostenpraktijk nodig. Als je een 3-node cluster draait op Hetzner voor €95/maand totaal, is de potentiële besparing van right-sizing misschien €20/maand. De tijd die je steekt in instrumentatie, analyse en bijstelling verdient zichzelf dan niet terug.
FinOps is zinvol wanneer:
- Je maandelijkse Kubernetes-uitgaven boven €500–1.000 liggen en je niet weet welke teams of workloads dat veroorzaken
- Je op hyperscaler-prijzen zit waar 30% reductie in absolute bedragen de moeite waard is
- Meerdere teams een cluster delen zonder resource governance
- Je cluster organisch gegroeid is over 12+ maanden zonder resource review
Het is niet zinvol als je cluster klein is, je team klein is, en je direct zicht hebt op wat waar draait. Op die schaal levert de juiste cloudprovider kiezen (zie de EU-prijssectie hierboven) meer op dan welke monitoringtool dan ook.
Key takeaways
- Het gemiddelde Kubernetes-cluster gebruikt 10% van de beschikbare CPU. Als dat getal je niet stoort, bekijk dan eens je cloudfactuur.
- Resource requests bepalen het schedulergedrag. Niet-onderbouwde requests veroorzaken structurele verspilling die lineair meeschaalt met je cluster.
- EU-cloudproviders bieden 50–70% lagere nodeprijzen dan hyperscalers. De trade-off: minder managed services en geen spot-instances.
- VPA in recommendation-only modus en OpenCost zijn gratis startpunten met laag risico. Binnen een week heb je kostenzichtbaarheid.
- FinOps is geen toolingprobleem. Het begint bij resource requests als een bewuste beslissing behandelen, niet als copy-paste uit een tutorial.