Kubecost-oorsig om geld op Kubernetes in die wolke te spaar

Tans dra meer en meer maatskappye hul infrastruktuur oor van hardewarebedieners en hul eie virtuele masjiene na die wolk. Hierdie oplossing is maklik om te verduidelik: jy hoef nie bekommerd te wees oor hardeware nie, die groepering kan maklik op baie verskillende maniere gekonfigureer word ... en die belangrikste, bestaande tegnologieë (soos Kubernetes) maak dit moontlik om rekenaarkrag eenvoudig te skaal na gelang van die las .

Die finansiële aspek is altyd belangrik. Die instrument wat in hierdie artikel bespreek word, is ontwerp om begrotings te help verminder wanneer wolkinfrastruktuur met Kubernetes gebruik word.

Inleiding

Kubecost is 'n Kaliforniese beginonderneming van Google, wat 'n oplossing skep vir die berekening van infrastruktuurkoste in wolkdienste (binne 'n Kubernetes-groepering + gedeelde hulpbronne), soek na knelpunte in groepsinstellings en stuur toepaslike kennisgewings na Slack.

Ons het kliënte met Kubernetes beide in die bekende AWS- en GCP-wolke, en, meer selde vir die Linux-gemeenskap, Azure - in die algemeen, op alle platforms wat deur Kubecost ondersteun word. Vir sommige van hulle bereken ons self die koste van binneklusterdienste (met 'n metode soortgelyk aan dié wat Kubecost gebruik), en monitor ook infrastruktuurkoste en probeer om dit te optimaliseer. Daarom is dit logies dat ons geïnteresseerd was in die moontlikheid om sulke take te outomatiseer.

Die bronkode van die hoof-Kubecost-module is oop onder die bepalings van die oopbronlisensie (Apache-lisensie 2.0). Dit kan vrylik gebruik word en die beskikbare kenmerke behoort voldoende te wees vir klein projekte. Besigheid is egter besigheid: die res van die produk is gesluit, dit kan gebruik word deur betaalde intekeninge, wat ook kommersiële ondersteuning impliseer. Daarbenewens bied die skrywers 'n gratis lisensie vir klein groepe (1 groepering met 10 nodusse - tydens die skryf van hierdie artikel het hierdie limiet uitgebrei tot 20 nodusse) of 'n proeftydperk met volle vermoëns vir 1 maand.

Hoe dit alles werk

Dus, die hoofdeel van Kubecost is die toepassing koste-model, geskryf in Go. 'n Roerkaart wat die hele stelsel beskryf, word genoem koste-ontleder en in sy kern is 'n samestelling van 'n koste-model met Prometheus, Grafana en verskeie dashboards.

Oor die algemeen het kostemodel sy eie webkoppelvlak, wat grafieke en gedetailleerde statistieke oor koste in tabelvorm toon, sowel as natuurlik wenke vir die optimalisering van koste. Die kontroleskerms wat in Grafana aangebied word, is 'n vroeër stadium in die ontwikkeling van Kubecost en bevat baie van dieselfde data as die kostemodel, wat hulle aanvul met die gewone statistieke oor die verbruik van SVE/geheue/netwerk/skyfspasie in die groepering en sy komponente.

Hoe werk Kubecost?

• Kostemodel ontvang pryse vir dienste deur die API van wolkverskaffers.
• Verder, afhangende van die ystertipe van die nodus en die streek, word die koste per nodus bereken.
• Gebaseer op die koste van lopende nodusse, kry elke blaarpeul 'n koste per uur van SVE-gebruik, per gigagreep geheue verbruik en per uur per gigagreep data gestoor - afhangende van die nodus waarop dit geloop het of die klas berging.
• Gebaseer op die koste van die bedryf van individuele peule, word betaling vir naamruimtes, dienste, ontplooiings, StatefulSets bereken.
• Statistieke word bereken deur gebruik te maak van maatstawwe wat deur kube-staat-metrieke en node-uitvoerder verskaf word.

Dit is belangrik om in ag te neem dat Kubecost by verstek tel slegs hulpbronne beskikbaar in Kubernetes. Eksterne databasisse, GitLab-bedieners, S3-bergings en ander dienste wat nie in die groepering is nie (selfs al is dit in dieselfde wolk geleë) is nie daarvoor sigbaar nie. Alhoewel jy vir GCP en AWS die sleutels van jou diensrekeninge kan byvoeg en alles saam kan bereken.

installasie

Kubecost vereis:

• Kubernetes weergawe 1.8 en hoër;
• kube-staat-metrieke;
• Prometheus;
• node-uitvoerder.

Dit het so gebeur dat in ons groepe vooraf aan al hierdie voorwaardes voldoen is, so dit het geblyk dat dit genoeg was om net die korrekte eindpunt vir toegang tot Prometheus te spesifiseer. Die amptelike kubecost Helm-kaart bevat egter alles wat jy nodig het om op 'n kaal groep te hardloop.

Daar is verskeie maniere om Kubecost te installeer:

1. Standaard installasie metode beskryf in instruksies op die ontwikkelaar se webwerf. Vereis voeg die koste-ontleder-bewaarplek by Helm, en installeer dan die grafiek. Al wat oorbly, is om jou poort aan te stuur en die instellings met die hand aan te pas na die verlangde toestand (via kubectl) en/of die kostemodel-webkoppelvlak te gebruik.

   Ons het nog nie eers hierdie metode probeer nie, aangesien ons nie gereedgemaakte konfigurasies van derdepartye gebruik nie, maar dit lyk na 'n goeie opsie "probeer dit self". As jy reeds van die stelselkomponente geïnstalleer het of jy wil meer fyn instel, is dit beter om die tweede pad te oorweeg.

2. Gebruik in wese dieselfde grafiek, maar konfigureer en installeer dit self op enige gerieflike manier.

   Soos reeds genoem, bevat hierdie grafiek, benewens die kubecost self, Grafana- en Prometheus-kaarte, wat ook na wense aangepas kan word.

   Beskikbaar op die grafiek values.yaml vir koste-ontleder kan jy opstel:

   • 'n lys van koste-ontledingskomponente wat ontplooi moet word;
   • jou eindpunt vir Prometheus (as jy reeds een het);
   • domeine en ander ingangsinstellings vir kostemodel en Grafana;
   • aantekeninge vir peule;
   • die behoefte om permanente berging te gebruik en die grootte daarvan.

   'n Volledige lys van beskikbare konfigurasie-opsies met beskrywings is beskikbaar in dokumentasie.

   Aangesien kubecost in sy basiese weergawe nie toegang kan beperk nie, sal jy dadelik basic-auth vir die webpaneel moet instel.

3. Om te installeer slegs die stelselkern - koste-model. Om dit te kan doen, moet jy Prometheus in die cluster installeer en die ooreenstemmende waarde van sy adres in die veranderlike spesifiseer prometheusEndpoint vir Helm. Daarna - aansoek doen stel YAML-konfigurasies in die cluster.

   Weereens, jy sal Ingress met die hand moet byvoeg met basic-auth. Ten slotte sal jy 'n afdeling moet byvoeg vir die insameling van kostemodel-statistieke in extraScrapeConfigs in die Prometheus-opstelling:

   - 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 kry ons?

Met 'n volledige installasie het ons die kubecost- en Grafana-webpaneel met 'n stel dashboards tot ons beskikking.

Totale koste, wat op die hoofskerm vertoon word, wys eintlik die beraamde koste van hulpbronne vir die maand. Hierdie geprojekteer prys wat die koste van die gebruik van die groepering (per maand) op die huidige vlak van hulpbronverbruik weerspieël.

Hierdie maatstaf is meer vir die ontleding van uitgawes en die optimalisering daarvan. Dit is nie baie gerieflik om na die totale koste vir abstrakte Julie in kubecost te kyk nie: jy sal dit moet doen gaan na faktuur. Maar jy kan kostes uitgedeel sien volgens naamruimtes, etikette, peule vir 1/2/7/30/90 dae, wat fakturering jou nooit sal wys nie.

Gepraat van etikette. U moet dadelik na die instellings gaan en die name van die etikette stel wat as bykomende kategorieë vir groeperingskoste gebruik sal word:

Jy kan enige etikette daaraan hang - gerieflik as jy reeds jou eie etiketteringstelsel het.

Ook daar kan jy die adres verander van die API-eindpunt waaraan die kostemodel koppel, die afslaggrootte in GCP aanpas en jou eie pryse vir hulpbronne en geldeenheid vir hul meting stel (om een ​​of ander rede beïnvloed die kenmerk nie Totale koste nie).

Kubecost kan verskeie wys probleme in die groep (en selfs waarskuwing in geval van gevaar). Ongelukkig is die opsie nie konfigureerbaar nie, en daarom, as jy omgewings vir ontwikkelaars het en dit gebruik, sal jy voortdurend iets soos hierdie sien:

'n Belangrike hulpmiddel - Cluster Spaar. Dit meet die aktiwiteit van peule (verbruik van hulpbronne, insluitend netwerke), en bereken ook hoeveel geld en waarop jy kan spaar.

Dit mag lyk asof optimaliseringswenke redelik voor die hand liggend is, maar ondervinding dui daarop dat daar nog iets is om na te kyk. In die besonder word die netwerkaktiwiteit van peule gemonitor (Kubecost stel voor dat u aandag gee aan onaktiewe), die gevraagde en werklike geheue en SVE-verbruik word vergelyk, sowel as die SVE wat deur groepnodusse gebruik word (stel voor dat verskeie nodusse in een ineengestort word), skyf vrag en nog 'n paar dosyn parameters.

Soos met enige optimaliseringskwessie, vereis die optimalisering van hulpbronne gebaseer op Kubecost-data: met omsigtigheid behandel. Byvoorbeeld, Cluster Savings stel voor om nodusse uit te vee, en beweer dat dit veilig is, maar neem nie die teenwoordigheid van noduskiesers en vlekke in die peule wat daarop ontplooi is in ag wat nie op ander nodusse beskikbaar is nie. En in die algemeen, selfs die skrywers van die produk in hul onlangse artikel (terloops, dit kan baie nuttig wees vir diegene wat belangstel in die onderwerp van die projek) dit word aanbeveel om nie kophou na koste-optimering te jaag nie, maar om die kwessie bedagsaam te benader.

Resultate van

Nadat ons kubecost vir 'n maand op 'n paar projekte gebruik het, kan ons tot die gevolgtrekking kom dat dit 'n interessante (en ook maklik om te leer en installeer) hulpmiddel is vir die ontleding en optimalisering van koste vir die dienste van wolkverskaffers wat vir Kubernetes-klusters gebruik word. Die berekeninge blyk baie akkuraat te wees: in ons eksperimente het dit saamgeval met wat die verskaffers eintlik vereis het.

Daar is ook 'n paar nadele: daar is nie-kritieke foute, en op sommige plekke dek die funksionaliteit nie die behoeftes spesifiek vir sommige projekte nie. As jy egter vinnig moet verstaan ​​waarheen die geld gaan en wat "gesny" kan word om die rekening vir wolkdienste konsekwent met 5-30% te verminder (dit is wat in ons geval gebeur het), is dit 'n goeie opsie .

PS

Lees ook op ons blog:

• «Outoskaal en hulpbronbestuur in Kubernetes (oorsig en videoverslag)»;
• «Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel»;
• «Kubernetes wenke en truuks: oor nodustoekenning en webtoepassingladings".

Bron: will.com