Kubernetes Cost Allocation (Kubecost Setup)

Hvad er Kubernetes Cost Allocation med Kubecost? Kubernetes Cost Allocation med Kubecost er arbejdet med at fordele udgiften til et Kubernetes-miljø på de teams, applikationer og workloads, der faktisk bruger infrastrukturen.

Problemet opstår, fordi en almindelig cloudregning typisk viser prisen på virtuelle maskiner, disks, load balancers og netværk. Den viser ikke nødvendigvis, hvilken mikrotjeneste eller hvilket udviklingsteam der har skabt udgiften inde i et delt Kubernetes-cluster.

Kubecost kobler Kubernetes-data med priser og cloud-billingdata. Omkostninger kan derefter fordeles efter blandt andet cluster, namespace, service, pod, controller og Kubernetes-labels. Labels kan bruges til at samle omkostninger efter virksomhedens egne begreber som team, produkt, projekt, afdeling eller miljø.

Det gør det muligt at svare på konkrete spørgsmål. Hvad koster betalingsplatformen at køre? Hvilket team bruger mest CPU og hukommelse? Hvor meget koster udviklingsmiljøet sammenlignet med produktion? Hvor ligger den kapacitet, virksomheden betaler for uden at udnytte den?

Cost allocation er mere avanceret end blot at måle CPU-forbrug. OpenCost-specifikationen, som Kubecost bygger sin cost allocation-model på, skelner blandt andet mellem workload costs, idle costs, shared costs og overhead. Det er nødvendigt, fordi flere workloads ofte deler den samme underliggende infrastruktur.

For CPU og hukommelse tager cost allocation også højde for Kubernetes resource requests. Hvis en container reserverer betydeligt mere kapacitet end den bruger, kan den reservation stadig være en reel omkostningsdriver. Kubecost kan derfor synliggøre både forbrug og overdimensionering.

Kubecost skelner mellem workload idle og infrastructure idle. Workload idle er ressourcer, som en workload har reserveret, men ikke bruger. Infrastructure idle er betalt kapacitet på clusterets noder, som ikke er allokeret til workloads. De to problemer kræver forskellige løsninger.

Shared costs er en anden vigtig del. Platformtjenester, systemkomponenter og andre fælles ressourcer kan komme flere teams til gode. De kan derfor fordeles efter en fast model eller i forhold til de øvrige workloads' ressourceforbrug, afhængigt af virksomhedens økonomiske model.

Præcisionen afhænger også af prisdata. Kubecost kan bruge offentlige cloudpriser, men virksomheder med egne rabatter eller aftaler bør integrere de relevante billingdata. IBM Kubecost understøtter cloud billing-integrationer, så beregninger kan afstemmes mod de priser og rabatter, virksomheden faktisk betaler.

Kubecost bruges ikke kun til rapportering. Platformen indeholder også funktioner til blandt andet efficiency-analyse, rightsizing, budgetter, anomalier og identifikation af ressourcespild. Cost allocation er dog fundamentet, fordi optimering først bliver operationel, når det er tydeligt, hvem der ejer omkostningen.

Hvem arbejder med Kubernetes Cost Allocation med Kubecost? Kubernetes Cost Allocation ligger typisk mellem FinOps og den tekniske platformorganisation. Kompetencen findes derfor ofte hos FinOps engineers, platform engineers, DevOps-specialister, Site Reliability Engineers, cloud architects og erfarne Kubernetes-administratorer.

En FinOps-specialist arbejder typisk med allocation-modellen, showback, chargeback, cost centers, rapportering og økonomisk ansvar. En platform engineer eller Kubernetes-specialist arbejder med namespaces, labels, resource requests, clusterarkitektur, Helm, cloudintegrationer og de tekniske ændringer, der gør cost allocation mulig.

De bedste løsninger kræver normalt samarbejde mellem engineering og økonomi. FinOps Foundation beskriver netop cost allocation som en tværgående disciplin, hvor cost- og usage-data skal skabe ansvar hos teams og produkter.

En Kubernetes-specialist er vigtig, fordi en dårlig teknisk struktur giver dårlige økonomidata. Hvis namespaces ikke følger nogen logik, labels mangler, eller workloads ikke kan knyttes til et produkt eller team, vil en del af udgiften ende som unallocated eller være vanskelig at forklare.

En selvstændig specialist er ofte relevant, når virksomheden allerede driver Kubernetes og har brug for at installere Kubecost, etablere cloud billing-integration, definere labels, bygge allocation-modellen eller rydde op i eksisterende rapportering.

En specialist kan også bruges til fejlsøgning. Det kan være urealistiske omkostninger, manglende namespaces, unallocated spend, forkerte priser, manglende billingdata eller store forskelle mellem Kubecost og cloudleverandørens faktura.

Et større FinOps- eller cloudbureau er mere relevant, når opgaven omfatter mange clusters, flere cloudleverandører, organisatorisk chargeback, fælles rapporteringsstandarder eller etablering af en samlet FinOps-funktion. Her er Kubecost kun én del af en større økonomi- og governance-model.

Virksomheder hyrer også specialister til optimering efter selve opsætningen. Kubecost kan vise ineffektive resource requests, idle kapacitet og andre besparelsesmuligheder, men ændringer bør vurderes sammen med applikationens performance- og stabilitetskrav.

Kurser og uddannelser Der findes ikke én almindelig dansk uddannelse, der specifikt uddanner Kubecost-specialister. Den mest relevante vej kombinerer praktisk Kubernetes-kompetence med FinOps og Kubecosts officielle dokumentation.

Kubernetes Fundamentals, LFS258, fra Linux Foundation er en relevant teknisk grunduddannelse. Kurset dækker Kubernetes-arkitektur, workloads, scheduling, storage, administration, Helm og troubleshooting. Det giver det fundament, der kræves for at forstå, hvorfor forskellige workloads skaber forskellige omkostninger.

Certified Kubernetes Administrator, CKA, fra Linux Foundation og Cloud Native Computing Foundation er den mest oplagte leverandøruafhængige Kubernetes-certificering for personer, der skal arbejde med clusterdrift og Kubecost-opsætning. Certificeringen er praktisk orienteret mod administration af Kubernetes-miljøer.

På økonomisiden er FinOps Certified Practitioner fra FinOps Foundation et anerkendt grundspor. Det giver forståelse for blandt andet allocation, reporting, budgeting, optimization og samarbejdet mellem engineering, finance og business.

For tekniske profiler er FinOps Certified Engineer endnu mere direkte relevant. FinOps Foundation anbefaler dette spor til engineers, der bygger og vedligeholder den tekniske infrastruktur bag FinOps-processer og automatisering.

FinOps Foundation har desuden FinOps Trained Containers som et specialiseret læringsspor. Det er særligt relevant til Kubernetes Cost Allocation, fordi containerøkonomi kræver andre metoder end traditionel cost allocation på virtuelle maskiner og cloudkonti.

Der findes ikke behov for en særskilt Kubecost-certificering for at administrere løsningen. Praktisk erfaring er central. En fagperson bør kunne installere Kubecost med Helm, forstå Kubernetes labels og namespaces, konfigurere pris- og billingdata og forklare forskellen mellem allocation, usage, idle og shared costs.

Et godt træningsmiljø består af et Kubernetes-cluster med flere namespaces og workloads. Her kan man installere Kubecost, etablere teamlabels, analysere resource requests og usage, undersøge unallocated costs og prøve forskellige modeller for shared og idle costs.

Standardværker og ressourcer IBM Kubecost-dokumentationen er det primære opslagsværk til den konkrete platform. Den aktuelle dokumentation beskriver installation, arkitektur, allocation, cloud billing-integration, efficiency, budgets, API'er og multi-cluster-opsætning.

Kubecost Allocations Dashboard-dokumentationen er særlig vigtig. Den beskriver, hvordan omkostninger kan grupperes efter Kubernetes-begreber som namespace, service og labels samt efter organisatoriske begreber som team, produkt, projekt og afdeling.

OpenCost Specification er det vigtigste tekniske standardværk bag selve cost allocation-modellen. OpenCost er et CNCF-projekt og definerer en leverandøruafhængig metode til at beregne og fordele Kubernetes- og containeromkostninger. Kubecost anvender OpenCost som sin underliggende allocation-model.

OpenCost-specifikationen er især nyttig, når man skal forstå forskellen mellem resource allocation cost, usage cost, workload cost, idle cost og shared cost. Den forklarer også, hvordan CPU, hukommelse, storage, netværk og andre Kubernetes-ressourcer indgår i beregningen.

FinOps Framework fra FinOps Foundation er det centrale faglige referenceværk til den organisatoriske side. Allocation er en selvstændig capability i frameworket og hænger sammen med blandt andet reporting, unit economics, workload optimization og chargeback.

Container Cost Allocation Labels and Dictionary fra FinOps Foundation er en praktisk ressource til virksomheder, der skal beslutte, hvordan Kubernetes-labels skal bruges til økonomisk fordeling. Den viser, hvordan labels kan koble containere og workloads til eksempelvis teams, produkter og cost centers.

Calculating Container Costs fra FinOps Foundation går mere direkte ind i problemet med Kubernetes. Ressourceguiden beskriver, hvordan cloud-billingdata, Kubernetes-metrics og workload-metadata kombineres for at fordele omkostninger på namespaces, teams og services.

Cloud FinOps af J.R. Storment og Mike Fuller er et af de centrale bøger på området. Bogen behandler cost allocation og har et særskilt fokus på FinOps i containerverdenen. Den er mest nyttig som supplement til Kubecost-, OpenCost- og Kubernetes-dokumentationen.