Je geen zorgen maakt over de kosten van je Kubernetes-cluster, geeft je misschien wel de nodige snelheid voor je POC. Eens de productie op gang is en de integratie van Kubernetes groeit, is het cruciaal om een aantal best practices in FinOps te volgen, om kosten onder controle te houden. Wij presenteren je de Ultieme Kubernetes FinOps-checklist om je Kubernetes-kosten onder controle te houden.
Er wordt de laatste tijd veel gesproken over FinOps. Daar is het huidige economisch klimaat ongetwijfeld niet vreemd aan. Tegelijkertijd is de adoptie van Kubernetes populairder dan ooit. Dit is niet nog maar eens een artikel over wat beiden inhouden en waarom ze essentieel zijn in de wereld van vandaag. Dit stuk focust op de toepassing van FinOps-praktijken in een omgeving die gebouwd is voor opschaling, zoals Kubernetes.
Het opzetten van een Kubernetes-cluster is relatief eenvoudig, met behulp van beheerde diensten zoals Google Kubernetes Engine. Het inzetten van containers in zo’n cluster wordt steeds eenvoudiger met hoogwaardige tools en de juiste DevOps-methodologieën. Dit te doen op een manier die past bij de FinOps-filosofie, dat kan echter wel eens een grotere uitdaging vormen.
De FinOps Foundation definieert de volgende drie fases. Elke fase vloeit netjes over in de volgende, ad infinitum:
- Informeren – zichtbaarheid en toewijzing
- Optimaliseren – gebruikspercentage en kansen
- Opereren – voortdurende activiteiten en verbeteringen
Laten we eens kijken hoe deze van toepassing zijn in een Kubernetes-omgeving. Specifiek, met een cloud-managed service die onvoorstelbare schaalbaarheid bevat.
Informeren
Je wilt inzicht krijgen in je Kubernetes-verbruik en de uitgaven als resultaat daarvan. Omdat Kubernetes, met zijn aanpak gebaseerd op namespace, gebouwd is voor multi-tenancy, zullen meerdere teams of afdelingen hun applicaties inzetten binnen een typische cluster. Daarom kun je niet zomaar alle clusterkosten toeschrijven aan gewoon één applicatie, team of afdeling. Tenzij je een SaaS-bedrijf bent, voor een individuele klant waarvoor je je oplossing host.
Pro tip: werk je met Google Kubernetes Engine? Dan is GKE Cost Allocation een geweldige manier om mee te starten.
Als je een laag dieper gaat, op applicatieniveau, begin dan met in de gaten te houden hoe efficiënt bronnen worden gebruikt. Bij het schrijven van je Deployment YAML’s zijn er veel aspecten om rekening mee te houden, die het gebruik van die bronnen kunnen beïnvloeden. Heel wat van die zaken kunnen de kosten beïnvloeden.
Het is cruciaal om ervoor te zorgen dat je verbruik op elk moment kan worden getraceerd naar een specifieke werklast, een specifiek team of een specifiek project. Kubernetes leent zich hier perfect voor, met zijn op labels gebaseerde aanpak. Daarbovenop, als je GKE gebruikt, kunnen je knooppunten bovendien worden getagd voor extra granulariteit.
Optimaliseren
Met dit arsenaal aan informatie direct beschikbaar voor alle betrokken teams, is het tijd om te gaan optimaliseren. Kijk naar alle beschikbare gegevens en zet je pet van Kubernetes-expert op (heb je die niet, neem dan gerust contact op). Dit zijn een aantal standaard optimalisaties:
- Geen CPU-, GPU- of geheugenquota voor je namespace? Een verkeerde configuratie kan het gebruik van je bronnen doen exploderen. Pod-CPU-aanvragen niet definiëren, maar alleen hun limieten? Kubernetes kopieert de limiet die je hebt opgegeven en gebruikt deze als aangevraagde waarde. Nu claimt elke microservice het maximum van de bronnen in je cluster, ongeacht de daadwerkelijke belasting.
- Host je een geheugenintensieve stack met relatief laag CPU-verbruik op knooppunten, met een standaard CPU-geheugenverhouding? Een groot deel van de CPU’s zal een groot deel van de tijd gewoon inactief zijn. Dat wordt nog erger wanneer je cluster moet schalen (meer nodes toevoegen) omdat je de geheugenlimieten hebt bereikt. Sterker nog, je voegt ongebruikte CPU’s toe.
- Hoe configureer je app- en infrastructuurschaling? Er zijn veel schaalparameters te configureren in een Kubernetes-omgeving, zowel op applicatieniveau (HPA, VPA) als op infrastructuurniveau (cluster-autoschaling). Als je geen gebruik maakt van deze parameters voor de inzet van autoschaling, zul je gefundeerd moeten gokken over de toewijzing van geheugen- en CPU-bronnen. Later, als je merkt dat je inschatting onjuist was, moet je ze opnieuw bekijken en afstemmen. Waarom zou je dat niet automatisch laten gebeuren, binnen vooraf ingestelde grenzen? Als je het vaste aantal pods per inzetbeurt of nodes in het knooppunt verkeerd configureert, zul je bronnen ongebruikt laten, wachtend op workloads die nooit zullen komen.
Compute-middelen? Verspild. Onnodige kosten? Opgelopen.
Pro-tip: elke grote cloudprovider zou je deze inzichten moeten kunnen geven, zoals GKE dat doet met kostengerelateerde optimalisatiecijfers.
Opereren
Zodra je volledig inzicht hebt in je Kubernetes-kosten, weet je precies wat elke applicatie kost. Je hebt je omgeving geoptimaliseerd om deze perfect te laten schalen. Nu kun je continu de bedrijfswaarde van alle individuele applicaties die in je vloot van clusters worden ingezet, evalueren aan de hand van hun werkelijke kosten, in plaats van de kosten die ontstaan door slecht cluster- en applicatiebeheer.
De ultieme checklist voor Kubernetes FinOps
- Informeren: gebruik maken van alle Kubernetes-native opties om kosten toe te wijzen aan teams (namespaces, labels…)
- Informeren: zorg ervoor dat je alle gegevens controleert die je van je cloudprovider krijgt en dat de relevante teamleden toegang hebben tot en getraind zijn in het interpreteren van de gegevens
- Optimaliseren: zorg ervoor dat je cluster, knooppunten en implementaties de juiste grootte hebben
- Optimaliseren: gebruik verschillende knooppunten met aanvullende kenmerken, toegespitst op de werklast die ze zullen hosten (taints en tolerations kunnen hierbij helpen)
- Opereren: kostenoptimalisatie is niet eenmalig, blijf kosten evalueren en vergelijk ze met de waarde die applicaties opleveren
Dit is een ingezonden bijdrage van DevoTeam. Klik hier voor meer informatie over het bedrijf.