Kubecosti ülevaade teie raha säästmiseks Kuberneteses pilvedes

Praegu üha rohkem ettevõtteid viib oma infrastruktuuri füüsilistelt serveritelt ja oma virtuaalsetelt masinatelt pilvede peale. Sellist lahendust on lihtne selgitada: pole vaja muretseda riistvara pärast, kluster on hõlpsasti konfigureeritav erinevate viiside kaudu... ja mis kõige tähtsam — olemasolevad tehnoloogiad (nt Kubernetes) võimaldavad arvutusvõimsust lihtsalt skaleerida vastavalt koormusele.

Finantsaspekt on alati oluline. Tööriist, millest selles artiklis räägitakse, on mõeldud eelarvete vähendamiseks, kasutades pilveinfrastruktuuri koos Kubernetes'ega.

Sissejuhatus

Kubecost — kalifornialane idufirma, mille asutajad on endised Google'i töötajad, kes arendab lahendust pilveteenuste infrastruktuuri kulude arvestamiseks (Kubernetes'sisese kluster + ühisressursid), kitsaskohtade leidmiseks klustere seadistustes ja vastavate teavituste saatmiseks Slacki.

Meil on kliente, kellel on Kubernetes nii tuttavates AWS ja GCP pilvedes kui ka haruldases Linuxi kogukonnas Azure's — kokkuvõttes kõik platvormid, mida Kubecost toetab. Mõne jaoks arvutame me kulud siseklastri teenuste põhjal iseseisvalt (meetodi järgi, mis sarnaneb Kubecost kasutatavale), samuti jälgime infrastruktuuri kulusid ja püüame neid optimeerida. Seetõttu on loogiline, et meid huvitab selliste ülesannete automatiseerimise võimalus.

Kubecost'i põhikomplekti allikas on avatud Open Source litsentsi (Apache License 2.0) tingimustes. Seda saab kasutada vabalt, ja saadud funktsioonide hulk peaks olema piisav väikeste projektide jaoks. Kuid äri on äri: ülejäänud toode on suletud ja selle kasutamiseks on vajalik tasulised tellimused, mis hõlmavad ka ärilist tuge. Lisaks pakuvad autorid tasuta litsentsi väikestele klustritele (1 kluster 10 sõlmega — artikli kirjutamise ajal laienes see piirang 20 sõlmele) või prooviperioodi täielike funktsioonidega 1 kuuks.

Kuidas kõik on korraldatud

Nii et Kubecost'i põhiosa on rakendus cost-model, mis on kirjutatud Go keeles. Helm-chart, mis kirjeldab kogu süsteemi, nimetatakse cost-analyzer ja on oma olemuselt kogumik cost-model'ist koos Prometheuse, Grafana ja mitmete juhtpaneelidega.

Üldiselt on cost-modelil oma veebiliides, mis näitab graafikuid ja üksikasjalikku statistikat kulude kohta tabelivormis, samuti loomulikult nõuandeid kulutuste optimeerimiseks. Grafana armatuurlaudade esitatud andmed on Kubecosti arengus varasem etapp ja sisaldavad suuresti samu andmeid nagu cost-model, lisades neile tavalise statistika CPU/mälu/võrgu/diskiruumi kasutuse kohta klastris ja selle komponentides.

Kuidas Kubecost töötab?

• Cost-model saab pilveteenuste pakkujatelt API kaudu hoolduskulude hinnad.
• Seejärel arvutatakse sõltuvalt sõlme riistvaratüübist ja piirkonnast sõlmede maksumus.
• Iga lõpp-podi jaoks arvutatakse protsessori kasutamise, ühe gigabaidi mälu ja ühe gigabaidi andmehoidla tunni hind, lähtudes sõlmest, millega see töötas, või säilitamisklassist.
• Eraldi podide töö maksumusest arvutatakse tasu nimede, teenuste, Deployment'ite, StatefulSet'ite kohta.
• Statistika arvutamiseks kasutatakse kube-state-metrics'i ja node-exporteri andmeid.

Oluline on arvestada, et Kubecost arvutab vaikimisi ainult Kuberneteses olemasolevaid ressursse. Välised andmebaasid, GitHubi serverid, S3 hoidlad ja muud teenused, mis ei asu klastris (kuigi need võivad asuda samas pilvis), ei ole tema jaoks nähtavad. Siiski on GCP ja AWS jaoks võimalik lisada oma teenusekonto võtmed ja arvutada kõike koos.

Paigaldamine

Kubecosti toimimiseks on vajalik:

• Kubernetes versioon 1.8 ja uuem;
• kube-state-metrics;
• Prometheus;
• node-exporter.

Nii on juhtunud, et meie klastrites olid kõik need tingimused enne täidetud, seega osutus piisavaks lihtsalt õigete lõpp-punktide näitamine Prometheusele. Siiski sisaldab ametlik Helm-chart kubecost kõike vajalikku, et alustada ka "paljas" klaster.

Kubecosti saab installida mitmel viisil:

1. Standardsed installimise meetodid on kirjeldatud juhendis arendaja veebisaidil. Tuleb lisada Helm-repositoorium cost-analyzer, pärast mida tuleks installida chart. Jääb vaid port enda jaoks suunata ja viimistleda seadistused soovitud olekusse käsitsi (kubectl kaudu) ja/või cost-modeli veebiliidese abil.

   Kuna me ei kasuta kolmandate osapoolte valmis konfiguratsioone, ei ole me seda meetodit isegi proovinud, kuid see näeb välja kui hea variant, et lihtsalt ise proovida. Kui teil on juba osa süsteemi komponente paigaldatud või soovite täiendavat kohandamist, tasub kaaluda teist teed.

2. Kasutada põhimõtteliselt sama charti, aga konfigureerida ja paigaldada see ise iga mugava meetodi kaudu.

   Nagu juba mainitud, sisaldab see chart lisaks kubecost'ile ka Grafana ja Prometheuse chart'e, mida saab samuti soovi korral seadistada.

   Chartis olev values.yaml cost-analyzer võimaldab konfigureerida:

   • cost-analyzer'i komponente, mida on vaja juurutada;
   • oma endpoinit Prometheusele (kui see teil juba olemas on);
   • domeene ja muid ingressi seadistusi cost-model'i ja Grafana jaoks;
   • annotatsioonid pod'ide jaoks;
   • vajaduse kasutamise ja nende suuruse osas püsivates salvestustes.

   Täielik saadaval olevate konfigureerimisvõimaluste nimekiri koos kirjeldustega on dokumentatsioon.

   Kuna kubecost põhiversioonis ei piirata juurdepääsu, on vajalik kohe seada ära basic-auth veebipaneelile.

3. Paigaldada ainult süsteemi tuum — cost-model. Selleks on vaja, et klastris oleks paigaldatud Prometheus ja selle aadressi vastav väärtus tuleks määrata muutujasse prometheusEndpoint Helmile. Pärast seda rakendatakse YAML-konfiguratsioonide kogum klastris.

   Taaskord tuleb käsitsi lisada Ingress koos basic-auth'iga. Ja lõpuks on vajalik lisada sektsioon cost-model'i metrikate kogumiseks extraScrapeConfigs Prometheuse konfis:

   - job_name: kubecost
     honor_labels: true
     scrape_interval: 1m
     scrape_timeout: 10s
     metrics_path: /metrics
     scheme: http
     dns_sd_configs:
     - names:
       - 
       type: 'A'
       port: 9003

Mida me saame?

Täieliku paigalduse korral on meil juurdepääs kubecost'i veebipaneelile ja Grafanale koos dashboard'idega.

Kokkuvõttes, mis kuvatakse peamisel ekraanil, näitab tegelikult ressursside arvutatud kulu kuu jooksul. See on prognoositav hind, mis kajastab klastrikasutuse maksumust (kuus) antud ressursside tarbimise taseme juures.

See näitaja on rohkem kulude analüüsimiseks ja nende optimeerimiseks. Üldised kulud abstraktse juuli kohta kubecost'is ei ole eriti mugav jälgida: selleks peate minema billimise. Siiski saab vaadata kulusid eraldi nimede, siltide, pod'ide lõikes 1/2/7/30/90 päeva jooksul, mida billimine kunagi ei näita.

Rääkides siltidest. Tasub koheselt seadistada sildid, mida kasutatakse lisa kategooriatena kulude rühmitamiseks:

Siltide külge võib riputada mingeid — see on mugav, kui teil on juba olemas oma märgistussüsteem.

Samuti saab seal muuta API lõpp-punkti aadressi, millega cost-model ühendub, seadistada GCP allahindluse suuruse ning määrata oma hinnad ressurssidele ja nende mõõtmisvaluutale (tõenäoliselt ei mõjuta see Total cost’i).

Kubecost suudab näidata erinevaid probleeme klastris (ja isegi teavitada, kui oht on olemas). Kahjuks ei ole valikut seadistada, seega — kui teil on arenduskeskkonnad ja neid kasutatakse, siis saate pidevalt jälgida midagi sarnast:

Oluline tööriist — Cluster Savings. See mõõdab podide aktiivsust (ressursside tarbimine, sealhulgas ka võrgu) ning arvutab, kui palju raha ja mille pealt on võimalik säästa.

Võib tunduda, et optimeerimisnõuanded on üsna ilmne, kuid kogemus näitab, et siiski on veel, millele tähelepanu pöörata. Eelkõige jälgitakse podide võrgutegevust (Kubecost soovitab pöörata tähelepanu mitteaktiivsetele), võrreldakse nõutud ja tegelikku mälu ja CPU kasutamist, samuti klastris node’d kasutatavat CPU’d (soovitavad mitmeid node’d ühte kokku liita), kettade koormust ja veel paari tosinat parameetrit.

Nagu igas küsimuses, mis puudutab optimeerimist, tuleb ka Kubecosti andmete põhjal ressursside optimeerimisele läheneda ettevaatlikult. Näiteks Cluster Savings pakub node’de eemaldamist, väites, et see on ohutu, kuid ei arvestata sellega, et ein täielikult puudub node-selector’ide ja taint’idega, mida mujal node’del ei ole. Ja üldse, isegi toote autorid oma Hiljutises artiklis (muide, võib see olla üsna kasulik neile, kes projekti teemast huvituvad) soovitavad mitte viskuda pea ees kulude optimeerimisele, vaid läheneda küsimusele arvestatult.

Summary

Pärast kubecosti kasutamist kuu jooksul paaris projektis võime järeldada, et see on huvitav (ja veel lihtne õppida ja paigaldada) tööriist pilveteenuste kulude analüüsimiseks ja optimeerimiseks, mida kasutatakse Kubernetes-klastrite jaoks. Arvutused on üsna täpsed: meie katsetes olid need kooskõlas sellega, mida teenusepakkujad tegelikult nõudsid.

Puuduvad ka negatiivsed küljed: esinevad mõningad mitte kriitilised vead, funktsionaalsete võimaluste osas ei kata need mõne projekti spetsiifilisi vajadusi. Siiski, kui on vaja kiiresti aru saada, kuhu raha läheb ja mida saab "lõigata", et stabiilselt vähendada pilveteenuste arvet 5-30% (nii meie puhul juhtuski), on see suurepärane variant.

P.S.

Lugege ka meie blogist:

• «Kuberneteses automaatne skaleerimine ja ressursside haldamine (ülevaade ja ettekande video)»;
• «Kubernetesi seiklus Dailymotionis: infrastruktuuri loomine pilvedes + kohalikes serverites»;
• «Kubernetes näpunäited & trikid: sõlmede eraldamine ja veebirakenduse koormused».

Allikas: habr.com