Kubecosti ülevaade Kubernetes'i rahasammaste kärpimiseks pilvedes

Üha rohkem ettevõtteid viib oma infrastruktuuri füüsilistelt serveritelt ja enda virtuaalmasinatelt pilve. Selline otsus on kergesti mõistetav: pole vaja muretseda riistvara pärast, kluster on lihtsalt seadistatav mitmesugustes viisides… ja mis kõige tähtsam, olemasolevad tehnoloogiad (nt Kubernetes) võimaldavad lihtsalt skaleerida arvutusvõimsust vastavalt koormusele.

Finantsaspekt on alati oluline. Tööriist, millest selles artiklis juttu tuleb, on loodud selleks, et aidata vähendada eelarveid Kubernetes'i pilvinfrastruktuuri kasutamisel.

Sissejuhatus

Kubecost — California start-up, mille asutajad on endised Google'i töötajad, arendades lahendust, mis arvutab pilveteenuste (Kubernetes'i klastris ja ühistes ressurssides) infrastruktuurikulusid, tuvastab klastris seadistustega seotud kitsaskohti ja saadab vastavad teavitused Slacki.

Meil on kliente Kubernetes'ega nii traditsioonilistes pilvkeskkondades nagu AWS ja GCP kui ka Linuxi kogukonnas haruldasemal Azure'il — kokku kõigil platvormidel, mida Kubecost toetab. Mõnede jaoks hindame neid kulusid vahe-klooniteenustes iseseisvalt (kasutades meetodit, mis sarnaneb Kubecostiga), jälgime infrastruktuuri kulutusi ja püüdleme nende optimeerimise poole. Seetõttu on loogiline, et meid huvitas võimalus neid ülesandeid automatiseerida.

Kubecost'i põhikomponendi lähtekood on avatud Open Source litsentsi (Apache License 2.0) alusel. Seda saab vabalt kasutada ning saadaval olevate funktsioonide peaks olema piisavalt väikeste projektide jaoks. Kuid ärige on äri: toote ülejäänud osa on suletud, selle kasutamiseks on vajalik tasuline tellimus, mis hõlmab ka ärilist tuge. Lisaks pakuvad autorid tasuta litsentsi väikestele klastritele (1 klaster, kus on maksimaalselt 10 sõlme — artikli kirjutamise ajal on see piir tõusnud 20 sõlmeni) või katseaega täielike võimalustega 1 kuu jooksul.

Kuidas kõik töötab

Nii et Kubecost'i peamine osa on rakendus cost-model, kirjutatud Go keeles. Kogu süsteemi hõlmav Helm-chart on nimetatud cost-analyzer ja tegelikult on see kokku pandud cost-model‘ist koos Prometheuse, Grafana ja mitme armatuurlauaga.

Üldiselt on cost-model’il oma veebiinterfatsioon, mis kuvab diagramme ja üksikasjalikku statistikat kulude kohta tabelivormingus ning muidugi ka soovitusi kulude optimeerimiseks. Grafanas esitatud armatuurlauad on arendamise varasem etapp Kubecost’ist ja sisaldavad suures osas samu andmeid, mis cost-model, täiendades neid tuttava statistika abil CPU/mälu/võrgu/diskiruumi kasutamise kohta klastris ja selle komponentides.

Kuidas Kubecost töötab?

• Cost-model saadab API kaudu pilveteenuse pakkujatelt teenuse hinnad.
• Seejärel, sõltuvalt sõlmest ja piirkonnast, arvutatakse sõlmede kulu.
• Sõlmede töö kulude põhjal saab iga lõpp-pod tunni kulu protsessori kasutamise, gigabaidi mälu kulutamise ja gigabaidi andmete hoidmise tunni kulu — sõltuvalt sõlmest, millel see töötas, või salvestusklassist.
• Pod'ide töö maksumuse põhjal arvestatakse tasu nimede, teenuste, Deployment'ite ja StatefulSet'ide järgi.
• Statistika arvutamiseks kasutatakse kube-state-metrics'i ja node-exporter'i pakutavaid mõõdikuid.

Oluline on arvestada, et Kubecost arvestab ainult Kuberneteses saadaval olevaid ressursse. Välised andmebaasid, GitLabi serverid, S3 salvestusruumid ja muud teenused, mis puuduvad klastris (kuigi need asuvad samas pilves), ei ole sellele nähtavad. Kuid GCP ja AWS puhul saab oma teenusekonto võtmed lisada, et kõik kokku lugeda.

Installeerimine

Kubecosti toimimiseks on vajalik:

• Kubernetes versioon 1.8 või uuem;
• kube-state-metrics;
• Prometheus;
• node-exporter.

Meie klastrites olid kõik need tingimused juba varem täidetud, seega oli piisav vaid määrata õige lõpp-punkt Prometheusele ligipääsuks. Siiski sisaldab ametlik Helm-chart kubecost kõike vajalikku, et käivituda ka „palja“ klastriga.

Kubecosti saab installida mitmel erineval viisil:

1. Tavaline installimisviis, mis on kirjeldatud juhendis arendaja veebisaidil. On vajalik lisada Helm'i repositoorium cost-analyzer, pärast mida saab chart'it installida.. Jääb ainult port edasi suunata ja häälestada seaded käsitsi (kasutades kubectl) ja/või veebiliidese cost-model kaudu.

   Seda meetodit me isegi ei proovinud, kuna me ei kasuta kolmandate osapoolte valmis konfiguratsioone, kuid see näeb välja kui hea valik, et "lihtsalt proovida enda jaoks". Kui teil on juba osa süsteemi komponente installitud või soovite peenemat seadistust, on parem kaaluda teist teed.

2. Põhimõtteliselt kasutada sama charti, kuid konfigureerida ja installida see ise mugaval viisil.

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

   Chartis olemas values.yaml cost-analyzer jaoks võimaldab seadistada:

   • cost-analyzer'i komponente, mida on vaja juurutada;
   • oma Prometheuse lõpp-punkt (kui see teil juba olemas on);
   • domeenid ja muud ingress'i seaded cost-model'ile ja Grafanale;
   • pod'ide annotatsioonid;
   • vajadus püsivate ladude kasutamiseks ja nende suurus.

   Täielik saadaval olevate konfiguratsiooni valikute nimekiri koos kirjeldusega on dokumentatsioonis.

   Kuna kubecost põhiversioon ei oska piiritleda juurdepääsu, tuleb kohe seadistada basic-auth veebipaneelile.

3. Installi ainult süsteemi tuum — cost-model. Selle jaoks peab klastris olema installitud Prometheus ning vastav aadress tuleb määrata muutuja prometheusEndpoint Helm’i jaoks. Pärast seda tuleb rakendada YAML-konfiguratsioonide komplekt klastris.

   Samuti tuleb käsitsi lisada Ingress koos basic-auth. Ja lõpuks tuleb lisada sektsioon cost-modeli meetmete 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 paigaldamise korral on meil veebipaneel kubecost ja Grafana koos dashboard’ide komplektiga.

Kokkuvõttes, mis kuvatakse avalehel, näitab tegelikult ressursside kalkuleeritud maksumust kuus. See on prognoositav hind, mis näitab klastrikasutuse maksumust (kuus) praeguste ressursside tarbimise tasemete juures.

See mõõdik on rohkem mõeldud kulude analüüsimiseks ja nende optimeerimiseks. Üldised kulud abstraktsel juul kubecostis ei ole eriti mugav jälgida: selleks on vaja minna arvelduse juurde. Kuid on võimalik vaadata kulusid, jagatuna nimede, silte, podide järgi 1/2/7/30/90 päeva jooksul, mida arveldus kunagi ei näita.

Rääkides siltidest. Tuleb kohe minna seadistustesse ja määrata siltide nimed, mida kasutada kui lisakategooriaid kulude rühmitamiseks:

Neid silte saab lisada mistahes — mugav, kui teil on juba olemas oma märgistussüsteem.

Samuti saab seal muuta API endpointi aadressi, millega cost-model ühendub, seadistada GCP allahindluse suuruse ja määrata oma hinnad ressurssidele ja nende mõõtmise valuutale (sellel funktsioonil ei ole mingit mõju kogukulule).

Kubecost suudab näidata erinevaid probleeme klastris (ja isegi häirida, kui oht tekib). Kahjuks ei saa seda valikut seadistada, seetõttu — kui teil on arendajate keskkonnad ja neid kasutatakse, saate pidevalt jälgida midagi sellist:

Oluline tööriist — Cluster Savings. See mõõdab pod'ide aktiivsust (ressursikasutust, sealhulgas võrgu kasutust) ning arvutab, kui palju raha ja mille pealt kokku hoida saab.

Võib tunduda, et optimeerimise näpunäited on üsna ilmseid, kuid kogemus näitab, et ikka on, millele tähelepanu pöörata. Eelkõige jälgitakse pod'ide võrgutegevust (Kubecost soovitab pöörata tähelepanu mitteaktiivsetele), võrreldakse nõutud ja tegelikku mälukasutust ja CPU-d, samuti klastrite sõlmede kasutatud CPU-d (soovitades mitut sõlme üheks kokku liita), kettakoormust ja veel paari tosinat parameetrit.

Nagu igas küsimuses, mis puudutab optimeerimist, tuleb ka Kubecosti andmetel põhinevat ressursside optimeerimist haalida ettevaatlikult. Näiteks Cluster Savings soovitab sõlmede eemaldamist, väites, et see on ohutu, kuid ei arvestata, et nendele juurutatud pod'idel on node-selector'id ja taint'id, mida teistel sõlmedel ei ole. Ja tegelikult, isegi toote autorid oma hiljutises artiklis (üldiselt võib see osutuda väga kasulikuks neile, kes on projekti teemast huvitatud) soovitatakse mitte kiirustada kulude optimeerimisega, vaid läheneda küsimusele läbimõeldult.

Kokkuvõte

Pärast kubecost kasutamist kuu jooksul paaril projektil saame järeldada, et see on huvitav (ja ka kergesti omandatav ja installitav) tööriist pilveteenuste kulude analüüsimiseks ja optimeerimiseks, mida kasutatakse Kubernetes'ega klastrites. Arvutused osutuvad väga täpseteks: meie katsetes kattusid need sellega, mida tegelikult nõudsid teenusepakkujad.

Ei olnud ka ilma miinuseta: mõned mitte kriitilised vead, funktsionaalsete võimaluste katvus ei taha mõnes osas katta teatud projektide spetsiifilisi vajadusi. Siiski, kui on vaja kiiresti mõista, kuhu raha läheb ja mida saab "lõikuda", et stabiilselt vähendada pilveteenuste arvet 5-30% (nagu juhtus meie puhul), — on see suurepärane valik.

P.S.

Lugege ka meie blogist:

• «Automaatskalaarimine ja ressursside haldamine Kuberneteses (ülevaade ja ettekande video)»;
• «Dailymotion'i Kubernetes seiklus: infrastruktuuri loomine pilvedes + on-premises»;
• «Kubernetes'i näpunäited ja nipid: sõlmede eraldamine ja koormused veebirakendusele».

Allikas: habr.com