Pagsusuri ng Kubecost para sa pagtitipid ng pera sa Kubernetes sa mga ulap

Sa kasalukuyan, parami nang parami ang mga kumpanyang naglilipat ng kanilang imprastraktura mula sa mga server ng hardware at kanilang sariling mga virtual machine patungo sa cloud. Ang solusyon na ito ay madaling ipaliwanag: hindi na kailangang mag-alala tungkol sa hardware, ang cluster ay madaling i-configure sa maraming iba't ibang paraan... at higit sa lahat, ginagawang posible ng mga umiiral na teknolohiya (tulad ng Kubernetes) na i-scale lang ang computing power depende sa load. .

Palaging mahalaga ang aspetong pinansyal. Ang tool na tinalakay sa artikulong ito ay idinisenyo upang makatulong na bawasan ang mga badyet kapag gumagamit ng cloud infrastructure sa Kubernetes.

Pagpapakilala

Kubecost ay isang Californian startup mula sa Google, na gumagawa ng solusyon para sa pagkalkula ng mga gastos sa imprastraktura sa mga serbisyo sa cloud (sa loob ng isang Kubernetes cluster + shared resources), naghahanap ng mga bottleneck sa mga setting ng cluster at pagpapadala ng mga naaangkop na notification sa Slack.

Mayroon kaming mga kliyenteng may Kubernetes kapwa sa pamilyar na AWS at GCP cloud, at, mas bihira para sa komunidad ng Linux, Azure - sa pangkalahatan, sa lahat ng platform na sinusuportahan ng Kubecost. Para sa ilan sa kanila, kinakalkula namin mismo ang mga gastos ng mga intra-cluster na serbisyo (gamit ang isang paraan na katulad ng ginamit ng Kubecost), at sinusubaybayan din namin ang mga gastos sa imprastraktura at sinusubukang i-optimize ang mga ito. Samakatuwid, lohikal na interesado kami sa posibilidad ng pag-automate ng mga naturang gawain.

Ang source code ng pangunahing Kubecost module ay bukas sa ilalim ng mga tuntunin ng Open Source na lisensya (Apache License 2.0). Maaari itong magamit nang malaya at ang mga magagamit na tampok ay dapat sapat para sa maliliit na proyekto. Gayunpaman, negosyo ay negosyo: ang natitirang bahagi ng produkto ay sarado, maaari itong gamitin ng bayad na mga subscription, na nagpapahiwatig din ng komersyal na suporta. Bilang karagdagan, nag-aalok ang mga may-akda ng libreng lisensya para sa maliliit na cluster (1 cluster na may 10 node - habang isinusulat ang artikulong ito, lumawak ang limitasyong ito sa 20 node) o isang panahon ng pagsubok na may ganap na kakayahan sa loob ng 1 buwan.

Paano gumagana ang lahat

Kaya, ang pangunahing bahagi ng Kubecost ay ang aplikasyon modelo ng gastos, nakasulat sa Go. Ang isang Helm chart na naglalarawan sa buong sistema ay tinatawag cost-analyzer at sa kaibuturan nito ay isang assembly mula sa isang cost-model na may Prometheus, Grafana at ilang dashboard.

Sa pangkalahatan, ang cost-model ay may sariling web interface, na nagpapakita ng mga graph at detalyadong istatistika sa mga gastos sa tabular form, pati na rin, siyempre, mga tip para sa pag-optimize ng mga gastos. Ang mga dashboard na ipinakita sa Grafana ay isang mas maagang yugto sa pagbuo ng Kubecost at naglalaman ng halos kaparehong data gaya ng cost-model, na nagdaragdag sa kanila ng karaniwang mga istatistika sa pagkonsumo ng CPU/memory/network/disk space sa cluster at mga bahagi nito .

Paano gumagana ang Kubecost?

• Ang cost-model ay tumatanggap ng mga presyo para sa mga serbisyo sa pamamagitan ng API ng mga cloud provider.
• Dagdag pa, depende sa uri ng bakal ng node at sa rehiyon, ang gastos sa bawat node ay kinakalkula.
• Batay sa halaga ng pagpapatakbo ng mga node, ang bawat leaf pod ay nakakakuha ng halaga bawat oras ng paggamit ng CPU, bawat gigabyte ng memory na nakonsumo, at bawat oras bawat gigabyte ng data na nakaimbak - depende sa node kung saan ito tumatakbo o sa klase ng storage.
• Batay sa halaga ng pagpapatakbo ng mga indibidwal na pod, kinakalkula ang pagbabayad para sa mga namespace, serbisyo, Deployment, StatefulSets.
• Kinakalkula ang mga istatistika gamit ang mga sukatan na ibinigay ng kube-state-metrics at node-exporter.

Mahalagang isaalang-alang ang Kubecost na iyon bilang default, binibilang lang ang mga mapagkukunang available sa Kubernetes. Ang mga panlabas na database, GitLab server, S3 storage at iba pang serbisyo na wala sa cluster (kahit na matatagpuan sa parehong cloud) ay hindi nakikita nito. Bagama't para sa GCP at AWS maaari mong idagdag ang mga susi ng iyong mga account ng serbisyo at kalkulahin ang lahat nang magkasama.

Instalasyon

Kinakailangan ng Kubecost:

• Kubernetes bersyon 1.8 at mas mataas;
• kube-state-metrics;
• Prometheus;
• node-exporter.

Nagkataon na sa aming mga kumpol ang lahat ng mga kundisyong ito ay natugunan nang maaga, kaya ito ay naging sapat na upang tukuyin lamang ang tamang endpoint para sa pag-access sa Prometheus. Gayunpaman, ang opisyal na kubecost Helm chart ay naglalaman ng lahat ng kailangan mo para tumakbo sa isang hubad na kumpol.

Mayroong ilang mga paraan upang i-install ang Kubecost:

1. Karaniwang paraan ng pag-install na inilarawan sa tagubilin sa website ng developer. Kinakailangan idagdag ang cost-analyzer repository sa Helm, at pagkatapos ay i-install ang chart. Ang natitira na lang ay ipasa ang iyong port at i-adjust ang mga setting sa nais na estado nang manu-mano (sa pamamagitan ng kubectl) at/o gamit ang cost-model na web interface.

   Hindi pa namin nasubukan ang paraang ito, dahil hindi kami gumagamit ng mga third-party na ready-made na configuration, ngunit mukhang magandang opsyon na "subukan mo lang ito para sa iyong sarili". Kung mayroon ka nang ilan sa mga bahagi ng system na naka-install o gusto mo ng higit pang fine-tuning, mas mabuting isaalang-alang ang pangalawang landas.

2. Gamitin ang mahalagang ang parehong tsart, ngunit i-configure at i-install ito mismo sa anumang maginhawang paraan.

   Tulad ng nabanggit na, bilang karagdagan sa kubecost mismo, ang tsart na ito ay naglalaman ng mga tsart ng Grafana at Prometheus, na maaari ding i-customize ayon sa gusto.

   Available sa chart values.yaml para sa cost-analyzer ay nagbibigay-daan sa iyong i-configure ang:

   • isang listahan ng mga bahagi ng cost-analyzer na kailangang i-deploy;
   • iyong endpoint para sa Prometheus (kung mayroon ka na);
   • mga domain at iba pang setting ng pagpasok para sa cost-model at Grafana;
   • mga anotasyon para sa mga pod;
   • ang pangangailangang gumamit ng permanenteng imbakan at ang laki nito.

   Isang kumpletong listahan ng mga available na opsyon sa pagsasaayos na may mga paglalarawan ay available sa dokumentasyon.

   Dahil hindi maaaring higpitan ng kubecost sa pangunahing bersyon nito ang pag-access, kakailanganin mong i-configure kaagad ang basic-auth para sa web panel.

3. Upang mai-install ang core ng system lamang - modelo ng gastos. Upang gawin ito, dapat ay mayroon kang Prometheus na naka-install sa cluster at tukuyin ang katumbas na halaga ng address nito sa variable prometheusEndpoint para sa Helm. Pagkatapos nito - mag-apply set ng mga configuration ng YAML sa kumpol.

   Muli, kakailanganin mong manu-manong idagdag ang Ingress gamit ang basic-auth. Panghuli, kakailanganin mong magdagdag ng seksyon para sa pagkolekta ng mga sukatan ng modelo ng gastos extraScrapeConfigs sa Prometheus config:

   - 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

Ano ang makukuha natin?

Sa ganap na pag-install, nasa amin ang kubecost at Grafana web panel na may set ng mga dashboard.

Kabuuang gastos, na ipinapakita sa pangunahing screen, ay aktwal na nagpapakita ng tinantyang halaga ng mga mapagkukunan para sa buwan. Ito inaasahang presyo na sumasalamin sa gastos ng paggamit ng cluster (bawat buwan) sa kasalukuyang antas ng pagkonsumo ng mapagkukunan.

Ang sukatan na ito ay higit pa para sa pagsusuri ng mga gastos at pag-optimize ng mga ito. Hindi masyadong maginhawang tingnan ang kabuuang gastos para sa abstract na Hulyo sa kubecost: kakailanganin mo pumunta sa pagsingil. Ngunit makikita mo ang mga gastos na pinaghiwa-hiwalay ayon sa mga namespace, label, pod sa loob ng 1/2/7/30/90 na araw, na hindi kailanman ipapakita sa iyo ng pagsingil.

Speaking of mga label. Dapat kang pumunta kaagad sa mga setting at itakda ang mga pangalan ng mga label na gagamitin bilang karagdagang mga kategorya para sa mga gastos sa pagpapangkat:

Maaari kang magsabit ng anumang mga label sa mga ito - maginhawa kung mayroon ka nang sariling sistema ng pag-label.

Doon mo rin mababago ang address ng API endpoint kung saan kumokonekta ang cost-model, isaayos ang laki ng diskwento sa GCP at itakda ang sarili mong mga presyo para sa mga mapagkukunan at currency para sa pagsukat ng mga ito (sa ilang kadahilanan ay hindi nakakaapekto ang feature sa Kabuuang gastos).

Ang Kubecost ay maaaring magpakita ng iba't-ibang mga problema sa cluster (at maging alerto sa kaso ng panganib). Sa kasamaang palad, ang opsyon ay hindi mai-configure, at samakatuwid, kung mayroon kang mga kapaligiran para sa mga developer at ginagamit mo ang mga ito, palagi kang makakakita ng ganito:

Isang mahalagang kasangkapan - Cluster Savings. Sinusukat nito ang aktibidad ng mga pod (pagkonsumo ng mapagkukunan, kabilang ang mga mapagkukunan ng network), at kinakalkula din kung gaano karaming pera at kung ano ang maaari mong i-save.

Maaaring mukhang medyo halata ang mga tip sa pag-optimize, ngunit iminumungkahi ng karanasan na mayroon pa ring dapat tingnan. Sa partikular, ang aktibidad ng network ng mga pod ay sinusubaybayan (iminumungkahi ng Kubecost na bigyang pansin ang mga hindi aktibo), ang hiniling at aktwal na memorya at pagkonsumo ng CPU ay inihambing, pati na rin ang CPU na ginagamit ng mga cluster node (nagmumungkahi ng pagbagsak ng ilang mga node sa isa), disk load at ilang dosenang higit pang mga parameter.

Tulad ng anumang isyu sa pag-optimize, ang pag-optimize ng mga mapagkukunan batay sa data ng Kubecost ay nangangailangan ng: gamutin nang may pag-iingat. Halimbawa, ang Cluster Savings ay nagmumungkahi ng pagtanggal ng mga node, na sinasabing ito ay ligtas, ngunit hindi isinasaalang-alang ang pagkakaroon ng mga node-selectors at mga bahid sa mga pod na naka-deploy sa mga ito na hindi available sa iba pang mga node. At sa pangkalahatan, kahit na ang mga may-akda ng produkto sa kanilang kamakailang artikulo (sa pamamagitan ng paraan, maaari itong maging lubhang kapaki-pakinabang para sa mga interesado sa paksa ng proyekto) inirerekumenda na huwag magmadali sa pag-optimize ng gastos, ngunit lapitan ang isyu nang may pag-iisip.

Mga resulta ng

Pagkatapos gamitin ang kubecost sa loob ng isang buwan sa ilang mga proyekto, maaari nating tapusin na ito ay isang kawili-wili (at madaling matutunan at i-install) na tool para sa pagsusuri at pag-optimize ng mga gastos para sa mga serbisyo ng mga cloud provider na ginagamit para sa mga kumpol ng Kubernetes. Ang mga kalkulasyon ay naging napakatumpak: sa aming mga eksperimento ay nag-tutugma sila sa kung ano talaga ang kinakailangan ng mga provider.

Mayroon ding ilang mga downsides: may mga hindi kritikal na mga bug, at sa ilang mga lugar ang functionality ay hindi sumasaklaw sa mga pangangailangan na partikular sa ilang mga proyekto. Gayunpaman, kung kailangan mong mabilis na maunawaan kung saan pupunta ang pera at kung ano ang maaaring "maputol" upang patuloy na mabawasan ang singil para sa mga serbisyo sa cloud ng 5-30% (ito ang nangyari sa aming kaso), ito ay isang mahusay na pagpipilian .

PS

Basahin din sa aming blog:

• «Autoscaling at resource management sa Kubernetes (review at video report)";
• «Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises";
• «Mga tip at trick ng Kubernetes: tungkol sa paglalaan ng node at pag-load ng web application'.

Pinagmulan: www.habr.com