Kubecost для эканоміі сродкаў на Kubernetes ў аблоках

У цяперашні час усё больш кампаній пераводзяць сваю інфраструктуру з жалезных сервераў і ўласных віртуалак у аблокі. Такое рашэнне лёгка растлумачыць: няма неабходнасці клапаціцца аб жалезе, кластар лёгка канфігуруецца мноствам розных спосабаў… а самае галоўнае – наяўныя тэхналогіі (накшталт Kubernetes) дазваляюць проста маштабаваць вылічальныя магутнасці ў залежнасці ад нагрузкі.

Заўсёды важны і фінансавы аспект. Інструмент, размова аб якім пойдзе ў гэтым артыкуле, закліканы садзейнічаць скарачэнню бюджэтаў пры выкарыстанні хмарнай інфраструктуры з Kubernetes.

Увядзенне

Кубэкост - каліфарнійскі стартап ад выхадцаў з Google, які стварае рашэнне для падліку выдаткаў на інфраструктуру ў хмарных сэрвісах (унутры кластара Kubernetes + агульныя рэсурсы), пошуку вузкіх месцаў у наладах кластара і адпраўлення адпаведных апавяшчэнняў у Slack.

У нас ёсць кліенты з Kubernetes як у звыклых аблоках AWS і GCP, так і больш рэдкім для Linux-супольнасці Azure – увогуле, на ўсіх платформах, якія падтрымліваюцца Kubecost'ам. Для некаторых з іх мы лічым выдаткі па ўнутрыкластарных сэрвісах самастойна (па методыцы, падобнай на тую, што выкарыстоўвае Kubecost), а таксама сочым за выдаткамі на інфраструктуру і імкнемся іх аптымізаваць. Таму лагічна, што нас зацікавіла магчымасць аўтаматызаваць такія задачы.

Зыходны код асноўнага модуля Kubecost адкрыты на ўмовах Open Source-ліцэнзіі (Apache License 2.0). Яго можна выкарыстоўваць свабодна, а даступных функцый павінна быць дастаткова для невялікіх праектаў. Аднак бізнэс ёсць бізнэс: астатняя частка прадукта зачынена, ёй можна скарыстацца па платным падпіскам, Якія таксама маюць на ўвазе камерцыйную падтрымку. Акрамя таго, аўтары прапануюць бясплатную ліцэнзію для невялікіх кластараў (1 кластар з 10 вузламі - за час напісання артыкула гэты ліміт пашырыўся да 20 вузлоў) або trial-перыяд з поўнымі магчымасцямі на 1 месяц.

Як усё ўладкована

Такім чынам, асноўная частка Kubecost - гэта дадатак cost-model, напісанае на Go. Helm-чарт, які апісвае ўсю сістэму цалкам, завецца cost-analyzer і па сваёй сутнасці з'яўляецца зборкай з cost-model з Prometheus, Grafana і некалькімі dashboard'амі.

Наогул кажучы, у cost-model ёсць свой вэб-інтэрфейс, які паказвае графікі і дэталёвую статыстыку па выдатках у таблічным выглядзе, а таксама, вядома, парады па аптымізацыі выдаткаў. Прадстаўленыя ж у Grafana dashboard'ы з'яўляюцца больш раннім этапам развіцця Kubecost і ўтрымоўваюць шмат у чым тыя ж дадзеныя, што і cost-model, дапаўняючы іх звыклай статыстыкай па выдатку CPU/памяці/сеткі/дыскавай прасторы ў кластары і яго складнікаў.

Як жа працуе Kubecost?

• Cost-model праз API хмарных правайдэраў атрымлівае кошты на абслугоўванне.
• Далей, у залежнасці ад жалезнага тыпу вузла і рэгіёна, лічыцца кошт па вузлах.
• На аснове кошту працы вузлоў кожны канчатковы pod атрымлівае кошт за гадзіну выкарыстання працэсара, расходавання гігабайта памяці і кошт гадзіны захоўвання гігабайта дадзеных - у залежнасці ад вузла, на якім ён працаваў, або класа сховішчы.
• Зыходзячы з кошту працы асобных pod'ов лічыцца аплата па прасторах імёнаў, сэрвісам, Deployment'ам, StatefulSet'ам.
• Для падліку статыстыкі выкарыстоўваюцца метрыкі, якія прадстаўляюцца kube-state-metrics і node-exporter.

Важна ўлічваць, што Kubecost па змаўчанні лічыць толькі рэсурсы, даступныя ў Kubernetes. Вонкавыя базы дадзеных, серверы GitLab, сховішчы S3 і іншыя сэрвісы, якія адсутнічаюць у кластары (хай і змешчаныя ў тым жа воблаку), для яго не бачныя. Хаця для GCP і AWS можна дадаць ключы сваіх сэрвіс-акаўнтаў і палічыць усё разам.

Ўстаноўка

Для функцыянавання Kubecost патрабуюцца:

• Kubernetes версіі 1.8 і вышэй;
• kube-state-metrics;
• Prometheus;
• node-exporter.

Так склалася, што ў нашых кластарах усе гэтыя ўмовы былі выкананы загадзя, таму аказалася дастатковым толькі паказаць правільны endpoint для доступу ў Prometheus. Тым не менш, афіцыйны Helm-чарт kubecost утрымоўвае ў сабе ўсё неабходнае, каб запусціцца і на голым кластары.

Усталяваць Kubecost можна некалькімі спосабамі:

1. Стандартны спосаб усталёўкі, апісаны ў інструкцыі на сайце распрацоўніка.Неабходна дадаць у Helm рэпазітар cost-analyzer, пасля чаго ўсталяваць чарт. Застанецца толькі пракінуць сабе порт і дапілаваць налады да жаданага стану ўручную (праз kubectl) і/ці з дапамогай вэб-інтэрфейсу cost-model.

   Дадзены спосаб мы нават не спрабавалі, паколькі не выкарыстоўваем іншыя гатовыя канфігурацыі, аднак ён выглядае як добры варыянт "проста паспрабаваць для сябе". Калі ж у вас ужо ўсталявана частка кампанентаў сістэмы ці вы жадаеце больш тонкай налады, лепш разгледзець другі шлях.

2. Выкарыстоўваць па сутнасці той жа чарт, але самастойна сканфігураваць і ўсталяваць яго любым зручным спосабам.

   Як ужо згадвалася, апроч уласна kubecost'а гэты чарт утрымоўвае чарты Grafana і Prometheus, якія таксама можна наладзіць па сваім жаданні.

   Наяўны ў чарце values.yaml для cost-analyzer дазваляе наладжваць:

   • спіс кампанентаў cost-analyzer, якія патрабуецца разгарнуць;
   • свой endpoint для Prometheus (калі ён у вас ужо ёсць);
   • дамены і іншыя наладкі ingress'аў для cost-model і Grafana;
   • анатацыі для pod'аў;
   • неабходнасць выкарыстання пастаянных сховішчаў і іх памер.

   Поўны спіс даступных опцый канфігуравання з апісаннем ёсць у дакументацыі.

   Паколькі kubecost у базавым варыянце не ўмее абмяжоўваць доступ, запатрабуецца адразу наладзіць basic-auth для вэба-панэлі.

3. ўсталяваць толькі ядро ​​сістэмы - cost-model. Для гэтага неабходна мець у кластары ўсталяваны Prometheus і паказаць якое адпавядае значэнне яго адрасу ў зменнай prometheusEndpoint для Helm'а. Пасля гэтага - прымяніць набор YAML-канфігурацый у кластары.

   Ізноў жа, прыйдзецца ўручную дадаць Ingress з basic-auth. І нарэшце, запатрабуецца дадаць секцыю для збору метрык cost-model у extraScrapeConfigs у канфігу Prometheus:

   - 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

Што атрымліваем?

Пры паўнавартаснай усталёўцы ў нашым распараджэнні апыняецца вэб-панэль kubecost і Grafana з наборам dashboard'ов.

Агульны кошт, Які адлюстроўваецца на галоўным экране, фактычна паказвае разліковы кошт рэсурсаў за месяц. Гэта прагназуемая цана, якая адлюстроўвае кошт выкарыстання кластара (у месяц) пры бягучым узроўні спажывання рэсурсаў.

Дадзеная метрыка - больш для аналізу выдаткаў і іх аптымізацыі. Агульныя выдаткі за абстрактны ліпень у kubecost глядзець не вельмі зручна: за гэтым давядзецца ісці ў білінг. Затое можна паглядзець выдаткі з разбіўкай па прасторах імёнаў, лэйблам, pod'ам за 1/2/7/30/90 дзён, чаго білінг вам ніколі не пакажа.

Дарэчы аб лэйблах. Варта адразу зайсці ў наладкі і выставіць назвы лэйблаў, якія будуць выкарыстоўвацца як дадатковыя катэгорыі для групоўкі затрат:

Лэйблы на іх можна павесіць любыя зручна, калі ў вас ужо існуе свая сістэма маркіроўкі.

Таксама там можна змяніць адрас API endpoint'а, да якога падключаецца cost-model, наладзіць памер скідкі ў GCP і выставіць уласныя цэны на рэсурсы і валюту для іх вымярэння (фіча чамусьці не ўплывае на Total cost).

Kubecost умее паказваць розныя праблемы ў кластары (і нават алерціць у выпадку небяспекі). Нажаль, опцыя не наладжваецца, а таму - калі ў вас ёсць асяроддзі для распрацоўнікаў і яны выкарыстоўваюцца, можна будзе стала назіраць нешта падобнае:

Важны інструмент - Cluster Savings. Ён вымярае актыўнасць pod'аў (спажыванне рэсурсаў, у тым ліку і сеткавых), а таксама лічыць, колькі грошай і на чым можна зэканоміць.

Можа здацца, што парады па аптымізацыі - даволі відавочныя, аднак вопыт падказвае, што ўсё роўна ёсць да чаго прыгледзецца. У прыватнасці, адсочваецца сеткавая актыўнасць pod'ов (Kubecost прапануе звярнуць увагу на неактыўных), параўноўваецца запытаны і рэальны выдатак памяці і CPU, а таксама CPU, які выкарыстоўваецца вузламі кластара (прапануе згарнуць некалькі вузлоў у адзін), нагрузка на дыскі і яшчэ пара дзясяткаў параметраў.

Як і ў любым пытанні, якое датычыцца аптымізацыі, да аптымізацыі рэсурсаў на аснове дадзеных Kubecost трэба ставіцца з асцярожнасцю. Напрыклад, Cluster Savings прапануе выдаліць вузлы, сцвярджаючы, што гэта бяспечна, аднак не ўлічвае наяўнасць у разгорнутых на іх pod'у node-selector'аў і taint'аў, не наяўных на астатніх вузлах. Ды і наогул, нават аўтары прадукта ў сваёй нядаўнім артыкуле (дарэчы, яна можа апынуцца вельмі карыснай тым, хто цікавіцца тэмай праекту) рэкамендуюць не кідацца з галавой у аптымізацыю выдаткаў, а падыходзіць да пытання абдумана.

Вынікі

Пасля выкарыстання kubecost на працягу месяца на пары праектаў можам скласці, што гэта цікавая (а яшчэ лёгкая ў засваенні і ўсталёўцы) прылада для аналізу і аптымізацыі выдаткаў на паслугі хмарных правайдэраў, выкарыстоўваных для Kubernetes-кластэраў. Падлікі атрымліваюцца вельмі дакладнымі: у нашых эксперыментах яны супадалі з тым, што ў рэальнасці патрабавалі правайдэры.

Не абышлося і без мінусаў: ёсць некрытычныя багі, функцыянальныя магчымасці месцамі не пакрываюць спецыфічных для некаторых праектаў запатрабаванняў. Аднак, калі трэба хутка зразумець, куды сыходзяць грошы і што можна «парэзаць», каб стабільна знізіць рахунак за хмарныя паслугі на 5-30% (так і адбылося ў нашым выпадку), - гэта выдатны варыянт.

PS

Чытайце таксама ў нашым блогу:

• «Аўтамаштабаванне і кіраванне рэсурсамі ў Kubernetes (агляд і відэа даклада)»;
• «Kubernetes-прыгода Dailymotion: стварэнне інфраструктуры ў аблоках + on-premises»;
• «Kubernetes tips & tricks: аб выдзяленні вузлоў і аб нагрузках на вэб-дадатак.

Крыніца: habr.com