Kubernetes-kostenzichtbaarheid is een engineering-probleem.
Waarom cluster-bezetting misleidt
Cloud-kostendashboards rapporteren op node-niveau. Kubernetes plant in op pod-niveau. Het gat tussen die twee weergaven is waar de verspilling zich schuilt.
Een cluster op 68 procent gemiddelde CPU-bezetting kan namespaces bevatten die op 90 procent draaien en andere op 20 procent. De gemiddelden heffen elkaar op in het aggregaat. De facturering doet dat niet.
De drie cijfers die je werkelijk nodig hebt: kosten per namespace, kosten per workload binnen een namespace, en het gat tussen wat een pod aanvraagt en wat hij werkelijk verbruikt. Een pod die 4 CPU aanvraagt en 0,3 CPU gebruikt, verspilt 3,7 CPU aan cluster-capaciteit. De cluster-bezettingsmetriek ziet er goed uit. De pod is het probleem. Je kunt het niet zien vanuit het dashboard dat je bekijkt.
Requests vs limits vs actueel: de drie samen lezen
Kubernetes-kosten volgen een eenvoudige regel: je betaalt voor node-capaciteit. De scheduler bepaalt de node-grootte op basis van pod-resource-requests. Werkelijk verbruik is irrelevant voor de scheduler en irrelevant voor de rekening.
Het verspillingspatroon dat we het vaakst tegenkomen: teams stellen resource-requests conservatief hoog in voor veiligheidsmarge. Ze stellen limieten veel hoger in, of laten ze weg. Werkelijk verbruik zit op 10 tot 30 procent van de request. De cluster plant in op basis van de request. Nodes draaien op de grootte die de request vereist. De rekening is correct voor de toegewezen capaciteit, niet voor het uitgevoerde werk.
Op een typische mid-market Kubernetes-estate met 8 tot 15 node-pools gemiddelt request-versus-actueel-verspilling 25 tot 35 procent van de totale clusterkosten. Oplossen vereist eerst zichtbaarheid, dan een gerichte right-sizing-pas op de pods met het grootste request-naar-actueel-gat.
De tooling die dit zichtbaar maakt
OpenCost is een CNCF-incubatieproject dat node-kosten toewijst aan namespaces en individuele workloads. Het draait in-cluster, leest de Kubernetes API en emitteert Prometheus-metrics. Het kostenmodel verwerkt on-demand-, spot- en gereserveerde node-capaciteit correct. Het integreert met Grafana zonder aanvullende configuratie en vereist geen wijzigingen aan bestaande workloads.
Kubecost breidt hetzelfde allocatiemodel uit met multi-cluster-weergaven, besparingsaanbevelingen en een budget-alerteringslaag. De gratis versie dekt de meeste teams. De commerciële versie voegt SSO en programmatische API-toegang toe.
Beide tools zijn basisvereisten, geen onderscheidende factoren. Het onderscheid zit in wie naar het dashboard kijkt en wat hij ermee doet. Dat is het deel waar wij aan werken.
"In de meeste clusters veroorzaken 20 procent van de workloads 70 procent van de verspilde request-capaciteit. De right-sizing is een PR, geen infrastructuurwijziging."
Danny Zak / FinOps Lead
Hoe handelen erop eruitziet
De eerste sprint is zichtbaarheid. Deploy OpenCost, verbind het met bestaande Grafana, voeg een namespace-kostenpaneel toe aan het teamdashboard naast CPU en geheugen. Kosten worden een first-class signaal op hetzelfde scherm als de andere engineering-metrics.
De tweede sprint is right-sizing. Identificeer de vier of vijf workloads met het grootste gat tussen request en actueel. In de meeste clusters veroorzaken 20 procent van de workloads 70 procent van de verspilde request-capaciteit. De right-sizing-wijziging is een PR tegen de Helm-waarden of de Kubernetes-manifests. Het is geen infrastructuurwijziging en vereist geen onderhoudsvenster.
De derde sprint is policy. LimitRange-objecten handhaven request-plafonds per namespace. ResourceQuota-gates vereisen een FinOps-review voordat een namespace zijn plafond boven een drempel kan verhogen. Een maandelijks chargeback-rapport gaat naar de engineering-lead van elk team met drie cijfers: kosten vorige maand, kosten ten opzichte van de maand ervoor, en kosten als percentage van de totale clusteruitgave.
Teams die alle drie sprints uitvoeren rapporteren 20 tot 30 procent Kubernetes-kostenreductie in het eerste kwartaal. De reductie komt van right-sizing, niet van het verwijderen van workloads. Er gaan geen features weg. De rekening daalt.