Kubecost-recensie voor het besparen van geld op Kubernetes in de cloud

Momenteel brengen steeds meer bedrijven hun infrastructuur over van hardwareservers en hun eigen virtuele machines naar de cloud. Deze oplossing is eenvoudig uit te leggen: u hoeft zich geen zorgen te maken over hardware, het cluster kan eenvoudig op veel verschillende manieren worden geconfigureerd... en het allerbelangrijkste: de beschikbare technologieën (zoals Kubernetes) maken het mogelijk om de rekenkracht eenvoudig te schalen, afhankelijk van de belasting .

Het financiële aspect is altijd belangrijk. De tool die in dit artikel wordt besproken, is ontworpen om de budgetten te helpen verlagen bij het gebruik van cloudinfrastructuur met Kubernetes.

Introductie

Kubecost is een Californische startup van Google, die een oplossing creëert voor het berekenen van infrastructuurkosten in clouddiensten (binnen een Kubernetes-cluster + gedeelde bronnen), het zoeken naar knelpunten in clusterinstellingen en het versturen van passende notificaties naar Slack.

We hebben klanten met Kubernetes zowel in de bekende AWS- als GCP-clouds, en, zeldzamer voor de Linux-gemeenschap, Azure - in het algemeen, op alle platforms die door Kubecost worden ondersteund. Voor sommige ervan berekenen we zelf de kosten van intraclusterdiensten (op basis van een methode die vergelijkbaar is met die van Kubecost), en monitoren we ook de infrastructuurkosten en proberen we deze te optimaliseren. Daarom is het logisch dat we geïnteresseerd waren in de mogelijkheid om dergelijke taken te automatiseren.

De broncode van de hoofdmodule van Kubecost is open onder de voorwaarden van de Open Source-licentie (Apache License 2.0). Het kan vrij worden gebruikt en de beschikbare functies moeten voldoende zijn voor kleine projecten. Maar zaken zijn zaken: de rest van het product is gesloten en kan door gebruikt worden betaalde abonnementen, wat ook commerciële steun impliceert. Daarnaast bieden de auteurs een gratis licentie voor kleine clusters (1 cluster met 10 knooppunten - tijdens het schrijven van dit artikel is deze limiet uitgebreid naar 20 knooppunten) of een proefperiode met volledige mogelijkheden van 1 maand.

Hoe alles werkt

Het belangrijkste onderdeel van Kubecost is dus de applicatie kostenmodel, geschreven in Go. Er wordt een Helm-diagram aangeroepen dat het hele systeem beschrijft kosten-analysator en de kern is een assemblage van een kostenmodel met Prometheus, Grafana en verschillende dashboards.

Over het algemeen heeft het kostenmodel een eigen webinterface, die grafieken en gedetailleerde kostenstatistieken in tabelvorm weergeeft, evenals uiteraard tips voor het optimaliseren van de kosten. De dashboards die in Grafana worden gepresenteerd, bevinden zich in een eerdere fase in de ontwikkeling van Kubecost en bevatten vrijwel dezelfde gegevens als het kostenmodel, aangevuld met de gebruikelijke statistieken over het verbruik van CPU/geheugen/netwerk/schijfruimte in het cluster en zijn componenten .

Hoe werkt Kubecost?

• Cost-model ontvangt prijzen voor diensten via de API van cloudproviders.
• Verder worden, afhankelijk van het ijzertype van het knooppunt en de regio, de kosten per knooppunt berekend.
• Gebaseerd op de kosten van het draaien van knooppunten, krijgt elke leaf pod een vergoeding per uur CPU-gebruik, per gigabyte verbruikt geheugen en per uur per gigabyte aan opgeslagen gegevens - afhankelijk van het knooppunt waarop het draaide of de opslagklasse.
• Op basis van de kosten voor het exploiteren van afzonderlijke pods wordt de betaling berekend voor naamruimten, services, implementaties en StatefulSets.
• Statistieken worden berekend met behulp van statistieken van kube-state-metrics en node-exporter.

Het is belangrijk om te overwegen dat Kubecost telt standaard alleen de bronnen die beschikbaar zijn in Kubernetes. Externe databases, GitLab-servers, S3-opslag en andere services die zich niet in het cluster bevinden (zelfs als ze zich in dezelfde cloud bevinden) zijn voor hem niet zichtbaar. Hoewel u voor GCP en AWS de sleutels van uw serviceaccounts kunt toevoegen en alles samen kunt berekenen.

installatie

Kubecost vereist:

• Kubernetes versie 1.8 en hoger;
• kube-state-metrieken;
• Prometheus;
• knooppunt-exporteur.

Het gebeurde zo dat in onze clusters vooraf aan al deze voorwaarden was voldaan, dus het bleek voldoende om gewoon het juiste eindpunt voor toegang tot Prometheus te specificeren. Het officiële kubecost Helm-diagram bevat echter alles wat u nodig hebt om op een kaal cluster te draaien.

Er zijn verschillende manieren om Kubecost te installeren:

1. Standaard installatiemethode beschreven in instructies op de website van de ontwikkelaar. Vereist voeg de kostenanalyseopslagplaats toe aan Helm en installeer vervolgens het diagram. Het enige dat overblijft is uw poort door te sturen en de instellingen handmatig (via kubectl) en/of via de kostenmodel-webinterface in de gewenste staat te brengen.

   We hebben deze methode nog niet eens geprobeerd, omdat we geen kant-en-klare configuraties van derden gebruiken, maar het lijkt een goede optie om het gewoon zelf te proberen. Als u al enkele systeemcomponenten hebt geïnstalleerd of als u meer verfijning wilt, kunt u beter het tweede pad overwegen.

2. Gebruik in wezen dezelfde grafiek, maar configureer en installeer het zelf op elke handige manier.

   Zoals reeds vermeld bevat deze kaart naast de kubecost zelf Grafana- en Prometheus-kaarten, die ook naar wens kunnen worden aangepast.

   Beschikbaar op de kaart values.yaml voor kostenanalyse kunt u het volgende configureren:

   • een lijst met componenten van de kostenanalyse die moeten worden geïmplementeerd;
   • uw eindpunt voor Prometheus (als u er al een heeft);
   • domeinen en andere instellingen voor inkomend verkeer voor kostenmodel en Grafana;
   • annotaties voor peulen;
   • de noodzaak om permanente opslag te gebruiken en de omvang ervan.

   Een volledige lijst met beschikbare configuratieopties met beschrijvingen is beschikbaar in documentatie.

   Omdat kubecost in de basisversie de toegang niet kan beperken, moet u onmiddellijk basic-auth voor het webpaneel configureren.

3. Om te installeren alleen de systeemkern - kostenmodel. Om dit te doen, moet u Prometheus in het cluster hebben geïnstalleerd en de overeenkomstige waarde van het adres in de variabele opgeven prometheusEndpoint voor Helm. Daarna - solliciteren set YAML-configuraties in het cluster.

   Nogmaals, je zult Ingress handmatig moeten toevoegen met basic-auth. Ten slotte moet u een sectie toevoegen voor het verzamelen van kostenmodelstatistieken extraScrapeConfigs in de Prometheus-configuratie:

   - job_name: kubecost
     honor_labels: true
     scrape_interval: 1m
     scrape_timeout: 10s
     metrics_path: /metrics
     scheme: http
     dns_sd_configs:
     - names:
       - <адрес вашего сервиса kubecost>
       type: 'A'
       port: 9003

Wat krijgen we?

Bij een volledige installatie beschikken wij over het kubecost en Grafana webpanel met een set dashboards.

Totale prijs, weergegeven op het hoofdscherm, toont feitelijk de geschatte kosten van bronnen voor de maand. Dit voorspelbaar prijs die de kosten weerspiegelt van het gebruik van het cluster (per maand) bij het huidige niveau van hulpbronnenverbruik.

Deze statistiek is meer bedoeld voor het analyseren van uitgaven en het optimaliseren ervan. Het is niet erg handig om de totale kosten voor abstract juli in kubecost te bekijken: dit zal je moeten doen ga naar facturering. Maar u kunt de kosten uitgesplitst zien naar naamruimten, labels en pods voor 1/2/7/30/90 dagen, wat u in de facturering nooit zult zien.

Over dat gesproken etiketten. U moet onmiddellijk naar de instellingen gaan en de namen instellen van de labels die zullen worden gebruikt als extra categorieën voor het groeperen van kosten:

Je kunt er eventueel labels aan hangen. Handig als je al een eigen labelsysteem hebt.

Ook daar kunt u het adres wijzigen van het API-eindpunt waarmee het kostenmodel verbinding maakt, de kortingsgrootte in GCP aanpassen en uw eigen prijzen voor bronnen en valuta voor hun meting instellen (om de een of andere reden heeft de functie geen invloed op de totale kosten).

Kubecost kan er verschillende tonen problemen in het cluster (en zelfs alert bij gevaar). Helaas is de optie niet configureerbaar, en daarom zul je, als je omgevingen voor ontwikkelaars hebt en deze gebruikt, constant zoiets als dit zien:

Een belangrijk hulpmiddel - Clusterbesparingen. Het meet de activiteit van pods (verbruik van hulpbronnen, inclusief netwerkbronnen), en berekent ook hoeveel geld en waarop u kunt besparen.

Het lijkt misschien dat optimalisatietips nogal voor de hand liggen, maar de ervaring leert dat er toch nog iets is om naar te kijken. In het bijzonder wordt de netwerkactiviteit van pods gemonitord (Kubecost suggereert aandacht te besteden aan inactieve), het gevraagde en werkelijke geheugen- en CPU-verbruik wordt vergeleken, evenals de CPU die wordt gebruikt door clusterknooppunten (suggereert het samenvouwen van meerdere knooppunten in één), schijf load en nog een paar dozijn parameters.

Zoals bij elk optimalisatieprobleem vereist het optimaliseren van bronnen op basis van Kubecost-gegevens het volgende: voorzichtig behandelen. Cluster Savings stelt bijvoorbeeld voor om knooppunten te verwijderen en beweert dat dit veilig is, maar houdt geen rekening met de aanwezigheid van knooppuntselectors en taints in de pods die daarop worden ingezet die niet beschikbaar zijn op andere knooppunten. En in het algemeen zijn zelfs de auteurs van het product in hun recent artikel (trouwens, het kan erg handig zijn voor degenen die geïnteresseerd zijn in het onderwerp van het project). Het wordt aanbevolen om niet halsoverkop in kostenoptimalisatie te gaan, maar om het probleem zorgvuldig te benaderen.

Resultaten van

Nadat we kubecost een maand lang op een aantal projecten hebben gebruikt, kunnen we concluderen dat het een interessante (en ook gemakkelijk te leren en te installeren) tool is voor het analyseren en optimaliseren van de kosten voor de diensten van cloudproviders die worden gebruikt voor Kubernetes-clusters. De berekeningen blijken zeer accuraat: in onze experimenten kwamen ze overeen met wat de aanbieders daadwerkelijk nodig hadden.

Er zijn ook enkele nadelen: er zijn niet-kritieke bugs en op sommige plaatsen dekt de functionaliteit niet de behoeften die specifiek zijn voor sommige projecten. Als u echter snel wilt begrijpen waar het geld naartoe gaat en waar op kan worden “bezuinigd” om de factuur voor clouddiensten consequent met 5-30% te verlagen (dit is wat er in ons geval is gebeurd), is dit een geweldige optie .

PS

Lees ook op onze blog:

• «Autoscaling en resourcebeheer in Kubernetes (overzicht en videorapport)";
• «Kubernetes-avontuur Dailymotion: infrastructuur creëren in de clouds + on-premises";
• «Kubernetes tips & tricks: over knooppunttoewijzing en het laden van webapplicaties.

Bron: www.habr.com