🥇Преглед на Kubecost за спестяване на пари от Kubernetes в облаците

В момента все повече компании прехвърлят своята инфраструктура от хардуерни сървъри и собствени виртуални машини към облака. Това решение е лесно за обяснение: няма нужда да се притеснявате за хардуера, клъстерът се конфигурира лесно по много различни начини... и най-важното, съществуващите технологии (като Kubernetes) позволяват просто мащабиране на изчислителната мощност в зависимост от натоварването .

Финансовият аспект винаги е важен. Инструментът, обсъден в тази статия, е предназначен да помогне за намаляване на бюджетите при използване на облачна инфраструктура с Kubernetes.

въведение

Kubecost е калифорнийски стартъп от Google, създаващ решение за изчисляване на инфраструктурни разходи в облачни услуги (в рамките на Kubernetes клъстер + споделени ресурси), търсене на тесни места в настройките на клъстера и изпращане на подходящи известия до Slack.

Имаме клиенти с Kubernetes както в познатите облаци AWS и GCP, така и в по-редките Linux- Azure общности — основно във всички платформи, поддържани от Kubecost. За някои от тях ние сами изчисляваме разходите за услуги в клъстера (използвайки методология, подобна на тази на Kubecost), а също така следим разходите за инфраструктура и се стремим да ги оптимизираме. Така че е естествено да се заинтересуваме от възможността за автоматизиране на подобни задачи.

Изходният код на основния модул Kubecost е отворен съгласно условията на лиценза за отворен код (Apache License 2.0). Може да се използва свободно и наличните функции трябва да са достатъчни за малки проекти. Бизнесът обаче си е бизнес: останалата част от продукта е затворена, може да се използва от платени абонаменти, което предполага и търговска поддръжка. В допълнение, авторите предлагат безплатен лиценз за малки клъстери (1 клъстер с 10 възела - по време на писането на тази статия това ограничение се разшири до 20 възела) или пробен период с пълни възможности за 1 месец.

Как работи всичко

И така, основната част от Kubecost е приложението разходен модел, написано на Go. Извиква се диаграма на Helm, която описва цялата система анализатор на разходите и в основата си е сглобка от разходен модел с Прометей, Графана и няколко табла.

Най-общо казано, cost-model има собствен уеб интерфейс, който показва графики и подробна статистика за разходите в табличен вид, както и, разбира се, съвети за оптимизиране на разходите. Таблата за управление, представени в Grafana, са по-ранен етап от развитието на Kubecost и съдържат почти същите данни като модела на разходите, допълвайки ги с обичайната статистика за потреблението на CPU/памет/мрежово/дисково пространство в клъстера и неговите компоненти .

Как работи Kubecost?

Cost-model получава цени за услуги чрез API на облачни доставчици.
Освен това, в зависимост от типа желязо на възела и региона, се изчислява цената на възел.
Въз основа на разходите за работещи възли, всеки листов модул получава цена на час използване на процесора, на гигабайт консумирана памет и на час на гигабайт съхранени данни - в зависимост от възела, на който е работил, или класа на съхранение.
Въз основа на разходите за работа с отделни модули, плащането се изчислява за пространства от имена, услуги, внедрявания, StatefulSets.
Статистиката се изчислява с помощта на показатели, предоставени от kube-state-metrics и node-exporter.

Важно е да се има предвид, че Kubecost по подразбиране отчита само ресурсите, налични в Kubernetes. Външни бази данни, GitLab сървъри, S3 хранилища и други услуги, които не са в клъстера (дори ако се намират в същия облак), не са видими за него. Въпреки че за GCP и AWS можете да добавите ключовете на вашите акаунти за услуги и да изчислите всичко заедно.

Инсталация

Kubecost изисква:

Kubernetes версия 1.8 и по-нова;
kube-състояние-метрика;
Прометей;
възел-износител.

Така се случи, че в нашите клъстери всички тези условия бяха изпълнени предварително, така че се оказа, че е достатъчно просто да посочите правилната крайна точка за достъп до Prometheus. Официалната диаграма на kubecost Helm обаче съдържа всичко необходимо, за да работите на гол клъстер.

Има няколко начина за инсталиране на Kubecost:

Стандартен метод за инсталиране, описан в Directions на уебсайта на разработчика. Задължително добавете хранилището на анализатора на разходите към Helm и след това инсталирайте диаграмата. Всичко, което остава, е да препратите своя порт и да коригирате настройките до желаното състояние ръчно (чрез kubectl) и/или като използвате уеб интерфейса на модела на разходите.
Дори не сме опитвали този метод, тъй като не използваме готови конфигурации на трети страни, но изглежда като добра опция „просто опитайте сами“. Ако вече имате инсталирани някои от системните компоненти или искате повече фини настройки, по-добре е да помислите за втория път.
Използвайте по същество същата диаграма, но го конфигурирайте и инсталирайте сами по всеки удобен начин.
Както вече споменахме, в допълнение към самия kubecost, тази диаграма съдържа графики Grafana и Prometheus, които също могат да бъдат персонализирани по желание.
Наличен на графиката values.yaml за анализатор на разходите ви позволява да конфигурирате:
- списък на компонентите на анализатора на разходите, които трябва да бъдат внедрени;
- вашата крайна точка за Prometheus (ако вече имате такава);
- домейни и други входни настройки за cost-model и Grafana;
- анотации за подс;
- необходимостта от използване на постоянно хранилище и неговия размер.
Пълен списък с налични опции за конфигурация с описания е наличен в документация.
Тъй като kubecost в основната си версия не може да ограничи достъпа, ще трябва незабавно да конфигурирате basic-auth за уеб панела.
установят само ядрото на системата - разходен модел. За да направите това, трябва да имате инсталиран Prometheus в клъстера и да посочите съответната стойност на неговия адрес в променливата prometheusEndpoint за Хелм. След това - кандидатствайте набор от YAML конфигурации в клъстера.
Отново ще трябва ръчно да добавите Ingress с базово удостоверяване. И накрая, ще трябва да добавите раздел за събиране на показатели за модел на разходите 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 с набор от табла.

Крайна цена, показан на главния екран, всъщност показва прогнозната цена на ресурсите за месеца. Това проектирани цена, отразяваща разходите за използване на клъстера (на месец) при текущото ниво на потребление на ресурси.

Този показател е по-скоро за анализ на разходите и тяхното оптимизиране. Не е много удобно да гледате общите разходи за абстрактен юли в kubecost: ще трябва да направите това отидете на фактуриране. Но можете да видите разходите, разбити по пространства от имена, етикети, подове за 1/2/7/30/90 дни, които таксуването никога няма да ви покаже.

Говорейки за етикети. Трябва незабавно да отидете в настройките и да зададете имената на етикетите, които ще се използват като допълнителни категории за групиране на разходите:

Можете да закачите всякакви етикети върху тях - удобно, ако вече имате собствена система за етикетиране.

Също така там можете да промените адреса на крайната точка на API, към която се свързва разходният модел, да коригирате размера на отстъпката в GCP и да зададете свои собствени цени за ресурси и валута за тяхното измерване (по някаква причина функцията не засяга общата цена).

Kubecost може да показва различни проблеми в клъстера (и дори предупреждение в случай на опасност). За съжаление опцията не може да се конфигурира и следователно, ако имате среди за разработчици и ги използвате, постоянно ще виждате нещо подобно:

Важен инструмент - Клъстерни спестявания. Той измерва активността на pods (консумация на ресурси, включително мрежови), а също така изчислява колко пари и от какво можете да спестите.

Може да изглежда, че съветите за оптимизация са доста очевидни, но опитът показва, че все още има какво да се разгледа. По-специално се наблюдава мрежовата активност на подовете (Kubecost предлага да се обърне внимание на неактивните), сравнява се заявената и действителната консумация на памет и CPU, както и CPU, използван от клъстерни възли (предлага свиване на няколко възела в един), диск натоварване и още няколко дузини параметри.

Както при всеки проблем с оптимизацията, оптимизирането на ресурси въз основа на данни от Kubecost изисква: лекувайте с повишено внимание. Например, Cluster Savings предлага изтриване на възли, като твърди, че е безопасно, но не взема предвид наличието на селектори на възли и петна в подовете, разположени върху тях, които не са налични на други възли. И като цяло, дори авторите на продукта в техните скорошна статия (между другото, може да бъде много полезно за тези, които се интересуват от темата на проекта) се препоръчва да не се втурвате стремглаво към оптимизиране на разходите, а да подходите към въпроса внимателно.

Резултати от

След като използвахме kubecost за един месец на няколко проекта, можем да заключим, че това е интересен (а също и лесен за научаване и инсталиране) инструмент за анализиране и оптимизиране на разходите за услугите на облачните доставчици, използвани за Kubernetes клъстери. Изчисленията се оказаха много точни: в нашите експерименти те съвпаднаха с това, което действително изискваха доставчиците.

Има и някои недостатъци: има некритични грешки и на някои места функционалността не покрива нуждите, специфични за някои проекти. Въпреки това, ако трябва бързо да разберете къде отиват парите и какво може да се „отреже“, за да намалите последователно сметката за облачни услуги с 5-30% (това се случи в нашия случай), това е чудесен вариант .

PS

Прочетете също в нашия блог:

Източник: www.habr.com